> just like the 10x CEO. They just make the right decisions and hence are compensated accordingly.
A lot of being a successful CEO is being at the right place at the right time (of course: in addition to actual qualities).
Anecdote time:
I once was a franchisee of a major (services) franchise that some time ago decided to expand to Germany (I sold my franchise years ago). I'll only talk about one person, but this happened throughout the network, it wasn't nearly as successful as hoped in this country.
So anyway, I personally know one of the guys who lead one of the best franchises in a major German city. He expanded, became responsible for the entire wider area (which allowed him a cut from all franchises in it in exchange for recruiting new franchisees and for advising them).
He had this exact opinion (and he was a former business consultant too, I think he even has an MBA), when a franchisee didn't do well that he just wasn't good enough. He himself was proof, after all, just do your customer acquisitions and all the necessary stuff,and success will eventually come! It worked for him!
When a franchisee failed he acquired their shop, it was in the same city and they seemed to be in very good areas, lots of businesses that fit the description of the target market. Not a big risk one would think given that his own shop was doing exceedingly well with the exact same demographics, just a few miles away.
Long story short, he ended up giving up the franchise for the area as well as the two additional shops he had acquired. Today he has just that one original location. Turned out that the exact same extremely successful guy only managed to be successful in one spot. Not even in very promising areas just a few miles away did it work out!
There were more stories like this, some of them I knew personally (through franchisee training at the beginning where I met many of them), all people who were formerly employed and "important people" in their jobs, and who all thought that it's all about you and the effort and skills you put in. Some of them managed to indeed build a successful business, but they all became much more humble over time, because they all found the large amount of randomness in their success when they tried to expand (area franchise or another shop).
So, tell me again about those successful CEOs, I'd like to learn more... the books are full of such people, successful in one place and time and failing in another place and/or time. Because they themselves are only one ingredient into what is needed for success, and not even the major one ("necessary but not [even nearly] sufficient").
[...] They studied professional programmers with an average of 7 years' experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1
I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst.
So even this scientific study (from the 60s) says that there aren't 10x developers according to this definition: the ratio goes down to sqrt(20), using the geometric mean, if a good-enough sample was chosen. Program size and program execution speed would put that ratio to sqrt(5) and sqrt(10), respectively.
I vaguely recall some of those big statements about programmer productivity came from observations of the relative performance of programmers developing IBM mainframe operating systems in assembly language.
I bet you'd surely find 10 to 1 or 100 to 1 differences in programming productivity on a project like that following waterfall methodology in the 1960's.
It definitely affects your ability to compare studies over a long period of time – e.g. there was a huge shift in what programming work looked like during the progression from submitting code as batch jobs with a turnaround time measured in hours, to having a terminal on a shared system (where compilation was still a slow process), to individual workstations. That changes some of the skills significantly – i.e. reasoning about code on a whiteboard isn't useless but it's not a critical skill the way it was before everyone had an editor running code checks continuously, interactive debugger, etc.
I think Fred Brooks was right to argue[1] that we're not going to see dramatic further improvements because we're at the point of diminishing returns on overhead and most of the remaining work is actually inherent to whatever problem is being solved. The closest we've probably come to a change on that scale was the rise of cloud technology shrinking the feedback cycle for testing but I don't think that's been an order-of-magnitude change for most people.
I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst
That could well be what people perceive. It's not what the studies said. While the article has some good references, I might as well quote Peopleware again just for the fun of it. I churn this out every so often:
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources.
[ "Peopleware", DeMarco and Lister, 1987, p45 ]
10x the worst literally means nothing at all if you find a sufficiently bad programmer you can have an infinity times programmer and the 10x developer as it is normally expressed is 10x average.
Further author even punts at the end of article by claiming that its not needed to measure difficult to measure things as we can instead reason our way to the right answer which is practically nonsensical. Measuring is step one in actually reasoning about things.
In short author may be a good developer but he is certainly not a 10x author.
> you can rely on the best outperforming the median by a factor of 2.5
This is roughly what I estimate the productivity improvement a good developer gets when they're working on a task that fascinates them and that they choose for themselves, and without too many dependencies on productivity killing things (like builds and flaky external libraries and services).
The most productive people I knew tended to the people who didn't do as they were told. They were amazingly productive at producing the things that fascinated them, much less productive at the drudge that the organisation demanded of them. Sometimes the organisation was able to recognise that they were doing useful stuff (despite the fact that they weren't always pulling their weight on the things they were supposed to be doing) and they became rockstars, sometimes it wasn't and they became pariahs.
I thought the same thing. Maybe because it's the only definition that makes sense. If you measure everyone against the department Wally (the lazy guy from Dilbert), you'll probably find plenty of 10x programmers. Not that it would mean anything.
Also, sample size would matter. Assume that there really is a Superwally out there who has worked in programming for seven years for some company without accomplishing anything at all. And I imagine that there is. It would matter a lot if he is part of the sample. In fact, the only sample that would make sense would be all programmers in the world, and now, thanks to Superwally, we all look pretty good.
And of course, there is probably some Hyperwally as well who can smugly boast seven years of negative productivity. Deleting random stuff, breaking functionality, leaving messy code for others to untangle. Adding Hyperwally to the equation and the relative productivity of everyone else would approach singularity levels.
The trouble with comparing the best to the worst is that there's really no floor for how bad a programmer can be. If an average programmer takes ten minutes to do a task, and a great one takes four, how long does an incompetent one take? Twenty minutes, thirty, an hour or two, never...?
Incompetent programmer will finish task in the same time as 10x but at the same time it will break production for 5h, losing 100h for company and another 5h for someone to fix it.
How about negative-times programmers: Programmers that decrease productivity by introducing bugs and broken features that costs more time to manage & fix than the sum of the value added.
Programmers writing features that add points of failures to previously working systems
Contrary to @iaweihli, I think the error is in the first one and that they originally meant: "They found no relationship between a 0.1x programmer's amount of experience and code quality or productivity."
1. Those who are good developers
2. Those who can't write any real code (cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the years because they were not able to FizzBuzz)(25%-50% of the market)
The 10x comes from comparing (1) and (2) - although dividing anything by 0 is larger than 10x.
+1 however I think there is a 3rd kind of developer as well. The 3rd being those who CAN do fizzbuzz/codekata style tests but when faced with a real programming problem in real code base they falter.
There are actually just millions or billions of discrete points, one for each programmer. Implying that they can be approximated by some kind of continuous gradient is quite frankly insane and unfounded.
Each of those 'programmers' is millions or billions of data points, one for each neural circuit. Implying that they can be approximated by a single discrete point is disingenuous and misleading.
I find the arguments in the "Programming is about choices" section a bit contrieved.
Yes, if you have a small team of say 10 people, a very competent lead engineer can make all the difference by setting up proper testing, SCM, CI, etc. i.e., by choosing the right tools and people for the job.
However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
In my opinion, the most important thing then is to spot anything that will make things go haywire, communicate them and convince the right people that this has to be fixed. If you force a new porgramming language onto the whole team because it makes you, the 10x engineer, more productive, you might face endless discussions, additional training costs and a big backlash ("why do we need this now?") from the team.
> However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
Another interpretation of this is that 10x programmers get dragged down when they have to work on teams that are too large or don't grant autonomy.
In my first job I convinced the boss to start transitioning the programmers away from using Windows machines for PHP (Drupal) development work.
The (unsurprising, really) backlash was not because their work had slowed down (in fact it solved many problems) but because their non-work was impeded. Flash was a bit dodgy, so browser games were out. Their favorite torrent programs didn't work in Linux. Of course, they couldn't use these reasons when complaining to the boss, so there were some amusing verbal gymnastics....
When I look at great developers, they can not only build things without taking as many dead ends but they can explain why and share their reasoning with the rest of the team effectively.
The very best can not only complete their own tasks well but their "prowess" (for lack of a better term) is witnessed and people seek out their advice.. therefore making others more effective too.
You could extend that logic: Since I couldn't code at some point in time and I can now, I've become infinitely better at it.
Compared to someone that can't code I'm infinitely faster in theory. Do note that in reality, if someone that can't code needs to write code, he'll likely learn to code first. However, once he learns to write code, he is no longer someone that can't write code.
The 10x programmer isn't 10 times nothing, of course. The 10 times rule is, I think, 10 times better than average. So we have to know the average first.
The amount of programmers rises very fast: IIRC, the amount of programmers doubles every 6 years or so. The average programmer therefore has 6 years experience.
The 10 times programmer has to be 10 times better than that. How is he 10 times better? He has to be able to beat a 10-person team of people with 6 years experience on average. That is a team of 4 juniors with 4 years experience, 3 "medium" programmers with 8 years experience and 2 senior programmers with 10 years of experience.
Imagine a contest where you have to develop a huge SAAS management-like system. One team has the 7 developers described above. The other team is the solo mythical 10 times developer.
Well, I think the 10 times developer is going to have a head start, but he's going to burn out within 2 months, releasing nothing and starting a new project somewhat later. The project manager now has to find a new 10 times developer, but he finds out that no-one can replace him and they need to start over.
Meanwhile, the 7 developers are playing table-tennis and having boring meetings and finish the product much later than planned, but it is done and it sells fine.
You're right, my thought experienced only proved that it is possible for a developper to be 10x better than another one, with the same brain, only more experience.
About your project, i had the experience of building the exact same project ( an product demo ios app with a web backend and its content management interface). First project had to be done using "enterprise" practices, and the other was free. First one i did with a senior developer helping me on the web interface side, the other with an intern i had to explain what MVC was.
First project took 6 months, plus 2 more because of some guidelines i didn't respect first, plus a whole team of admins to handle the production side. It probably costed more than 100k to the company ( not counting the internal days spent in meetings). The internal team that was supposed to maintain the code wasn't able to do so.
The other took less than 3 months and costed something like 10k, including server cost (i used app engine). The intern made the project evolve for more than a year.
A 10x developper is not just able to produce more, it can prevent you from falling into traps that can simply lead your product to a complete failure, and your company to simply cease to exist.
I'd suggest there is no quantifiable way to measure what "a good programmer" is.
Nor is there a way to quantify "good code" in any scientific manner. It IS possible to identify obviously bad code, BUT "good code" comes in a variety of forms and looks different depending on the experience level of the developer.
In the end, many of the measures that people apply to assess programmers are simply a matter of personal opinion.
edit: downvoters - if you think I'm wrong then please explain your counter opinion, don't just downvote. A downvote without a counter opinion simply confirms my assertion that there is no science to this because you won't identify what that science is, you have only a vague opinion that I am wrong.
I disagree - wish you hadn't used the word science when you probably meant verifiable or respectable, too - but I upvoted 'cause you used a great transcendental argument vs your downvoters. My comments on measuring are elsewhere here. I think it's difficult, and something Muggles in management get way wrong most of the time, but that's another matter from whether it can be done or is done, all the time.
Programming is a craft, not an art. If programmer a satisfies the requirements 10 times faster than programmer b, and does so repeatedly, then programmer a is a 10x compared to b
Absolutely. We can even measure Picasso against other artists (e.g. in bucks per lifetime). 10x is not some internal state, it is a fusion of key performance indexes. If one doesn't have these though, then managing his company is pure art, by definition.
You are highly probably 10x programmer asking it, because sometimes I get bored to death waiting on employees to perform a simple task, which is done by me on other OS 20 minutes ago. Sometimes I can't help but help them with "long-standing problem" by going into code and understanding how it works, making patch in few minutes. Am I rockstar? Pfft, no way. But the median is far lower than Picasso/10, it can be measured easily.
It's a self-serving mythology, because a few individuals can claim to be 10Xers to gain special privileges.
It's telling that there's no such thing as industry talent matrix. Instead of general skills - creativity, accuracy, speed, debugging insight, ability to learn new languages/frameworks, team leadership, good-to-have-around vs toxic asshole, and so on - we have this myth of "the rockstar".
A certain kind of management loves because rockstars because having them around reflects well on management (reason number one for hiring them) and supposedly they are super-productive (reason number two, which often turns out not to be true in practice, especially in a team setting.)
The hiring process tests for almost none of the qualities on the talent matrix. There's a ridiculous notion that knowing algos makes you a developer worth talking to, and a slightly less ridiculous notion that a bit of hazing tells you something about how well someone works under pressure.
The bottom line: that after all these decades we have far too little research defining the qualities that really matter in different work contexts, and almost no research at all into how to select for them.
It's a self-serving mythology, because a few individuals can claim to be 10Xers to gain special privileges.
Do people say "I'm a 10x programmer" and get promoted or some sort of perk? Get better jobs by saying that you're a rock star?
Of course not. The premise of 10x programmers, outside of bloviating bloggers, is primarily one that people observe in programming teams. The "go to" person, the person who invariably initiates all of the important shifts and base designs, etc. Many projects start around such a person, they leave and it slowly rusts under a team of normal competency developers, who eventually all disperse and join another project started by a standout developer.
My experience in this industry is that there are absolutely extreme exception developers, and thinking back I'd say it was about 1 out of every 100 developers in most orgs. They were the people who didn't need to be hand held, used heuristics to find solutions, developed designs that invariably became the kernel of solutions, etc. Other developers were critical in the mix, but the notion that all are the same is destructive and unrealistic.
There's also a certain kind of person who seems to really want 10x people _not_ to exist.
I'm not a 10x person, but I have worked with some. I don't think they are unique to programming..there are 10x folks in every field.
Sometimes you don't need a 10x person, and if you don't, it can seem like they don't matter. In those cases, a few 1x people will do just as well. But I do believe that sometimes you _do_ need a 10x person, and if you do, you can't do the same things without them. In those cases, I'd absolutely take a 'toxic' 10x person over the nice-but-1x alternative.
Part of the issue is that there's more work for programmers than ever, and most of that work is of the 1x variety.....if you're just banging out CSS for some small-business website, it doesn't matter whether you have Jeff Dean do it, or a new grad from Omaha Community college. If, however, you need to write a new globally consistent database abstraction at scale, then the new grad probably won't cut it. If you actually need that thing, then it wouldn't matter if the new grad was the nicest person on earth, and Jeff Dean the most 'toxic' (though actually I understand that he's a very nice person).
See other replies vs measurement - and remember all the large software projects that never get deployed, becoming outright failures. Can you really conclude that they were problems nobody on earth could have solved?
I don't disagree you will see orders of magnitude differences between people by some measurement.
The problem is that nobody defending it is specifying what measurement will yeld those orders of magnitude difference, and what is its relevance. Claiming a difference without telling in what dimension is an empty claim, and that is exactly the problem with the 10x developer idea.
(By the way, yes, there are plenty of problems nobody on Earth could ever solve. That doesn't follow from the fact that easier projects fail, but it's not false either.)
There isn't merely one vector in which superior programmers are superior, there are many; see the Feynman example. Your search for simplicity is misplaced, I believe.
Nobody's said there aren't unsolvable problems, the question was whether nearly every massive failed software project (and they're common) represented such a thing - obviously no.
I have no doubt that there are programmers who are 10x as productive as other programmers. I witnessed it over and over.
But as I understand it, the "10x" means 10 times the productivity of an average programmer. I wonder how productive the average programmer is. I find this question super interesting.
For example, I see more and more programmers who use "Query Builders" and "ORM layers" without understanding the underlying database mechanics.
Coding this way not only takes multiple times longer then - for example - just writing plain SQL. It also often results in code that runs hundreds or thousands of times slower. And complexity explodes as the project grows.
I have the feeling that - with the rise of frameworks - this might be the new "average" of coding. If so, then there definitely are coders who are orders of magnitude more productive then this average.
That article is a post-mortem with an awful lot of hindsight. Not everybody would able to ask the questions Yossi identifies in the post-mortem while the requirements are presented.
Would somebody then, instead, be able to become 10x more effective by thinking 10x more about their work, before they do it?
Personally, I believe there's some level of "intuition" involved, that perhaps some people are just gifted with naturally. I think these people still have to practice though, to build upon that natural ability.
Note that I'm certainly not referring to myself here -- I consider myself Just Average. I'm thinking of friends and colleages I've known over the years who have this seemingly natural gift.
That being said, I also think everyone can benefit by finding some sweet spot between 'thinking hard up front' and 'analysis paralysis'. For me personally that means start by doing something, then revise and iterate. That's just my cognitive style I suppose.
When I hear 10x programmer I think "10x me". I've worked with a handful people like that over the years and it has been a pleasure. If there's a 10x programmer in my team I know I'm in the right team!
There is a huge cost to handwriting SQL too that one mist be careful of - it is very easy to result in poor abstractions as a result of inconsistent apis from lack of abstraction over SQL.
My company is currently in the process of moving back to an ORM after 5 years or so abandoning ORM usage due to nightmarish performance using NHibernate in .Net (maybe more of an indictment on the code than anything else, but I don't know the specifics of the history). We found the company had a lot of problems that resulted from handwritten SQL, including lack of ability to adequately abstract the logic for proper unit/integrated testing, and inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state.
The worst thing we encountered with handrolled SQL over ORM was that it actually hindered our ability to deliver major business requirements. We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location...not a good situation to be in at all.
> inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state.
You are coding against actual queries? Why not functions to hide the table abstractions:
I think he's saying that there was a lot of duplication in the client SQL for various applications (copy/paste, probably). Using SQL functions/procedures/views to return the same result sets would eliminate the duplication and provide "one true source" for such queries. Plus, it would reside in the actual database, allowing it to be portable and not requiring any extra work in the client applications.
This is not only about frameworks and ORMs, it's about refusing to comprehensively understand stuff before you use it or change it. It can be any abstractions, even (usually) the ones you created by yourself.
It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!).
Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos.
I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole.
I've seen a great compact example recently, one of the students I supervised wrote sth like this:
The student wrote both methods, and got rejection from tests because of NPE. He wanted to fix it by adding
if (persons != null) {
...
}
:) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.
Yeah, the first argument backs the notion that there are developers who are 10x better than than the worst developers -- I take "10x" developer more to mean 10x the average/typical developer.
Also I love, love this line: "10 engineers writing the wrong code could definitely be out performed by a single engineer writing the right code."
Especially as it extends up the chain -- 10 employees building the right product can outperform 100 employees building the wrong product. Etc.
There may or may not be 10x programmers - I, personally, find the reasoning in the article convincing. And I think there may be programmers that vastly outperform others in programming tasks. So I think there may be 10x programmers.
But, I believe it does not really matter (at least most of the time, most meaning something like 99%).
We are working in teams, inside a company that has a certain culture, rules and processes. How we work together as a team and how the company/culture/system we work in helps us in / prevents us from doing our work has a much greater influence in overall results than individual programmer performance.
This also includes how the system supports us in learning (not only formal training, even though this might be beneficial) and teaching. Teaching each other skills needed for the job, and learning how to work together so that we amplify our collective skills and dampen our shortcomings.
It also doesn't matter if 10xer's exist for most companies.
Most just don't have the money, culture, management, fellow coworkers, or whatever else to keep that 10xer (often times even get them in an interview).
Seriously most companies can't even keep a 10xer janitor if they tried.
This completely misses the point. Nobody is denying that they exist; it's that they are completely irrelevant to software engineering because software engineering is delivering consistent (not necessarily "outstanding" or "very good") results with the fat part of the bell curve.
Yes, you can deliver a project with the right person with 100th of the effort, but this is not repeatable (the person will move on or very likely work as singleton contractor). If you get a 10x developer at the rate of the 1x developer and can convince him to stay at this pay grade, then we would be having an actual topic to discuss.
Look at the number of massive outright software project failures (no delivery, ever.) I think there are many times when you'll cheerfully pay at least ten times for the one guy who could actually get you to the finish line.
I wonder what you should do if you are one of these 0x programmers. Throw away your degree and change career? Or try to close the gap? But what if you really aren't able to become one of the 10x?
I wonder because I feel that this is my situation. The people I started working with are so much above my skill level, it's ridiculous.
Maybe 0.5x? I'm sure I had a negative performance impact on my former team. They would have been faster doing all features by themselves instead of reviewing and correcting my pull requests. New team isn't as good as the other one, but I'm still behind.
I've learned quit a lot in the former team, the new team on the other hand.. I've hardly coded anything this year. I work with code, but I don't build stuff. As a result, my coding skill progression stopped almost completely, while general IT skills improved somewhat. In my former job, I was able to work at my own pace and do everything by myself (SQL dev). I believe I was good there. But now? Working with big systems in Java developed by others in unknown frameworks, done by high skilled people.. I suck.
Do you like software development, in general ? In other words, is there something that you've worked on in the past that you were passionate about, and found yourself thinking about, even when not "working" ?
If the answer to any of the above is "yes", then you may just need to find another job that better suits your interests and needs in terms of career progression. Software development jobs can vary greatly in terms of being interesting/challenging. Being on a big development team is sometimes not the best option for developers that are just starting out. There's simply not enough room to grow and explore because your work environment is so rigid and pre-determined by others.
Your first sentence is exactly what I've asked myself recently. What do I think about once I'm no longer sitting at my desk? What kind of problems does my brain try to solve?
Incongruously, I think mostly about non coding related problems. Still, if I understand the code base and its frameworks, the degree of coding related thinking increases substantially.
But normally, I automatically think more about "How to improve the reviewing process? How to improve onboarding? How to calculate costs? How to organize / improve our customer support?" and similiar problems. Those topics are all more in the project manager department. Maybe I'm better suited for that kind of role, but I can't take myself seriously if I haven't build a strong tecnical skillset.
> I automatically think more about "How to improve the reviewing process? How to improve onboarding? How to calculate costs? How to organize / improve our customer support?" and similiar problems.
FWIW, those interests really should make you a good choice for moving into a less technical role. I don't know if there are career paths that don't start with being someone technical but that's something I would persue, if I were you.
It's really not that difficult to explain, Programmers are like musicians. You have the ones that have over 100,000 hours of dedicated professional practice and are grandmasters, those that play in a band, and those that do it casually.
> Imagine traffic increases exponentially, and this average team setup an average website, with a data storage engine that’s hard to shard, hosting that doesn’t have enough redundancy, version control without proper backup, no CI environment, and no monitoring. How productive will those 10 coders be if they are spending all their time putting out fires?
The 10x developer may or may not be a myth, but the idea that you can design your system for exponential traffic increase without any tradeoffs is not engineering, it's fantasy. I guess "no silver bullet" is dead in the year 2017.
This was a weird example to me because anyone who's dealt with exponential traffic increase knows that you will end up rewriting several times. Dean's Law: "Plan for 10x growth, but expect to rewrite before 100x":
Additionally, one thing the best programmers I know have all drilled into me is don't write code speculatively. You should write code because it solves the problem you have now, not the problem you think you're going to have in a couple years. It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to foresee the future.
The problem is that you usually don't know in which direction that flexibility will be required.
I can't count the number of times I've "trivially extrapolated a bit", showed my boss or VP, and then gotten back "actually, we don't want to put any more effort into X. I appreciate how you went above-and-beyond, but priorities have changed, and it turns out we really want Y instead," followed by much handwringing when I go back to the code and find out that the flexibility and modularity that I built into the system expecting we'd do more of X next actually impedes progress in making it do Y.
Lest you think this is just bad management - I work for myself now, on a startup, and I have the same problem (or would had I not beaten this habit out of myself). Very often, I'll think "Woah, there's a much more elegant approach that will let me do Y and Z much better at relatively low engineering cost", and then I'll finish X, and put it in front of potential users, and they'll say "Actually, we don't care about Y and Z at all...why would we want them? We want to do A and B instead", where A and B take the product in a completely different direction from Y and Z.
There is a place for planning a little bit ahead, but that place is to plan to reach the next milestone as quickly as possible. You should never try to guess what the milestone beyond that is without checking in with users or management.
Without an established culture of adaptation and refactoring, your team lacks the perspective necessary to know what the 'right' architecture is.
The paradox here is that people who could extract the most benefit from a rewrite don't have to ask for one, and those least equipped to benefit constantly blame their problems on the lack of one.
At the end of the day, the rewrite or 'perfect architecture' is a dodge. You get to be left alone for 4-8 months with nobody hassling you, which means the perverse incentive is:
The problem here is that the concept got off on the wrong foot and has stayed on the wrong foot since then. The conceptualization of software developers as some sort of industrial worker who churns out widgets all day long is simply ludicrous. In the days back when a lot of software development involved just doing the same thing repeatedly for hire the measurement of "productivity" based on "output" at least had some basis in reality. But that era didn't last long, modern software development is an incredibly automated endeavor. We use automation (compilers, linkers, IDEs, unit test frameworks, and so on and so on) to take out a lot of the drudgery that previous generations had to grapple with more directly. Today productivity in software development is not about churning out lines of code (even assuming it ever was) it's about building stuff that has a high value (to users/customers et al) and low cost (operationally, tech debt. wise, and so forth). And there, of course, the range in productivity spans not just one but many orders of magnitude between the highest and lowest tier of coders.
There is a small group of folks (charitably tiny, uncharitably maybe like 1/4 of all devs) who on average contribute negligible or even net negative overall value vs. cost to the code base as they work. And there are some folks whose individual work has a value of upwards of several billion dollars. In between there are perhaps bunches but it would be a stretch to imagine that there were only one bunch where the vast majority of other devs were collected within a single order of magnitude in terms of the value of their work.
And, make no mistake, I'm not just talking about moving up the "hierarchy" or the management chain in terms of value. Even if you restrict your dev. sample to just individual contributors with more or less identical work responsibilities (instead of say, junior intern vs. principal architect or somesuch) you will still find many orders of magnitude difference in value and quality of work.
The reason why this isn't objectively obvious is that so much of software is invisible. Yes, you can in principle read all the source code but in practice that's not tenable. And we still do not have all of the tools, models, or even terminology to concretely break down the structure of complex software systems into representations that aren't extraordinarily handwavy and overly simplistic basically almost immediately (compare, for example, an electronics wiring diagram versus a UML diagram or a layer representation). That coupled with the fact that software development is a creative and even artistic endeavor where the value of some piece of work can vary greatly between otherwise very similar examples (which is much less true of, say, bridges or diesel generators) means that estimating the value of a given developer's work a priori is enormously difficult. Indeed, that also explains why hiring is such a constant struggle.
Back in the day, the concept started out very well as a way of trying to convince Muggle bosses (etc) that coding wasn't pretty much the same as bricklaying, with most bricklayers being about the same in precision and productivity.
The difference between an average programmer and a "10x average" programmer is in the architecture and design phase, not the "fill in the methods for the API" stage. If you put people who don't have domain knowledge (or experience) in charge of API design the resulting codebase will easily take 10x longer to complete (if it is ever finished), and maintenance will probably require 10x the manpower.
Doing good design and tooling upfront is at least a 10x opportunity. Too often I've seen it get brushed off by people who want to see quick results, to the detriment of the long-term design goals.
It's hard to explain without having concrete examples to work with. I would say it is all about recognizing when the trade-offs will pay off. Like, knowing when a quick fix will do and when a whole system rewrite is necessary.
Good fundamentals are also good, like being attentive to details and never letting crasher bugs remain unfixed.
I don't think you can imbue good habits on people who don't want to be imbued. So that's what you need to ensure first.
Good questions. You should post an AskHN for this.
Someday we'll have "problem-solving" classes in elementary schools to help teach those basics; and better unambiguous communication, etc. One habit that's been well-documented for a long while is that the best problem-solvers take more time being sure they've understood the problem correctly and settling on an optimal approach before charging in doing the work.
The best habits that often spring from good character - I agree with Bourne on that - those with neurotic motivations or insecurities may choose "solutions" that show off their ability with some extra arabesques, rather than taking a more straightforward path that's best for the company, for example. Not to mention being willing to possibly embarrass yourself by asking what may or may not be "dumb questions." That's huge.
Hip firms only hire 10x programmers. They don't pay 10x though, the total compensation is closer to 0.7x + free session beers. For some reason, results have been mixed.
10x only works if you're a team player or if the company is organised in a way that encourages team work.
the 10x is just the guy that's already overcome this blocker that a more junior coder could spend a day on, and if the company doesn't encourage teamwork the junior is still taking a day and the senior is appearing 10x when he should be assisting other coders.
there's more value in a team being 3x than one person being 10x.
247 comments
[ 2.7 ms ] story [ 252 ms ] threadCompanies like MS and google have sufficient data to tell us whether the 10x programmer is a meaningful term.
A lot of being a successful CEO is being at the right place at the right time (of course: in addition to actual qualities).
Anecdote time:
I once was a franchisee of a major (services) franchise that some time ago decided to expand to Germany (I sold my franchise years ago). I'll only talk about one person, but this happened throughout the network, it wasn't nearly as successful as hoped in this country.
So anyway, I personally know one of the guys who lead one of the best franchises in a major German city. He expanded, became responsible for the entire wider area (which allowed him a cut from all franchises in it in exchange for recruiting new franchisees and for advising them).
He had this exact opinion (and he was a former business consultant too, I think he even has an MBA), when a franchisee didn't do well that he just wasn't good enough. He himself was proof, after all, just do your customer acquisitions and all the necessary stuff,and success will eventually come! It worked for him!
When a franchisee failed he acquired their shop, it was in the same city and they seemed to be in very good areas, lots of businesses that fit the description of the target market. Not a big risk one would think given that his own shop was doing exceedingly well with the exact same demographics, just a few miles away.
Long story short, he ended up giving up the franchise for the area as well as the two additional shops he had acquired. Today he has just that one original location. Turned out that the exact same extremely successful guy only managed to be successful in one spot. Not even in very promising areas just a few miles away did it work out!
There were more stories like this, some of them I knew personally (through franchisee training at the beginning where I met many of them), all people who were formerly employed and "important people" in their jobs, and who all thought that it's all about you and the effort and skills you put in. Some of them managed to indeed build a successful business, but they all became much more humble over time, because they all found the large amount of randomness in their success when they tried to expand (area franchise or another shop).
So, tell me again about those successful CEOs, I'd like to learn more... the books are full of such people, successful in one place and time and failing in another place and/or time. Because they themselves are only one ingredient into what is needed for success, and not even the major one ("necessary but not [even nearly] sufficient").
I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst.
So even this scientific study (from the 60s) says that there aren't 10x developers according to this definition: the ratio goes down to sqrt(20), using the geometric mean, if a good-enough sample was chosen. Program size and program execution speed would put that ratio to sqrt(5) and sqrt(10), respectively.
Anyway, in the 60s the profession was in its infancy, so I'm not sure how much studies from this era matter today.
I bet you'd surely find 10 to 1 or 100 to 1 differences in programming productivity on a project like that following waterfall methodology in the 1960's.
I think Fred Brooks was right to argue[1] that we're not going to see dramatic further improvements because we're at the point of diminishing returns on overhead and most of the remaining work is actually inherent to whatever problem is being solved. The closest we've probably come to a change on that scale was the rise of cloud technology shrinking the feedback cycle for testing but I don't think that's been an order-of-magnitude change for most people.
1. https://en.wikipedia.org/wiki/No_Silver_Bullet
That could well be what people perceive. It's not what the studies said. While the article has some good references, I might as well quote Peopleware again just for the fun of it. I churn this out every so often:
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
Further author even punts at the end of article by claiming that its not needed to measure difficult to measure things as we can instead reason our way to the right answer which is practically nonsensical. Measuring is step one in actually reasoning about things.
In short author may be a good developer but he is certainly not a 10x author.
This is roughly what I estimate the productivity improvement a good developer gets when they're working on a task that fascinates them and that they choose for themselves, and without too many dependencies on productivity killing things (like builds and flaky external libraries and services).
The most productive people I knew tended to the people who didn't do as they were told. They were amazingly productive at producing the things that fascinated them, much less productive at the drudge that the organisation demanded of them. Sometimes the organisation was able to recognise that they were doing useful stuff (despite the fact that they weren't always pulling their weight on the things they were supposed to be doing) and they became rockstars, sometimes it wasn't and they became pariahs.
Also, sample size would matter. Assume that there really is a Superwally out there who has worked in programming for seven years for some company without accomplishing anything at all. And I imagine that there is. It would matter a lot if he is part of the sample. In fact, the only sample that would make sense would be all programmers in the world, and now, thanks to Superwally, we all look pretty good.
And of course, there is probably some Hyperwally as well who can smugly boast seven years of negative productivity. Deleting random stuff, breaking functionality, leaving messy code for others to untangle. Adding Hyperwally to the equation and the relative productivity of everyone else would approach singularity levels.
Programmers writing features that add points of failures to previously working systems
and
"From years of experience, a great programmer will know that errors are much more costly to fix later."
So which is it?
They did find a difference between a programmer with 7 years of experience and a programmer with no experience.
1. Those who are good developers 2. Those who can't write any real code (cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the years because they were not able to FizzBuzz)(25%-50% of the market)
The 10x comes from comparing (1) and (2) - although dividing anything by 0 is larger than 10x.
Yes, if you have a small team of say 10 people, a very competent lead engineer can make all the difference by setting up proper testing, SCM, CI, etc. i.e., by choosing the right tools and people for the job.
However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
In my opinion, the most important thing then is to spot anything that will make things go haywire, communicate them and convince the right people that this has to be fixed. If you force a new porgramming language onto the whole team because it makes you, the 10x engineer, more productive, you might face endless discussions, additional training costs and a big backlash ("why do we need this now?") from the team.
Another interpretation of this is that 10x programmers get dragged down when they have to work on teams that are too large or don't grant autonomy.
The (unsurprising, really) backlash was not because their work had slowed down (in fact it solved many problems) but because their non-work was impeded. Flash was a bit dodgy, so browser games were out. Their favorite torrent programs didn't work in Linux. Of course, they couldn't use these reasons when complaining to the boss, so there were some amusing verbal gymnastics....
When I look at great developers, they can not only build things without taking as many dead ends but they can explain why and share their reasoning with the rest of the team effectively.
The very best can not only complete their own tasks well but their "prowess" (for lack of a better term) is witnessed and people seek out their advice.. therefore making others more effective too.
I don't think a lot of people with 10+ years of experience would say no ( if you do, it may be time to change company).
Compared to someone that can't code I'm infinitely faster in theory. Do note that in reality, if someone that can't code needs to write code, he'll likely learn to code first. However, once he learns to write code, he is no longer someone that can't write code.
The 10x programmer isn't 10 times nothing, of course. The 10 times rule is, I think, 10 times better than average. So we have to know the average first.
The amount of programmers rises very fast: IIRC, the amount of programmers doubles every 6 years or so. The average programmer therefore has 6 years experience.
The 10 times programmer has to be 10 times better than that. How is he 10 times better? He has to be able to beat a 10-person team of people with 6 years experience on average. That is a team of 4 juniors with 4 years experience, 3 "medium" programmers with 8 years experience and 2 senior programmers with 10 years of experience.
Imagine a contest where you have to develop a huge SAAS management-like system. One team has the 7 developers described above. The other team is the solo mythical 10 times developer.
Well, I think the 10 times developer is going to have a head start, but he's going to burn out within 2 months, releasing nothing and starting a new project somewhat later. The project manager now has to find a new 10 times developer, but he finds out that no-one can replace him and they need to start over.
Meanwhile, the 7 developers are playing table-tennis and having boring meetings and finish the product much later than planned, but it is done and it sells fine.
About your project, i had the experience of building the exact same project ( an product demo ios app with a web backend and its content management interface). First project had to be done using "enterprise" practices, and the other was free. First one i did with a senior developer helping me on the web interface side, the other with an intern i had to explain what MVC was.
First project took 6 months, plus 2 more because of some guidelines i didn't respect first, plus a whole team of admins to handle the production side. It probably costed more than 100k to the company ( not counting the internal days spent in meetings). The internal team that was supposed to maintain the code wasn't able to do so.
The other took less than 3 months and costed something like 10k, including server cost (i used app engine). The intern made the project evolve for more than a year.
A 10x developper is not just able to produce more, it can prevent you from falling into traps that can simply lead your product to a complete failure, and your company to simply cease to exist.
https://leanpub.com/leprechauns
I liked it
Nor is there a way to quantify "good code" in any scientific manner. It IS possible to identify obviously bad code, BUT "good code" comes in a variety of forms and looks different depending on the experience level of the developer.
In the end, many of the measures that people apply to assess programmers are simply a matter of personal opinion.
edit: downvoters - if you think I'm wrong then please explain your counter opinion, don't just downvote. A downvote without a counter opinion simply confirms my assertion that there is no science to this because you won't identify what that science is, you have only a vague opinion that I am wrong.
The thing about the 10x claim is that it takes something complex and creative and applies a scalar multiplier to it.
Talking about 10x programmers is _semantically_ problematic.
Edit: grammar
It's telling that there's no such thing as industry talent matrix. Instead of general skills - creativity, accuracy, speed, debugging insight, ability to learn new languages/frameworks, team leadership, good-to-have-around vs toxic asshole, and so on - we have this myth of "the rockstar".
A certain kind of management loves because rockstars because having them around reflects well on management (reason number one for hiring them) and supposedly they are super-productive (reason number two, which often turns out not to be true in practice, especially in a team setting.)
The hiring process tests for almost none of the qualities on the talent matrix. There's a ridiculous notion that knowing algos makes you a developer worth talking to, and a slightly less ridiculous notion that a bit of hazing tells you something about how well someone works under pressure.
The bottom line: that after all these decades we have far too little research defining the qualities that really matter in different work contexts, and almost no research at all into how to select for them.
Do people say "I'm a 10x programmer" and get promoted or some sort of perk? Get better jobs by saying that you're a rock star?
Of course not. The premise of 10x programmers, outside of bloviating bloggers, is primarily one that people observe in programming teams. The "go to" person, the person who invariably initiates all of the important shifts and base designs, etc. Many projects start around such a person, they leave and it slowly rusts under a team of normal competency developers, who eventually all disperse and join another project started by a standout developer.
My experience in this industry is that there are absolutely extreme exception developers, and thinking back I'd say it was about 1 out of every 100 developers in most orgs. They were the people who didn't need to be hand held, used heuristics to find solutions, developed designs that invariably became the kernel of solutions, etc. Other developers were critical in the mix, but the notion that all are the same is destructive and unrealistic.
I'm not a 10x person, but I have worked with some. I don't think they are unique to programming..there are 10x folks in every field.
Sometimes you don't need a 10x person, and if you don't, it can seem like they don't matter. In those cases, a few 1x people will do just as well. But I do believe that sometimes you _do_ need a 10x person, and if you do, you can't do the same things without them. In those cases, I'd absolutely take a 'toxic' 10x person over the nice-but-1x alternative.
Part of the issue is that there's more work for programmers than ever, and most of that work is of the 1x variety.....if you're just banging out CSS for some small-business website, it doesn't matter whether you have Jeff Dean do it, or a new grad from Omaha Community college. If, however, you need to write a new globally consistent database abstraction at scale, then the new grad probably won't cut it. If you actually need that thing, then it wouldn't matter if the new grad was the nicest person on earth, and Jeff Dean the most 'toxic' (though actually I understand that he's a very nice person).
The problem is that nobody defending it is specifying what measurement will yeld those orders of magnitude difference, and what is its relevance. Claiming a difference without telling in what dimension is an empty claim, and that is exactly the problem with the 10x developer idea.
(By the way, yes, there are plenty of problems nobody on Earth could ever solve. That doesn't follow from the fact that easier projects fail, but it's not false either.)
Nobody's said there aren't unsolvable problems, the question was whether nearly every massive failed software project (and they're common) represented such a thing - obviously no.
But as I understand it, the "10x" means 10 times the productivity of an average programmer. I wonder how productive the average programmer is. I find this question super interesting.
For example, I see more and more programmers who use "Query Builders" and "ORM layers" without understanding the underlying database mechanics.
Coding this way not only takes multiple times longer then - for example - just writing plain SQL. It also often results in code that runs hundreds or thousands of times slower. And complexity explodes as the project grows.
I have the feeling that - with the rise of frameworks - this might be the new "average" of coding. If so, then there definitely are coders who are orders of magnitude more productive then this average.
I imagine the "10x developer" would just be really good at avoiding this kind of thing ... most of the time.
Would somebody then, instead, be able to become 10x more effective by thinking 10x more about their work, before they do it?
Note that I'm certainly not referring to myself here -- I consider myself Just Average. I'm thinking of friends and colleages I've known over the years who have this seemingly natural gift.
That being said, I also think everyone can benefit by finding some sweet spot between 'thinking hard up front' and 'analysis paralysis'. For me personally that means start by doing something, then revise and iterate. That's just my cognitive style I suppose.
My company is currently in the process of moving back to an ORM after 5 years or so abandoning ORM usage due to nightmarish performance using NHibernate in .Net (maybe more of an indictment on the code than anything else, but I don't know the specifics of the history). We found the company had a lot of problems that resulted from handwritten SQL, including lack of ability to adequately abstract the logic for proper unit/integrated testing, and inconsistent data fields being returned by various queries, resulting in inconsistent api endpoint data returned to the client and thus inability to safely abstract without significant hacks/nebulous data model state.
The worst thing we encountered with handrolled SQL over ORM was that it actually hindered our ability to deliver major business requirements. We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location...not a good situation to be in at all.
You are coding against actual queries? Why not functions to hide the table abstractions:
https://www.postgresql.org/docs/current/static/sql-createfun...
https://dev.mysql.com/doc/refman/5.7/en/create-procedure.htm...
>We had no ability to gate content by various values from other tables without modifying the handrolled SQL in every single location
Again, don't sql functions solve this?
The impedance mismatch between relational and OO is much bigger.
Isn't that roughly what an ORM/ODM is?
It's easier to add a special case check, than to read through the codebase to see if it's even needed, or, God forbid, to refactor in 5 places so it's not needed (it might break sth else!!! I would have to read and keep in memory the whole control flow of the program!!).
Programmers have to do dozens such decisions every day, so after a few months if they go the easy way too often it adds up and creates chaos.
I've done this myself, and seen this done by younger programmers. It's that crucial skill of stepping a few steps back and looking at the code as a whole.
I've seen a great compact example recently, one of the students I supervised wrote sth like this:
The student wrote both methods, and got rejection from tests because of NPE. He wanted to fix it by adding if (persons != null) { ... }:) this example is easy, but in more complex situations it's easy to do the same, and it adds up. This is one of the reasons I dislike OO programming (especially the kind where you hide everything behind a few layers of interconnected objects). Because it makes it harder to understand what REALLY happens on the data level.
Also I love, love this line: "10 engineers writing the wrong code could definitely be out performed by a single engineer writing the right code."
Especially as it extends up the chain -- 10 employees building the right product can outperform 100 employees building the wrong product. Etc.
But, I believe it does not really matter (at least most of the time, most meaning something like 99%).
We are working in teams, inside a company that has a certain culture, rules and processes. How we work together as a team and how the company/culture/system we work in helps us in / prevents us from doing our work has a much greater influence in overall results than individual programmer performance.
This also includes how the system supports us in learning (not only formal training, even though this might be beneficial) and teaching. Teaching each other skills needed for the job, and learning how to work together so that we amplify our collective skills and dampen our shortcomings.
Most just don't have the money, culture, management, fellow coworkers, or whatever else to keep that 10xer (often times even get them in an interview).
Seriously most companies can't even keep a 10xer janitor if they tried.
Yes, you can deliver a project with the right person with 100th of the effort, but this is not repeatable (the person will move on or very likely work as singleton contractor). If you get a 10x developer at the rate of the 1x developer and can convince him to stay at this pay grade, then we would be having an actual topic to discuss.
I wonder because I feel that this is my situation. The people I started working with are so much above my skill level, it's ridiculous.
How much more experience do they have than you? Do you feel like you learn new things?
I've learned quit a lot in the former team, the new team on the other hand.. I've hardly coded anything this year. I work with code, but I don't build stuff. As a result, my coding skill progression stopped almost completely, while general IT skills improved somewhat. In my former job, I was able to work at my own pace and do everything by myself (SQL dev). I believe I was good there. But now? Working with big systems in Java developed by others in unknown frameworks, done by high skilled people.. I suck.
If the answer to any of the above is "yes", then you may just need to find another job that better suits your interests and needs in terms of career progression. Software development jobs can vary greatly in terms of being interesting/challenging. Being on a big development team is sometimes not the best option for developers that are just starting out. There's simply not enough room to grow and explore because your work environment is so rigid and pre-determined by others.
Incongruously, I think mostly about non coding related problems. Still, if I understand the code base and its frameworks, the degree of coding related thinking increases substantially.
But normally, I automatically think more about "How to improve the reviewing process? How to improve onboarding? How to calculate costs? How to organize / improve our customer support?" and similiar problems. Those topics are all more in the project manager department. Maybe I'm better suited for that kind of role, but I can't take myself seriously if I haven't build a strong tecnical skillset.
FWIW, those interests really should make you a good choice for moving into a less technical role. I don't know if there are career paths that don't start with being someone technical but that's something I would persue, if I were you.
The 10x developer may or may not be a myth, but the idea that you can design your system for exponential traffic increase without any tradeoffs is not engineering, it's fantasy. I guess "no silver bullet" is dead in the year 2017.
https://static.googleusercontent.com/media/research.google.c... (page 11)
Additionally, one thing the best programmers I know have all drilled into me is don't write code speculatively. You should write code because it solves the problem you have now, not the problem you think you're going to have in a couple years. It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
It's very much a novice mistake (one that I've made a dozen or so times, sigh) to think that you can jump straight to your "ideal" architecture without any of the steps or missteps along the way.
Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to foresee the future.
The key words are slightly. The trap is to overgeneralise or apply a technology or approach like a hammer without understanding its limitations.
Out is impossible to foresee the future, but trivially easy to see current requirement and extrapolate a bit.
I can't count the number of times I've "trivially extrapolated a bit", showed my boss or VP, and then gotten back "actually, we don't want to put any more effort into X. I appreciate how you went above-and-beyond, but priorities have changed, and it turns out we really want Y instead," followed by much handwringing when I go back to the code and find out that the flexibility and modularity that I built into the system expecting we'd do more of X next actually impedes progress in making it do Y.
Lest you think this is just bad management - I work for myself now, on a startup, and I have the same problem (or would had I not beaten this habit out of myself). Very often, I'll think "Woah, there's a much more elegant approach that will let me do Y and Z much better at relatively low engineering cost", and then I'll finish X, and put it in front of potential users, and they'll say "Actually, we don't care about Y and Z at all...why would we want them? We want to do A and B instead", where A and B take the product in a completely different direction from Y and Z.
There is a place for planning a little bit ahead, but that place is to plan to reach the next milestone as quickly as possible. You should never try to guess what the milestone beyond that is without checking in with users or management.
Without an established culture of adaptation and refactoring, your team lacks the perspective necessary to know what the 'right' architecture is.
The paradox here is that people who could extract the most benefit from a rewrite don't have to ask for one, and those least equipped to benefit constantly blame their problems on the lack of one.
At the end of the day, the rewrite or 'perfect architecture' is a dodge. You get to be left alone for 4-8 months with nobody hassling you, which means the perverse incentive is:
There is a small group of folks (charitably tiny, uncharitably maybe like 1/4 of all devs) who on average contribute negligible or even net negative overall value vs. cost to the code base as they work. And there are some folks whose individual work has a value of upwards of several billion dollars. In between there are perhaps bunches but it would be a stretch to imagine that there were only one bunch where the vast majority of other devs were collected within a single order of magnitude in terms of the value of their work.
And, make no mistake, I'm not just talking about moving up the "hierarchy" or the management chain in terms of value. Even if you restrict your dev. sample to just individual contributors with more or less identical work responsibilities (instead of say, junior intern vs. principal architect or somesuch) you will still find many orders of magnitude difference in value and quality of work.
The reason why this isn't objectively obvious is that so much of software is invisible. Yes, you can in principle read all the source code but in practice that's not tenable. And we still do not have all of the tools, models, or even terminology to concretely break down the structure of complex software systems into representations that aren't extraordinarily handwavy and overly simplistic basically almost immediately (compare, for example, an electronics wiring diagram versus a UML diagram or a layer representation). That coupled with the fact that software development is a creative and even artistic endeavor where the value of some piece of work can vary greatly between otherwise very similar examples (which is much less true of, say, bridges or diesel generators) means that estimating the value of a given developer's work a priori is enormously difficult. Indeed, that also explains why hiring is such a constant struggle.
Doing good design and tooling upfront is at least a 10x opportunity. Too often I've seen it get brushed off by people who want to see quick results, to the detriment of the long-term design goals.
What are the decision-making habits that make someone significantly more productive on a software engineering team?
What are ways to imbue a team with these habits?
Good fundamentals are also good, like being attentive to details and never letting crasher bugs remain unfixed.
I don't think you can imbue good habits on people who don't want to be imbued. So that's what you need to ensure first.
Someday we'll have "problem-solving" classes in elementary schools to help teach those basics; and better unambiguous communication, etc. One habit that's been well-documented for a long while is that the best problem-solvers take more time being sure they've understood the problem correctly and settling on an optimal approach before charging in doing the work.
The best habits that often spring from good character - I agree with Bourne on that - those with neurotic motivations or insecurities may choose "solutions" that show off their ability with some extra arabesques, rather than taking a more straightforward path that's best for the company, for example. Not to mention being willing to possibly embarrass yourself by asking what may or may not be "dumb questions." That's huge.
the 10x is just the guy that's already overcome this blocker that a more junior coder could spend a day on, and if the company doesn't encourage teamwork the junior is still taking a day and the senior is appearing 10x when he should be assisting other coders.
there's more value in a team being 3x than one person being 10x.