I used to fix the machines. Now I write the software that watches them.

There’s a line on my LinkedIn profile I wrote almost as a joke:

I build software for predictive maintenance, and before that, I maintained the machines.

It reads like a tidy piece of personal branding. It isn’t. It’s the shortest true summary I have of the thirteen years I spent in overalls and the six I’ve spent at a keyboard. It’s also the reason I picked the company I work for over the other offer on the table.

This is the long version. Not the LinkedIn one, where somebody quits a stable job, discovers grit, and everything resolves in three paragraphs with a photo of a laptop on a beach. The one with the numbers in it. The mortgage. The two-year-old. The second child who was on the way while I was earning nothing. The year of working an eight-hour shift and then sitting in a classroom until nine at night. The rejections, including the rejections for unpaid internships.

I’m writing it because people message me about it constantly, and because the honest accounting is more useful than the inspirational one. The jump was worth it. It was also the hardest three years of my life, and most of that weight didn’t land on me.

Thirteen years of other people’s emergencies

I started at seventeen. Corrective maintenance on industrial machinery, preventive maintenance, installations, shifts, call-outs.

If you’ve never done that job, the thing to understand is that corrective maintenance is defined by other people’s worst days. A line stops. Production stops with it. Every minute the machine is down, money burns, and somebody whose bonus depends on it is standing behind you while you work. You don’t get to think about it for a day. You form a hypothesis, you test the cheapest one first, you keep the machine in a state you can back out of, and you do all of that while someone asks how long.

Hold onto that description. It comes back later, and it’s the most valuable thing I own professionally.

Nobody walks out of a job like that on a Tuesday because of one bad afternoon. There was no moment. It was erosion: the shifts, the call-outs, the breakdown that lands ten minutes before your shift ends and belongs to you now. And the part that wears through fastest, faster than the hours: contempt from the people above you.

I’m not going to turn anyone into a villain to make this story land, so I’ll keep it short and general: by the middle of 2019 the way I was being managed had stopped being something I could absorb, and no amount of liking the actual work made up for it. That’s as much as anybody needs from me, and it’s as much as I’m going to say.

That’s the real trigger. Not a vision. Not a calling. I was burned out and I was being treated badly, and I decided I’d rather be poor and terrified than stay.

The arithmetic of quitting

At the end of August 2019, I resigned.

Do the arithmetic before you admire the decision:

• Just past thirty.
• Married.
• A mortgage.
• A two-year-old daughter.
• A son on the way.
• No degree in computer science, no bootcamp behind me, no code written.
• Household income: my wife’s salary. That’s it.

My wife and her family backed the decision completely. My own family’s advice was simpler and, honestly, more defensible on paper: just change jobs. Find another plant. A lot of people didn’t believe I’d finish, and I don’t hold it against a single one of them. From the outside, a thirty-something maintenance technician with one child and another on the way announcing he’s going to become a software developer isn’t a plan. It’s a phase people go through.

The only reason it wasn’t is that somebody else agreed to carry the cost. I’ll come back to that, because it’s the part most of these articles quietly omit.

What that year actually looked like

I did not sit at home and study. I couldn’t afford to.

I found work dismantling aircraft at Castellón airport, 7:00 to 15:00. Then:

• 15:30 to 21:00: classroom. A vocational degree in web application development at a training centre in the area, in person, every weekday. (In person, that is, until COVID moved a few months onto a screen.)
• After that: an English academy, working toward the Cambridge B1. I passed it in November 2020.
• In parallel, for a stretch: preparing for my A2 motorcycle licence, because apparently I had decided that year needed to be worse.

Read that schedule again and try to find the family in it. There isn’t one. That’s the part I want on the record, because it’s the part that gets sanded off every time this story is told as a triumph.

The romantic version of a career change is late nights, headphones on, a beautifully themed editor. The real one is walking into a classroom at half past three having spent eight hours taking an aircraft apart, and staying awake through it. Then doing it again. For months.

And the cost wasn’t mine to pay alone. My wife held the household together: a toddler, a newborn, and a husband who was physically present for maybe two hours of any given weekday. The hardest thing about that year wasn’t the tiredness; it was the time with my kids I didn’t get and can’t go back for.

So when people ask me what a career change takes, I don’t start with discipline. I start with this: the people around you are going to pay for a large part of it. Make sure they’ve genuinely agreed, not just nodded. If they haven’t, don’t start yet.

A year to the first euro

The first money code ever earned me was a small website for a friend, about a year after I began.

That’s my honest number for the length of the unpaid stretch: roughly a year to the first euro, and about two more years after landing a full-time role before I was earning what I’d earned in the plant. Three years, give or take, from resignation to break-even.

Anyone who tells you six months is selling something.

The rejections nobody puts in the thread

My vocational programme included an internship. I did mine at a small company working with an insurer: C#, Blazor, JavaScript, improving the tooling around their processes. Real work, real codebase, and genuinely the first time I felt like a developer rather than a student.

While I was there, I applied to remote positions. Sat the technical tests. I was rejected by every single one.

I also applied for other internships. I was rejected for those too.

Let me say that again plainly, because it’s the sentence I most want someone in the middle of this to read: I was rejected for positions that paid nothing.

None of that meant the plan was wrong. It meant the market’s first filter isn’t skill; it’s legibility. A CV reading thirteen years electromechanical technician, one year of web development is not legible to a recruiter scanning for the fifth React developer of the afternoon. It looks like a mistake in the file. Getting through that filter isn’t about being good yet; it’s about surviving long enough for someone to actually read the thing.

