A personal story about 10× development | Hacker News Reader

A personal story about 10× development

nibblestew.blogspot.com

289 pointsbkor225 comments

Let me tell you about one of my personal stories.

The project I got transferred to was the thing of nightmares.

Not deterred, I hacked into it a shitty solution and shipped it very fast. I shipped it so fast that suddenly I had everyone's attention. And I shipped another thing super fast and got more attention. One day, I said "this needs to go", and everybody listened, architects and directors alike. 6 months later, most of the code was replaced by my code or something originating from it. Every projects and features delivered on time with great appreciation of the clients.

You have to make it like software development is not a problem at all in the eye of your client and never never go behind the line where this is not true. The day software development is a problem, you lose. You must deliver software like you're delivering a book from amazon, no matter what. Because then, you got credit to make things better, which creates a positive loop. In that particular instance, I used some rushed victories to get more credits to make things clean later on. The guys who say they can make things clean but never ship and never win any battle against a deadline are just funny anyway.

To be honest, I took some fights in my career. I was fighting some dudes in every project. But don't fool yourself: if you're not really capable of making things better, then fighting is useless, just improve. You win the fights because the managers are on your side and you get them on your side by making software development not a problem at all.

edited

I really don't get your point. How does this help this guy's situation?

He couldn't get things released quickly because he couldn't even get the program compilied without serious effort involved.

If there was minimal code and a lot of the dependencies were unmodified forks of common things, the GP here is likely of the opinion that he should have started ripping the wiring out and replacing it with something that works.

That generally takes a while. Not great if you want quick results.

I agree with this. Showing results is the easiest way to influence people, especially when it comes to software devs and management.

As a manager, I'm more inclined to trust someone who's delivered results even in challenging codebases. It's human.

  "trust someone who's delivered results even in challenging codebases"

Yes but comparing a guy's productivity when he is demonstrating how difficult the environment is to make progress is poor management. He has already shown the results in previous project.

Both you and OP are right. May be the codebase you went in could be salvaged. Not true for OP where he has to prepare for a big launch.

> Not deterred, I hacked into it a shitty solution and shipped it very fast.

And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter. You may look good, but the team / dept / company is worse off, and someone else has to clean up.

Well, that depends. You haven't actually seen the product so the assumption that it sucked and needed cleaning up may be a faulty one. I've seen the 10x phenomenon first hand a couple of times and some of those people really are that much better that their 'quickly hacked out solution' still beats your 'carefully considered product of 12 individuals'. In fact some of these simply work better because they are the work of a single talented individual, no meetings, no distractions, no comms overhead or having to explain stuff. Design by committee is rarely better than design by a good craftsman or woman.

The parent literally said it was a "shitty solution".

I agree design by committee can produce awful results - and I said nothing about a single person doing a design as being an issue.

People overestimate the duration that their software will be used, so in many cases imperfections aren't as important as a developer might think they are.

My last project I released still had about 20 TODOs in the code. I launched it, it got great reviews, everyone loved it, then I got a new project and they deprioritized the "cleanup" phase. I suspect the edge-cases are just getting handled manually - no one cares and I'm still a hero.

> You may look good, but the team / dept / company is worse off, and someone else has to clean up.

The people/team handling it manually probably care

Here’s a problem:

The alternative to shipping something that works good enough, on time often isn’t to ship something perfect on time but to not ship on time or even worse, -at all.

That would be even worse for the people/team supposed to use the product.

> People overestimate the duration that their software will be used

Please justify that.

I did some software, a not too complex chunk of work for a midlands (UK) retailer in 1999. It dealt with a couple of million pounds of retail orders that year. Not so big but not trivial either. It was still in use in 2015, and quite possibly is today (although the boss told me they re-used it for a rather different purpose by their sales reps).

It was very reliable because I fought to keep it simple, and tested it brutally (eg. the core part took 5 days to write but got 3 weeks testing, founding only 2 errors, but it was 2 errors fewer).

If it was crap it would have been junked so I'll claim that the end quality contributes to its life.

High reliability tends to stick around. I think lex/yacc started in the 70s and is still around today in the form of its spiritual successors flex/bison. Ancient but still grinding along.

' In a 2008 interview, Johnson reflected that "the contribution Yacc made to the spread of Unix and C is what I'm proudest of" ' (https://en.wikipedia.org/wiki/Yacc)

If you ship crap its lifetime is intrinsically much shortened. That's my thesis anyway.

So tell us, how is a shitty solution better than a well designed testable solution? Literally every book on project management is about the development cost vs maintenance cost and how the latter beats the former. But yeah, keep dreaming.

Because what a "10x developer" (i would just call them pragmatic, personally) might call a shitty solution is still better than what you may call a well designed testable solution?

Not everything needs 90% test coverage and more comments than code to be good. And not everything with 90% test coverage and more comments than code is any good at all.

This is so true, because people that are really good at something usually hold themselves to incredibly high standards (which is one of the main reasons they become master craftsmen in the first place).

Yes. The standard is so high that they can't even find words for it. So they just call it simply shitty.

Not at all. The quality of the code may be terrible.

BUT - when someone else new comes along to look at it, the 90% code coverage, and comments helps them immensely - they can get up to speed to fix whatever bug has appeared a lot quicker.

Pragmatism based on shittyism? Or how shall we imagine this? Is there a motto for this? "We excel in shitty code or something?"

I think it's just another variant of Less is More

I think you are missing the point. That someone calls their own solution "shitty" doesn't mean that it's shitty by your standards, its shitty by theirs. The reality is that people have different standards. I don't understand the hate you seem to be exuding for productive people.

The key word here is "solution." If your code is supposed to do a job, and for whatever reason it's not doing that job, then you do not have a solution.

Code that doesn't do the job is worthless, no matter how testable and well-designed it is.

Of course you can debate whether this is a management (scheduling, resource, PM) problem or a developer (competence, architecture, tool choice) problem - most likely some of both.

But whoever is responsible, it's still a non-solution.

> Literally every book on project management

The real world is much sloppier than any book will ever tell you.

> is about the development cost vs maintenance cost

Absolutely true.

> how the latter beats the former

If you're believing that equivocally ((I don't think you personally are btw) then I don't think you're reading the advice the book is giving you correctly.

A shitty technical solution that gets to market quicker often (not always) can make the company more money in the long run. There is no "one right answer" here, it's all about judgement. 100+ tech DD's and counting...I've seen the whole spectrum. I've seen a $40M revenue (38% EBITDA) tech company built using a FileMaker-like tech stack (all WYSIWYG). And yes, I'm serious.

Keep reading... One day, I said "this needs to go", and everybody listened, architects and directors alike. By shipping something that worked he bought himself time and credibility which he then used to replace the shitty solution with good code.

No, they did a thing that got him ahead - and they hoped enough to fix the thing he did before.

Now, if they hadn't gotten the credibility (due to the short term fix for thing they wrote broke sooner than expected), or they gained a lot more credibility and moved in the company, or out of it, the broken thing would still be there, and someone would have inherited it, and had to refactor / relearn / replace it.

One of the points about 10x devs that people are pushing back on is this - do the thing to a minimum spec, drop it on the floor, and get kudos for it, while the rest of the devs run around picking up the pieces.

> And moved the burden of maintenance to someone else?

If you read on:

> > One day, I said "this needs to go", and everybody listened, architects and directors alike.

The OP hacked a shitty solution to make people listen to him. Once people started listening to him, he found it easier to persuade them to let him improve things.

> And moved the burden of maintenance to someone else? If so, this is one of the things people are complaining about 10x dev on twitter.

Sometimes the burden of maintenance is the price you have to pay go get an operational/production system early on and enables you to let other requirements emerge earlier.

You might focus on the "burden of maintenance", and also assume that you're saving time by taking the long route to production, but letting requirements emerge early on in the project is also a significant time saver as it enables the project to avoid committing the mistake of investing time developing a goldplated solution that will have to be thrown out.

You need to accept the fact that the "burden of maintenance" is always there and it will always be there, whether you invest years rolling your goldplated solution or just dash to production with a quick and dirty solution. You don't get rid of that burden by aiming for an academically pristine implementation that takes ages to deliver. Requirements do change, and do so continuously. Heck, designing stuff for a scale that will never be required is also a major problem. So, why would anyone be concerned with having to spend 120% of the time developing a solution if that path enables you to get up and running in 20% of the time?

> You must deliver software like you're delivering a book from amazon, no matter what.

This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball.

If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.

"hey, this framework seems hellish, we might face some problems"

The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.

I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done.

Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard.

While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.

I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt.

I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often.

I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.

You shipped hacky software very fast, and you think this is a good thing? Sounds like you got ahead personally at the expense of anyone who had to use what you wrote :/

> You must deliver software like you're delivering a book from amazon, no matter what.

If you are taking responsibility to maintain it for 15 years, feel free to go on. Otherwise, please step down and let professionals do their work.

I suppose downvotes are from so-called project managers whothinks that valuable things are created by checking boxes in a spreadsheet.

More likely from developers who hate to identify as developers because developers like to focus on development problems without empathy for the end result.

