
A personal story about 10× development - bkor
http://nibblestew.blogspot.com/2019/07/a-personal-story-about-10-development.html
======
quadcore
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_

~~~
mugsie
> 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.

~~~
jacquesm
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.

~~~
fogetti
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.

~~~
supermatt
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.

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

~~~
supermatt
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.

------
pizza234
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

~~~
spion
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)

~~~
Crinus
> 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.

~~~
spion
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.

------
lasagnaphil
_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.

~~~
karma_fountain
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.

~~~
bdavis__
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').

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

------
benjaminwootton
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.

~~~
mugsie
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.

~~~
laichzeit0
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.

~~~
mugsie
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.

~~~
zimpenfish
> 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?)

~~~
kumoflow
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.

------
craigzucchini
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.

~~~
nerdponx
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.

~~~
pavel_lishin
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.

------
GoToRO
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.

~~~
commandlinefan
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.

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

------
n_ary
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
:(

~~~
BigJono
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.

~~~
Nyandalized
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

------
xenator
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.

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

------
tjpnz
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.

~~~
arethuza
"which HTTP verbs you were allowed to use"

I hope they only allowed GET?

~~~
Elixyrs
Nah, only DELETE

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

------
tabtab
"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.

~~~
JamesBarney
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.

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

------
randomsearch
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.

------
ramblerman
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.

~~~
kareninoverseas
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.

~~~
ramblerman
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.

~~~
themarkn
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.

------
probablybroken
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.

------
empath75
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.

~~~
maaaats
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.

~~~
kevinconroy
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.

------
jnwatson
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.

~~~
kevinconroy
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.

~~~
username90
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.

~~~
kevinconroy
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.

~~~
jnwatson
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.

------
cosmodisk
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..

------
adim86
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.

------
Kaotique
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.

~~~
jonathanstrange
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!

~~~
GuB-42
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.

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

------
pjc50
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.

------
losthobbies
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.

------
tmaly
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.

------
fareesh
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.

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

~~~
Traster
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.

------
gbersac
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...

~~~
tluyben2
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?

~~~
CraigJPerry
>> 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.

~~~
tluyben2
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).

------
yomly
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...

------
noir_lord
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.

------
phtrivier
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.

------
stanislavb
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.

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

------
pixelbath
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.

------
karmakaze
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.

------
bushido
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](https://basecamp.com/shapeup)

------
mbesto
"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.

------
Gin1234
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

------
he0001
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.

------
ilaksh
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?

------
hyperpallium
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.

------
strictfp
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.

------
dep_b
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.

------
qwerty9876
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.

~~~
Nyandalized
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.

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

------
austincheney
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/](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.

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

~~~
Nyandalized
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.

------
artsyca
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

~~~
mbrumlow
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?

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

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

------
choeger
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?

~~~
Traster
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.

~~~
mbeex
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.

