4 ms·

I've come to dislike the idea of the "10x engineer" partly because it puts software development too much in the realm of factory work or even craft-work, which

I've come to dislike the idea of the "10x engineer" partly because it puts software development too much in the realm of factory work or even craft-work, which it is not. Fundamentally software creation is creative and inventive. It is not a matter of stamping out a certain number of widgets per day. It is not a matter of churning through some number of bugs, lines of code, function points, or what-have-you. It is design work, it is creation, it is art and artisanry. To purport to measure developers against one another along some linear measure is to miss the point entirely. It is the same as asking whether Mark Twain and Walt Whitman are "10x writers", or whether fillet mignon is 10x better than a PB&J. Not only are these things non-linear, they exhibit complexity that is irreducible to such simple measures, which is why we try to avoid the attempt (although somehow we refuse to learn that lesson when it comes to movies, television, and video games, but I digress). The top tier of developers are far more than 10x more valuable than the average developer. Not because they produce 10x more lines of code, or "crush" 10x as many bugs or sprint points, but because they build. better. systems. Period. They write better code. They build the right stuff. They promote better team cohesion. And they execute on difficult projects more effective. And they don't just make one order of magnitude difference, often they make multiple orders of magnitude difference. Here are three fairly common scenarios involving such "keystone" developers: There's a large and crucial code base which is owned and maintained by an entire team, but there is one developer who has a much different relationship to the code than the other people on the team. They wrote most of the original code, though it has grown much since then, and they know far more of it than any other single person on the team. Tasks related to the code which would require much more time and often the collaboration of multiple team members can be done alone and with much less time by this person. If they leave the project will live on, and it may even flourish, but the development velocity and the capabilities of the team will be significantly diminished compared to when the key developer was around. There's a core feature on a very important product that is in development, and there's one developer who seems to have an outsized impact on it. They've gone the extra mile to make sure the feature is designed and implemented well, they've put in the hard work to get the feature shipped with excellent quality (both in the code behind the feature and in the way it works and feels to end-users). They've made sure that the right work has gotten done and the most important core aspects have shipped. And the end result is a phenomenal product that attracts and retains users, engenders customer loyalty, and ultimately results in a massive amount of revenue for the company. There's a tiny team or a startup working on an ambitious product. Despite their limited resources they produce something of significant value and quality, something that normally would require a much vaster number of average developers working for much longer to achieve a similar result. This leads to runaway success. These scenarios happen all the time in the industry, and they speak to a gulf in capabilities between the most capable devs and the industry average. And it's not necessarily about "productivity" it's about getting the right work done, done well, and done efficiently. You put a top tier developer and a middle of the road developer on the same task for a week or two and the difference isn't that one has written a lot more code than the other, the difference is that one developer has something that works and something that you wouldn't mind keeping around. This is another thing. Good developers learn and build from their past projects. Which means that over time the developer is getting better, and also what they're able to deliver based solely on their own work grows exponentially, because it builds and builds and builds, like compound interest. Whereas mediocre developers are building foundations of sand, they can only build so high before everything comes crashing back down and they have to tear down and replace what they've built before with something a little bit better. Mediocre developers tend to spend their time running in place. P.S. Another huge factor is culture, mentoring, leadership by example, and work environment. Top tier developers raise everyone around them to a higher level through their example and their interactions with others. Learning from better developers is a hugely important way that devs get better at their job. And merely getting into a mindset that getting better is possible and valuable is important in its own right. Additionally, working with talented engineers, people we look up to, people we take inspiration from, etc. are important reasons why devs show up to work every day. When an "anchor" dev with a lot of talent leaves a team or a company it can trigger an avalanche of talent leaving the org as other talented engineers decide that the work environment isn't as worthwhile as it once was and they leave as well, accelerating the process until a lot of the talent has evaporated from the org. This is a very common process in the industry because the people who tend to be the most talented and the most intrinsically motivated tend to have the easiest time finding other jobs and tend to be the most sensitive to the quality of the work environment. Unless you're immersed in the work environment and sensitive to these things you may not pick up how drastic these changes can be until years down the road when the impact of a team that has lost all its talent finds itself vastly less able to execute on important projects effectively. And while I've talked about a lot of "soft" subjects such as "art" and "work environment", these things absolutely have an impact on the bottom line.

