From Field Technician to Full-Stack Developer

People ask how I moved from installing networks to building software, usually expecting a story about a decisive career break. There wasn't one. It was incremental, and most of it happened on evenings and weekends.

The starting point

My first roles were hands-on: parcel operations, then Windows deployment and IT support, then fibre and wireless installation. Practical work with visible results — a link that didn't work now works.

What I didn't appreciate at the time was that I was accumulating something useful. I was learning how systems fail in the real world, which is knowledge you cannot get from a tutorial.

The first step was small and specific

Not "learn to code" — that goal is so large it's paralysing. Instead: automate one annoying part of my actual job.

For me it was a repetitive configuration task. I wrote a script that was genuinely bad. It worked maybe 70% of the time. But it was mine, and fixing it taught me more than any course had.

The lesson: pick a real problem, accept an ugly first version, and let the fixing teach you.

What the field work actually gave me

The transition felt like starting over. It wasn't. Three things carried directly across:

Debugging temperament. Field work teaches you to form a hypothesis and test it cheaply before committing to an expensive action. That's the same loop as debugging software, just with higher stakes and worse weather.

Systems thinking. You can't configure a router in isolation — you have to consider what's upstream, what's downstream, and what breaks when this piece changes. That's architecture.

Explaining to non-experts. I spent years explaining connectivity problems to people who didn't care about the mechanism, only the outcome. That's exactly the skill for writing documentation and reviewing interfaces.

What I had to build from scratch

Being honest about the gaps matters more than the encouraging part:

• Patience with abstraction. I was used to seeing the whole system. Learning to work inside someone else's abstraction — and trust it until proven otherwise — took real adjustment.
• Reading other people's code. Far harder than writing your own, and unavoidable.
• Design. I could make things work long before I could make them clear. That gap closed by studying work I admired and copying it deliberately.

The part that actually mattered

Consistency. Not intensity — consistency. An hour most evenings for a couple of years beats a heroic month every time, because the compounding is in the reps.

If you're in a hands-on role and want to move toward building software: you're not starting from zero. You're starting from a position most developers would pay for. You just have to notice what you already know.