What's with all the socks?

LeadDev LDX3 and two days of watching software engineering refuse to look up

Several years ago me & my family went on a short break to York. In between visiting Rowntrees (for chocolate), Jorvik (for smells?), and the Shambles we squeezed in a trip to a museum. One of the exhibits showcased kitchens through the ages. I do like a good kitchen, so I bribed my kids with chocolate to come and have a look. We started with a Victorian one, then a 1940s one (lots of lime green), and then, we turned a corner, and we were in my parents’ kitchen from the 1980s.

Oh my. Had I really reached the point in life where my childhood was now preserved in museums?

Now it obviously wasn’t my parents’ actual kitchen - that went on a one-stop trip to a recycling centre many years ago. But this museum kitchen had the same tan cupboard doors. Same brown worktop. Same red tiles. Same Russell Hobbs kettle. Admittedly the hopeless spice rack where all the bottles fell out whenever you went near it had gone missing. In truth, not really a loss…

Last week I was on a train passing through York and I found myself remembering our trip - was the kitchen still there? Or had the museum, like my parents, decided to part ways with it?

LDX3

The train was taking me to the LeadDev LDX3 conference in London (thanks Qing for the ticket!) It’s been several decades since I was last at a conference like this. And it was interesting noticing how things have changed. Perhaps the biggest change is how software has settled on a common language. Everyone knows what a junior/senior/principal/staff engineer is. Or a PR. Or a sprint. PM and Eng are standard terms.

Thirty years ago things were much less mature - the industry didn’t have standard terminology. People weren’t siloed. You’d get a funny look if you told someone you were a professional product manager. Agile was decades away. We didn’t refactor code; we fixed it.

It took many years but, slowly, the software industry worked out how best to build software. Terms, roles, processes - they all became standardized. And that standardization was based around humans doing the work.

Unsurprisingly, many of the talks referenced this world - people talking about how to optimize working practices across distributed teams. Or how to spot when a competitor might be about to enter your market. Or develop team agreements for working with AI.

But it wasn’t just talks. There was a hall full of stands of companies promoting their wares - and offering swag. Pens, stickers, the occasional plushie. And socks. So many, many socks. Obviously branded socks are what cool people aspire to. Me? I preferred the couple of stands who offered chocolate. My kids will thank me for bringing back chocolate; socks just don’t cut the mustard…

All these companies talked enthusiastically about AI - most of them were small-ish companies offering custom software development tools. AI powered code-review. Deterministic test harnesses. Outage detection and management. Lots of specialist niches.

There were good ideas a-plenty. But they hold tenuous niches; I reckon it’s probably cheaper to steal their idea and get Claude & Codex to implement it rather than integrate their tool with our workflow. That was a sobering realisation.

I joined a couple of workshops. One was about team agreements for AI adoption. There was a passionate discussion about how to train engineers; the managers I was with seemed to care deeply about their people. But the discussion rather missed the point. Things are moving so fast that traditional top-down training doesn’t work - by the time you’ve learnt good practice, the state of the art has moved on. Instead, I reckon we need to learn the meta skill of curiosity and a desire to learn - and then use that to try to cling onto the frontier. Someone asked me how you teach that skill; I replied I wished I knew.

Mixed in was a discussion about token costs. Microsoft’s recent about-turn on Claude Code seems to be playing out in many companies - people are spotting they are spending $$$ but getting little ROI (there’s a story doing the rounds of a company getting a unpleasant shock when they discovered their engineers had spent $500 million on tokens…). Some are cutting AI budgets. Others are turning to spying on their staff - I found myself shifting uncomfortably as one manager enthusiastically described the spyware they’d installed to track AI usage. Others got excited, and wanted more details. I winced; isn’t it obvious this is a terrible idea? Spying on your team is not the way to drive adoption. And skimping on spending on tokens? That feels like an unforced error.

