The Best In The World

If you've been following along and understanding most of what I have been talking about, you have a pretty good idea of what software developers do. I've written about putting The Plan together. Making technology choices. Investigating issues. Navigating the sea of primitives. Code and quality metrics. Breaking the work up. There are some gaps, and most of these concepts could be fleshed out further. Nevertheless, I believe we have covered enough ground to start thinking about an interesting question.

Who is the best developer in the world?

It's a big question, and if we can't reasonably answer that, maybe a suitable substitute would be: "What does the model developer look like?". The answer could have some implications for recruitment, education, professional development and perhaps beyond.

To try and answer this question, let's use the framework. Developers assemble The Plan based on the information that they are provided. As new information comes in they make decisions on how to amend The Plan. They make a certain set of technology choices and externalise work where possible. They write code that could be improved in some way, at the expense of other ways, or at the expense of time. They review the code of other developers. They may contribute to the breaking up large blocks of work into chunks, and estimate the time to completion. They work with professionals of other disciplines as colleagues. They may also work with other stakeholders, such as users. They navigate the field of truth to identify and resolve issues. Perhaps they are significant contributors to the digital supply chain.

While I have spent a lot of time writing about what happens within a project workflow, developers often perform a lot of work on their own time, such as when they work to maintain an awareness of developments in the social context: particularly with respect to the digital supply chain, the craft of forming The Plan, and compliance in digital spaces - a story for another time.

There is a lot there to consider.

Of note is how much of this involves a relationship to the work of other people. The work that software developers do is downstream of the work that other professionals perform, which includes other software developers. Even in code, there are constraints imposed by the current state of The Plan when altering The Plan to satisfy new requirements.

In some ways being a software developer is like participating in a team sport, in the sense that there is a diffusion of responsibility for success among members. In other ways it is quite unlike a team sport, there is really significant differentiation between teams, technologies, and projects. But let's follow the sporting analogy for a moment, and for arguments sake I will choose football, where there are various roles where some members are responsible for scoring for their team, and other members are responsible for preventing scoring against their team. The offence have the benefit of their success metric being something that is directly measurable. Goals happened, or they did not happen. The more goals, the better. The defence have a more difficult time. Fewer goals are better, but how do you know whether the performance was great, if it was not zero? How do you really measure what is not there? In sport, the answer is often in commoditisation, or the use of a benchmark (e.g. a longer-term average).

Like sport, success in software often looks like what didn't happen. Unlike sport, the work is not commoditised in a meaningful way. Over the course of their career, software developers could stay at the level of 'Senior Developer' for 30-40 years and work in completely different industries, companies, teams, technologies and projects with each and every role. For all but the most commoditised of work, measurement is not all that useful.

The various code quality metrics may have their moments of relevance at different points in time. The best metrics to use today may not be the best tomorrow. The most important consideration at any given moment may in fact be speed rather than a code quality metric. In other circumstances, the most important metric may be budget.

I believe to be the best developer in the world is to be highly effective at navigating the moment, whatever that may be for their present circumstances. Often that means successful delivery, which is of utmost importance - yet whether it is actually realised is incidental due to the diffusion of responsibility and the influence of circumstance.

There is a phrase that I think is appropriate for reflecting , and some version of it is this: control the controllable. Software developers can take the time to hone their ability to form The Plan. They can take the time to maintain an awareness of the available primitives and form their own ideas of when they might be useful and why. They can navigate the social context. They can take the time to understand the forces that shape the field of truth and the fog of war. They can hone their instincts for when to apply particular trade-offs, and sometimes they will be wrong. They can learn from this. They can be the best in the world.

Until next time.