DEV Community: Karthikeyan

Pressure is a Privilege

Karthikeyan — Mon, 31 Aug 2026 14:27:12 +0000

08.08.2026

Welcome to Karthi’s blah blah… This article is about a term called “Pressure is a Privilege.” I’ve heard this phrase used by many legends like Billie Jean King, Virat Kohli, and Novak Djokovic, and I finally understood why they say it. On 08.08.2026, I experienced the feeling of this phrase in my own life. Hey readers, come, let’s dive into that Saturday…

Before Pressure

On a chill-weather morning, my day started as usual waking up late, rushing into the bus, and somehow finishing my breakfast of that weird-looking idli. I reached the office at around 10:00 AM. The first half an hour was surprisingly smooth. The machine was running automatically, no disturbance, no drama. Of course, with the machine making all those sounds, calling it “peaceful” would be a little too much, but still, the day had started pleasantly.

And then, suddenly, a team walked in and asked us to STOP.

In Pressure

The head of the team came in with the first question: “Why is this feature still not completed? It should be running with that, right?” Then he suddenly looked at me and asked, “Why hasn’t this been done?” I just stood there like a rock — no reaction, no movement, nothing. That’s when I realized I was the only developer present from my team, which meant I had to take this responsibility on my shoulders.

The requirement was simple: if a part fails at the first station, the remaining stations should not perform the operation on that part. They should simply skip it.

Since my lead was absent, the manager asked me how much time I would need to complete it. It was around 11:00 AM, I said, “One hour for development and one hour for testing.”

Technical Handle and Struggles

By Technically it was not hard so much the station 1 should be must happen, since the data cannot be passed from station to station , we used to store the data in data base. by checking the data of before station the we can declare the station should perform or not

// Sample Draft
bool stationResult = await GetStationResult(partNumber);

if (stationResult)
{
    // Run the next task
}
else
{
    // Set station process completed and skip the tasks
}

Now the logic was correct , while running the stations , I get another bug the data of station 1 itself haven't updated in the database, its an issue of Null-coalescing operator (??), the real struggle is i want to reset all the stations and check with a new part and after checking with five cycles , I strongly believed everything was fine.

Another Stop, Another Problem, Another Pressure

After completing that, I went to have my lunch. When I came back and visited the next group of people, they stopped the machine again and started looking for a Software Developer.

They came with another question: “Why haven’t we handled MES and TRACE?”

I had absolutely no idea about MES or TRACE. In my mind, I was like, “What the hell are these, and who even needs this?”, So, I asked my senior for some help and slowly understood what they were actually talking about.

For those who are wondering what MES and Trace actually mean:

MES (Manufacturing Execution System): MES manages and records the assembly process by capturing production information such as part details, station status, process results, and production quantities.

Trace Data: Trace data records the detailed history of each assembled part, such as the part/serial number, component information, process parameters, test results, and timestamps. Basically, it helps us know exactly what happened to a part throughout the entire process.

And then I understood — if the machine was the player, MES and TRACE were the scorecard keeping track of every move.

Real Pressure

This was the real pressure I faced. I had no idea what exactly I should do or what the correct solution was to achieve this. But somehow, this pressure pushed me to think harder and come up with a promising solution. I asked my lead for 3 hours — including development and testing.

When I started the development, there were nearly 20 people standing around me and watching me. In my mind, I was like, “Why does it feel like I’m writing my exam paper with the entire class watching?”

Initially, I created a class and a global object for it. I maintained a queue structure for passing the data. I started recording the machine start time, process time, part value, and machine end time. I also started recording the gantry start and end times, so that we could calculate the cycle time in the future.

public Queue<Data> = new Queue<Data>();
public class Data{
// needed properties
}

The development was completed across all five stations. Now came the next part — I had to make sure both the database data upload and the MES/TRACE uploads were working properly.

Thank God! In the very first cycle, everything worked as expected. By the fifth cycle, everything was working fine, and the timing was also within the expected limit. And finally, the machine was running smoothly again.

What I Learnt

Just like,

decision-making is an art, handling pressure is also an art.

Pressure brings a great sense of responsibility and pushes you to think beyond what you normally would. So, when pressure comes your way, don’t try to run away from it. Face it, work through it, and let it push you forward. That’s when you truly discover what you are capable of.

Sometimes, pressure doesn’t come to break you — it comes to show you how strong you can actually be. And maybe that’s why they say, “Pressure is a Privilege.”

No Heroics, Just a Day at Work

