The squib problem

In J.K. Rowling’s world, a squib is someone born into a magical family who can’t perform magic themselves. For almost a decade, that’s exactly how I felt in tech.

I’d spent years at Twitter and Stripe working in partnerships, business development, and people management. I sat in engineering standups. I reviewed roadmaps. I relayed product feedback from lighthouse customers to engineering teams and debated technical trade-offs in planning meetings. Over time I developed a credible technical vocabulary and a genuine respect for the craft of building software. But I couldn’t build anything myself. I was fluent in the language of engineering without being able to speak it.

That gap always nagged at me. Not because I thought I needed to become a full-time engineer, but because the inability to build felt like a structural limitation in how I could operate. When you’re on the front lines with customers, taking in feedback about what the product should do, and you can’t translate that into even a rough prototype or a meaningful code review, you’re always one degree removed from the work that matters most.

So in May 2019, I enrolled in a full-stack software engineering bootcamp in London. Evenings and weekends, alongside a demanding day job. My goal was simple: un-squib myself.

Why a senior operator should learn to build

The decision wasn’t impulsive. I’d been thinking about it for years, and I’d watched the gap between “business people” and “technical people” cause real damage at every company I’d worked at. Misaligned priorities, lost-in-translation requirements, product decisions made without understanding what’s actually hard and what’s trivially easy. I’d been on the business side of those failures enough times to know that the divide wasn’t inevitable — it was a skills gap that could be closed.

There’s a broader argument here too. The best operators I’ve worked with have some fluency in how the product gets built. Not because they need to ship code, but because understanding the medium changes how you think about what’s possible. An architect who has never lifted a hammer designs differently from one who has. I wanted to understand the material, not just the blueprints.

I also had a more personal motivation. I’d managed engineers for years. I’d given performance reviews, set priorities, advocated for headcount, and shaped team structures. But I’d never experienced the actual work — the blank editor, the failing test, the three-hour debugging session that ends with a misplaced semicolon. I suspected that going through that experience would make me a better manager and a more honest operator. I was right.

Choosing JavaScript and a bootcamp format

I deliberately chose a bootcamp that used JavaScript as its core language. This was a strategic decision, not a default. I’d considered Python and Ruby. Python was surging in popularity with the data science and ML community, but it was primarily a back-end language. Ruby was more beginner-friendly but losing ground — I’d watched Twitter and Deliveroo migrate away from it as their systems grew more complex. JavaScript was the only language that spanned the entire stack: front-end, back-end, and increasingly mobile via React Native.

For someone with limited time who wanted maximum surface area, full-stack JavaScript was the right bet. One language, one syntax, applicable everywhere. The learning curve was steeper than Ruby, but the compounding returns were better over time.

The bootcamp format itself was deliberate too. I could have done self-paced online courses, but I knew myself well enough to know I needed structure, deadlines, and other people struggling alongside me. The program ran thirty weeks, and by the end I’d be building full-stack applications using core computer science concepts. That was the commitment.

What 160 hours of coding taught me about learning

About ten weeks and 160 hours in, I hit what Erik Trautman calls “the desert of despair” — the long plateau between early enthusiasm and actual competence. The Dunning-Kruger curve is real, and it applies to coding with brutal precision.

Here’s what I learned about the learning process itself, observations sharpened by years of watching engineers learn and grow on my teams:

Theory is no substitute for live coding. I’d spent years absorbing technical concepts through osmosis — reading docs, attending architecture reviews, listening to engineers explain their systems. None of that prepared me for staring at a blank editor. Theoretical understanding is companion learning at best. The real learning happens when your code doesn’t work and you have to figure out why. This reframed how I thought about onboarding engineers on my teams — less documentation, more pairing.

The failure rate is the feature, not the bug. Coding is not like constructing a sales pitch or running a meeting. It’s mostly binary: your code works or it doesn’t. There’s no bluffing past a failing test. Developing comfort with a high failure rate — and learning to extract signal from each failure — is the core skill. I found this oddly liberating after years in roles where ambiguity was the norm.

Practice intensity matters more than practice duration. I noticed a direct correlation between concentrated coding time and concept retention. Sixteen hours a week was my baseline, but when I pushed beyond that, the returns were disproportionate. This mirrors what I’d seen managing engineering teams: makers need long, uninterrupted blocks, not scattered hours.

Coding is like learning an instrument. Having played piano as a kid, I recognised the pattern immediately. You isolate small elements, drill them until they’re automatic, then layer in complexity. There are many Mr. Miyagi moments — wax on, wax off exercises that feel trivial but build the foundational muscle memory that everything else depends on. The repetitive strain on your coding muscle is how you develop fluency, same as scales on a keyboard.

Neat code is a thinking tool. I started treating code as an aesthetic exercise early on, and it paid off. Writing clean, well-structured code isn’t vanity — it’s a forcing function for clear thinking. Messy code reflects messy reasoning. This was something I’d always sensed when reviewing engineers’ work, but experiencing it firsthand made the principle visceral.

What it changed about how I operate

The most valuable outcome wasn’t the code I learned to write. It was how the experience reshaped my understanding of the work I was already doing.

After managing engineers for years, spending evenings wrestling with my own code gave me a fundamentally different perspective on what I was asking of my teams. I understood, in a way I hadn’t before, why context-switching kills productivity. Why “quick changes” are rarely quick. Why estimates are genuinely hard and not sandbagging. Why engineers get frustrated when requirements shift mid-sprint.

It also changed how I communicated with engineering teams. I could read a pull request and understand the shape of a change, even if I couldn’t have written it myself. I could ask better questions in architecture discussions. I could spot when a proposed solution was over-engineered or when a shortcut was going to create tech debt. Not because I became a great engineer — I didn’t — but because I understood the medium well enough to engage with it honestly.

The gap between managing builders and understanding building is one of the most under-discussed problems in tech organisations. Business leaders who’ve never written a line of code make decisions about engineering teams every day: headcount, timelines, tool choices, build-vs-buy decisions. Many of those decisions would be better if the people making them had even a basic understanding of what software development actually feels like.

The long game

Learning to code didn’t make me an engineer. It made me a better operator. It closed a gap that had limited my effectiveness for years and gave me a shared language with the people building the products I was responsible for bringing to market.

If you’re a senior operator in tech and you’ve been thinking about learning to code, my advice is simple: do it. Not to change careers, but to change your understanding. The experience of building something from nothing — even something small, even something ugly — will reshape how you think about your own work in ways you can’t predict from the outside.

The squib era is over. And the view from the other side is worth every frustrating hour in the desert of despair.

Comments