
A look at the 10x paradigm - devupio
https://devup.co/10x-or-not-youve-got-to-do-things-right-8e45311ecbcb#.pdul8uywo
======
wvenable
Like others here, I don't consider 10x programmers to be someone who writes
10x the amount of code. In fact, most 10x programmers actually write less code
but get more done with it.

Personally I think the narrative works better when you think there are 1x
programmers and 0.1x programmers. And a very large number of developers are
actually between 1.0 and 0.1. These 0.1x programmers somehow manage to solve
problems by simply puttering away at it over time. For example, these
programmers might start out reading a web service into an XML file, re-opening
that XML file to process the result, copying that file someone else that is
never read again, taking the result and inserting it into a database table,
reading the table to create an aggregate result, and then finally inserting
that result into another system. And they do this all day long every day for
every problem they come across.

Not everyone is quite that bad, there are 0.5x programmers who know better
than that but still manage to write 6 classes to solve a problem that could be
done in a single 2-screen long function.

Tools and processes can help and code reviews are pretty invaluable. Any good
process will have weeded out 0.1x programmers already and they will settle in
those places without them.

~~~
eecks
> 6 classes to solve a problem that could be done in a single 2-screen long
> function

Isn't the former promoted as better programming? IoC, decoupling, Law of
Demeter, testability etc

~~~
1138
Promoted? Yes. Actually? No.

~~~
eecks
So, genuine question, why?

~~~
ktRolster
You scatter the code all over the place, making it harder to understand and
less flexible (less flexible, because if you want to change something, now you
have to change it in six places).

Best practice doesn't mean "make as many classes as possible" although I would
probably break up two-pages into a few different functions (large functions,
even when they are good code, invite programmers who come later to add to them
in a messy way).

~~~
rimantas
If you have to change it in six places it just means that you did something
wrong. Keeping those six places in the single file is not the solution either:
next time you will need something similar, but not exactly the same you will
copy that file. And next you will find yourself changing twelve places.

~~~
wvenable
The good rule of thumb is not to refactor into reusable parts unless you need
to do something similar. It isn't hard, _at that point_ , to split things up.
Premature design is like premature optimization -- you do the wrong things, or
things you never need to do.

And yes changing things in six places means you did something wrong, but
that's easy to do when you _start_ by splitting things into six places. The
worst, of course, is when developers don't change it when it needs to be
changed and instead just keep adding. Once you have something so _designed_ it
makes removing and changing code more painful than adding code.

------
wting
10x is a measure of impact relative to others. From that definition, I have no
doubt it exists. There's a couple ways to find 10x'ers:

# A person that does things no one else can.

A problem requires calculating taxes for an invoice. Someone who computes this
programmatically is better than a person who hand calculates everything.

A problem requires calculating the area under the curve. Someone who uses
calculus is better than someone who only knows algebra and geometry.

A problem requires charging a user's credit card once on checkout. Someone who
understands idempotent operations is infinitely better. (I was charged 3 times
for a single purchase yesterday, and now disputing with the merchant.)

# A person that grows the people around them.

A person growing teammates to 2x or 3x their previously level has a cumulative
10x impact.

This can be teaching how to approach problems, choose the right abstractions,
make engineering tradeoffs, manage risk, write robust code that is easily
testable, etc.

# A person that makes others more efficient.

If the average dev waits 1 hr for a build, and someone reduces that to 5
minutes then they have saved: x devs * y builds / day * 55 min

This has indirect effects such as maintaining flow state, minimizing context
switching, etc.

# A person that brings down the teammates.

A dev that builds fast enough (5x), but grows tech debt such that the rest of
the team operates at 0.5x. By definition they are a 10x relative to their
teammates. :P

------
devishard
This article starts off with addressing how so-called-10x developers are often
just building tech debt into their applications. I was with Tiwari on that.
Then he moves on to creating a non-judgmental culture... not sure I agree
there. And then... linters? Huh?