100% true. You don't get to replace a pile of shit or even to call it a pile of shit before you demonstrate that you can navigate the pile of shit and teach it new tricks, otherwise you have no credibility. This of course means, at least theoretically, that a sufficiently big pile of shit never gets replaced (since nobody can (or wants to) be sufficiently productive with it to gain the necessary credibility) and might sink the company which made it. But there's no other way. There are always 10 people telling that the code is shit and the only reliable way to tell that some of them are trustworthy is by observing their ability to get things done in the existing code base.

I think you make a great point but the argument depends on the unstated assumption that master shit navigator == master architect, and I'm not sure how often that's true. They are different skills (maybe?) and while I'm sure there are loads of people with both skills I don't think it's universal.

I personally know one engineer that after a decade of being the 10x rockstar shit navigator finally got the opportunity to create a codebase from scratch. They'd been dreaming of doing such a thing for years and had the design all planned out. It was to be the shiny new product for the company.

One day the people upstairs finally gave their blessing. The ninja worked alone, making all the decisions, with full support of upper management. The result was a great big steaming pile of shit that nearly sunk the company. After a short period of mental health problems the ninja was promoted to shogun and the company hired a new shit navigator.

In football (soccer) it's easy to observe that good players can be good in totally different ways and/or situations. And it's also easy to observe players who were once thought of as good or bad can totally change either way when they change teams. It's a shame engineering performance can't be as easily observed.

The story has survivorship bias. I have similar stories that are exactly the opposite. Started on a prohecr, refused to ship crap, shipped the right thing late to the delight of customers and supporting staff.

The other main point is that while I'm doing this thing that gained cred and leeway, at the time I'm just trying to do the right thing in the eyes of people who have to deal with it first hand over the long term including maintainers of the software. At no point dud I think if I do this and look good I'll have the points to fix my mess later or any sort of gaming strategy at all.

It can also go the other way in that your shipping in the face of adversity can be taken as evidence that the adversity isn't actually that bad. And... that's kinda legitimate, although weighting it too heavily is bad.

I find comments like these, which boil down to “stop complaining and hack a solution already” to reinforce the problem identified by TFA, which is that context matters. I feel like OP has elided that fact; the context is that a hacked up solution was acceptable here. That is not always the case, and sidesteps the point that context is king

Sounds like you’ve advanced in your career by undermining your teammates and sacrificing professionalism in order to win praise from people who are willing to put systems and users at risk without understanding the co sequences.

I understand your point, which basically boils down to the axiom of managing expectations. But sacrificing professionalism is not something that should be accepted as normal, let alone celebrated as clever. It’s the oldest trick in the book.

"There is hardly ever lock contention, so I just ignored locks in my coding. It really sped up my deliveries and I got a good reputation for moving quickly. Sure there were some corner cases to clean up later, but by then I had moved onto another project where I moved fast and broke things!" - fictitious person we've all known

Let me congratulate you. I'd be very yealous of such an achievement. You probably had things on your side, like being able to ship/deploy when you wanted and cooperative colleagues letting it pass review quickly. As for the 'just improve' part, few people can. Even experienced people like myself who are not at all bad programmers. Some things just take talent.

In my personal opinion, the fact that in discussions about 10x engineers, many of the anecdotes and ideas try hard to discredit/disprove the concept¹ rather than presenting real-world examples of very productive engineers, indicates the fundamental will not to recognize them, simply because of pride.

So I'll give a short and sweet argument: read John Carmack's biography and code (both in detail), then feel free to argue that he's not a 1000x engineer, and/or that he's the only one in the engineering world with such capacity.

¹: I agree, though, that "10x" is a profoundly misguided label

I don't think anyone doubts that outliers exist. That is obvious and true in any profession.

It's more about what a "10X" is. If someone comes up with "10X developers use black background and their x key is more worn out than the e key," I think it's not unreasonable to question that.

Also the question of whether someone who's able to spit out great code really fast but is incapable of testing, documenting, or architecting something is indeed "10X".

So the question is not "do outliers exist?" but "what qualities do outliers exhibit?"

I doubt that it's about writing code quickly but instead about how they architect the system. They build in a way that makes the code easier to use, easier to add features, and less prone to errors (because it's more straightforward). I always think of it as someone who lays a solid foundation that lets them build quicker and better.

I'd say it's this, but with a couple more thing. One is a lot of experience with the tools they are using. Not having to learn something new saves time. The other is not over-engineering. They have a great idea of the scope and scale of the project, and avoid programming for things that would be out of scope.

The 10x label, especially as described by the tweet that started the tweetstorm is the situation which you may encounter when someone who designed the system understands it yet its not comprehensible to anyone else, because either:

* their design is poor

* they didn't take the time to document it

* they don't take the time to explain, mentor and in general communicate with others

This is a way more common situation than the one you're describing (John Carmack)

I haven’t been exposed to this tweetstorm but that sounds like the opposite of 10x. If no-one else has named it I’d call it the pig-in-mud engineer: They’re happy working with that codebase because they’re used to it (and it probably contains a fair bit of their excrement) even though no one else can get anything done in it.

> This is a way more common situation than the one you're describing (John Carmack)

FWIW i remember reading that Carmack didn't really document nor explain his code and all people who bought id's engines got was a single day to ask questions about it to him and that was it.

On the other hand for the vast majority of its life, id was a very small studio (IIRC the entire team who made Doom 3 was just 21 people - this includes programmers, artists, designers, etc) so chances are if someone wanted something they'd just ask him directly. I also remember a comment about programmers at id not having meetings and decisions were taken in informal discussions.

Yeah I've often wondered if many of the heroes we celebrate might be heroes by means of being at least a bit selfish and less of an ideal team player :) Its interesting to read that that might be the case even with J.C.

An amazing engineer who is also an extremely strong team player is less likely to be that noticeable because the contrast between them and the people around them tends to disappear in those situations.

I think part of the problem is people are talking past each other. There is clearly a distribution of talent, as you yourself say - Carmack might be a 1000x engineer. But that sort of makes the point against the 10x idea. We talk about the idea there's a group of 1x engineers and a group of 10x engineers.

10x engineers are just a phenomenon where an outlier exists in a standard team. IN reality it's quite rare - all those 10xers are employed by Google working in teams of 10x engineers all looking like a 1x engineer. It's only when a 10x engineer stumbles into a 1x team you suddenly see this effect.

It's not just relative to the team, it's relative to the industry median.

What's the industry median? Does anyone know? People who hire keep reporting that a lot of candidates can barely pass fizzbuzz. 10X compared to that probably isn't that unusual.

I think people on HN and Twitter absolutely overestimate the global industry median.

Just to mention one dimension of it: There are many self-deprecating jokes about how 1x programmers use StackOverflow all day. I'd argue that it's actually the opposite: good Google-Fu alone can make you a 10x engineer! Many developers in continental Europe or Asia still struggle with English. They'll get stuck tinkering around for a day when the solution is result #1 on Google.

I think fizzbuzz is an interviewing artifact. I've never worked with someone who couldn't write a fizzbuzz. But I've heard lots of stories of people interviewing them.

I think the reason is the number of times a developer interviews is reciprocal of his talent. Great developers don't have to interview often. Anyone who has worked with them will vouch for them and they pass most of their coding interviews. Really shitty developers have to interview 100 times before they get a job. So you interview 100x more shitty developers than great ones.

* This description is to illustrate a point. I know there are plenty of great developers who interview terribly and shitty ones who interview well, but on average good developers interview better than bad ones.

The problem that I have with the '10x' label is that it is often linked to an understanding that engineering ability is innate.

Whereas, everything I have observed suggests that engineering skills are taught, and only taught. At one time, John Carmack couldn't code like John Carmack.

With the right training, guidance and mentoring, with the right team to collaborate and build with, and with the space and motivation to deeply consider how to solve problems in a useful, pragmatic and productive way, almost anyone can be a 10x engineer.

Keep in mind discussion about this is related to companies hiring "only the best". Even though they exist, I highly doubt there are enough 10x engineers out there to supply even all the startups in the world with employees, much less all software companies. This is why the discussion about it is so pointless and unrealistic: if companies only hired 10x people, 99%+ of software developers would likely be unemployed.

I dont know a lot about him, but his specialization is a good source of outperformance. If he was to write a graphics based C++ library I would have no doubt he would be a 1000x times developer. If he was forced to modify a existing old corporate CRUD codebase, I'm not convinced he'd be 10x.

I know this is a fact. I’ve seen brilliant devs struggle with other code based because lack of domain (technical and business) and fail miserably.

The project I got transferred to was the thing of nightmares. It was a C++ project and all the bad things that have ever been said about C++ were true about that code base. There was not much code but it was utterly incomprehensible. There were massively deep inheritance hierarchies, compilation speed was measured in minutes for even the most trivial changes, and so on. It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable).

Oh no, it seems like a hyper-modern-C++ developer lead the project and transformed the code into template-metaprogramming madness... (inferred by the absurdly long compile times) Deep condolences to all the people who worked on the project.

I have done this when I was younger, after reading Modern C++ Design and the Template Metaprogramming book. I am sorry.

Please not I'm not saying those books are bad, just blindly apply stuff because you think it is cool and fancy is probably not good leadership.

How do you know how to use the new shiny things without real practice? My friend, we have all done this. (after about the 10th time the 'new technique' turns to a mess, you become very conservative about 'new things').

I consider this one of the milestones leading to the senior title

