The Many Faces of a 10x Software Engineer | Hacker News Reader

The Many Faces of a 10x Software Engineer

worldofbs.com

47 pointsyamrzou47 comments

Everyone spends so much effort chasing the ideal of the "10x engineer," but nobody ever stops and thinks about whether there's an even more powerful engineer archetype. Well you might be surprised to learn that there's a level _beyond_ 10x engineer, a literal order of magnitude more engineering power. That's right, I'm talking about the 100X ENGINEER.

It is often said that a 10x engineer is as productive as an entire team of engineers, but for the 100x engineer, 10x is only a small fraction of their full power. These freakishly productive individuals are more powerful than an entire _army_ of engineers. Think one coder, one Macbook, and more engineering capability than the entire staffs of Google, Facebook, and Amazon combined. Much, much more.

Now, you might be thinking "What--100x?! There's no way that can be right! Can it?" but you would be wrong. I have seen the power and capability of these 100x engineers. I have trained alongside them in the Hyperbolic Engineering Chamber, where an hour of engineering work is squeezed into every second that passes. Those who survive this mentally taxing and severely dangerous process transcend all known levels of engineering to attain the fabled Super Engineer Level 3 Ultimate.

If you work for Google, Amazon, or Facebook you should be very afraid. Because the 100x engineers are coming for your jerbs!

A 10x engineer? Hah! You haven't even seen my final form.

But in all seriousness, there is a wide range of productivity levels. That includes some people who even have negative productivity. Ever been unfortunate enough to be on a team with one of those sorts?

That does it, my new phone camera based social networking startup will hire only 100x engineers. They must wear mirrorshades and if I allow 20 minutes for an interview coding question, the 100x engineer should be able to solve it in 12 seconds.

But per HR policy, will only be offered market rate for this area.

They will be hired remote and be paid market rate for where they live or where the company is based, whichever is lower

The "Always New Projects, Never Docs" section is something that I often point out to my manager. He uses other engineers at the company as an example of the best engineers during our performance reviews.

The "best" engineers are constantly on greenfield projects. They are quite talented, but they have it easier in a lot of ways.

- Working on projects with the most perceived value, so they have strong reasons to be motivated by their work.

- Using the newest technologies, so they don't get bogged down in technical debt. This can also be motivating for engineers.

- They have more autonomy because the product hasn't built any bureaucracy around it yet.

Most engineers hired in the past few years are maintaining the projects those engineers created 2 or 3 years ago.

The projects are never documented well. Technologies haven't been upgraded, so versions are out of date. Tooling was poorer years ago, so engineers have to fight that. Needs of the products have shifted and architecture hasn't. Refactoring is always on the back burner, so the problems persist and multiply as new features forced in.

The people who got to build the original projects years ago keep looking better as they build new projects today. Everyone hired since is mired in trying to keep the product running while adding new features. The result is a growing gap between the "good" engineers and the "bad" engineers.

The worst part of it is that if you point any of this out, you're essentially calling out the "best" engineers in the company.

When you get to build your mental model directly into the app, you're always going to be at a huge advantage when thinking about it.

As far as I'm concerned, a big part of my job is fighting my urge to do just that, and try to write code in a way that my coworkers appear to have a better time understanding.

This is the developer version of empathy. To even consider what it would be like for your future self to touch this code, or someone else to read or reuse your code is empathetic.

It’s understated and I think it’s the most important thing any developer should have. I personally don’t care about any other trait other than that at this point in my career.

I love to see it, and inspires me to up my developer altruism game. I’d love to see more interviews where people just hand someone not-so-perfect code and have them describe what could go through the mind of a variety of team members as they read it, and what could have gone through the mind of the person that wrote it, and finally what is forgivable.

If anyone reading wants a place to start, I think I started by realizing that I needed to write a lot more code than I wanted to attach my identity to. Start by writing the code that you would like to not have to be responsible for as if you expect someone else to be happy to take over, or at least not stressed or grossly disappointed.

Then if you can figure out that it's all 'our code', you can work from there.

> When you get to build your mental model directly into the app

