Lessons from Master Programmers
Product organisations obsess over minor process optimisations, but they'd ship a lot more if they just focused on making their programmers better.
At RubyConf 2013, Geoffery Grosenbach did a talk which was mostly him playing videos of other people talking.
His company is long gone now, but they were building some sort of tool for pair programming. To help promote it, he sought out expert programmers and recorded them thinking through, and working through, some problems.
The talk is a joy to watch (even though the audio sucks) because it is like being a fly on the wall while masters of their craft do what they do best. It would be hard to watch this and not take something useful away. As well as programmers the video also interviews designers and product shapers, so there’s something for everyone.
In the video, the programmers were all given a task and 90 minutes to complete. There’s a strict amount of time, and a clear desired outcome. But beyond that, they had no real constraints. They weren’t given a checklist of tasks to complete; they were given free range to architect a solution and implement it as best they could. There’s a great moment in the video where Tim Caswell pauses for a moment, looks up from the screen, rethinks everything, and a few lines of code later he is done.
People who aren’t programmers may not realise that this is very representative of how most great code gets written. It’s rare to think of the perfect solution before you start writing, then sit down and write it with no issues. Sketching and planning don’t hurt, but great programmers tend to change course as they hone in on the right solution.
Why share this talk? There’s so much thought put into how to get more out of product management frameworks. There’s a million levers you can tweak, from how you prioritise work through to what detail you hand over. But at the end of the day, the output must be created by programmers - everyone else that’s involved is a middleman.
I think the most effective lever to building better products is to make the programmers better at their jobs. If just a bit of the effort that was put into writing better product specs was redirected into making better programmers, the payoff would be enormous. This video shows an example of how the very best think, and work. Imagine how much you could build if everyone on your team got to that level.
This may seem like it’s primarily a problem for engineering managers. What can everyone else involved in building a product do to make programmers better? Surely not much? I disagree. In fact, my product management framework of choice, Shape Up, is specifically designed to make programmers more effective - if you use it right.
We’ve been using Shape Up for a few years now, and generally it’s gone well, but there’s always infighting over some of the concepts it introduces. The most contentious concept is Appetite.
I think many people struggle with appetite because it forces them to set a limit on how much a problem can be worked on. If a problem is valuable, surely we want to keep working on it until it’s done? Why would we stop arbitrarily early because of an arbitrary deadline we set?
Shape Up works in 6 week cycles, and you’re meant to re-assess priorities after each one. But people like to tweak its boundaries. I see a lot of debates that boil down to “X is strategically important, so we must work on it for more than 6 weeks. There’s so many tasks we need to do. We’ll just keep doing 6 week cycles on it until it’s done.” This is justified by arguing that programmers don’t like context switching every 2 months (so more cycles on the same thing is good), and that if a problem isn’t worked on until it’s done then a half-baked version is all that’ll get released (so we need to commit more time to prevent that).
What this misses is that great programmers thrive on constraints. If the amount of time that can be worked on a problem is not set in stone, then it’s a suggestion, not a constraint. Programmers can abide by constraints, but they can struggle with suggestions.
In our video, the programmers were forced to do their best work because they only had 90 minutes to solve the problem they were given. The essence of Shape Up is a strong belief that programmers can solve any problem if they spend 6 weeks working on it.1
This belief comes from the realisation that mastery is attainable, but it’s not inevitable. You develop mastery through being stretched. Give programmers a big, but achievable goal, with a challenging but practical time frame, and they’ll be stretched, but often they’ll get there. It’s a good thing.
This is why appetite works well if done properly. If you only focus on what outcomes you want achieved, and let the programmers work out how to solve the problem fully within 6 weeks, most of the time it will happen. It might take a few cycles to get used to working in this way, but after that point the results will come.
If you insist on spelling out exactly what steps are required to get the outcome, then you are totally dependent on how quickly the programmer can follow those steps (not to mention, how correct those steps are). And if you accept as inevitable the idea that a project can’t be done in 6 weeks, then of course it won’t be.
I’ve been really proud to see some of the folks I’ve worked with over the years become really good programmers very quickly. I hired a lot of university graduates, and after a few years you would have no idea they were still so junior, at least in terms of time.
For a long time I have tried to pinpoint why some programmers progress much more quickly than others. I’m not vain enough to say it’s all my doing, or even that there’s only one thing that explains it all. But I do think you can create an environment that matches how the best programmers like to work. Everyone who works in it, will be nudged in the direction of greatness. Giving programmers full agency over a problem, coupled with time constraints on how to solve it, is a big step in that direction.
Ok, not literally any problem. But if your problems can never be solved in less than 6 weeks, don’t use Shape Up.