
Becoming a 10x Developer (2018) - jiux
https://www.kateheddleston.com/blog/becoming-a-10x-developer
======
reese_john
Well like others said, this reads more like an opinionated piece on how to be
a good teammate.

I think Antirez[1] has more practical advice on how to actually become a "10x
programmer"

Key points:

* Experience: pattern matching

* Knowledge: some theory is going to help

* Low level: understanding the machine

* Debugging skills

* Perfectionism, or how to kill your productivity and bias your designs

* Design sacrifice: killing 5% to get 90%

* Simplicity

* Focus: actual time VS hypothetical time

[1] [http://antirez.com/news/112](http://antirez.com/news/112)

~~~
djmips
I think this is the closest I've seen to a concise answer to the 10X
programmer's advantage. Earlier in my career, I noticed a fellow programmer
who was quite noticeably faster at completing tasks than everyone else
including myself. We also had a coding competition and I 'programmed' as fast
as he did in direct comparison on the same task. So it turns out, the
performance boost was not in raw coding speed but a lot of other things like
not being distracted, being ok with a great but not the greatest design,
getting to work and avoiding analysis paralysis. A sense of urgency from day
one on a project.

When competing head to head for a fun competition, many of these things come
naturally but when given 'time' it can be easy to fall back to less productive
habits when a deadline is months away.

Like my mentor Steve Hayes once told me 'hands on keyboard'

------
benjaminjosephw
> Teams that work well together can outperform groups of people who are
> collectively more talented because there is a multiplication factor for
> teamwork.

There's some great advice here about building a team culture that allows
everyone to level-up and contribute their best. Some comments here have
suggested that this isn't what 10x means but that's the point! What if we
value the wrong kinds of people in our teams - the talented jerks? We should
instead call out the value of those that help the whole team improve.

On top of the productivity gains, the value of building a culture like this is
invaluable for a startup or team with a long-term vision. It builds a sense of
camaraderie and environment for learning and growth that draws people in and
keeps them around for a long time.

Jessica Livingston shares on the role she played in founding YC and building
the culture. She points out some of the same kinds of ideas in one of her
talks[1] showing that some of the soft skills and the social environment that
founders build are way more important than they often realise.

[1] -
[https://www.youtube.com/watch?v=8d-cApFHjeY](https://www.youtube.com/watch?v=8d-cApFHjeY)

------
Gravyness
> Invite discussion with your language by using words like “I think” and
> “maybe”. (I call this conversational style: "Maybe you should talk more like
> a woman?")

Aside from the fact that I did not understand that "talk like a woman" thing,
is the author advising us to stop the long-running advice of "speak precisely"
with "say anything, even if you are not sure' with the only caveat being to
let people know when you aren't certain of something?

That's like a public speaker telling me to say "uuhh..." in between my
phrases!

~~~
rumanator
> is the author advising us to stop the long-running advice of "speak
> precisely" with "say anything, even if you are not sure' with the only
> caveat being to let people know when you aren't certain of something?

You got it all wrong. The key point is that by adopting a conversation style
where you cease to impose your beliefs as unquestionable facts and start to
leave the door open for others to provide their observations and insight, you
start to get observations and insights from others.

It's as simple as that.

And by the way, your personal opinion is not precision or an expression of a
fact. Your personal opinion is just the conclusion you've made based on the
information and experience you had up to that point. If you cease to be
defensive about your opinions when sharing them with others, others will
follow suit.

------
ravenide
Here are some serious outstanding problems in software:

* Considering how fast modern computers are, software is so damn slow.

* Software frequently stops working. When it does, the process to diagnose the bug and fix it conclusively is not a straightforward one.

* Software is poorly understood. Most developers today work with other people’s abstractions. It’s rare to find a software system that someone can describe the inner workings of end to end.

* Software is excessively complex. To understand a codebase, you might have to crawl through ten layers of dependencies, imports, and scaffolding before finding code that actually does anything.

These are just some obvious ones off the top of my head. Does following the
advice on this list make me any better at tackling any of these problems?

Could someone conceivably do _none of the things on this list_ , and still be
a very skilled developer who makes strong strides toward solving these
problems?

~~~
dragonwriter
> These are just some obvious ones off the top of my head.

But they are all the same one (the last form is the clearest statement),
restated in different ways or viewed through effects that the same source
causes.

~~~
Olreich
I’d argue that there’s at least two problems: software is needlessly complex,
and no one understands what the computer is doing.

You might say that second one is the same, but our model for what a processor
is and what it’s doing and how fast it’s working hasn’t changed in at least 10
years. Graphics cards have gotten faster, but still have a similar operating
model. If anything access to low level systems has gotten easier to understand
and harness.

Because all of this stuff is still the same, you can usually take a look at
any piece of software and make it faster by aligning the code to what the
computer is good at. That could be done by increasing data locality and
widening the processing pipe with SIMD. Caching and cheating the calculations
are also often good since they essentially skip work that will go unnoticed.
This will often increase the code complexity, but improve the software speed.

------
peter_d_sherman
Excerpts:

"1\. Create an environment of psychological safety"

"6\. Hold yourself and others accountable"

Now, not to get all lawyerly (I am not a lawyer) or anything, but...

 _How exactly do you do #1 if it conflicts with #6?_

?

And...

 _How exactly do you do #6 if it conflicts with #1?_

?

~~~
Msurrow
Psychological safety, I think, comes with not being afraid of unexpected
actions or consequences of actions, and from knowing that not everything is on
the line all the time, ie it is ok to make mistakes. Safe = not having to fear
being fired or worse due to either mistakes or unexpected reactions of bosses
and peers.

You can do accountability while having that safety by (kindly) informing
people that they will be expected to do a task that they accept/are given, and
being clear about other expectations like deadlines, BEFORE they start the
task. Give people the informantion needed to predict the result of their
actions. And by growing a culture where people know that it is bad not to
uphold an agreement (and that may include some kind of “punishment”, which ofc
is known to everyone beforehand). It is not bad to do you best to solve a task
but make a mistake doing it. That should not have consequences.

------
downerending
However overused, the phrase _10x developer_ does have a fairly specific
meaning, and this isn't it.

~~~
al-king
The article is pretty up-front and unapologetic about that conceit: the
argument is "that mythology isn't useful, here's a better one."

That said, it's certainly a bait-and-switch headline. Kind of par for the
course.

~~~
rumanator
> the argument is "that mythology isn't useful, here's a better one."

That's just a lame attempt to piggy-back on the name recognition of an
established concept to try to funnel the spotlight on an entirely different
and unrelated concept.

Different concepts are different. Thus they should be named differently,
without resorting to unexcusable PR tactics.

~~~
lonelappde
It's not like "10x developer" was ever an intellectually rigorous concept.

~~~
rumanator
> It's not like "10x developer" was ever an intellectually rigorous concept.

Isn't it? The developer whose productivity is 10x the average developer's?

Sounds like it's straight forward to me.

------
dang
Discussed at the time:
[https://news.ycombinator.com/item?id=17304619](https://news.ycombinator.com/item?id=17304619)

------
mpoteat
Every developer should do all of these things, the behavior and norms
described in this blog post seem like the absolute minimum to have a healthy
work environment.

------
ncmncm
I know a >250x programmer. That is strictly objective: on a 500-engineer
6-month death-march project, fully half the code delivered was his. He knows
somebody who he estimates at 10x his own rate, and who wears out 2 keyboards a
year (or did, 20 years ago).

(You might object that this makes him a 500x programmer, but he doesn't agree:
a fair bit of code was written that did not end up in the product, an unknown
fraction of which was good.)

~~~
ablekh
I'm curious about what was the technology stack for that project. Also, it
would be very interesting to learn what those ">250x" programmers think on
various languages / technology stacks (that they use) from the developer
productivity perspective ...

~~~
ncmncm
This was in the '90s, so pre-'98 C++, on a proprietary OS fielded by Siemens
and Ericsson.

The stacks in use today optimize for accessibility by less skilled
programmers, and (more) for heavy requirements on management participation and
total head count. Productivity is a non-goal. A 250x programmer would be
distinctly unwelcome _almost everywhere_ , today, although there are still
more places that want one than are available to hire. I spoke recently with
someone who spent time at Walmart corporate, and got in deep, deep trouble for
finishing in a week a project scheduled to take 12.

Dan Luu explains on his blog how little value his employers have placed on his
contributions that earned or saved them hundreds or thousands of times his
salary for the time he spent. Managers mostly value what improves their
standing among other managers, not what benefits the company.

Doing what benefits society or the world gets you escorted out without
severance pay.

~~~
ablekh
I much appreciate your comment. This is all very interesting and very weird
(or even quite scary), at the same time.

------
smabie
And I thought being a 10x developer meant cranking out high quality code..

~~~
commandlinefan
I would have thought it would have at least something to do with computers at
all...