Ideally, I prefer to practice radical new approaches on hobby projects, or single person explorations, rather than team projects.

Modern C++ Design is simultaneously a work of genius and a practical handbook on how not to write maintainable software. I've never seen anything like that book.

One of the reason why sight-unseen I would actually prefer to be dropped into a c based project than a c++ based one.

Sure. As long as code generators that parse adhoc type descriptions from header comments and spit out code for a homegrown object oriented system / generic data serialization framework are banned on sight.

Or most code generators in general. If you are using a code generator to bring features from other languages to C then just use those other languages.

My impression is that these are less common in c codebases than simply abusing c++'s built-in features is in c++ one (probably cause the former actually requires a lot more tech skill than the latter).

Maybe I'm wrong?

They are less common, but in general doing big projects in C as opposed to C++ is less common, at least in my experience (note though that it might be my bias on working with games and desktop software).

C doesn't allow for much overengineering and most C projects tend to be simple (well, they tend to be libraries that do mostly one thing) but if someone really wants to overengineer a C project they can put the worst C++ architecture astronauts to shame since as C doesn't allow for much by itself they need to work outside of it (hence generators) and there are no limits to what you can do outside of C.

Not very dissimilar from golang as far as (badly implemented) code gen goes.

You just get more macros then.

It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable).

Serious question: how do these people make it past intermediate level? Luck, no major catastrophes/bugs, putting in 14 hour days, all of the above?

Maybe things are different in data science, but I was kind of the data science equivalent of this at one point in my life. It left me with nothing but bad blood between myself and former colleagues and employers.

I’m a definite believer in 10x developers because I’ve seen these mythical beasts with my own eyes.

For instance, dev teams of 20+ where one person is the absolute backbone of the team and churning out features faster than the rest of the team put together.

I’ve seen maybe 5 instances of this across hundreds of teams I’ve worked with (I was a developer turned consultant so have a lot of data). They are rare beasts but 10x devs absolutely exist.

Maybe you're only aware of these beasts because their codebases need disproportionately more maintenance? Please say yes. :-)

I am not saying you are wrong, but could it also be:

1. the person had been there the longest, and had the most context on the code base.

2. There was very little docs on the code base, so new people had to go to them.

3. This person would just do the feature instead of helping the other person implement the feature, and ensure their position as "top feature churner"

If these are true, they may be 10x of the others on the team, but they are holding the team back by not dropping themselves to 4x and lifting up the other team members to 2x.

It's so weird to see so many people argue so hard that the Usain Bolt's of the programming world simply cannot / should not exist.

Sprinting - individual sport.

Development - team sport. You could put Messi on my company's 5 a side lunch time team, and we still wouldn't win the champions league, and the skill of the others on the team would atrophy, and they would become over reliant on a single person. Not a great thing for a team.

A true "10x" engineer raises up the team by 10x by doing the things a lot of devs hate doing - docs, mentoring, guidance (without taking over someone's feature), and knowledge sharing. Not shipping :all-the-things: on their own.

Oh, a thousand times this. Absolutely. I would love to work with that developer.

> Messi

One of my assertions is that Messi hasn't proven himself to be a GOAT until he's been great somewhere else. It's easy* to perform at a high level when the entire team is built around you as at Barcelona. In non-Messi-specific environments (ie Argentina national team), he just doesn't perform as well.

Whereas Ronaldo, on the other hand, has done it in several distinct environments and elevated the teams he's been in (which I guess makes him a "true" 10x player?)

honestly, I just googled "best football player 2019" and it was the first result :)

But still is the same thing. If Ronaldo, the best player in the world, would be considered a 10x player, it would mean that him and just a goal keeper would be able to compete with other professional teams, which we all know is bullocks.

The original 10x term was about productivity (and namely, lines of code that is pretty much bunk).

For me is always about what is a 1x developer. If we consider them a professional developer that does their tasks (somewhat) on time, documented, and with minimal bugs, which I would consider the baseline for what I would call a professional developer, I have a strong opinion you won't find 10x developers compared to this.

On the other hand, if a 1x developer is a person that can't create a simple algorithm(fizzbuzz), copy pasts code from every possible source, including his own code from file A to file B, etc etc, then sure, 10x developers are there, but this is because we set the bar too low.

