People find it strange when I tell them I learned software engineering on a factory floor. Not in a bootcamp. Not in a computer science lecture hall. Between schiffli machines and rolls of lace fabric, surrounded by the hum of industrial looms and the smell of chemical dyes.
My family runs Paras Lace. We manufacture lace -- the kind used in garments, curtains, table covers, and decorative textiles. It is a real, physical business with inventory you can touch, machines that break down, and customers who call at 7am asking where their order is.
Growing up in this business is the single most important thing that shaped me as an engineer. More important than any tutorial, any framework, any programming language. And I think the tech industry fundamentally misunderstands why.
The Factory as a Classroom
When you grow up around a manufacturing operation, you see systems everywhere. Not software systems -- real ones. Raw materials come in. They go through a sequence of transformations. They become finished products. They get packaged, invoiced, and shipped. At every stage, something can go wrong.
Thread breaks. Machines jam. A chemical batch arrives with slightly different viscosity than the last one, and suddenly your lace patterns look different. A customer changes their order after production has already started. The truck meant to deliver 500 rolls shows up with 480 because 20 got damaged in transit.
These are not abstract engineering problems. They are daily realities. And handling them teaches you something that most software engineers never learn: systems fail in predictable ways, and the best engineering is not about preventing failure but about recovering from it gracefully.
Every error handling pattern I write in code, every retry mechanism, every circuit breaker -- the mental model comes from watching physical systems degrade and recover. A machine does not crash like software crashes. It slows down, produces lower quality output, makes strange noises, and eventually stops. The operator who catches the early warning signs saves hours of downtime. That is monitoring and alerting, learned on a factory floor.
Seeing the Waste
The thing that pushed me to learn programming was waste. Not material waste -- time waste. I would watch our accountant spend three hours creating invoices by hand. I would watch our warehouse manager walk through the factory counting rolls of fabric with a clipboard. I would watch my father take phone calls from customers asking for order updates, then physically walk to the production floor to check the status, then walk back to call the customer.
Every one of those activities screamed automation. Not because I knew what automation was -- I was a teenager -- but because even at that age, the inefficiency was so obvious it was almost painful to watch. Why is a human being doing a task that is the same every single time?
My first "software project" was an Excel spreadsheet. I taught myself basic Excel formulas to create an inventory tracker. Columns for product name, quantity, reorder point. A formula that highlighted rows in red when stock dropped below the threshold. It took me a weekend. It replaced a paper notebook that had been used for years.
That was the moment I understood what software is for. Not to build cool things. Not to impress other engineers. To eliminate waste. To take a process that consumes human time and attention and make it automatic, accurate, and instant.
The Training Arc
If you are a Dragon Ball fan (and I am, unapologetically), you know the concept of the training arc. A character faces a challenge they cannot beat, retreats, trains intensely in isolation, and returns stronger. My path into serious software development followed exactly this pattern.
The Excel spreadsheet worked for a year. Then it didn't. Our business grew, the spreadsheet became unwieldy, multiple people needed access simultaneously, and data started getting corrupted because two people would edit the same file. I hit the limit of what a spreadsheet could do.
So I retreated into learning. YouTube tutorials on HTML and CSS. Then JavaScript. Then Node.js because I needed a backend. Then PostgreSQL because data needed to live somewhere real. Then React because the frontend needed to be interactive. Then Docker because deploying on a VPS was painful without containers.
Each technology I learned was motivated by a specific problem in the family business. I did not learn PostgreSQL because a course told me to -- I learned it because our inventory data needed proper relationships (a product belongs to a category, a category has a price tier, a price tier applies to specific customers). I did not learn Docker because it was trendy -- I learned it because deploying a Node app on Ubuntu and keeping it running through server reboots was driving me insane.
When you learn technology to solve a problem you personally care about, the knowledge sticks differently. It is not abstract. Every concept maps to a real-world outcome you can see and measure.
Why Domain Expertise Matters More Than CS Degrees
Here is the controversial take: I am a better engineer than most CS graduates I meet. Not because I am smarter or more talented. Because I understand something they do not: the business domain.
A CS graduate building an ERP system for a textile factory will ask "what are the database tables?" I ask "what happens when a customer's order is partially ready? Do we ship the partial order or wait? What does the invoice look like for a partial shipment? Does the customer's credit limit apply to the full order or just the shipped portion?" These are not technical questions. They are business questions that determine the correct technical implementation.
Most software projects fail not because the code is bad but because the engineers did not understand the problem deeply enough. They build what the spec says instead of what the business needs. And the gap between those two things is where all the bugs, rework, and frustrated users live.
Growing up in the textile business gave me a permanent advantage: I know what it feels like to be the user. I have been the person manually reconciling inventory counts because the software did not handle partial shipments. I have been the person on the phone with an angry customer because the order tracking system showed "shipped" when the order was actually still in production. That visceral understanding of user pain drives every design decision I make.
The Leap
There was no single moment where I went from "family business IT guy" to "AI automation architect." It was a gradual escalation. The inventory system led to an invoicing system. The invoicing system led to a full ERP. The ERP needed automation, which led me to n8n and workflow builders. The automation needed AI capabilities, which led me to LLMs and agents. The agents needed infrastructure, which led me to MCP servers and multi-model orchestration.
Each step was driven by the same question: what is the next bottleneck? What is the next thing that is wasting human time unnecessarily?
By the time I had configured and integrated 14 MCP servers into my workflow, built a production ERP, shipped several SaaS platforms, and created custom AI tooling like the Contract Validator MCP, I realized I had accidentally become the kind of engineer that companies pay good money for. Not because I set out to build a career, but because I set out to solve problems and the problems kept getting bigger.
Advice for Non-Traditional Paths
If you are reading this and you are not a CS graduate -- if you come from a different industry, a different background, a family business, a trade, anything -- here is what I want you to know:
Your domain expertise is your unfair advantage. The tech industry is full of people who can write code. It is desperately short of people who can write code AND understand a real business domain deeply. If you know manufacturing, healthcare, logistics, agriculture, retail -- any field with messy real-world operations -- you have something that a pure software engineer cannot fake.
Learn by building for yourself. Do not start with toy projects or tutorial clones. Find a real problem in your own work or business and build a solution. The motivation will sustain you through the hard parts that tutorials cannot prepare you for -- deployment, debugging production issues, handling edge cases, dealing with real users who use your software in ways you never imagined.
Do not apologize for your background. I used to feel self-conscious about not having a CS degree. Now I lead with it. "I grew up on a factory floor" is a more interesting and more relevant qualification for building business software than "I graduated from IIT." Both are valid. But one comes with a lifetime of domain knowledge that the other has to acquire separately.
The training arc never ends. I am still learning. Every week. Rust for performance-critical services. Security research with Frida and Ghidra. New LLM capabilities and patterns. The technology changes constantly, and the only way to stay relevant is to stay hungry. The factory taught me that too -- if you stop improving your process, your competitors will eat you alive.
The lace machines are still running at Paras Lace. The chemical dyes still arrive in drums that need to be stored carefully. Customers still call at 7am. But now they get instant order status updates from a WhatsApp bot. The inventory counts itself. The invoices generate automatically. And I am somewhere between the factory floor and the terminal, building the next thing that makes the whole operation a little bit smoother.
That is the path. It is unconventional. It is messy. And it works.