In Defense of the Mediocre Developer
Or: Are we overestimating the importance of averages in our teams?
A year ago, I was lucky enough to receive a work permit from the Canadian government, and spend some time in Vancouver while doing contract work and continuing my studies from afar. Less fortunately, I got to see some questionable behaviors by the hiring end, including experiencing suspicions of using AI, or being lied to about terms previously agreed upon. But this is not an article complaining about AI or even hiring practices, but something else I’ve come to think about as I’ve been observing software engineering culture here and pursuing my statistics degree. Namely, that in our efforts to optimize for and define the ideal individual developer, we seem to have forgotten about the composition of teams.
Again, my intention is not to make a specific case against the use of Leetcode, or any other of the testing methods widely contentious in the developer community. I’m actually going to be far more polemic, and (gently) open for discussion what I think is a broader misconception in our industry. To give some exposition for my argument, I want to first establish a basic premise, and that is that most of our discourse surrounding engineering has to do with a single individualized engineer as our basic unit. From there, we have a pretty clear idea that for hiring, training, evaluating, or anything else for that matter, we tend to aim for a certain level of technical ability. Presumably, if that level is high enough in the aggregate, we will necessarily see benefits, right? To me, it is not at all clear that this level is what ends up benefiting our business’ bottom line.
Edit: after writing this article I found out there were a couple of articles written not too long ago about a similar topic, which I found to be an interesting coincidence! I think my own framing of the issue is quite useful here, as it avoids the pitfalls of certain assumptions on productivity.
The limits to individual skill
For one, we have a very limited understanding of what makes a good developer. This is evident by the numerous ways we’re trying to test for it, often having no overlap in the skills they purport to test with each other, or even having entirely different intentions (for example, some argue that the best type of test filters for studiousness and dedication rather than some technical ability).
Beyond technical tests, there is also the clear challenge that associating skill with business impact necessitates a selection effect: not every contribution by a developer is going to be visible for the business. A highly skilled developer could be mostly working on internal infrastructure and tooling that supports the productivity of others, but hidden outside their team. A lowly skilled developer could be working on projects with high visibility, but hiding underneath costly technical debt that will be paid by someone else (or many) later on.
Most experienced developers seem to agree (roughly) that a good developer has a mix of qualities, like being able to design quality code (appropriate use of design patterns, qualities like readability/flexibility/maintainability/performance, adherence to set of numerous design principles, and understanding of how code changes over time), some architectural know-how, and ability to communicate effectively with stakeholders and advance technical initiatives at the org level. In reality, developers often disagree with each other on what/who exactly constitutes these qualities, or how they actually look like. Incurious sprint planners may think it all boils down to individual contribution to velocity, or to bug churn. And there are more viewpoints, ofcourse. This is all fine, and mostly reflective of an industry capable of improving on itself. However, it pretty obviously sidesteps the actual driving unit of the business, which is the team, not the individual.
Understanding the ecology of software
Now, obviously teams across the industry are going to differ a lot. In size, types of roles, internal hierarchy, size of their encompassing organization, interactions with other teams. These are all important characteristics one should consider before making sweeping statements. But generally speaking, all teams are going to fall under a certain distribution. You are going to have a couple of experienced engineers in leading positions, these will call the shots or mediate decisions from the higher ups. Then you have the brunt of the team, the developers that actually crank out the majority of code. They may have different responsibilities, domains they’re dealing with, etc. but they’re the ones generally programming everything and are reflective of the broader engineering capacity of the business. Then you have the “lower tier” engineers, these are interns or juniors, that mostly follow instructions for easily digestible tasks that were given by the developers above them. They don’t really call any shots, and in the broader context their purpose is mostly to grease the wheels for larger scope initiatives or projects that someone above them is managing. Everyone is going to have different personal knowledge, experience, and expertise.
However, they’re all situated inside a team, all of these engineers are going to constitute in one shape or another how the codebase ends up looking. Even if one is not coding, they may make code reviews, or set up organisation-wide coding conventions. The intern may only write up some documentation, but it will be read by another developer and may guide their judgement as they’re altering or adding to an existing code. Through the codebase, meetings, conversations, etc. everyone is sharing and gaining knowledge from each other. When referring to the parameters I’ve previously mentioned (e.g. management structure), there is a case to be made that they may also not be insignificant contributors. In fact, one of the main points I want to advance is that teams’ outputs, as a whole, are not as affected by individual variance in skill as much as how they’re configured.
That distribution also applies for preferences. Different coders are going to love to work on different technologies, domains, or systems. It’s not at all unusual in my experience to see a dev that I would consider weaker, preferring to do work nobody else wants to in a specific system. Or very capable developers choosing the most challenging problems, even if their business impact is equal, or less, compared to other less interesting ones. This obviously matters for motivation and burnout.
My point in all of this is that a dev team constitutes an ecology. And it’s the unit of ecology that ultimately matches the demands of the business. No work (or feature) is going to demand one type of developer, one technical skill, or interest. The types of tasks we get to do are varied, because the underlying business domain is varied. This is the ultimate reality of software as a profession. In particular, it is the ultimate reality even in the scope of a single product manager.
Beyond the averages
Now, to put this all in “statistical” terms, we seem to be optimizing for a single team average, some kind of composite metric every developer should strive to maximize. This is not at all bad in itself. There is no disadvantage, to my mind, in trying to have the largest possible average. But my argument is that in trying to do so, we’re forgetting about different characteristics of the distribution.
For one, its shape. We want to have the requisite technical diversity in our team so we can maximize our ability to match the varying and evolving business needs. If I only hire architects, my ability to churn boring tasks is greatly diminished. On the other hand, if my team benefits from 2 or 3 developers that “carry” everyone else, I should want to make life as easy as possible for them. Secondly, we misunderstand multi-dimensionality. If our developers are all alike in a certain quality, that means one event that would require something else we didn’t think about is going to create an exceedingly costly hurdle. It may also mean that our interpretation of domains is consistently biased. Thirdly, we miss on network effects. Everyone loves to think about concepts like “force multiplier” in a team. The reality in this case is that one capable developer could add new PR review standards, git hooks, github actions, whatever, and level up the baseline quality of 5 less experienced junior engineers with “low” average contribution. Applied correctly, this is a very particular “skill”, or initiative, that isn’t traditionally thought of as ‘technically meaningful’. In a sense, it itself has to be enabled by a team. Conversely, a single uncommunicative dev could make the lives of the rest of their team miserable and lower everyone’s output. And similarly, a “10x” developer would not be able to contribute much if the team composition, processes etc. are misfit.
Now, since I don’t believe in vibes, I want to also try to give some empirical weight to my idea. For instance, we can get some intuition from the fact that the traditional relationship between productivity and team size reverses in certain open source projects. Another is that there is research denoting the different ways team composition, based on attributes, can influence organizational outcomes and processes. It seems plausible that team composition could be part of a deliberate task that, similarly to software design, requires intentionality and the balancing of trade-offs. We also know that there is no point for limiting the analysis of network effects to the boundary of a single team, there is research to suggest that it can be further extended to other teams in an organization (or even further outside).
To put my cards on the table, I was being a bit facetious with the title. I don’t actually intend to argue that hiring mediocre developers is any good. However, I do want to make the case that (almost) any mediocre developer could become a good developer given the appropriate team composition. This is not just a vision for hiring specifically (there are often, as we all know, more practical concerns), but for how we can arrange our teams internally across an organisation. In fact, an industry practice that focuses solely on maximizing those specific technical metrics, ultimately likely loses in the way of systematic diversity and composition, and possibly creates a market for more creative businesses with initiative.
Some authors that inspired me in thinking about this:
James C. Scott
Christopher Alexander
Stafford Beer