I think that the anti-judgment folks are trying to achieve something good, but
they're throwing out the baby with the bathwater. We need to make a
distinction between judging behaviors and judging people. The former isn't
just good, it's fundamental--the only way to improve your behaviors is to
judge them. But judging people is generally pointless, at least without some
sort of temporal limitation--almost everyone starts at a new job as -0.5x net
contribution until they're onboarded and improves from there.

~~~
d23
> This article starts off with addressing how so-called-10x developers are
> often just building tech debt into their applications. I was with Tiwari on
> that. Then he moves on to creating a non-judgmental culture... not sure I
> agree there. And then... linters? Huh?

Thank you. Did anyone read the damn article? It's all over the place --
borderline nonsensical. I suppose it's intended to be a promotion of their
company. Color me unconvinced.

------
Darmani
There are a couple ways to be called a 10x programmer.

One is by doing more, by throwing around more code and building more features.
This is the kind that the article talks about. It's quite hard to maintain
this kind of multiplier, no matter how much technical debt you're willing to
create. I can think of one example of someone like this, and his multiplier
was definitely not 10x. At the time, he was at best labelled "up-and-coming."
He'd go home over the weekend and write thousands of lines of code, and then
the team would come in and find everything broken.

Another is by doing less, and simply being at a higher level than others.

In my experience, no-one gets to 10x by just banging harder and letting other
people clean up the mess. Even if you do, those aren't the people whose impact
is felt for years after they leave, at least not in any positive sense. You
get to 10x by being the one person who can spot the mess the rest of the team
is about to create before they've written the first line. Your impact isn't
felt for years by writing code: it's felt by setting the architecture, by
making design decisions that constraint people into writing good code for
years to come.

~~~
ktRolster
_In my experience, no-one gets to 10x by just banging harder and letting other
people cleaning up the mess._

Yeah, that's a good one. Cleaning up your messes is a way to improve your
architecture skill quickly. I can give you other ideas that will quickly push
you to 10x skill level:

* Focus. Put away your phone, don't surf the internet at work. That alone will raise you above the crowd and let you go home early.

* Fix bugs early. Don't send them out to QA, don't send them to customers. Once your bug count starts increasing, it's a death cycle that slows you down like molasses.

* As soon as bugs (or problems) come in, try to think of a way to avoid that problem in the future. Over time, you'll develop habits that will serve you well.

------
j45
It's less about 10x programmers and programmers that can do 10x architecture.

Clever and elegant architecture will always beat clever programming.

It's almost always a large part of how "10x programmers" achieve so much.

10x effectiveness comes out in different way on different projects, be it new
code vs existing code, or knowing enough about the solution space vs being in
an unknown world.

~~~
maxxxxx
I'd say that coming up with a 10x architecture is also a matter of luck.
Sometimes your architecture pans out, sometimes it doesn't. It's hard to
anticipate future requirements.

Where good people win is that they adapt quickly when there are signs that the
design doesn't work. A lot of people just "stick to the plan" although
everybody knows that it won't work.

~~~
devishard
I think "anticipating future requirements" is entirely the wrong way to
approach the problem.

Instead, you should look at how those requirements will be produced. If your
architecture "thinks" the same way as your users, it will be able to be
modified easily to include more of their thinking. So instead of trying to
predict future requirements, you should attempt to capture and accurately
model the way your users think about the problem. Sometimes that creates
designs that mathematically/algorithmically seem pretty ugly. But in the long
run I'll often discover that the ugliness exists for a reason--people mostly
only add complexity to their mental models because that complexity allows them
to solve a problem. So even when the domain expert's thinking seems
overcomplicated, it's usually actually the _least_ complicated model that
accurately represents the problem.

~~~
tensor
This has definitely not been my experience. Users vary greatly, some like
simple mental models, but some love complex mental models. You definitely
shouldn't be letting your users define your product.

Rather, listen to your users problems, listen to what they think a solution
is, then let your design team determine if there is a better and more simple
solution. Sometimes there may not be, but often there is.

~~~
devishard
Of course you shouldn't let users define your product. Nothing about what I
said suggests that.