> A true "10x" engineer raises up the team by 10x by doing the things a lot of devs hate doing - docs, mentoring, guidance (without taking over someone's feature), and knowledge sharing. Not shipping :all-the-things: on their own.

That is gate-keeping, a person who could replace a team is 10x no matter if he is super helpful to slower developers or not. Of course you'd prefer to work with the guy who makes you look better instead of the guy who makes you look bad, but both are still 10x. However a person who just wants some development work done would prefer to work with a single 10x over trying to organize a whole team, a single guy will be more agile and much easier to communicate with while trying to get 10 persons to pull in the same direction is a monumental task. In that environment it doesn't matter if the dev can help slower devs or not, all that matters is that he can communicate with stake holders and users about requirements.

Development is a team sport, yes, but it is a team sport where some people can act as a whole team on their own.

> That is gate-keeping

Lol wut? The entire 10x meme is gatekeeping, this is about including more people than Rockstar DevOps SRE Ninjas.

> a person who could replace a team

Doesn't exist.

> However a person who just wants some development work done would prefer to work with a single 10x over trying to organize a whole team, a single guy will be more agile and much easier to communicate with...

A person "who just wants development work done" may well prefer a single developer, but it is not sustainable in the long run. That one 10x dev needs vacation, family/friends, sick leave, and career progression at some point.

> Development is a team sport, yes, but it is a team sport where some people can act as a whole team on their own.

Nope, not for any product that will last longer than a year, is anyway complex, or has more than one timezones worth of usage.

I see you are focusing too much on your own problem space where you need people ready to fix fires any time in the day and you need to ensure that you have people who can fix fires for years to come. In that environment you need replaceable cogs, then I agree that 10x engineers can't fill that role since you can't get a steady supply of them.

However in an environment where you are writing solid libraries which are not meant to break or change much and therefore wont need much maintenance the requirements are very different. Then it is better to have an extremely good team build a good solution once and then ship it and then mostly leave it alone.

Writing solid libraries is useful everywhere, since it can make work easier for the rest of the organization and such. Forcing people to only hire replaceable cogs and ignoring that some developers can be vastly more productive is therefore counter productive, even in organizations which mostly need replaceable cogs.

> I see you are focusing too much on your own problem space

I have worked in many problem spaces, and what I have said stands for all of them.

> I agree that 10x engineers can't fill that role since you can't get a steady supply of them.

10x engineers definitely can, just not Lone Ranger style mavericks that poison teams, or "replace teams"

> Then it is better to have an extremely good team build a good solution

I 100% agree. key work in that sentence is team

> However in an environment where you are writing solid libraries which are not meant to break or change much and therefore wont need much maintenance the requirements are very different. Then it is better to have an extremely good team build a good solution once and then ship it and then mostly leave it alone.

Very little code these days is write, compile and ship once. Compilers, runtimes, interpreters, base libraries, kernels, OSes, CPUs, and tooling all change. Unless you are deploying to a main frame that is slated to run for the next 40 years, all of these changes require updates to code, and that isn't even accounting for security issues (how many companies do you think were frantically trying to recompile programs with retpoline mitigations? How many "run once" pieces of software had to be recompiled with updated OpenSSL after Heartbleed?)

> ignoring that some developers can be vastly more productive is therefore counter productive,

So is discounting the harm they can cause, or the opportunity cost of them not lifting up their teammates.

Let me explain what my job is at Google:

I work in a larger team, but I always solve problems alone. When others have failed to solve something important they give it to me, and I always solve it quicker than them putting a team of staff-engineers on it would. Often my solutions are good enough that they make the whole team pivot in a different direction since it solves many problems for the wider organization. I often design new architectures in doing so, build frameworks etc which others then use.

Note that I am relatively new on the team, so it is not that I designed things which others don't understand. Instead I came in, started fixing a lot of shit and my responsibilities just grew. The most senior engineers on the level of senior directors noticed that I could fix a lot of things others couldn't so I get tasked with solving large problems which are blocking a lot of other efforts. Almost always it involves cleaning up bad architecture and implementing something which allows us to solve more problems. There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me.

Would you say that having me on the team is bad? Am I toxic? I think I wouldn't fit into a lot of teams, but I still think that I can help a lot. If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done.

> Would you say that having me on the team is bad? Am I toxic?

Without knowing you, or your team, I can't know. I have worked with people like this before, (and done it myself on a few teams), and it is a mixed bag.

> There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me.

Again, I don't know your team, but I would doubt there is no-one on your team you can teach. Pairing is not what I was talking - I personally really dislike it, and it doesn't suit me either. Designing a solution, and helping teammate(s) through implementation of the designs is valuable in this context, and helps lift up other team members.

> If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done.

No one is a perfect engineer - the solution you design might not have been produced, but this team existed before you joined, and most likely will after you leave, and it produced solutions.

> Note that I am relatively new on the team ..

This is a key point - I have done things before that were great solutions / libraries that others could use, so I didn't sink much time into docs / comments in the code. No one would need to change the library, just the config and stuff calling it. Which was true for about 2.5 years, at which point we needed to update what should have been something minor. cue me spending a week trying to understand my own code, after someone else tried and gave up. Time is the real judge of how much impact someone has on a team, and which direction it is in.

Your judgement doesn't really matter in this situation, the distinguished engineer and the rest of our senior team thinks I am doing an awesome job and they review my changelists and design docs. But I realize there is not much I can do to convince you, in your mind I don't exist so you try to find alternate explanations for everything.

> Again, I don't know your team, but I would doubt there is no-one on your team you can teach.

What would I teach them? I can go into an unknown codebase in a new domain and solve problems quicker and cleaner than the team who wrote the code. There is no secret knowledge I posses, no bag of tricks I apply, I just see the code, figure out what happens and solve it. If I could reliably teach that to people then I could become the richest man on earth.

My skills are good enough to reach a decent position as an IC, nothing to brag about really, but they aren't worthless either.

Definitely - I am a internet randomer, nothing I (or others) say should be taken with anything less than a truck full of salt.

I would trust that a DE in GOOG knows how to leverage their team in the most efficient / useful way.

My point isn't that very smart / productive engineers don't exist (they definitely do), but that the meme of the dev in the corner who sits in the dark, and spews out golden code, without talking to anyone else on the team is actively harmful for our industry, especially in the smaller startup R&D teams that the current batch of publicity about them comes from.

It sounds interesting and I wish I could learn something from you. Do you have any idea what are you doing differently? How do you work?

Not the GP but I've been in a similar position:

- Be good (and fast) at Googling things.

- Know your foundations, deeply. Don't memorize design patterns and algorithms: instead, learn how to arrive at them organically and how to analyse and understand them.

- Avoid overengineering like the plague and stop seeking perfection. I've seen lots of teams of "1x" engineers fail because they're too worried about peer approval, so they end up trying too hard to arrive at the "perfect" solution. And then business changes its mind and they have to rearchitect everything.

- Accept that business people will change their minds and design your software around it. The world doesn't revolve around your precious codebase. If the higher ups want to change something, you have to do it. Your codebase should have been malleable enough for a 180 degree pivot.

- Stop chasing unicorns. Yeah, maybe Vim will give you that extra 10% edge you need, but if you're comfortable with Atom, why change?

- Keep it simple, don't be clever. Only use the subset of the programming language that is free of "gotchas". What's the output of `[].push(1)` in ES6? Who gives a shit? Keep that stuff out of your code.

- Learn to evaluate if using an external dependency is actually faster than writing something from scratch or just copying some code. Sometimes it isn't, and people miss out on having simpler code, simpler interfaces AND learning new stuff because of that. Of course, you're not going to do that with a crypto

- Avoid things that might slow you down. The CI taking 30 minutes to run or the compilation taking 10 minutes are a sign that you're doing something very wrong and too complicated.

As for practical recommendations:

- A single integration test is better than multiple disconnected unit tests that have the same coverage. It allows you to change your code without changing the tests.

- Avoid transitive dependencies in your classes/functions by using simple Dependency Injection. Just pass those dependencies as a parameter or whatever. This will help you have units of code that are more testable, more flexible and don't require maintenance. Also you don't need those mock-in

- Make code simpler to read and to debug. Avoid reflection, metaprogramming and stuff like that. Don't do things that require magic.

I'm not really sure, but the thing I do most different is that I don't really trust anything. For example, in a mathematics class I wouldn't trust what they taught, instead I always tried to disprove it and I didn't use formulas I couldn't derive myself.

This is a lot of extra work, but it meant that I always had an extremely strong foundation to stand on. When I know something I really know it, and having learned this way since early school I have spent a really long time doing it so it covers quite a lot.

Also when you learn this way you don't forget, so it just compounds. There is no way a person who "cheated" by implementing for example algorithms and data structures without deriving things themselves can compete. They have spent their entire lives learning how to apply things without understanding, they would have to redo all of that to catch up.

When you know things this well then being much faster than others is not very hard. Also creating original solutions is not something scary or time consuming, it is something you've done throughout your entire life.

Anyhow, I am not sure if others can learn this way, I just know it works for me. I've tried teaching others to do it, but it didn't work that well. It might be that it was too late, I just naturally learned mathematics this way from early school so I already knew how to think about algorithms before I even started programming. I mean, calculating things by hand or in your head are the original algorithms so if you can confidently alter those as you wish then you already know the basics of programming.

This is a Senior Engineer, not a 10x.

A 10x engineer is just a workhorse who happens to know enough of everything to be truly useful wherever. I like to call them "glue engineers" instead because it's a little more friendly to the team setting. They do exist, though.

OK, this is a different (and better) description than the meme that is going around (see the twitter thread that kicked off this latest round of bikesheding about "10x" engineers).

If someone is a Usain Bolt of software development though, they probably are someone who should be guided into, or are in, a senior engineering role. Glue Engineers / Smokejumpers / problem solvers are different, and useful, but when companies become over reliant on them it is an issue. And no matter how productive they are, they should be held to the same standards as other engineers.

Yes. I think this "raising up the team" is called servant leadership. Not many people know how to do it, and it seems not many want to, because it does not help then look like heroes.

likewise, it's weird to see people compare Usain Bolt who's only concern is to run for 100m in a straight line, with the complex diverse field of software engineering. Winning in a 100m sprint is a simple contest to measure. You win or you don't. The parent raised perfectly relevant qualifiers that were summarily dismissed because the hypothetical 10X programmers exist.

It's hard to argue against excellent programmers, statistically they must exist. All this work identifying them and the qualities is a bit silly when it's hard to even define the term.

I think it's a perfectly valid analogy;

A runner is doing everything you'd be doing running, but more, and can achieve far greater speeds that you ever can.

No one argued that, just that "Usain Bolt's" shouldn't be that common.

The pride of others offends our tastes only when it offends our own pride.

Usain Bolt isn't 10x faster than the average human much less the average professional sprinter.

If quickly-googled numbers are any indication, Usain Bolt isn't 10x faster than my walking speed.

It's the product of a culture where success is the core of identity.

I agree that it's weird, and to me it's also a delusion.

As a delusion, though, it also has a function. Most of the people will never meet outliers in their field, and this will protect their self-esteem with the thought that the outliers don't exist, can't exist or that those skills can be reached with enough effort.

If the connection success was disconnected from identity, then there would be no need for this delusion, since admitting that somebody could be immensely better in a certain field wouldn't hurt self-esteem.

I agree to this. As I commented elsewhere, this is what most 10x I have come in contact with can be described as(sort of).

I have seen a lot more 10x engineers that were just pilling technical debt on.

They'd not be a 10x engineer then. The whole "x"ness is an oversimplification, which is the point of the article

> For instance, dev teams of 20+ where one person is the absolute backbone of the team and churning out features faster than the rest of the team put together.

I also have seen that. And, when that person leaves is another one from the group that took the role. Because you can have so many roosters in a flock.

It is so important to be able to lead as to let other lead you. Too many people, especially managers, does not understands potential. They see the result without taking into account any context.

Can be even bad. In one team, there was this guy that was more productive than the rest. He was an asshole. Everything has to be done his way, so, it was clear why he was the fastest one. Without him the team will have been faster and the product delivered earlier. But, the manager only was comparing outputs and the asshole that did not let the rest of the team work had higher output.

So, yes, there is people that are 10x. But, they are the ones that share knowledge, that put the team needs above her owns. It is that person that everybody wants to work with. And usually has little to do with personal output and more with improvements in the overall team performance.

Too many times I have worked with self-proclaimed 10x that are just making other people lives miserable and are surrounded with people that is new because his previous colleagues have left the company.

So, you are right. I just wanted to make clear what, at least for me, it means to be a 10x developer.

Maybe another way to look at it is those less productive are 0.1x developers?

I don't know - I've been the developer that produced more than the rest of the team combined, but it's important to stay grounded. An arrogant developer is going to be resented or even hated, regardless of productivity.

I also feel it's important to mentor other team members if you are more skilled in some areas - someone who shares the fruits of their knowledge and experience is more valuable to the rest of the team.

Lots of conceited sounding comments here from devs who either have an inflated sense of communication skills or stopped reading the article quite quickly.

In my personal experience, the author's anecdote rings very true. At my first and last corporate job, I was handed a thick af HP laptop that could barely be used anywhere but in the cube, a hideous screen, 30 min build times, and a java stack that made testing/understanding the existing YUI (JS) codebase a brutal activity. It took almost my entire first 6 month contract to just get minimally productive, and that's without accounting for meeting interruptions. Another frontend fella was hired on shortly after me, and we worked together to test and get productive with this codebase which was great, until a month later the manager who popped his head in every so often to check that things were running to his measure, decided to shake things up and dismantle all the teams, re-positioning them on different projects for no apparent reason. My colleague and I were split up, me on the new project that he had been prepping for through requirements gathering and UX stuff. Starting from square one, on a team whose members had barely met, in a different part of the codebase that I'd never touched, and with a 2 month arbitrary deadline, all while everyone was moving from SVN to git, and the feedback loop on a frontend change (locally) being 5 - 10 minutes. Shocker, the project failed, I was fired, and much like the author, I wanted to get the fuck out of the industry.

Edit: I think it's important to note sometimes the nature of what you're working on or the company you're doing it for can be extremely constrained. That in and of itself isn't unsurmountable. But when the expectations, compensation, budget, and measure of output aren't balanced, or if the constraint is poor management that don't understand or care about the people they're managing, then it's just a tire fire.

Is this a communication issue?

When you realized the codebase was a mess and that it would take you forever to reach productivity, did you reach out to the manager and explain the situation? Did you push back on splitting up the teams, and explain why splitting the teams would be a bad idea? Etc.

Unless a manager is truly incompetent, in my experience they usually listen to technical people when they speak up on these kinds of topics.

Competence is a spectrum. I've worked with managers who would listen, and nod along to problems I was pointing out, and after the meeting nothing would change.

It's very much a communication issue, but also an incompetance political game playing issue. To answer your question, I put a ton of energy into doing exactly what you suggest, which most people didn't and don't. It ammounted to some changes eventually taking place after I left, according to my former team members, but the managerial nonsense never dissapeared; those managers involved were later promoted.

I'm sorry but the author misunderstood the situation:

- He explained to the manager that a simple Hello World took a lot of time bla bla bla. The manager already knew this, that was his "achievement". He also took it personally as most people do, because when you tell him that something was bad, indirectly, you criticized his work (and so him) in the last years maybe.

- The author tried to explain rationally the situation. The manager didn't want to hear it because he was already desperate. The manager knew that the end was close. A desperate man does not think rationally. All you can say is that you will fix it and then proceed as normal. They just want to hear that everything will be good even if you know it will not be. You are his psychologist/priest now.

- The project had to failed. When you as a developer are in a situation when management is bad you should not do your best to save the project. The badly managed projects and companies must fail in order for the sane ones to survive. If you save a bad project/company you are the reason why there are some many bad jobs everywhere. Also this is the reason there is so much burnout in this industry.

Yep, exactly. One thing I’ve learned over my 30-year career as a programmer is: never argue. It’s a waste of not only your time, but your credibility. If they say it has to be done in a week, and it’s impossible to get it done in a week (like, actually impossible), you have two choices: disappoint them in a week, or argue, make them hate you, lose the arguments and disappoint them in a week anyway.

More stuff needs to be written to teach well behaved people how to deal with all kind of toxic persons in the workplace.

My question is: why didn't the author express all of this as soon as he realized it was a problem?

One would hope that the author didn't spend several weeks in silent frustration!

"Hey, all this template stuff is cool but it's going to take me a long time to sort through and understand. I'm going to need to ask a lot of questions about functions and logic. It would also be helpful if you could throw together some kind of quick and dirty documentation for X, Y, and Z classes which I already know are going to be important and it will be much faster and easier for you to write that (15 min) than for me to reverse engineer your thinking (15 hours)."

From my experience, in those type of situations, nobody is actually listening. Also there is no experienced person there to explain the project and... there is so much technical debt that no one can do anything about it.

What are the common "safe" traits of a 10x developer?

So far everyone I have met with traits like - produces working feature/code faster than anyone else - delivers stable massive projects on time - can carry a whole team through fire and hell - praised to produce masterpiece*

Are the same people everytime who are just - good at playing office politics - are excellent at cutting major corners - knows when their project will fall apart and leaves before - are in league with upper management, so can't callout

I have yet to met a real developer who when left team/project/job didn't leave a massive trail of destruction but up until they were present everything was a-ok-top.

May be someday I aspire to meet one, but so far, most pseudo 10x are just people knowing how to play right politics and hide the skeletons really well :(

This is a complete guess just based off my experience, but I know a couple of devs I'd bet on to 10x the worst of the devs I've worked with (over a long sample period), and the one thing they have in common is that they keep their code simple moreso than the average dev does.

One part of that is they all seem to err on the side of less code (including dependencies) over quicker implementations. The other part is a few times I've shot them a piece of code and they've come back with something simpler that I've overlooked. I.e they seem to have good fundamentals, good algorithm knowledge, good understanding of the language etc.

It makes sense to me, because I think this is the only vector you can 10x somebody in. You can't generally 10x somebody early in a greenfield project because everyone is smashing out work. You can't 10x somebody in a hellish project like in the OP because everyone is struggling with the same cruft. The only way you can really 10x somebody over a big sample size is by keeping every project you work on simpler for longer.

So that's what I look for when I'm looking for 10x devs. I might be completely wrong but it's the best indicator I've found yet.

You can absolutely beat people in greenfield projects with experience; choosing and designing business data structures optimally so that not a lot has to be refactored.

I don't really buy into the idea of attributing "x speed" to a developer, the idea is trying to oversimplify what is really a function of experience in- and the complexity of current task

> I have yet to met a real developer who when left team/project/job didn't leave a massive trail of destruction

Consider yourself lucky. The ones where this doesn’t happen with are the ones that simply don’t contribute and are somehow allowed to linger with the team. When they leave it’s usually a boost to the teams productivity overall.

Some times ago I was working in one company. We were building some platform and have the big task to integrate with another technology. I was involved in an absolutely different field and only participated in some meetings during the planing phase. The discussion lasts for a few months and when I completed my other project team already spent some sprints on development. When I have joined I wasn't familiar with underlying libraries and spent almost the whole week to improve my knowledge. When I have started to coding I found that whole project size is only 3-5 days of productive coding including tests for one person. My firsts thought was "I don't understand something", but when I ask some other guy to do pair coding during a day he barely did one class during 6 hours without tests and other things. And it was their normal pace for the whole team. But they get their bonuses and endless meetings.

Definitely, I feel myself as a 10x developer that days working with my normal 1x speed.

I think there are more < 1x teams out there than people think

Are there general work practices of yours vs theirs which you can share that would give insight into why their pace was so much slower? Or was it all meetings :)

A lot of this rings true for me. A few years back I worked for a company that seemed hell bent on utterly demoralising its engineering organization. Think endless rules (even down to which HTTP verbs you were allowed to use), a Macbook Air for development work, releases that very literally required manager signoff coupled with a company culture that was very partial towards throwing engineers under the bus. Of course they were crippled by technical debt, outdated development practices and regularly plagued by production fires. They did make a lot of bad hiring decisions - helped largely by not conducting technical interviews. But even those of us who were competent felt like 0.1xers.

"which HTTP verbs you were allowed to use"

I hope they only allowed GET?

Nah, only DELETE

If this was the case the poster wouldn’t be complaining about the limitation, but celebrating!

If they only allowed POST, there would be actual good reasons for it.

For those interested it was HTTP DELETE. The kicker was that they disallowed it due to "security" concerns.

I feel you. See me other comment itt.

"Wanted: Spaghetti-Wizard"

There are indeed a lot of factors involved and a good environment/stack/management can result in a lot of productivity from the team or at least multiple individuals. There are probably a handful of people in your city who could even do good work with spaghetti stacks and chaotic management.

But if your software requires a Spaghetti-Wizard, you're in deep doo-doo when he/she leaves because Spaghetti-Wizards are rare and hard to identify up front. It's a safer bet to clean up your organization and processes by listening to multiple people and not getting caught up in hype. Non-friends give you the most useful advice. If you gravitate toward people who only tell you what you want to hear, you'll have a biased perspective.

Another thing, sometimes a given stack or org is just not a good fit for you. People think in different ways. The author perhaps should have looked around and if other devs were doing fine with the odd stack, just say, "for some reason I find this particular stack confusing and difficult." Be honest and don't bash the architect if it's only you struggling.

It looks in this case like the manager was the spaghetti wizard.

I started my career on a 1.5 million LOC project that only had 5 developers working on it. It really influenced my development methodology, and I've always thought working on messy code bases was fun and challenging.

So when I started my consulting company I thought about marketing it as something like "Spaghetti-Wizard". Similar to the "we buy ugly houses" but "we work on ugly code. never surrender. never rewrite.". Couldn't think of proper way to find clients though, so with one exception mostly been working on greenfield projects or as an expert on Oil and Gas IOT systems.

There is certainly a need for "spaghetti decoders". Being able to study and figure out messy systems is a fairly rare gift.

I’ve worked with people who are the “10x developer” people are talking about. I hope I can explain the confusion.

First: let’s just replace that with “much more productive than average” developer. 10x is a silly statement, a bit like saying someone is a 10x footballer etc.

It’s correct to say these people get a lot more done than others. They often have admirable traits, such as great focus or enthusiasm for their job. They’re dedicated and will work long hours to get things done. Great for a CEO or investor to have. On solo projects, they’re exactly the man for the job. And startups usually begin as solo projects.

The reason there’s such a backlash on Twitter is that there is a huge cost to the rest of a software engineering team when working with such a colleague. Every instance I’ve seen of this situation has a common factor: as others joined the team, the MPTA developer monopolised the codebase. They won’t delegate, and preferred to spend time coding rather than helping others do their job.

And here’s the thing: The productivity gap is mostly a function of this dynamic

Try to take ownership of something, and the MPTA dev will use the time in the evening to rewrite your code in their style. They are extremely opinionated (though often correct) and unwilling to delegate and bring in ideas from others. Make a mistake (inevitably as you pick up the codebase) and the MPTA will roll their eyes at the CEO and replace your code. Working in a team is not about who writes more code, it’s about how to work together to move the company forward. And a happy team building a large product will always outperform a MPTA developer by long-term measures.

With no documentation, strong communication, team ethic, and delegation, employing a MPTA is unsustainable in the long term. If you’re a VC or early stage startup you probably don’t care about that. But most developers are in teams in bigger companies, and perpetuating the 10x myth makes their lives worse, and makes them look bad.

Moving on from the idea that a 10x developer is good for a sustainable development effort is a significant step in the maturation of software engineering as a field. They have their place and can be an incredible asset, but great software engineering is about teamwork and communication.

This is a nice anecdote, but it misses the mark a little bit.

A 10x developer is 10x compared to his peers under the same conditions. Comparing across project conditions like this is talking about a different concept.

That depends on whether you consider 10x as to be a context-based quality or person-based quality, and IMHO the later is the thing normally discussed. A python dev might be 10x in python, but they'll drop to 0.1x when doing JS for e.g. the first month. Does that make them a 0.1x dev? I'd argue not.

New programmers on a team eventually affect the quality of the code as they work, and thus the project conditions. Project conditions can also include how easy it is to work with others on your team, which depends both on the new dev and the existing team. So that definition misses a lot.

Everything you said is true, but I didn't make up the definition :) This term was coined many years ago to highlight one simple idea.

That you can hire someone tomorrow that would have 10x the output of the average hire. Basically that such people exist.

Cross team productivity, and inter team dynamics are very interesting topics, perhaps more interesting, but this label for this topic is pretty clearly defined.

The meaning of 10x has blurred considerably - when coined, as far as I can tell, it seemed to mean that sometimes the most productive developer on a team is 10x more product than the least productive developer, not the “average hire“ - which is a very different claim.

This story also raises an interesting point for development managers; When you transfer a dev to a new project, it's a lot like getting a new job - you ( probably ) won't have the domain knowledge, knowledge of the tools in use, will have to prove yourself to the other developers on that project before anyone takes anything you say seriously - etc; with one key difference - when you get a new job, you would usually expect a pay rise. I think this is a massive problem in larger orgs where developers may be seen as an interchangeable resource, and can be a major contributor to staff turnover, and loss of critical knowledge. Soon all your developers will be 0.1x.

If the definition of a 10x developer is 10x more productive than the least productive member of the team, then I’m at least a 10x engineer.

We had a story to build a relatively simple go web server and deploy it to kubernetes one of my teammates got it, and basically got no where with it for a couple of days so I thought I’d get it started for him.

I got a basic hello world server set up and deployed along with a ‘ko’ setup so he could do hot rebuilds and deploys with a keypress.

I sent him the git repo and instructions for how to get it working.

While I was waiting for him to get it working, I was kind of in a groove so I kept adding features from the story.

By the time he got it compiled (with me coming over and just walking him through everything because he couldn’t follow the same docs I used to get started), it was already 90% finished.

If I had waited for him, he’d still be working on it for another 2 weeks at least.

It’s not that I’m a genius or he’s an idiot, he’s just fairly new on the team and I built our whole stack from scratch more or less and know it like the back of my hand.

Have you considered actually teaching and paring that developer for a few weeks?

You know have another capable engineer. That's real 10x.

Your solution of just doing it by yourself is a short term boost.

He didn’t want to pair, I asked. He also never asks for help when he’s struggling.

You could have been a 10x developer if you taught him how to do it. A single developer can only scale so much, a true 10x developer is one that scales the output of those around as well.

Yep. And if you're a 10x developer who becomes a manager or team lead, your best bet to maintaining your 10x effect (or increasing it to 100x) is to grow and support your team. You might not say that they are each and all 10x, but if you can grow them from 0.01x-2x range up to the 1x-10x range, then multiple by n team members and you get the net effect of a 100x-1000x dev.

That sounds like a very hostile way to solve the problem of them struggling with something.

What about the infinity X developer. I’ve seen time and time again situations where a developer simply didn’t have the skills to complete a task. You could give that developer infinity time and it would never be completed.

And then you hand it to someone else, and it gets done.

There are some problems that are just really hard, and some folks just aren’t cut out for those problems.

Infinity X developer? If true, I'd say that team has a professional development and growth mindset problem, one symptom of which is a productivity problem.

Having expectations that any person should be able to teach what they can do to the rest of the team in a timely manner is unreasonable.

Problems like "Make X take less than Y time to run" or "Reduce binary size to Z" or "Design a fault tolerant system accomplishing Q" etc are often impossible for most to solve since they simple don't have enough foundations and intuition to solve them. You'd have to spend years drilling fundamentals to get people to that level if they are even capable of gaining the same intuition, most developers never gain those skills no matter how many years of experience they get.

Who says you have to be the one to do it? What conferences exist? What books? Online courses? You don't have to be the professor, but you do need to be their advisor and point them in the right direction to learn, grow, and thrive.

Sometimes there aren't conferences, books, or courses. There are lots of problems out there without solutions you can take courses for. Board bring up, performance, and lots of problems that fall into the bucket of "machine learning" require knowledge, cleverness, and lots of persistence.

There's also the set of problems that are best learned at universities. Normally, one doesn't have time for a developer to catch up on their missing compilers or cryptography class (this is particularly a problem since perhaps a quarter of programmers have CS degrees, and a quarter of them went to a decent program). If I were asked to debug a clock skew problem on a particular VHDL design, it would take me a long time to learn enough to even approach the problem.

Also,if one is a kind of mediocre developer but gets thrown into the team,where standards are high, the productivity of such a person would be higher than in a kingdom of spaghetti code..

I think the author raises a very good point. Developer productivity does not lie in a vacuum, this is overlooked a lot mostly because for small teams most developers manage their environment and toolings and for big teams there usually are standards to follow but there is a huge gap in the middle where if a developer is not vocal enough or has sway in a toxic team a good developer could spiral downwards in productivity.

As to a solution to what the author asked: "What could have been done". I think the way to handle that situation is to approach the manager with a solution. Tell them, if you give me A, B and C I will be productive, I do not have these now and they are causing me pain. To do this one has to have self-awareness and experience in what they need for a productive environment. one also has to be vocal and willing to fight for it.

I think the 10x developers are a myth if you compare the whole output versus another developer whole output.

But it is very common that a developer can fix a problem or build something 10x or even 100 times faster than others. Simply because they know the project, the language, understand the problem already, have experienced that problem before.

I have many anecdotes where I was stuck on something for hours and a colleague solved it in 10 minutes. But I have also counter anecdotes where 2 colleagues were stuck a whole day trying to solve a problem while I was out of the office and the next day I solved it in less than 5 minutes. The multiplication factor of that is insane, but it really happened.

I don't think it is a myth. If you look at coding challenges and live coding, there are developers who can churn out correct and well-documented C or C++ code while speed typing and without making any substantial mistakes. Not every developer can do that, no matter how experienced he or she might be with the language. I'm not one of them, but to give an example, I find some of Bisqwit's live programming on Youtube pretty impressive - and he works as a bus driver during daytime!

Yeah, but what if you shove some other language/problem in front of them? Will they still be 10x more effective than another developer? I don't think so. My point is that you can become very good in a specific area so much that you are able to outproduce the average developer by an enormous amount, but it may very well be the other way around in another area.

They’re a 10x code typer then. This is not development in a general sense, which involves working with people.

Doing coding challenges is a special skill. To be fast you need to:

- Have all the boilerplate code almost memorized. By that I mean things like parsing a simple file, opening a display, etc..

- Know the relevant techniques, and train. For example, if you are doing a coding competition, dynamic programming algorithms are a classic. If pretty pictures are your goal, fractals and raytracing are a good start. Neither is likely to be of much use for you in the real world.

What coding challenges don't require is the ability to think long term. That code is likely to be thrown away after the challenge is completed. Managing complexity is maybe the most important part of real world programming, and for technical reasons you have very little of it in coding challenges.

As for Bisqwit's videos, they are awesome, and he certainly is very talented. I actually learned a lot from him. However, all his videos are about toy projects, not building complex applications. BTW, I think this is the reason he is a bus driver. He doesn't enjoy coding in a professional setting, because it is a different kind of work.

On a lighter note, iIf you don't see any 10x developers around, maybe you're the one :D

It looks like the real 10x debate is not so much "do these people exist" (yes) or "is it context dependent" (yes), but the more subtle questions of how to identify one by any other means than working with them for weeks, and what a 10x developer (or salesperson!) is allowed to get away with in terms of not following the rules.

There is also the Stakhanov question about how to attribute the work of supporting and being supported by others, and how this can be used for propaganda.

I think it’s not unreasonable to suggest that there are very productive people out there. They pick things up easier and they generally have an aptitude for the work and the environment. However, the original tweet that set this whole thing off listed out a number of attributes that 10x engineers are supposed to have. Things like having dark mode in their IDE, using the command line and never needing to read documentation. Which is nonsense of the highest order.

I deal with this type of situation on a daily basis. It turns your team into firefighters instead of being able to focus on building more value.

When I hire new people, I hammer clean code and TDD. I am not dogmatic about it, I just know from experience that maintainable code makes for a more enjoyable experience for everyone on the team.

I prefer the term Batman developer

He doesn't play well with others and usually he'll just do stuff his own way without telling anyone.

He's usually right and he's usually more effective than his sidekicks.

Some villains need Batman, but after a while he can work on more pressing issues and the sidekicks can handle the weaker villains.

Sounds like the same destructive behaviour that is commonly referenced as the bad 10x developer.

Yeah, the obvious point is that Batman is a billionaire businessman who could pay his taxes and get Gotham to hire some decent police but instead of actually focusing on the structural problems that cause crime in Gotham, he runs around banging models and beating up street criminals.

The Batman comparison is a great example, because the criticisms of the 10x developer match exactly the problems with batman.

It's an apt analogy. A sociopath who refuses to work within a system, is accountable to nobody, and is arguably creates the very same villains that he is forced to battle.

It's easy to be a 10x developer if you don't write tests, no documentation and don't design anything, don't do any code review...

And yet there are just people out there that do ALL of that, play well with others AND have high productivity.

The question is how do us 1xers avoid getting compared to them ;-)