dozzie 11y ago
> [...] it puts software development too much in the realm of factory work or even craft-work, which it is not. Fundamentally software creation is creative and inventive. I assure you, it is craft. It's much less in the realms of art, science, and invention, and much more in the realms of putting well-known patterns together to build something, sometimes even something new. I assume you have never seen a modern woodworker at work?
- InclinedPlane 11y ago
  Craft and art exist on a continuum, there is no break between them. Often people who are not or do not know artists imagine that the creation of art entails some magical skill, some special step that is lacking in craft work or engineering work. That some "quintessence" is injected into the process which breathes a vitality of art into the work that would otherwise be absent. But this is a false impression of art. the creation of art is precisely as you say, putting together well-known patterns to build something, sometimes something new. Wood-working using the skills of working the lathe, the chisel, the rasp is fundamentally the same sort of thing as painting using brush strokes. And both skills can be used to create either a work of art or a work of craftsmanship. It's a matter of skill and intent. Fundamentally though, creating a painting, a poem, or a song is mostly craftsmanship, it's the application of skills to build something in a familiar way. There's no magic breath of life that elevates a crafted work into the realm of art, rather it's the purpose it's made for and other factors which make that distinction. Something that is considered "not art" would typically be something that is completely unoriginal and has a purely practical purpose. Art, on the other hand, tends to involve creativity and originality, it tends to not just be for a practical purpose but also to be evocative, emotional, and communicative. You see, the method and skills of construction are not the differentiator here. Both a EULA and a sonnet can use the same medium (written language) yet while one is purely practical and ordinary the other communicates more than mere facts and details, involves some degree of originality and creativity, and engages the reader at a higher level. Software dev is a very wide ranging field, so it is difficult to talk about it holistically. However, in my experience it does not fit the description of unoriginal rote work. Often there is creativity and originality, as well as subtlety and fine artisanship. It is a new kind of thing which does not neatly fall into either the manufacturing/engineering/"craft" or "art" buckets, and for that reason it requires different ways of thinking about the work and the workers. The most important point here is that when you give craftsmen the task of making 20 chairs, they will do so. Some with greater efficiency than others. But this task is nonsensical when it comes to software, because it is only ever necessary to make one of a thing in software, copies are free (or as nearly so as makes no practical difference). Instead the equivalent task would be to make 20 different chair designs. And now it becomes more clear that we are not dealing with craftsmanship, we are dealing with design work. Creative work. The closest analog to which is art. And how do you judge an order of magnitude difference in design work? How do you objectively measure the difference between an Eames lounge and plastic patio furniture? Objectively you can't, but subjectively we are aware that the difference between middle of the road design and top tier design is much more than a single order of magnitude.

dozzie 11y ago

> [...] it puts software development too much in the realm of factory work or even craft-work, which it is not. Fundamentally software creation is creative and inventive. I assure you, it is craft. It's much less in the realms of art, science, and invention, and much more in the realms of putting well-known patterns together to build something, sometimes even something new. I assume you have never seen a modern woodworker at work?

InclinedPlane 11y ago
Craft and art exist on a continuum, there is no break between them. Often people who are not or do not know artists imagine that the creation of art entails some magical skill, some special step that is lacking in craft work or engineering work. That some "quintessence" is injected into the process which breathes a vitality of art into the work that would otherwise be absent. But this is a false impression of art. the creation of art is precisely as you say, putting together well-known patterns to build something, sometimes something new. Wood-working using the skills of working the lathe, the chisel, the rasp is fundamentally the same sort of thing as painting using brush strokes. And both skills can be used to create either a work of art or a work of craftsmanship. It's a matter of skill and intent. Fundamentally though, creating a painting, a poem, or a song is mostly craftsmanship, it's the application of skills to build something in a familiar way. There's no magic breath of life that elevates a crafted work into the realm of art, rather it's the purpose it's made for and other factors which make that distinction. Something that is considered "not art" would typically be something that is completely unoriginal and has a purely practical purpose. Art, on the other hand, tends to involve creativity and originality, it tends to not just be for a practical purpose but also to be evocative, emotional, and communicative. You see, the method and skills of construction are not the differentiator here. Both a EULA and a sonnet can use the same medium (written language) yet while one is purely practical and ordinary the other communicates more than mere facts and details, involves some degree of originality and creativity, and engages the reader at a higher level. Software dev is a very wide ranging field, so it is difficult to talk about it holistically. However, in my experience it does not fit the description of unoriginal rote work. Often there is creativity and originality, as well as subtlety and fine artisanship. It is a new kind of thing which does not neatly fall into either the manufacturing/engineering/"craft" or "art" buckets, and for that reason it requires different ways of thinking about the work and the workers. The most important point here is that when you give craftsmen the task of making 20 chairs, they will do so. Some with greater efficiency than others. But this task is nonsensical when it comes to software, because it is only ever necessary to make one of a thing in software, copies are free (or as nearly so as makes no practical difference). Instead the equivalent task would be to make 20 different chair designs. And now it becomes more clear that we are not dealing with craftsmanship, we are dealing with design work. Creative work. The closest analog to which is art. And how do you judge an order of magnitude difference in design work? How do you objectively measure the difference between an Eames lounge and plastic patio furniture? Objectively you can't, but subjectively we are aware that the difference between middle of the road design and top tier design is much more than a single order of magnitude.