#15 - Speed, Quality, and the Frontier
Hey all,
Last week, I received feedback from a good friend that my previous installment was a bit underwhelming. He’d come to expect a certain bar of quality from me, and last week’s post felt rushed.
I reflected on this, and tend to agree. My strength is not in producing a voluminous amount of content - I haven’t developed the ability to write with that kind of speed.
In fact, I should have known this from the beginning. On the job, I’ve always been the type of engineer who would trade off some speed for more quality. There are times when this approach is bad, but in the long run, I believe this mentality wins out (because of compounding).
So I want to share a tweak to Software Mentor: I’m going to move to a more sustainable pace. I will publish a post when it’s ready - no less than once a month, but I may not keep pace with my current weekly cadence. Expect some quiet weeks in the future.
And, on the topic of last week’s post - expect a “rewrite” of “Reading and Writing” at some point soon. The original idea was a piece that spanned multiple plays on the term “reading and writing” and I expect the full version will be a lot more interesting!
Alright, now that the announcement is out of the way, let’s talk about Speed, Quality, and the Frontier.
Tradeoffs
A lot of engineering is about tradeoffs - do we optimize for reads or writes? Do we build something we know won’t scale to millions, but will allow us to ship this month as opposed to in 3 quarters from now?
The right call depends on a multitude of variables and getting it perfect is pretty much the bane of our existence. Most of the time, we can’t have our cake and eat it too - and that annoys our stakeholders.
When it comes to software engineers themselves, I find that there seems to exist a tradeoff in their attitudes towards speed and quality - deliver now vs delivered well. I clearly have a bias - I lean towards quality, but I’ve seen many times when that isn’t always the way to go. Sometimes, a delay will cause significant costs to the business, lost opportunities, or even a psychological drain on morale to a dependent team. Sometimes, the better version is never even needed.
There’s a time to go fast and dirty, and there’s a time to go slow and pristine. Sadly, it might be impossible* to go fast and pristine, but it’s useful to flesh this idea of tradeoffs further.
The Frontier
In Economics, there’s this idea called the Production Possibilities Frontier.
Imagine a factory that can produce two goods, A and B. When the factory chooses to produce all of A, it can produce none of B. But the factory can also choose to produce a blend of A and B. How can we express all possible configurations of what the factory can produce?
The Production Possibilities Frontier (PPF) is the answer. Let’s take a look at this diagram from Investopedia:
The PPF is the curve that shows the maximum production of product A, given a quantity of product B. All points underneath this curve are possible configurations.
Let’s now pretend product A is “speed” (replace wine with speed 😛) and product B is “quality” (instead of cotton).
Using that analogy, let’s look at some of the points on the graph :
Point A, speed over quality: These engineers tend to get excited about shipping product, but only loosely care about quality.
Point B, speed and quality balanced: I don’t know any engineer that’s perfectly balanced between speed and quality, but this is a good balance to strive for.
Point C, quality over speed: I believe I fall on this point in the chart. Engineers here tend to want to get things right, and will spend more effort on design and planning.
Point X, the slacker: These engineers have more in the tank, and for whatever reason they’re holding back.
Point Y, the unicorn*: these individuals don’t exist!
And while they’re not shown, you can imagine there are some engineers at the extremes. Some may focus entirely on speed at the complete disregard for quality (I’ve never met one, but some come awfully close) and some may focus entirely on quality at the expense of shipping (sadly, this happens).
*The Exceptions
In the above sections, you might have noticed a star next to “impossible” and “unicorn”. I claimed that combining speed and quality just doesn’t happen.
I’ve worked somewhat closely with about 40-50 engineers and I would say the vast majority of them can be described along the PPF above, where speed and quality seem to exist in tradeoff of each other.
But 2 of my former coworkers seem to possess a ludicrous combination of speed AND quality. They’re the impossible unicorns.
How is this possible? Well, I don’t think these individuals are necessarily born with ridiculous capabilities. I can’t claim to know how they got this way, but let me describe some characteristics:
Type quite fast (120+ wpm)
Work long hours (sadly, I wish this wasn’t the case)
Love simplicity and have strong opinions on “bad code”
Welcome engineering discussions and learning (rarely get defensive regarding technical topics)
Ability to hunker down and focus
Are highly skilled at using their IDE
Have relatively clean workspaces (physical workspaces are meh to great, but digital workspaces are always ✨)
What these engineers have been able to do, is shift their PPF. Consider this chart:
The PPF has shifted outwards! Point Y is now along the curve.
In fact, while I know 2 unicorn engineers, I know 3-4 more engineers who are on the cusp. They tend to have many of the same qualities, type a little slower, and work fewer hours, but they too seem to be breaking away from the rest of the pack.
While I can’t say I’ve achieved the same, I’ve raised my typing speed from about 70 WPM to 88WPM in the last year, and have tried to incorporate a mentality of “work clean”. There have been some days where I achieve those rarefied levels of productivity of “Point Y” (unsustained though).
I believe certain investments extend your PPF in the direction of speed (multipliers on your output), and others extend it in the direction of quality (refine your taste for good code). I don’t have a step by step tutorial on how this can be achieved, but I truly believe it’s worth asking how to get to greater heights.
As a junior engineer, understanding what is possible will allow you to reach for the stars!
Conclusion
In the intro, I mentioned my good friend who gave me feedback on my previous post. He’s one of these “speed and quality” engineers - and it inspired me to write this post today. Maybe I’ll get him and the other impossible engineers to describe their habits and how they got this way.
There’s much more to cover on “quality” - what that even means, and how it compounds - but that’s a topic for future newsletters.
For now, understand that you have a Production Possibility Frontier, and that with investment, it’s possible to shift your PPF. If and when I learn how to do this, I’ll share those tips.
Until next time!
Phil