Also, your preferred libraries, and the level of abstraction you are most comfortable with.

Personally, for now, I like being one of the "maintainergineers".

Often, when I read code written by "green fielders", I question their competence, and question myself why I'm still working at this place. I admit this says more about my ignorance than anything else. I'm just saying what I feel at the moment.

All projects that I have been part of in my current company don't have automated tests (at least initially before I joined). Instead we rely on QA. Since I read a lot about things like DDD / well architected code I often dream working on a codebase where implementing features and fixing bugs isn't frustrating and deploying to production isn't nerve wracking.

Since the first step of refactoring is to have tests, in my first project I endeavoured to have unit/integration/e2e tests. They're a bit subpar for my taste, and can be a bit slow to run at times. However, these tests allowed me to sleep better at night after each deployment.

In the last few days, since joining a new (EDIT: non-greenfield, as a maintainer) project, all I've done is write unit/integration tests. (EDIT: I'm writing unit tests to what I currently consider very sloppy code, e.g., not using dependency injection, leaky abstractions like calling request() inside a model class (project uses laravel framework))

I like to think that what I have done and what I'm doing right now will enable me to write better architected code. As an extremely simple example, I find it harder to test `new FooClass` than its dependency injected counterpart. I hope I'll remember that next time I write code.

> All projects that I have been part of in my current company don't have automated tests

On the rare occasions when I start on the green field, logging and unit tests are literally the first things I set up. It only takes a moment, and the time investment is paid back the first moment you investigate a bug.

Doesn't mean I do unit tests religiously, but at least I do them sometimes.

I would love to be a maintenance engineer in my current job, if it was respected. Sadly, it's not and project managers drive for features.

I agree that maintenance work is more likely to be instructive in creating well architected code. It has been a joy when it's possible to take a poorly build module, write tests, and refactor it into something simpler and more effective.

> Using the newest technologies

What's so good about newest technologies?

Every single time I tried to use them, I had to waste lots of time reporting and working around bugs in these technologies, and bugs in the surrounding ecosystem triggered by these technologies.

Generally, I prefer technologies at least 1-2 years old.

I would interpret "newest" as "latest best suited" technologies. Well vetted would certainly factor into that choice.

In other words, new projects don't start with any dependencies on tools that are no longer considered the best for the job at hand.

Yes, newest was probably not the best word for it.

The best technologies can be chosen, new or old.

How do you explain engineers who are great and motivated while working on less sexy work?

You can have great engineers in maintenance, I didn't say all great engineers are on greenfield work.

The ones working on greenfield projects have been the ones used as the bar to measure other engineers by, in my experience. This works both to glorify the greenfield engineers and hold back the engineers stuck in maintenance.

Motivation is very personal. Some people are motivated in everything they do. A lot of engineers are motivated by working on high quality code or new technologies. Others are motivated by perceived fairness in how work and rewards are assigned.

For those latter two sets of people, being stuck in maintenance and having greenfield engineers used as examples of how to be better can be demotivating.

Some people just love a certain legacy system (in the old days of more experimentation it was legacy hardware too) and want to be able to stay with it as long as possible.

This doesn't prevent them from keeping up with the latest stuff either BTW.

the ones with good pay check? /s

This is the trick, always pick the work that is relatively easy/has less unforeseen edge cases. Rapidly develop it before it becomes complex. Collect your pay checks! Theres no reason not to do this, life is short, just avoid the bad work at all costs.

I read somewhere a report that suggested that top software engineers tend to be up to 3 times more effective than average software engineers, and that 10x and the like is only really achievable in comparison to the worst engineers, and the worst engineers are often so bad that it's not sensible to compare with them. For a company, avoiding those guys is probably even more important than hiring the best - if your company has 10x engineers, your recruitment process is probably broken.

I have worked with some extremely productive software engineers. They tended to know the domain and codebase they were working in well, worked long hours and had either the enthusiasm, motivation or mental practice to maintain focus, and I believe those factors explained the majority of their advantage, which was large but not superhuman.