When you get requirements from your users, they're going to mix in how they
think about the problem with how they think that problem should be represented
in the program. The problem with that is that they don't know what computers
can do, so they can't possibly be expected to know how the problem should be
represented in the program. And in fact, the UI, which is the only thing they
ever see, will probably be more task-oriented than representation-oriented, so
they probably will _never_ see how your program actually models the problem
and therefore won't be able to suggest good changes to it.

Ultimately, though, there's an underlying mental model that the user is using
for the task. And for most fields, there's really only one correct mental
model, so I actually disagree that expert users have different mental models,
at least not with significant differences.

------
leovonl
Fact: everybody wants a 10x programmer but nobody wants to be a 10x manager.

Also, dealing with a skilled programmer is not just a matter of top-down
policy: a 10x programmer may have a different opinion about tools and
processes and will not be happy on simply conforming - as opposed to the
programmer who doesn't know better.

~~~
ktRolster

      >but nobody wants to be a 10x manager.
    

How would one go about becoming a 10x manager? Like, what would that person
accomplish?

------
ktRolster
Every study I've ever seen has found that some programmers are dramatically
more productive than others (10x is a vague estimate). I don't think it's a
controversial 'paradigm' at all.

It also matches with the fact that skill in general is an exponential
distribution, not a bell curve.

------
blacksmythe
Does anyone doubt that there are 2x programmers (programmers twice as
effective as an average senior developer)? I have worked with a number of
them.

If one were to assume some sort of power law or Gaussian tail distribution, it
is logical to assume that a few 10x programmers exist. However, they are going
to be sufficiently rare that you are not likely to be able to find them or
recruit them.

A more interesting question is if there are 3-4x programmers, and if so, is it
feasible to find and recruit them? I have worked with people (rarely) that I
would consider 4x programmers.

------
x64_lol
Where is this rush to hire 10x people taking place? I asked the last 10
recruiters who called me if they know what a 10x developer is, and they had no
idea.

------
BerislavLopac
The main problem with the "10x productivity" myth is that it's not clear what
is that 10x _of_. Is it the amount of functionality? Or maintainability of the
code? Reusability? Performance?

I've seen many developers implement some functionality in a record amount of
time, but the resulting code was later discovered to be a) bug-ridden, b)
difficult to maintain, c) unscalable or d) all of the above.

~~~
mathgeek
> the resulting code was later discovered to be a) bug-ridden, b) difficult to
> maintain, c) unscalable or d) all of the above.

I think this describes most code that's ever been written.