Well, they might as well fire their in-house devs, outsource those jobs to some third-world developers for half the cost.

Same result: no tests, no docs, no design, no code review

That will make you a 10x developer today but a 0.01x developer when shit hits the fan.

I worked with a developer and he wrote the best tests and coverage. He encouraged me to also write tests that covered everything as he would often re-implement something somewhere else and it would break my code, but there wasn't a test that showed it being broken. I wrote tests to protect my contributions!

Thats what I think when I hear rockstar developer. They truly are rockstars. They come in, give all and accomplish great things, but you have to clean up the venue the next day

I disagree, I think that there are a lot of developers that produce a constant stream of mediocre designs, mediocre implementations, mediocre testing and mediocre documentation.

And when a (let's call it 10x) developer steps in and produces just a very good design or implementation, it still adds a lot of value, to the project or to the team's productivity, even without tests or documentation.

(In that sense, the 10x label is a misnomer: exceptional developers aren't faster at typing, they produce something that the others wouldn't produce in any amount of time, and that something often increases everybody else's productivity).

And a lot of it is experience knowing what to build in or what hooks to set up so that when the obviously missed requirement gets added right at the end its trivial to add.

So like most companies then? They say they do or plan to do but when you go and check there is nothing. Most projects I encounter when doing integration have nothing (well, perhaps some minimal docs for the integration) while they process millions-billions $ via these systems.

My latest encounter was an insurer who spend a lot of money on building a system by a hip team who started with node/mongo/react and a few months ago insisted on switching the frontend to Svelte because ‘React is not current tech’ (I am not joking here). No tests, bare minimal docs, bad design (every change takes forever and some changes are deemed impossible) but it works, makes money, client is happy. It took however over 2 years (not cheap guys either; Dutch, 120+euro/hr people) to finish while my beer napkin estimate is 6 months and that would include tests and docs. Easier because there already is a system so that is not fair but the idea that companies are living in some HN nirvana where they pay programmers to implement non business stuff (tests, docs etc) is just not realistic. And the people who do it are not ‘10x’ even then.

If I would say 6 months to rewrite (if that was on the table) inc tests and docs, the client will say; how much without those then?

Then you answer ‘9 months without’ because that is undoubtedly going to happen if you have no quality control and a client that want to skimp on it from the start.

>> inc tests and docs

Why should the client have to worry about tests or developer documentation? I would not be trying to get it as a line item on the invoice.

Keeping the code base in a state that makes it fast and cheap to add future features is just a professional duty. Decide how to best achieve that on a project by project basis and bake it into your estimates.

Some projects the client just wants the absolute cheapest implementation though and i am completely fine ripping out the need for continual re-factoring or keeping the test suites in good shape IF i've explained the down side to the client first.

You are right, my point is that this is the HN echo chamber; I see almost no-one and no company doing this in real life. At least not in the countries and companies I have ever worked with and that's quite diverse. Naming and shaming makes no sense here, but I know many Silicon Valley, Berlin, London, HK, Shanghai, Barcelona startups saying that they 'will' do these things (and some of them shouting on Reddit & HN it's bad if you do not) but not doing them at all and many fortune 1000 companies not doing it either. Not even the basic stuff.

So yes, it's my professional duty, but my 'competition' doesn't do it and is therefor cheaper. I don't do much of that work anymore as I now do a lot more own products with my company where I can do it, but if I 'bake it into the estimates' we will come out most expensive. So for us it's line items, and if you, after we explain everything, do not want that, we will remove or not take the contract (depending on the terms).

There is also such a thing as a team which validates its performance only on test coverage, documentation coverage, endless pedantic code review and adherence to strict architectural standards, but manages to produce little to no real-world value.

They must be building for either an enterprise or a startup!

If those things are required for his role and he's not doing it, then he's not a 10x developer. There's some issues with your management.

Also, just because someone has good performance doesn't mean he's an insufferable idiot. In fact, those kinds of snarky replies about 10x devs here are way more toxic than anything claimed by them.

I have maybe seen two people I would characterise as what other people might call a 10x developer.

One of those 10x was truly someone who was worth 10 developers (at least!) given that not only was he capable of holding the entire business in his head, but he could also mentor and bring people together. At crunchtime he could also shield the rest of the team by churning out features at triple speed while still keeping them in a mostly maintainable fashion. He brought the best out in everyone.

The other 10x was a silo of knowledge, was terrible at mentoring and wrote code which was neither readable nor high quality. That said, he was unmatched in his ability to ship and solve problems in distal regions of the codebase. In my evaluation of him, although he was 10x more productive than everyone else, I can't help but wonder how much less productive everyone was around him (and the team was larger than 10!).

So tl;dr YMMV. They definitely exist, when they work right then probably can set up systems/organizations that can scale around them and generate tonnes of value. When they're egotistical/insecure vampires, their global value will be questionable but they will definitely look good relative to everyone else!

I think moral of the story is don't hire assholes...

I inherited a similarly Kafkaesque codebase where I work now and yes, iteration on features went down dramatically from previous workplace.

It's just so difficult to do anything without something completely unrelated breaking.

Enough that I have considered simply leaving.

Rather sureal to see so many blog post about a "10x" controversy, without anyone actually referring to controversy - therefore making it impossible to understand if people are even talking about the same thing.

Without any snarkiness implied, I suspect not being on twitter anymore lately has spared me a few hours in this case.

Maybe 10x programmers (I'm not one) don't have time to talk about 10x programmers.

I’d like to highlight this part:

“But even more important than technical issues are things that promote healthy team dynamics. These include things like blameless postmortems, openness to ideas from everyone, permission to try new things even if they may fail, stern weeding out of jerk behaviour and, ultimately, trust.”

It’s just so important.

I have personally witnessed 10x developers. The trick is making everyone else look like 0.1x developers.

I am getting so tired of the term "10x" due to the past week. Some people use it as a synonym for "socially maladjusted" or "toxic," while others use it like "amazing developer." Just...stop.

Some people are more productive than others; it happens. Some people are toxic and destroy entire teams. It doesn't make sense to lump all different kinds of "developers we don't like" into the category of "10x" because that's not what that is. There's another comment in this thread suggesting a change to "more productive than average," which is a term I could get behind. You can't measure productivity to multiply it by any number, so please just stop.

This is a great story as it illustrates how to make a 0.1x (or 0.01x) developer. The 10x version of that is one who created a codebase that's missing all the ineffectiveness of this one as well as adding sprinkles if well defined boundaries to work on parts indepently without complication. Setting up this sort of multiplier environment of code structure is how you achieve Nx output for onself or others. Most of the time you shouldn't even see the 10x'ers work because it's invisible what's not there is the magic.

Can't speak to what makes a 10x dev. But a 10x dev team is much easier. Where each member can carry their own weight, most of the time.

I have been involved in seemingly simple projects that never seemed to end (and a lot did not or shipped with significant debt) and on other complex/novel projects (with many unknowns) which went really really smoothly and shipped on time.

Successes are oft attributed to a 10x developer or a high performing individuals contributors. But, then I've seen the same 10x devs go to 0.1x and 0.1x to 10x and back.

My anecdotal observations on what sets successes apart from the fails are:

- A well defined problem: Well defined to the extent that this intends to solve X. It can easily solve y,z,a and b, but it will not and is out of scope/not expected to be delivered.

- PMs with domain knowledge: An external aide who can step in and guide when asked, or if the visibility reduces. But understands the problem and technologies involved (task masters need not apply). No PM is often better too. Also the PM here is more like a sponsor, only steps in when asked, to recover failure.

- Smaller teams: Structured like a cross-functional pod. For complex projects a senior dev, a not as senior a dev and a designer work well. A lone wolf + a designer works. A junior dev with high degree of domain expertise on the problem + a part time designer works too. No designer necessary if there isn't a front end.

- Hard code reviews: Starts with a good convention that's documented, a style guide for programmers. Some languages have this baked in. This happens at the very end in the testing/cleanup phase.

- Let the teams write out the task, then group these in to scopes. A PM or person with more knowledge outside the pod might be tapped in to help sub-divide scopes.

- Let the team on their authority cut down on scope if it helps ship on time, with fewer unknowns, without changing what we were trying to solve.

- No extensions: The project is done or its done.

- Finished early? Free time to NOT write code. Usable as the team sees fit.

A few other nuances, one could argue that this makes for good and consistent 1x dev. It definitely makes for a 10x team.

aside: read a great book that summarized a lot of the successes as a plan they use in there team. Its an easy 60-80 minute read (I'm a slow reader). Highly recommend it if any of this resonates, high recommend if it doesn't and you want more ammo for a flame war. https://basecamp.com/shapeup

"10x developers" are about as well defined as the word "startup". Similarly they are often used by VCs (or similar stakeholders) to attribute causation to a highly complex system, which is basically a fool's errand. The description the original VC uses for a 10x developer (where the tweetstorm originated) is akin to a supply chain that just spits out masses of widgets to a nascent widget market. VCs love this because it means a quicker ROI on their investment.

The 10x comparison makes only sense if you compare developers on the same project. If there are colleagues that perform much better, try to learn from them

One serious side effect of these kind of discussions is that people tries to be a “10x” developer, and start producing like hell but it’s just garbage. Also it creates a culture of “I deliver, ergo it’s good”. And then you are in knee deep crap, and the guy moves, leaving everyone else with the shit.

Don't forget "competent managers". The manager blamed him even though the codebase was the problem.

Or do competent managers even exist? Or we just assume that they usually aren't and we will have to work around them?

I always thought the 10x developer was simply someone who sees the cleverer, simpler way to do it. Like in trick maths problems: software is the thing in the world that is most like math.

This story is basically about a 10x coder and architect which acheives his 10x by belittling others by means of architecture astronauting and personal job security.

The worst thing about 10x devs is that some of them work in places where the process or general dread reduces them to 0.1x to 1x developers.

I imagine most 10x developers just have their life together as a whole and that's what allows them to be so productive.

So many developers I see are overweight, drink alcohol often, play video games until 2AM and then sleep 5 hours, no exercise at all, bad diet, porn addiction.

By having such a bad lifestyle they are really low energy and tend to go into "autopilot" which of course translates to worse output at the job.

Meow :-) What happened to being civil

I don't see the issue as the statement is not targeted at any single person, just a generalization.

Doesn't work like that though does it

I don't see a causation here, those things aren't specific to tech, and are in fact fairly common in other areas of work as well.

Yes, and I bet there are 10x employees in all other areas of work as well.

Here are my brief incomplete thoughts on becoming a 10x developer writing JavaScript. In summary, become comfortable with how the technology actually works. Hoping something else will solve your problems for you makes you less productive (I've heard all the excuses).

* Understand that super productive people likely do things that aren't the popular way of doing things. If the super productive way of doing things were the most popular way of doing things then everybody would be more productive. Be critical about why a productive person intentionally does something in defiance of popularity.

* Become comfortable reading code. Frameworks, unit tests, processes, and tools are not there to make sense of the code for you. You cannot be a 10x developer if you are intimidated by reading code or expect something else to do it for you.

* Learn to organize to the scope model before adopting any other convention. This will reduce the amount of code in a given application. In many cases it will also greatly increase code performance. In JavaScript OOP concepts and inheritance are conventions that can be avoided, but not scope. Scope is always present and not hidden behind a code convention that can be avoided. Don't be afraid to nest functions and try to declare references as locally as possible and share where necessary as this greatly increases maintenance speed.

* Write original code. In JavaScript invented here syndrome is exceedingly common. In many cases it is faster to write original code for a given problem and in many cases that original code will execute orders of magnitude faster than misunderstood dependencies downloaded from NPM. If writing code is intimidating you will always be less productive. If you want to write clean maintainable code solve a given problem as directly as possible and then later, after clearing your mind, refactor the code to achieve simplicity. Simplicity almost always takes extra effort, but reduces maintenance time down the road.

* Master the DOM. The DOM is still the ultimate backbone that glues all things together in the browser. The DOM is not some strange React fiction. It is a language agnostic standard. Learn the standard DOM methods and node relationships. The DOM methods execute thousands of times faster than query selectors and faster to maintain for code where sections of the page are in flux. https://dom.spec.whatwg.org/

* Become comfortable with callbacks. Node is callback driven. If you cannot figure out callbacks or passing by reference your code will be a struggle to write and look like spaghetti.

* Learn to write your own tools. It is nice to increase your own performance because you have learned to automate part of your daily tasks or parts of your job away. This isn't something that comes naturally and it does take practice to become efficient write quick tools on the fly that doesn't burn up all your time.

* Take ownership of test automation. Some developers want to test everything because people have told them testing is somehow important but have never learned what is important about testing. Tests are a form of debt that. Test what your application claims to do opposed to what it literally says. Test features, options, and output. Test that collisions of features do not produce unexpected results. If you are confused about what to test ask for guidance from your QA team. Ensure your tests automation executes as quickly as possible so that it isn't a swamp holding back the productivity of your team. Slow test automation is worse than unnecessary unit tests.

* Most importantly accept that you are fallible and that you are probably wrong more than you are right. Learn to appreciate negative feedback and criticism as gifts of guidance. If you drink your own Cool-Aid believe you are too good for improvement you aren't improving. The soft-skills are perhaps the most important part of becoming more productive.

Do 2x developers exist? And what about 5x developers?

It's a matter of speech, not a concrete measurement. I'd liken the speed to a "compiled" version of the problem in your mind; if you've done it before, it's easier to apply it now, rather than to start from the beginning to understand the problem.

you fools still believe it's an innate characteristic that only a few can possess; it's something anyone of us can achieve as a form of transcendence

Just wondering. Can we all be J. R. R. Tolkien?

Other industries have people who are clearly Superstars. Why would they not hold true for development?

Nah, I expect not. But we can probably all be Jim Butcher or Robert Jordan.

You're still trying to be anything but yourself, why not start at first principles?

JRR Tolkien worked closely with CS Lewis and they formed a powerful workflow -- go ahead and believe whatever you want but each of us has a unique ability and we're superstars in our own right but we rely on context which is sorely lacking in the technological industrial complex

Well, but C++ does take a lot of time to compile. The whole meta language implementation is relatively dumb for a lack of another word. So should every C++ product now be scraped and rewritten either in rust, ocaml, or C? Or is it upon the Developer to see these problems and find a workaround?

The problem didn't seem to be that C++ was slow to compile but the manager' inability to understand that C++ was slow to compile (i'm ignoring the whole "architecture astronaut" and "untestable code" angle because it relies on the author's ability to judge that and from my experience people need a lot of time to become familiar with non-trivial C++ codebases and way more often than not they blame the codebase itself and whoever wrote it for that).

Considering the project folded it might also have been a sign of bigger issues with management there.

What you ignore is:

"It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable)."

I'd like here to quote this:

https://blogs.msdn.microsoft.com/ricom/2007/02/08/performanc...

"Which of the following is more likely the culprit of this crisis that has your boss in a panic:

1) A developer failed to code a good algorithm in some module and now a very smart person must come along and replace that module with something much better.

2) The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time."

"Of 27 responses at this writing

8 didn't specify #1 or #2 at all or were balanced

4 went clearly for #1

15 went clearly for #2"

I've had my own experiences of #2 on different occasions (I work for decades already).

Yes, without having enough information to judge for themselves people tend to assume the worst. This applies to both the poll you linked and to people coming head first to a new complex codebase they have no idea about (yet need to learn fast due to boss pressure).

My experiences do confirm that there are developments which are indeed “worthless crap that never had any hope of meeting the goals much less being worth maintaining over time.“

There is a real problem of making unnecessary and long-term bad abstractions, and there is a lot of such often in the code using Boost, as an example.

I suspect projects in a new language always look better for a while as there simply hasn't been the time for cruft to build up, everyone is excited about the new language and learning how best to apply the new features.

NB I'm saying that things Rust aren't 'better' than C++ - just that initially all new project in a new language have a positive bias (as do new projects) and that time will tell how big the advantage really is.

This article doesn't feel like an attack on C++ but rather C++ written by incompetent people.

Large codebases can take a long time to compile, but if, as the article claimed a simple new Hello-World example is taking minutes that's because your build system is unnecessarily rebuilding everything every time.

I know not all things should be attributed to technical causes.

But I'm a consultant and I often have to deal with - to me - new MLOC piles of C++ code. These code bases are of course almost always non-trivial and my first approach is most of the time - If I am permitted - to analyze the include structure and to optimize it. Removing headers, pimpl, basic things. Only then would I even begin, to explore particular problems. Side effect is an intermediate 500 feet view, that develops along the way.

Many developers are too hasty, taking too narrow an approach.

People need to remember that in the old days several minuets to compile was the norm and you might have to wait your turn in the queue.

I recall working in my first jobs terminal room and one of the engineers came in to login to AUWE ICL - and shaking her head after seeing 38 jobs in the queue in front of hers

C++ is never fast to compile, but some design decisions will make it much slower than it needs to be. The less stuff you put in your headers, the faster it will build (for the most part).

You can also sometimes make templates slow by programming horrors like iteration through repeated template instantiation. There's an old joke about those sorts of problems. "Doctor, it hurts when I do this," says the patient. The doctor replies, "then don't do that."

There are many techniques to combat compile times in C++. One of the more easy solutions is to not use heavily templated header-only libraries too much, which is precisely what the architecture astronaut mentioned in the article did.

Many people say that templates in C++ is a zero-cost feature, but it slows down compile times so much up to the point that you can't call it "zero-cost". I think it's just another tradeoff that C++ developers have to make - between generic code, performant code, and fast-to-compile code.

Reply on news.ycombinator.com