So I want to move fast. But how?
Imagine two cars.
One car is very fast, has great steering too, rapid acceleration. But the driver is hesitant, always checking the rearview mirror, and on every road crossing he stops to check if there are any cars coming and consults with the GPS.
The other car is literally a 1980s Corolla with 4th gear not even working anymore, but the driver is very confident and ready to react to any situation in a fraction of a second.
Which one do you think will get to the destination faster?
This metaphor is kinda how I am currently thinking about management and leadership in software development.
2010s
In the early 2010s, the fastest growing programming languages were Ruby and Python. Both languages were designed to optimize one specific metric – the number of lines of code. The idea was that the less code you have to write, the faster you can move, while also having better DevEx.
And it seems logical, right? You are faster if you have to write less code. It also should be easier to read a pull request with fewer lines of code. And if you have powerful features in the language that allow you to do anything and create very flexible and reusable components, that should definitely help. Sounds great.
Except, was it ever a bottleneck?
When I am writing code, I’m sitting and thinking about the design 99% of the time and only 1% of the time I’m actually typing. When I am reviewing code, I’m also spending 90% of the time trying to figure out if the PR is doing what it was supposed to do, and only 10% of the time my eyes and my brain are just processing text. Does it actually save any time to have a magic class that does something in only 10 lines of code, if after writing those 10 lines I’m spending like an hour trying to make sense of all the intertwined abstractions and crazy stuff that is happening under the hood?
So in 2018, when I was still a junior engineer, I started using Go. After a few years working with Python and JavaScript it felt like I was finally out of the dark forest. Go was very easy for my brain and for my IDE too. In 2018 having a reliable ‘jump to definition’ feature in the IDE when working with Python was only a dream, but with Go it worked immediately out of the box even in free editors like the recently released VS Code. It felt so good to understand everything from my HTTP handler down into the deepest dwellings of the standard library and all the way down to the syscalls. I really think that switch changed my career.
Go’s approach to abstractions was that you don’t need any, and if you need flexible implementations, you can just write a code generator. That code generator would generate a whole bunch of more code for you, pushing the total number of lines even higher. But the good news is that unlike squishy humans, the code generator doesn’t make mistakes and you don’t even need to ever read the generated code. Even more good news is that you still can though :) It’s all there, all your code-generated enums (that aren’t natively supported by the language itself), your database mappings, even your JSON serializer, everything can be just simple imperative code.
It’s exactly the opposite of what people in the dynamic languages were doing, and it felt great.
Typing code was never the problem.
Back to mid-2020s
So for a few years I was having a blast coding in Go, surrounded by people who also loved it and understood the benefits of software simplicity.
And then fucking LLMs happened.
A lot of people – influencers, consultants, managers, and engineers too – suddenly decided that now code is cheap and we can easily boost our productivity like 10X, all we have to do is… stop typing code ourselves?
Typing code was never the problem.
So in the previous paragraph I was talking about how when even writing code, I am spending most of the time not typing but making decisions. Those are usually really small decisions, almost operational, as military folks would say. Some are more tactical. You can let the machine make them for you, but you still have to understand them and agree with them, and have a greater picture in your mind. So a speed up, maybe not 10X but a more modest 2X is possible.
2X still sounds really good, however we only optimized the time that engineers spend coding. The real question is, what do they also do?
If in your organisation the period of time from ‘here is an idea’ or ’this is a problem’ to ‘we should try doing this’ is months, and your engineers are constantly busy trying to finally start the engine of that sports car and begin driving at least somewhere, then it’s very likely that if they had a faster decision-making process and a Corolla, they would be already there drinking beer.
Unfortunately what I saw happening is that people freed a bit more time by leveraging LLMs, and all that time was immediately consumed by more meetings, planning, and arguing what to do next.
I want to be clear though, this is not just an introvert developer’s take that we should stop talking to each other and just sit alone and write code. My opinion is quite the opposite. What I want to point out is that communication and planning are the areas that should be optimized first.
How to win a race on a Corolla?
Saving time on coding is only that few last squeezes of the toothpaste. Most of the tube is about product development, decision making, and communication.
Some ideas that I find helpful:
-
Clear ownership and accountability. It should be obvious to a given team that if they think that something should be done, they can just do it, and they don’t need to consult with others, and also nobody else would do it for them. They are in the driver’s seat.
-
Repeating processes. The classics work. Have a backlog grooming process, a sprint planning, a little retrospective. Don’t drown in bureaucracy. If you hired good people, their experience and judgement should be trusted.
-
Allow people to have specialization and focus. A team that does something different every month will not be excellent at anything and won’t be trusted by others either.
-
If you’re not designing a nuclear reactor, then the design stage can be a 1-hour meeting with a whiteboard, not a two-week-long gathering around a single page in Confluence.
If management is done right, people may use Java 8 and type it manually using only a terminal with Git and barebones Vim installed.
Let people care about the code again. It’s been so important for a reason. Save time somewhere else.