------
hashkb
[http://kytrinyx.com/presentations/here-be-
dragons](http://kytrinyx.com/presentations/here-be-dragons)

An excellent talk that can put this in perspective for non technical people.

------
x64_lol
I see the point here.

No matter what it's called, you're talking about people that don't use best
practices, for better or worse. Best practices will get you where you're going
in a predictable way, but there is a ton of inefficiency, as they don't take
your specific problem into account.

When I was new to moving away from best practices, I wrote a lot of difficult
to understand code that was very performant. I spent my evenings reading
documentation, reading the code of the people I admired (mostly decompiled
framework code), and was very excited to put what I learned into practice and
learn by experience. It made me proud to write code that out-performed my
coworker's code by orders of magnitude. I worked for one of the top 100 most
trafficked sites in the US, and on a platform that was not designed for that
level of traffic (none are).

A month later, the lead architect and I had a discussion that did not go my
way. I was asked to write a very public and humbling apology to the team, and
that apology still exists hosted on the internal network at that company (in a
place that is easy to find). I had a lot of talent, but not a lot of wisdom.
From that day on, I was to work on the most difficult projects exclusively,
and under direct supervision of that architect. We worked on maintaining the
performance edge, but doing so in a way that is easy for other developers to
understand and extend. He taught me to interface directly with the other
departments and senior management to make changes to the development process
before work got to development; to enable us to do our best. It was a
difficult road, and I was yelled at a lot; but eventually the architect
cleared me to work without supervision. What followed is the most productive
two years the company I worked for had ever had. I was promoted multiple
times, was awarded patents, and was able to do a lot of lasting good. I had a
hand in every project, feature, and department. I designed and internally
evangelized a few myself, and had become the go-to guy to get difficult things
done. You know this company, if I told you their name you'd recognize them and
their product immediately (you've likely used my work).

I left about 4 years ago to build my own company. I do consulting during the
day, and take jobs that require a hero to survive (to stay sharp). Since I
left, there have been no significant new features or achievements out of the
company I left.

Moral of the story: If you're talented, your idea of a good night is reading
documentation and decompiling/memorizing products you like, and want to be a
10x developer; get someone you admire to yell at you, rip your work apart
every day, and tell you that you're garbage for a year. It will do you (and
your company) a lot of good.

~~~
tensor
There must be more to this than you've said. Simply writing difficult to read
code doesn't seem like a good reason to tell someone they are garbage and to
publicly humiliate them by forcing them to give the team an apology. Usually
simply bringing it up in a one on one should be enough, most people when
pointed out that they should focus on documentation or readability by others
will quickly and gladly take that advice without being yelled at.

~~~
x64_lol
There was more to it. I was not just writing pages, I was writing a micro-
framework to support my pages. I was doing manual complex multi-threading,
run-time code generation and compilation, custom memory caching, run-time
server-side generation of graphics (before HTML5 canvas or solid SVG support)
etc. Two days after my hire, I was assigned solo to a very difficult project
and the product department recognized me as a way to get everything they
wanted done without push-back (and without going through the normal chain of
command). I never told them no, so they gave me everything someone else
wouldn’t do (including projects that had been previously cancelled due to
technical complexity concerns, breaking the design refinement process that is
meant to take place). Since they kept giving me challenging projects, I took
every project as a personal challenge, and I finished them in record time. The
team was very busy, and there was very little time for code-review. My micro-
framework went unnoticed for quite some time. My pages looked simple, as they
were mainly just making calls to the micro-framework. I thought I found my
place; I was getting individually requested by the product department for
projects (which was unusual), and I was giving them everything they were
asking for. I thought I was taking pressure off of the rest of the team. I
thought I was being a hero. What I was actually doing was creating an area of
the code-base that effectively a black hole for everyone else and giving the
product department unrealistic expectations. There is a natural trade-off
between performance optimization and readability; and I chose performance
optimization every time. My inspiration (decompiled framework code) had no
comments, so I had no comments. It was performance optimized, so my code was
performance optimized. I wanted to be my heroes; and there were plenty of
heroes to become. The maintenance developers did not share my enthusiasm for
study, hard-core mathematics and lateral thinking. They referred to my work as
“the space shuttle”; as in “I don’t want to touch that, I might break the
space shuttle”.

I was never literally told that I was garbage, but I was made to feel that
way. It was necessary, I was getting mixed messages; some of the managers
loved me, product loved me, the designers loved me, the other developers
didn’t know what to think of my work. Technically everything was written
concisely, extensible (by someone who understood it), performed very well, had
few bugs (if any), and was pixel perfect when compared to the comps. I was
giving people what they wanted, quickly and relatively bug free. I lacked
discipline, and my architect was ex-military. He effectively stripped me of my
ego, and I am very glad he did. I imagine the apology was a plan to make sure
management and other developers didn’t encourage me (and it worked).

The year of discipline was the best thing that could have happened to me. It
completely changed the way I thought about software development. It wasn’t
just me anymore, it was everyone. It made me a much more effective employee,
and taught me to spread complexity out. I am still fast, the code is still
performant, but I stopped building black holes and do more of my code and
process optimization in architecture, design, and process and less in fringe
techniques. I still use fringe techniques when there is no “normal” way to
accomplish what needs doing (and we can’t change what needs doing), but they
come with full explanations now, are built to be discoverable, and I spend
significant time training a second person in how to do the same in case I am
hit by a bus.

Before, if management gave me the requirement that they should be able to
flush a Doberman down the toilet, I would build them the world’s most powerful
(and frightening) toilet. After, I knew to argue that we should be burying
dead Dobermans outside, and I knew how to get management to agree.

TLDR: I am considered a 10x developer by my co-workers, but early on I was one
of the scary people this post is warning about.