I’m not here to talk about some heroic performance of mine. I just wanted to share that day with you — the things I faced, the pressure I went through, and how I managed to overcome it.

Anyway, that’s all for this one. Let’s meet again in the next technical blog.

Bye from Karthi’s blah blah…

Nobody Told Me Motors Needed Software Too

Karthikeyan — Sun, 05 Jul 2026 17:43:30 +0000

Life transition from margin-left : 3px to x-axis move : 3mm

Welcome to Karthi's Blah Blah. I'm going to share my experience of how a web developer who was stuck with Git, servers, and deployments moved into the “Automation” field and was surprised that “Motors need software too...?!” This article describes the transition I made in my career, where the world doesn’t care :)

What is Automation?

Automation is the art of making machines perform tasks automatically using software, sensors, motors, and controllers. Think of it as programming, but instead of updating a screen, your code controls real-world movements and actions. In simple terms, it's where software meets hardware to make factories smarter, faster, and more efficient.

Day 1 in Automation

In childhood, I used to play with a motor that I bought for my 5th standard windmill project. At that time, I didn't know that in the future I was going to work with it. While entering into automation, my first day felt like, “Wow, I'm going to work with huge machines and cutting-edge technology,” and I felt proud of myself. But when I got a laptop and saw the C# code, I was searching for where the Controller.cs file was... and then life changed.

Here they used to say Gantry, movement points, motion cards — it felt like switching to another language commentary while watching IPL. When they said PLC, my mind started thinking about...

Padding
Line-height
Color

I came from localhost:4200… and landed in a factory with 4200 wires.

Technical Struggles

Initially, It was very new for me to understand the hardware interaction with me and my C# knowledge. My C# knowledge was still useful, but the world around it had completely changed. I had a blank mindset and more questions inside me..

How I'm going to survive in this?
What are those motion card, cylinders, motors..
What we are going to do inside this large rectangular building box?

In web development, I was comfortable with MVC Architecture. Now everyone was talking about MVVM, Prism, Threads, Motion Helpers, Axis Groups, and Real-Time Communication.

As the saying goes,

You can't judge a fish by its ability to climb a tree."

The biggest surprise? - There was no browser to refresh. No F12 Developer Tools. No Console.log() to save me. When my lead says it's an error , Like every web developer, I instantly opened Visual Studio and started hunting for red squiggly lines. He looked at me, laughed, and said, ""Not that error... the motor has an error!" , On that day I have realised 'Not every error has a stack trace. Some errors have a physical address'.

The Hero's Training Montage

Every day I learned something that wasn't even mentioned in my engineering textbooks. But slowly, Rome wasn't built in a day. One thing this journey taught me is that industrial automation is much more than just writing C# code. It requires understanding how software, hardware, and real-time communication work together.

I learned the MVVM architecture and Prism framework for building WPF applications, which was very different from the MVC pattern I used in web development. I also understood the importance of Tasks, Threads, and the Dispatcher to keep the UI responsive while continuously communicating with hardware in the background.

Another major learning was the concept of Finite State Machines (FSM). Unlike web applications, machines must always follow a defined sequence of states such as Idle, Homing, Running, and Emergency Stop to ensure safe operation.

I also gained hands-on experience working with motion controllers, servo motors, sensors, cylinders, and industrial communication protocols like EtherCAT. Interacting with hardware through vendor-provided DLLs taught me how software can directly control physical devices.

Most importantly, I learned that automation isn't just about making code work—it's about making machines work safely, reliably, and continuously.

Debugging

The most important skill every developer should have is debugging. For me, it helps to identify problems quickly. But debugging becomes very difficult during asynchronous running operations because if we place a breakpoint, the whole machine freezes, which may affect the next stations too. The whole scenario of Dry Run will be like the movie “Maanaadu” — “He came... He shot... He died... The day repeats” — similarly, “The machine goes left and right and gets stuck... debugging starts and the Dry Run repeats.”

I also learned a painful truth:

In Web Development, bugs break screens.

In Automation, bugs start making sounds.

The Final Commit (For Now)

Moving from web development to automation was definitely not a simple branch switch — it felt like migrating an entire project without documentation. From fixing CSS alignment issues to controlling real machine movements, every day introduced a new challenge and a new lesson.

I still write bugs, I still debug, and I still wonder why something isn't working. The only difference is that earlier I refreshed the browser hoping it would work... now sometimes I restart the machine hoping it behaves.

The journey is still running, the learning thread is still alive, and this commit is definitely not the final version.