From PLCs to the Cloud: How Industrial Automation Shaped My Software Engineering Mindset

I took programming classes in university and dabbled in some amateur development projects, but I didn't start my professional career building web apps. I started on the factory floor, working with Programmable Logic Controllers (PLCs) and industrial automation.

In the automation world, a bug doesn't just crash an app—it can break a machine, halt production, or worse. You learn to respect constraints, timing, and memory because you have no other choice. When I eventually transitioned heavily into high-level software development, mobile apps, and IoT, I realized something surprising: the strict, unforgiving world of PLCs had quietly given me a profound intuition for software architecture.

I’ve made plenty of mistakes along the way (and I’ll share some here), but looking at modern software through an "industrial" lens has been my secret weapon. Here are a few ways the automation mindset translates to better software design.

1. The Physical Reality of Data (a needless waste)

In a PLC, memory is not infinite. You are acutely aware of the difference between a Byte, an Int16, an Int32, and a Real. Consider that the Apollo 11 mission took humanity to the moon on less than 1MB of memory. That perspective changes you. When you are moving data over industrial protocols like Modbus, you have strict limits (like 125 registers), and you have to design your payloads carefully to avoid bottlenecks.

I remember working with Siemens S7-300 PLCs in TIA Portal. If you had a User Defined Type (UDT) and carelessly added a new tag right in the middle of it, you would shift the absolute memory addresses of everything below it. Suddenly, external devices reading that memory block were pulling garbage data. You learn to respect data structures and backwards compatibility the hard way.

So, you can imagine my culture shock when I started working with modern cloud databases like Firebase Firestore. I went to create a simple counter—a number that would never exceed 100—and realized the only integer option available was an int64 (8 bytes).

To be fair, modern databases are incredibly smart; they often compress and optimize this storage internally so it doesn't take up literal gigabytes on disk. But the point is about intentionality. My PLC brain looks at an 8-byte container holding a 1-byte number and sees a needless waste of bandwidth and performance. It taught me that just because the cloud has "unlimited" capacity doesn't mean we should be careless with our data payloads. When you are transmitting data from thousands of edge IoT devices over cellular networks, every byte still counts.

2. When a Late Message is a Failed Message

In high-level programming, we talk a lot about making things run faster. In automation, we often care more about predictability and controlling how slow things are allowed to be.

If a motor receives a run command, but a remote Emergency Shutdown (ESD) input is delayed over the network, lives could be in danger. A late message in an industrial facility isn't just an inconvenience; it's a critical failure.

I don't deal with life-or-death ESDs in my current software projects, but I still carry that paranoia about network latency. Recently, I was working on a ticketing mobile app. When a new ticket is generated, a push notification needs to reach a technician in the field.

Nobody gets hurt if a mobile notification is delayed, but from a business perspective, a missed notification means an unresolved ticket, an angry client, and lost revenue. Because of my automation background, I don't just blindly trust the network. I find myself building in acknowledgments, state checks, and fallbacks—ensuring the data actually reached its destination, just like I would with a critical machine.

3. Data Integrity and the "Junior Mistake"

In automation, you quickly learn that data is a physical thing subject to electrical noise. You learn that floating-point values are imperfect, and if just one bit in a register flips due to interference, your values are compromised. You learn to scrutinize how data is represented.

But that doesn't mean I didn't make embarrassing mistakes when I moved to software.

Early on, I needed to store the accumulated run time of a machine in a SQL database. Because PLCs use specific TIME formats, I thought it made sense to store the time in SQL as a formatted string: "00:30:15".

It was a classic junior mistake. Trying to query, sort, or do math on a string in SQL is a nightmare. I was fighting the database.

I took a step back and applied my PLC mindset: How would I store this most efficiently at the bit level? The machine would never run for more than an hour at a time in this specific process. I realized I could just count the total seconds and store it as a single Int16 (e.g., 1815 seconds). It took up a fraction of the memory, and doing math on it was instantly fast. I had to learn the hard way to stop storing data based on how it looks and start storing it based on what it is.

4. When Object-Oriented Programming Finally "Clicked"

I had studied Object-Oriented Programming (OOP) in my university classes. I knew the definitions of Classes, Objects, and Inheritance. But in my early, amateur development projects—like my first real Visual Basic application—I still wrote bloated code. I would use dozens of individual, scattered tags and write blocks of code 45 lines long just to pass variables back and forth. OOP was just a theory to me; I hadn't truly internalized it.

Then, I started working heavily with PLCs.

In the automation world, we use User Defined Types (UDTs) to strictly group related data, and Function Blocks (FBs) to encapsulate logic with its own instance data. If you don't use them, your factory line becomes a dangerous, unmanageable mess.

It was on the factory floor that the concept of OOP finally "clicked." A PLC UDT is exactly a Class property structure. An FB with an instance DB is literally an encapsulated Object.

I took that strict, industrial discipline back to my software development. I refactored that early VB app, enforcing the same rigorous structure I used for factory machines. That system is still running today. It's been 10 years, it hasn't needed any major upgrades, the client is incredibly happy, and they still hire me for new solutions. Automation took OOP from a theoretical classroom concept and turned it into an intuitive engineering tool.

5. Systems Architecture: Microservices on the Factory Floor

In industrial automation, your code rarely exists in isolation. Your machine is almost always part of a larger, interconnected process. You have to constantly ask: If I change this, what upstream or downstream system will I break?

I once worked on a packaging machine for wheat flour that produced 1lb packages. Upstream, the hopper feeding my machine was controlled by an old Micrologix 1100 with no ethernet communication. The only way we knew if there was product to package was via a single sensor near the servomotor screw. Because of this blind spot, the machine would sometimes run empty, wasting packaging material. When we finally upgraded to a network-connected S7-1200, we could pull data directly from the main PLC, know exactly what the upstream system was doing, and drastically improve material usage.

Downstream, my 1lb packages fed into a final packing machine that grouped 25 of them into a large delivery sack. The catch? Two of my 1lb machines were feeding into one of these final sackers. If our speeds weren't perfectly coordinated, the final machine would jam. Initially, we had to use hardwired routing to sync them up, until we eventually upgraded the downstream machine to use Profinet for precise coordination.

This ingrained a deep "Systems Architecture" mindset in me. Today, when I build software, this translates perfectly to designing Microservices. Even before the kickoff of a software project, my PLC brain is already mapping out the dependencies. How can I build this module so it keeps working even if another service fails? If this service produces data too quickly, will it jam the database downstream?

We have unit tests in software to make our lives easier, but the true defense against cascading failures is architectural thinking—and there is no better teacher for that than a jammed packaging line.

Final Thoughts: Ready for the Future

Moving from the rigid constraints of industrial automation to the flexible, seemingly limitless world of cloud software is a strange journey. You find yourself obsessing over byte sizes and network latency in a world that often tells you not to worry about it.

But as the Internet of Things (IoT) grows, and the cloud has to interface more and more with physical edge devices, that constraint-driven mindset becomes a superpower.

I don't have it all figured out. I've made plenty of mistakes, and I'll make plenty more. But if there is one thing this career transition has taught me, it’s this:

"I'm not going to stop learning until the day I die."

If you are coming from an unconventional background, trust the engineering intuition you've built. The syntax might change, but the fundamentals of good design never do.