The “10x engineer:" 50 years ago and now
How has parts of the classic book on software engineering, ‘The Mythical Man Month,’ aged with time, and is it still relevant half a century on – or does it belong in a museum, alongside floppy discs?
👋 Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover topics related to Big Tech and startups through the lens of engineering managers and senior engineers. In this article, we cover one out of five topics from today’s subscriber-only article What Changed in 50 Years of Computing. If you’re been forwarded this email, you can subscribe here.
‘The Mythical Man Month’ by Frederick P. Brooks, Jr. is a bona fide classic in the software industry. First published in 1975, and with an updated edition in 1995, the text is almost 50 years old. Lots of time has passed, yet the book is still relevant.
The title of the book takes aim at the “myth” that software development can be measured in “man months,” which Brooks disproves in the pages that follow:
“Cost [of the software project] does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth.”
I’ve been making my way through this book from software’s earliest days and taking notes of what’s remained the same in the 50 years since Mythical Man Month came out, which predictions the book got right or wrong, and what’s different about engineering today.
Chapter 3 is “The Surgical Team,” and contains what might be one of the very first mentions of the “10x engineer” concept. This is how Brooks put it:
“Programming managers have long recognized wide productivity variations between good programmers and poor ones. (...) In one of their studies, Sacknman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances average about 10:1 productivity measurements, and an amazing 5:1 on program and speed space measurements! In short, the $20,000/year programmer [in 2024 terms: $120K] may well be 10 times as productive as the $10,000/year one [in 2024 numbers: $60K].”
Brooks agrees with this observation, and suggests a radical solution: have as few senior programmers as possible, and build a team around each one – a bit like how a hospital surgeon leads a whole team. Brooks suggests the set up below, borrowed from Harlan Mills, could work well:
The chief programmer. Brooks calls this person “the surgeon.” They write the specification, code, tests it, and write the documentation. Has 10+ years’ experience, and a broad range of expertise across developing, math, business, and whatever else is needed.
The copilot. “The alter ego of the surgeon, able to do any part of the job, but less experienced.” This is a bit like a junior pair-programming partner.
The language lawyer. “Most computer installations have one or two people who delight in mastery of the intricacies of a programming language. These experts turn out to be very useful, and very widely consulted.” This role implies the chief programmer will usually not have time to go in-depth on a programming language, and will rely on an expert in it. A most interesting addition!
The toolsmith. Responsible for building and maintaining developer tools so the programmer and copilot can do their jobs better; such as improving editors, building better debugging functionality, creating utility tools and macros, etc.
The tester. They come up with test cases and data. Also responsible for scaffolding of tests.
The program clerk. “Responsible for maintaining the technical records of the team in a programming-product library, responsible for both machine-readable and human readable files.”
The administrator. Responsible for payroll, renting offices, buying computers, etc.
The editor. Edits documentation the chief programmer writes, and makes it production-ready.
Two secretaries. “The administrator and the editor will each need a secretary; the administrator’s secretary will handle project correspondence and non-product files.”
Here’s what this “surgical team” built around a very productive programmer looks like:
My sense is this team setup was aspirational. The roles certainly made sense at the time, but why would any business leader sign off to hire 9 other people to support one developer? In 1975, I assume the answer was very few.
In 2024, there is no need for most of Brooks’ proposed roles, and the “surgical team” has transformed thanks to advancements in tooling and how we work:
It’s fascinating how much tooling has improved in 50 years. Tools and approaches at our disposal, which didn’t exist in 1975, or were not widespread in 1995, include:
Git – the now-dominant version control system used by much of the industry, with exceptions for projects with very large assets, like video games
Code reviews: these became common in parallel with version control. Code reviews reduce the need to pair while working on a task, allowing engineers to keep up with changes and learn from each other.
CI/CD: running automated tests on all changes, and deploying code to production automatically.
Rollout and rollback mechanisms. Brooks discusses software in the context of producing operating systems, pre-internet. Building operating systems and embedded software remains challenging, but software updates over the internet are common and bug fixes can be delivered later. A good example is automobiles; most modern vehicles regularly refresh firmware and operating systems “over the air!”
Picking up languages and frameworks is easier. There are countless online resources, sandboxes, and advanced IDE functionality like autocomplete and inline signaling for compile-time errors, that make getting started with a new language much easier, today. To come right up to date, we’re currently discovering the productivity impact of AI coding tools.
Progress has changed what used to be a 10-person team supporting a lead developer, into a set of tools — as well as a couple of centralized platform teams, at larger companies.
The concept of “hierarchical programming” feels dated. One thing that strikes me about Brooks’s model is that it’s hierarchical. The “chief programmer” acts as an architect and does all planning, most direction setting, and some coding, while everyone else works well-defined, supporting roles. The copilot is described as:
“knows all the code intimately. [They] research alternative design strategies. [They] obviously serve as an insurance against disaster to the surgeon. [They] may even write code, but are not responsible for any part of the code.”
This setup made sense when access to computers was more limited because machine time was expensive, but, today, it would be wasteful to not have even an entry-level engineer writing production code. What didn’t exist back then was source code control and code reviews to stop poorly written code making it to production.
It’s a good reminder that tooling changes a team’s social dynamics. Thanks to better tooling, we are able to reject overly hierarchical team structures these days.
Brooks’ “toolsmith” concept is still valid, but different. I am intrigued by the role for a dedicated developer to build better debugging tools and utilities, and also by an addition to it:
“Each team will need their own toolsmith, regardless of the excellence and reliability of any centrally provided service. Their job is to see to the tools needed or wanted by the surgeon, without regard to any other team’s needs.”
Brooks was convinced that even with a central tooling team – which we’d call a platform team, today – there was still plenty of value in a team-specific tools specialist. But this need has vanished almost entirely because tools, developer environments, build tools, and more, can be configured in detailed ways.
All teams at a company use the same CI/CD tools, but they might change the configurations slightly.
It’s true that within an engineering team, there’s usually one or two engineers who enjoy tweaking build systems and shared environments more than others do. However, with central platform/infrastructure teams, there’s no need for an “embedded” platform engineer in teams. This has to do with how much developer tools have evolved in the 50 years since the book came out.
The “10x engineer” has always been a source of debate and contention. We’ve all seen developers who seem to be a lot more productive than others. CTOs and CEOs catch on to this as well, and some label standout folks as “10x developers.”
However, there’s a lot of nuance:
A developer who builds things rapidly might do so by writing unmaintainable code that several developers will struggle to modify, later
The “10x developer” might be someone who hoards information, and is effective because they refuse to let others understand obscure systems they build
A “10x developer” could be far more productive because of their long tenure at a workplace with high turnover
Another “10x developer” could be someone with good business sense, working on the most profitable projects, who avoids other work
Another “10x developer” could also be very good at taking credit for work done by a larger team, which they finished
You see where this leads. “10x developer” behavior can actually be undetected toxic behavior under a different label. Meanwhile, others could have the advantage of a specific context that cannot be replicated. It’s certainly a complex topic, and one we haven’t stopped thinking and arguing about for more than 50 years, across the industry.
This was one out of the five topics covered in the article What Changed in 50 Years of Computing. The full article additionally covers:
Joys and woes of programming, then and now
Why do we ship faster now than in 1975?
Is “Brooks’s Law” still valid?
Do we spend more time coding than 50 years ago?