Eventually two companies said yes at the same time, and I got the strangest luxury of that whole period: a choice.

Choosing the company on the other side of my old problem

I chose I-care. The other offer was perfectly good. I picked this one because the entire business exists to predict the failures I spent thirteen years responding to.

For thirteen years I was the person who showed up after the machine stopped. Now I build the software meant to make sure nobody has to. Same world, opposite end of the timeline. That symmetry mattered to me far more than any technical detail of either offer, and five years later it still does. It’s a lot easier to care about software when you’ve personally been the guy standing in front of the stopped line.

Here’s where I have to disappoint the neat version of this story, though.

That doesn’t make me a domain expert. I don’t understand vibration analysis. That’s a serious discipline with people who’ve spent their careers in it, and I’m not one of them. My job was to repair machines, maintain them, install them. What I brought wasn’t the physics of failure prediction; it was having stood next to the consequences.

I’m spelling that out because career-change stories love to claim a transfer of expertise that never happened. Mine didn’t. Something else transferred instead, and it turned out to be worth more.

What actually transferred

Four things. None of them are what people expect.

1. Thirteen years of knowing how a workplace works

The first thing had nothing to do with machines. I’d spent thirteen years in a demanding professional environment before I wrote a line of code: showing up, dealing with difficult people, being accountable for something expensive, handling a bad day without it becoming everyone’s problem.

A surprising amount of a junior developer’s first year has nothing to do with programming. It’s learning how to work. I’d already done that, and I was doing it while some of my peers were still at school. That gap is invisible on a CV and enormous in practice.

2. A properly calibrated sense of pressure

“The build is broken and the demo is in an hour” is a genuine problem. I take it seriously.

It is not a production line stopped, with a plant manager over your shoulder, at two in the morning, with the cost of the outage visibly climbing.

I’m not braver than my colleagues. My scale is just calibrated somewhere else. When something goes wrong in production, the adrenaline that makes other people tighten up doesn’t do that to me; it’s a familiar feeling attached to a familiar procedure. That’s not a personality trait. It’s thirteen years of exposure therapy I didn’t choose.

3. A bias toward action

This is the one I’d put above all the others, and it’s the one I’d tell any career-changer from a hands-on trade to lean on hard.

Software culture is very good at deliberating. There’s a thread, a sync, a document weighing the options, and most of the time that’s exactly right, because most software decisions genuinely benefit from being thought about slowly. But when something is actually broken, my instinct pulls the other way: I’ll have already reproduced it and isolated it while I’m still reading the thread. That isn’t a virtue I cultivated. Maintenance teaches it to you in your first month, because there the discussion has a price and the price is measured in money per minute.

Be careful with this, though, because it’s easy to hear it wrong. Acting is not thrashing, and it isn’t cowboy work. Corrective maintenance is structured diagnosis under time pressure:

1. Form a hypothesis about what failed.
2. Test the cheapest one first.
3. Keep the system in a state you can back out of.
4. Don’t touch three things at once, or you’ll never know which one mattered.

Read that list again. That’s debugging. It’s the exact same loop, with a different kind of machine on the bench. Nobody at a keyboard taught me it. A factory did, ten years before I knew it was a transferable skill.

4. Resilience, which is a boring word for a real thing

By the time a hard sprint shows up, I’ve already lived through that year. The bar for “this is difficult” is somewhere far away. That’s not toughness for its own sake; it just means I don’t spend energy on being demoralised, and that energy goes somewhere useful.

Leading eleven people, five years in

I’m a Frontend Tech Lead now, responsible for a team of eleven engineers building software used by some very large companies.

People assume that jump (junior to lead in five years) is mostly about getting good at code. Part of it is; you don’t get to lead engineers who don’t respect your technical judgement. But the part nobody guesses is that I’d already run a shift in an ink factory before I ever wrote a line of JavaScript. Coordinating people who are tired, under pressure, and don’t all agree with you wasn’t a new challenge in 2024. It was an ordinary Tuesday in 2012.

I won’t pretend I’m serene about it. I lose my patience sometimes, and I’m not going to write a paragraph claiming otherwise. But I like organising things and I like watching people get better at their work, and it turns out most of leadership is those two things applied consistently, for a long time, without dropping them the week everything is on fire.

If you’re the one doing the arithmetic right now

Every few weeks someone messages me some version of: I’m thirty-eight, I’ve been doing X for fifteen years, is it too late?

My answer hasn’t changed: if not now, when? You lose nothing by trying. That isn’t a slogan, it’s arithmetic: the alternative is arriving at fifty in the same job, with the same question, and fewer years to spend on the answer.

But I’d be doing you a disservice if I stopped at the encouraging part. You already have my numbers: a year before code paid me anything, three before I matched what the plant paid me, and a run of rejections in between that included jobs paying nothing at all. Sit with those before you resign, and decide with the person who will be carrying the other half of them.

Then there’s the condition nobody warns you about, and it’s the one that makes me genuinely angry on people’s behalf.

Stop treating your old career as dead weight. They hide the fifteen years. They apologise for them in interviews. Those years are the only thing on your CV that the twenty-two-year-old competing with you doesn’t have. You know how to work under real pressure, how to be accountable for expensive things, how to act when something is broken. The industry is full of people who can write clean code and freeze when the line goes down.

Don’t apologise for the machines. They’re the reason you’re good at this.

---

I build software for predictive maintenance. Before that, I maintained the machines.

Thirteen years I once assumed I’d have to leave at the door turned out to be the part of my CV I’d give up last. The plant never disappeared. It just stopped being the job.