A different workshop described a framework for spotting threats to your business from new startups - and strategies for killing those startups. But it seemed firmly grounded in the old world - the assumption was your competitor might only be a little bit more efficient than you. The premise was to find a way to force the startup to burn through investor cash until they failed. It was a proven model. In the past.

But now? If your competition is a one person AI powered company, does that work? The competition has minimal costs - way, way lower than yours. They may not need external funding. Can legacy companies win against that?

As I chatted I realised there were relatively few of us grey tops around. People old enough to remember the fall of Digital. And Sun. And SGI. And all the rest. People who’ve never known anything other than the stable world of juniors/seniors/PRs/PM. People who don’t know anything about the turbulent history of the software world. People who thought they were getting into a safe, well paying job for life. I talked to parents who worried about the future for their children. People who had stopped signing their kids up for coding camps because they doubted coding was a useful skill. I hadn’t thought of that. I used to run a CodeClub at my kids primary school; I felt a pang - had I been teaching an irrelevant skill?

A lovely person at the O’Reilly stand gave me a demo of their book search platform. Unfortunately the main search was slow. And the AI powered insights search didn’t work. They effortlessly glossed over the failures; I felt sure they’d seen them before. Their pitch to justify the $500 annual fee? The books don’t hallucinate. But Claude & Codex are excellent at mining the official docs. I’d rather use Claude or Codex to get info from, say, the AWS docs than read an outdated book about it.

Towards the end of the conference I found myself sitting in the audience for the main stage. As I waited a video advert started playing on the main screen. It was an advert for a learn-to-code training course. I pinched myself - had I travelled back in time?

People told me about their team structures. They were invariably old-world. Eng:PM ratios of 10:1. Teams that still had dedicated designers. Leaders - the ones who can drive change - choosing not to prioritize the essential thinking that needs doing right now. Instead seemingly choosing to fiddle with the day-to-day while the world outside shifts. Are they choosing failure under the pretext of being too busy to engage?

The final talk proposed best practices for distributed teams. In the old world. There was an example of optimising a design review with 10 participants. How to stop professional-meeting-attenders from attending meetings that had nothing to do with them. The presenter had an engaging sing-song voice - it was hard not to listen.

But the talk missed the point. It was about optimising the old world. In the new world things move much faster and are much leaner. Design reviews don’t need ten people. Ten agents maybe. But not people.

Take an example. Last Friday we discussed adding SaaS support to our product. Claude, Codex and I designed it on Saturday. On Sunday we did the initial spikes to confirm our assumptions. And this week it is being implemented. I’m confident quality didn’t suffer; the design is better than any of the SaaS designs I saw back in the human world. Truth be told, in the world of designs, it’s really rather sexy. And humans involved? Just the one.

And so?

But underneath it was easy to feel - and hear - the unease within people. The people who had spotted it was all over for juniors. No one was hiring. Anyone who’d been paying attention knew a storm was coming. But no one seemed to know how to prepare. Folk weren’t running. Instead they seemed paralyzed.

If you know me, you’ll know that I think the future lies with small, multi-discipline teams. PM, engineering, support will cease to exist as separate disciplines and merge into one. The unit of work will be a feature, not a PR. Codebases will auto review, auto test, auto refactor. Terms, roles, processes - they all need to be rethought and redefined.

I am undoubtedly wrong. But also partly right. Having an opinion means I have a plan for how to try to survive.

But this picture for the future - any picture for the future - was lacking at the conference. Where were the people painting a vision of what software engineering will look like at LeadDev 2027? What skills people will need? What will teams look like? What do you need to do to your org now to survive?

Maybe it’s just too horrific to contemplate. Maybe sticking your head in the sand is the right decision. Maybe I’ll come to appreciate the lifetime’s supply of socks I’ve acquired. I don’t know.

Seeing my parents’ old kitchen in a museum gave me an awful shock of having travelled back in time. And I felt that same feeling over and over during the past few days. I couldn’t help but feel I was witnessing the end of an era.