But like the author of this article, I've also seen a lot of situations where an apparently huge multiplier was best explained in some other way. For example, some apparently 10x engineers were only so because they were allowed to only work on interesting, relatively easy early stage work. The difficult, fiddly work of mopping up the awkward corners was left to other engineers, who were considered 'slow'.

Incidentally a lot of people will be a lot more productive if you let them work on only projects that interest them. I know some people who were considered 'problem' engineers because they spent most of their time doing stuff other than what they were asked to do, but they made a lot of interesting and useful stuff and with only a slight change in perspective or luck, they could have been considered 10x developers.

For maximum impact, having the wisdom and opportunity to work on the right thing is much more important than working 10x as hard.

> For example, some apparently 10x engineers were only so because they were allowed to only work on interesting, relatively easy early stage work. The difficult, fiddly work of mopping up the awkward corners was left to other engineers, who were considered 'slow'.

I am someone who loves mopping up the awkward corner cases. For me, this is the most fun part of coding. I think the early design and infrastructure work is actually pretty challenging work. The decisions made at this stage pay dividends later on, in ease of debugging, api goodness, future expendability, etc. I prefer collaborating with senior engineers who are strong and relatively fast with that, and then I help clean-up to facilitate their speed. If everyone is on-board, I am not sure what is wrong with this arrangement.

> If everyone is on-board, I am not sure what is wrong with this arrangement.

I think that insufficient attention is paid in hiring to building a team of people whose interests compliment each other.

The situation you describe is fantastic. Problems would arise only if you and the senior were compared on speed for what are actually two very different kinds of work.

I believe the "full-stack developer" meme did a lot of harm here. It is hard to discuss different strengths of different people openly, when everyone pretends they understand everything equally, because admitting that you specialize on X and can only do mediocre work in Y makes you seem like a loser compared to people who pretend to be great at everything.

I have seen people happy when the database guy was allowed to design the database, the back-end guy was allowed to write back end, the front-end guy was allowed to write front end, and the CSS guy wrote the CSS. Then management intervened and said no, the highest priority task must be done immediately, by the first person available. Afterwards both the happiness levels and the code quality returned to the mean.

> worked long hours

This is interesting to me. Of course from a business perspective you want to prefer developers who are willing to put in big amounts of OT.

But when it comes to judging their productivity, is it really fair to compare them to your devs who don't put in OT? As far as their performance review, maybe sure. As far as their actual skill and effectiveness? It seems unreasonable.

A dev dev who works twice as much as an average dev is not suddenly equivalent to an average dev because the work they are producing is probably not that great.

Yeah, I was nervous putting that in there, because I think beyond a certain level, long hours start to tell in other ways. Some of the people I'm thinking of were contractors and would take months off at a time when they weren't working super hard. Some of them simply allowed their work to take up an unreasonable portion of their life, which then sometimes had negative effects on health down the road.

I've also seen multiple times when '10x' engineers did a crazy hack working late into the night, which was lauded by managers, but actually had to be entirely rewritten over much longer by less lauded engineers.

Lack of sleep probably impedes coding ability as much as alcohol (and that's another factor I've seen create big chunks of code that needed to be rewritten).

I just hope people don't fall into the trap of believing every 10x engineer is just a symptom of dysfunction.

There are some truly remarkable people in this line of work and there exist 10x engineers that are just extremely smart, extremely hardworking, and it doesn't come at the expense of others. You'll recognize it when you see it -- if you're lucky enough. I feel blessed to have run into 10x people, because I really needed to be humbled. You have to work hard.

Absolutely. This article was annoying because I've worked with real 10x devs a number of times over my career. And one of them only worked 4 days a week and kept the computer closed on weekends! She was remarkable, and easily more productive than anyone else, at least by a factor of 10. She also wrote the best tests.

I feel like the article is describing an anti-social (please don’t confuse this with introvert, or shy) developer. Pathologically, their behavior is dysfunctional (I’m avoiding the overuse of the word toxic since it has major pejorative implications on ones character). Dysfunction can be rehabbed, and often a symptom of ongoing bad habits and insecurity.

