The software engineering war - Manager.dev

Thanks Weave for supporting today’s article!

One of my main struggles in the past year:

I’m expected to mentor my engineers and help them adopt AI more effectively. But I first need to get better at it myself…

This became much easier since my company integrated Weave. It gives you (and your engineers) visibility into their work process: prompt quality, one-shot success, code quality, and skills+tools usage.

So instead of a vague ‘we need to be more effective’, you can see exactly where your team can improve.

See your own data

I became a ‘co-founder & CTO’ 18 months ago. There were 2 of us - me and my childhood friend, who was the CEO.

The first month was amazing. We had a clear vision and lots of energy - I was responsible for building, and he for getting our first customers.

In the second month, the arguments started. He couldn’t understand why I was so slow in a world with LLMs. He wanted to push features into production from his phone, without reading any of the code. “If we have a bug, I’ll just tell the agents to fix it”.

I felt we’d be building a house of cards that would collapse the moment a real client used it.

The arguments turned into fights, and 7 months later we finally split up, with zero paying customers and a barely working product.

He was a builder, and I was a keeper.

It’s the same fight our whole industry is having right now.

The software engineering war

This is not a new war. For 15 years in tech, I heard the same argument again and again: “Let’s just ship it quick and dirty” vs “We need to build things properly”. It was mostly PMs vs engineers, but sometimes also PMs vs PMs and often devs vs devs.

Somewhere in 2023-4, the fight started to escalate. The builders discovered guns:

Even inside software teams there is conflict. In my team of 6, there is an even split:

On one side, you have the builders. Those are the engineers who get their dopamine hits from customers and the usage of the product they build. They won’t miss typing code by hand. A refactor without any customer impact doesn’t excite them. They’ll prefer to dogfood their product to reading technical articles.

The extreme ones are saying:

LLMs will generate 100% of code

Code is obsolete. You won’t need to read it soon

The idea is all that matters

Software engineers without product orientation are doomed

On the other side, you have the keepers. Those are the engineers who enjoy writing well-built systems, purely for the technical challenge. They hate sloppy code. Every time they work in an area, they’ll do some small refactors to make it better. They’ll always want the most technically complex task to challenge themselves.

They are the ones saying:

The models will always produce shitty results

If you won’t read the code, disaster will happen

Vibe coders will ruin their companies

There is no clear division, but every single person reading this leans a bit more toward one side.

3 weeks ago I wrote an article about the “I don’t know, Claude wrote this” pandemic. It went viral on Reddit, with a heated debate:

A popular comment mentioned an intern who dared to question why understanding the code even mattered anymore:

And of course, the replies were brutal:

I carefully wrote my take (didn’t want a wave of hate): this intern could be a great builder. Surprisingly, the OP agreed:

I want to expand a bit on that ‘balanced perspective’ part the original poster mentioned (“I hope I can guide them towards a more balanced perspective of strong engineering vs getting business results”)

It depends who you're standing next to

In politics, 90% of people lean either left or right. When you meet someone holding an ‘opposite’ view, and you start a conversation about politics, most likely you’ll both end up frustrated and angry. “How come they don’t get it??”

But what happens when you meet someone from the “same side” , but much more extreme than you? Suddenly, they might label YOU as the ‘wrong’ side, because your opinions are not extreme enough.

So your political orientation is not just about your opinions, but where they land in relation to others.

I feel the same in the builders vs keepers war. With my co-founder, I was very much a ‘keeper’. It’s probably the same for all engineers - when you talk without non-engineers, you are representing ‘the keeper’ mindset, and the importance and difficulty of creating production-ready systems.

But inside my team, I’m much closer to the builder side. I haven’t typed a line of code in a few months, and I get my dopamine from business impact and not well-written code.

That's your position in a given room. The second thing that moves is your position over time:

Re-evaluating your opinions

Like with politics, the people I respect the most are the ones who CAN change their opinion with time, and not be ashamed to admit they were wrong (which DOESN’T mean switching to the ‘other’ side)

David Heinemeier Hansson is a great...