The one implied aspect of the 10x engineer that the article doesn’t address explicitly is productivity. I sincerely believe most 10x engineers arise from a situation where they wrote all of the initial code. This is an advantage that can make it difficult for any other engineer to appear within reach of the ‘10x’ engineer, especially if the initial architecture was convoluted.

These ‘10x’ engineers usually compensate by being highly available and protective of the architecture. How the latter manifests (guardianship of the codebase) can be related to where they are on the anti-social spectrum. Hiring juniors that can’t assess the true nature of the codebase is common.

To the article’s point, some of the symptoms the ‘10x’ engineers exhibit are negative. The question is, why? The root cause of it simply can’t be ‘secret genius that has character flaws, like all other secret geniuses’ - that’s a caricature. I would hammer home that the symptoms are by-products of a process that allowed such a situation to occur.

Word to the wise, don’t create a ‘10x’ engineer in your company by propping them up and giving full ownership, and consequently, the subsequent task of maintaining the defense of the shoddy situation. It’s unhealthy for everyone involved.

The writer does not understand or appreciate eXtreme Programming principles. They slam continuous refactoring, while continuous refactoring is THE thing that keeps your codebase from falling apart.

90% of the time the refactored code is objectively worse than the code it replaces. Gmail's UI was refactored into one of those shiny SPA apps, and it's absolutely awful now. Type in the search box before it's loaded and your key strokes get jumbled or keys get ignored because 50mb of JS garbage is thrashing your i9 CPU. Old Gmail was 100x faster and didn't make my laptop sound like a spaceship.

Refactoring is a retention program for engineers that provides almost no customer value.

Counterpoint: how often do you have a lump of legacy code that no one wants to touch, and changes in that area become too scary? Refactoring can address parts of that, by adding tests and identifying use cases.

The Gmail UI change is not a good example since it is a UI refactor.

Engineers might not have any say on features that the product manager wants but impacts performance negatively.

It is not refactoring if it changes functionality.

I get the impression that they're using a different definition of refactoring. It would have read better to me if they had said restructuring.

Tomato, tomato.

Well except that refactoring has a specific description that rules out what the OP talks about.

Yes. The dictionary definition of refactoring is ”restructuring of source code without altering functionality”.

Agile, agile.

Et tu, scrumfall.

The idea that if you want to be 10x you have to avoid empowering your teammates is false. Teamwork skills generally are one of the most realistic ways to become a 10x'er, when it comes to what matters, which is making your team succeed.

Simply beating up your entire team and hospitalizing them and boasting about your superior productivity compared to them won't make you a 10x'er even if it makes you relatively productive.

This is a really refreshing take to read.

I do think there is a lot of skill variance in developers. If we consider the theoretical best developer in the world vs the average developer, do you think there would be a truly 10x productivity difference?

Maybe from the theoretical best developer in the world to the theoretical worst, but that's kind of a silly and useless comparison anyways.

I bet if you find a super smart, top tier developer working on something that motivates them, you'd see a 10x vs average developers. I also think there are some problem domains that are just too difficult for some people to work on, and their productivity would be very low or zero.

Call me biased, but I don't believe the average developer is very good.

The first time I saw people posting about 10x engineers I thought it was a meme and a joke... I assumed the punchline was super obvious and clearly insinuated the things written about in this article.

That lead to a couple awkward situations where I discovered the adoration of what were even obviously poor behaviors such as treating other devs poorly ... was sadly serious.

I feel the author does not understand the meaning of 10x engineer. Fabrice Bellard is a 10x engineer. They are rare birds. Their output is undeniable super human. The idea that one can strive to be a 10x engineer is a fallacy. One can't, you have to be born that way, like a savant that can take one glance at a cityscape and then draw it from memory.

https://en.wikipedia.org/wiki/Fabrice_Bellard

The effect of most 10x software engineers is seen most often at the architectural level rather than the coding level of the project.

The 10x Software Engineer is a symptom of the tech industry's tendency to quantify everything.

You don't see people talking about 10x doctors, 10x engineers or 10x musicians.

Reply on news.ycombinator.com