
10x or not: You’ve got to do things right - tiwarinitish86
https://devup.co/10x-or-not-youve-got-to-do-things-right-8e45311ecbcb#.enn4v8i3v
======
Xcelerate
> Odds are far better than good that your high performers are achieving what
> appears to be high levels of productivity by building technical debt into
> the application by taking shortcuts whether intentionally or
> unintentionally.

Perhaps this is a true statement; however, I have no doubt that 10x
programmers do exist who do not build technical debt into the application.
Some people really are _that good_. I don't think the average person realizes
exactly how good the best in the world are at what they do. For instance, I
ran track for 8 years and competed in college. You don't realize exactly how
insane a 12:37 5K is until you've trained as hard as you can for years and
you're not even close to that time. Nor do you realize how difficult a perfect
rendition of Liszt's transcendental etudes are until you've spent years trying
to learn them on your own. I imagine the best programmers in the world are
similar, but it would take the average programmer decades of programming
before the magnitude of the skill gap becomes evident.

~~~
ljw1001
10X programmers are unicorns.

If a 5K of 12:57 was really "10X", an average runner would take just over two
hours. That performance is nothing like 10X.

~~~
bdcravens
I don't think that's a good analogy - a run has a very defined course, a very
defined technique (you must run, not use a motorcycle), and very defined end
point. Most programming problems have infinite solutions, and you're typical
1x developer can only see what they know and have experienced.

To carry the analogy forward, a 10x runner might take a shortcut, use a better
implement to complete the course, etc.

~~~
sn9
It's more about taking an analogy where you compare a normal distribution to
something that isn't a normal distribution.

Physical capabilities of organisms (e.g., strength, speed, jumping height,
etc.) tend to fall into normal distributions.

Knowledge work where you can take advantage of powerful (mental | software)
abstractions don't tend to fall into normal distributions, as previous work
can make a bottleneck disappear, leaving you with more mental bandwidth for
other concerns, which quickly expands your capabilities.

~~~
ljw1001
intelligence is a physical capability.

~~~
sn9
I wasn't talking about intelligence.

I'm talking about productivity in knowledge work which is different.

------
xiaoma
It's interesting how different this advice is from what some of the greatest
engineering cultures have done.

At Microsoft during its heyday in the 90s, it was common for people to say
things like, _" That's the dumbest fucking idea I've ever heard"_ and the
behavior came straight from the top. Similarly, Steve Jobs and Jeff Bezos are
well known for humiliating engineers in front of an entire room after a
presentation.

[http://www.businessinsider.com/things-amazons-jeff-bezos-
tel...](http://www.businessinsider.com/things-amazons-jeff-bezos-tells-
employees-when-he-gets-angry-2013-10)

There's no way to prove the issue definitively either way, but I suspect this
blog post suffers from the cognitive bias of confusing how the world should be
with how it is. At the very least, a "no shaming" rule isn't a requirement for
building a world-class engineering organization and attracting top talent.

~~~
onion2k
Looking at Microsoft (or Ggole, Apple, Facebook, etc) is a distraction. They
have the resources to keep great engineers from leaving toxic environments -
not just by paying a lot, but by having the most challenging and huge scale
projects, and by having other great engineers. Those things don't apply to
Acme Software Inc. Most businesses aren't building world-class teams or making
cutting edge products. In that environment cultivating a team where someone
speaking up might be shot down and made to feel ashamed will lead to
developers refusing to share ideas, which is potentially bad for the business,
and worse, refusing to share experience, which is _definitely_ bad for the
business.

If an engineer feels they can admit a mistake early then the rest of the team
can help to fix the issue before it escalates to the point where you lose a
client. If an engineer hides their mistakes because they're afraid of how
their boss might react, things are left lingering, and they don't get fixed.
That's how _really big problems_ happen.

~~~
xiaoma
This is definitely true today. It wasn't true when MS was a startup and Bill
Gates was particularly harsh and it certainly wasn't true when Steve Jobs
returned to Apple. At that point they were only a few months away from
bankruptcy.

Another data point is the vastly greater acceptance of giving workers a
tongue-lashing in China vs the US. In that case as well, the harsher culture
has certainly been growing faster in terms of engineering-driven companies. In
fact, I've never seen a US company of comparable size that can move as fast as
a Chinese tech company. Part of this is due to differences in IP and
compliance laws but I believe culture also plays a role.

To be clear, I don't _like_ that employers treat their staff harshly. That
doesn't necessarily mean the practice is less effective, though.

------
issa
In my experience, the most important skill in an engineer is figuring out what
to build. Someone's skill at the actual task of programming is trivial in
comparison.

------
vigilant
The reason the debt metaphor is used for technical debt is that debt isn't
necessarily a bad thing - it just something to understand and manage.

Most people, when they buy a house, go into debt (e.g.: a mortgage) for the
initial purchase - without that debt, they would never be able to save up the
money needed to buy that house.

A startup seems similar - the first goal of a startup should be to show
traction and market fit before running out of runway - and if building up
technical debt lets them achieve that more quickly, then that is the right
thing to do. This first phase seems to be where the 10x programming would
shine.

~~~
pacala
Great point. Debt is a necessary part of bootstrapping a new project. That
being said, technical debt is not a blanket excuse for violating elementary
engineering precepts, shipping shoddy components full of bugs or a necessary
evil part of the final product. The team must be able to be specific about the
technical debt and execute a reasonable plan to repay it.

~~~
mpbm
Technical debt actually isn't a great metaphor. It breaks down too quickly, as
in this case. You don't have to "repay" technical debt. It's not really debt.

A company only needs to build something that works. If it works in spite of
violating elementary design precepts, shoddy components, bugs, and necessary
evil, then it still works. The only thing that matters is the result.
Investing resources into optimizing it so that it works better than necessary
is merely an option, whereas getting it to work wasn't.

The iron triangle includes cost and schedule in addition to performance. If it
would take more money or time than you have to make it perform better, then it
just won't, because you don't have that much money or time. A product that
frightens the maintainers, but keeps the lights on, is a good result.

Of course, you might optimize yourself into a local maximum if you're weak on
strategy. That's why nearly every organization in the world has some kind of
separation between "officer/executive" and "enlisted/staff" in the hierarchy.
Someone needs to balance the triangle and someone needs to write code and
there isn't enough time for the same person to do both.

------
vmarsy
All all the tools mentioned and similar tools are great and it would be a good
idea to integrate them in the development process, but I don't think they're
that useful to diminish technical debt.

Technical debt to me is uncessary dependencies, anti patterns etc. The only
way to prevent this is a good code review were people pay attention to such
things. Ideally the code author and the reviewers have the right thinking:
after checking for correctness, they ask themselves "is this code
modular/reusable/easily testable _/ easy to debug/..."

_ Hopefully the testing is already here, but that's in a perfect situation

------
miguelrochefort
"Right" is never fully defined, and keeps changing. Therefore, you can never
do the right thing.

My solution is radical, but necessary. 99.999% of code should never be
written. Let's start saying no to businesses with arbitrary demands, and let's
all agree on a set of standards. Only then will we have affordable and quality
software.

~~~
jpgvm
If we did that then we might actually start resembling a field of engineering.
Unfortunately software is much more nebulous than structural, mechanical and
other fields of engineering. There are less clear cut right and wrong things
to do.

Part of what gives software it's unique advantage in today's world is it's
ability to change to meet evolving demands quicker than any other way of
formulating solutions. As such unclear specifications are somewhat of a pillar
of software engineering.

However with unclear and perhaps rapidly changing specifications comes a lot
of judgement calls on what to build, how to build and what are reasonable
shortcuts to take. Software engineers are almost alone in this, most other
professions have the "correct" way and all the ways you can do it wrong. In
software there is no "correct" way and just many different ways of kinda
achieving something "right".

~~~
Fiahil
I guess, if it was possible to build towers and bridges at the same speed we
build software projects, we would see the same level of nebulousness appear.

------
venomsnake
If your name is Alice and you live in Wonderland. Or Harry in Hogwarts.

In the real where requirements change constantly, libraries that you rely on
rely on left-pad, budgets are short - or hell people just learn to write
better code - so the old need to be refactored - the debt accumulates.

Code debt is like entropy - always goes up. The normal state of a software
project is under staffer, under budgeted, in constant flux requirement wise
and for yesterday.

Doing it right with reviews, refactoring, consistently is a luxury. You can
try to have a process that minimizes chaos to minimum, but every project will
devolve into unmaintainable mess. You cannot afford to be pure while you have
the huge state monad called rest of the world that gives its best to crush
you.

~~~
sgift
Like every "we are doomed" answer there's a core of truth in here: If
something is used and/or changed it will probably break down.

Given that and trying to use it as starting point for something more helpful:
Sofware is nothing special here. Your things will - depending on their quality
- break down with time, especially when you tinker with them and/or use them.
You can push this further into the future using maintenance, repairing damaged
parts and so on, but at some point you will have repaired so much that you
will in essence have a new thing, not the old thing anymore.

The task is to balance your efforts with your use case. An engine which has to
work for one formula one race is constructed very different from one which has
to work 200 or 300k kilometers. Again, software is nothing special here. If
your software has to work for one run "doing it right" may be a luxury. If you
need your software for years to come your luxury becomes necessity.

------
conorgil145
The article referenced in the blog post is also quite good:
[http://thenewstack.io/10x-programmer-just-
jerk/](http://thenewstack.io/10x-programmer-just-jerk/)

------
im_down_w_otp
I'm pretty sure the marketplace has decided that doing things "right" isn't
particularly valuable.

There are places currently where you'd expect an extremely high degree of
rigor to be applied to a variety of engineering and technology problems
because the potential financial impact of a cluster of interrelated faults
would be irreparably financially and reputationally disastrous. But instead
you will often find the overwhelming culture is to instead hire legions of
employees/contractors ranging from demonstrably incompetent to tacitly
complicit in knowingly producing garbage just so long as that garbage can be
produced on reliably unrealistic (were any amount of rigor to be applied)
timelines, and where the optics of "progress" vastly outweigh the quality of
releases. And while none of this would be a spoken or agreed upon culture, the
set of incentives in place guarantee that results do not align with the
institutional rhetoric.

And as much as it pains me personally to see cultures like that (as a 1x
engineer who labors naively over correctness in design and implementation)...
for the most part I think the marketplace got this right. If you consider
realistically that the percentage of software
programmers/developers/engineers/architects who work on something truly
"mission critical"/"carrier grade"/"matter of life and death" is a rounding
error compared to the number which work on the next Dashboards as a Service,
or Fitbits for Dogs, or next-gen tween sexting mobile platform, or just
toiling away fruitlessly on shelf-ware in large directionless companies
surviving on the carcasses of well-heeled dinosaurs in their "enterprise sales
channels", then quite obviously doing things "right" comes along with almost
no actual value other than just the ability to claim you did it that way.

If building most software came with anything remotely resembling the risk and
liability of building a high-rise apartment building, or a suspension bridge,
or the hydraulic controls of a jetliner, then one would likely see much more
common practice, conventions, and thorough auditing of software that gets
created. Rather than "best practices" being outliers, they'd be the norm, and
they'd be much more codified and immutable than simply the most recent blog
post about scar tissue earned from a metaphorical software skyscraper
collapsing into The Bay one sunny Tuesday afternoon.

As an informal support of the above claim. How many among us have worked on
projects which included, as a central pillar of the engineering process and
culture, _all_ the following forms of testing... unit, integration, property-
based, concolic, end-to-end, chaos, regression, soak, and mutation, and have
indefinitely pushed back releases until _all_ those forms of testing could be
exercised and validated? Whatever the number I'd wager a year's salary that
there are more people who don't even know what most of those things are than
the number which have been required to diligently do all of them. Probably by
an order of magnitude. If we're talking about mythological 10x unicorns,
perhaps we can start with that one?

------
draw_down
Instead of a "no shaming" culture, I'd like to find a culture of "don't fuck
up". "No shaming" and "no assholes" just leads to people cheerily and politely
fucking up.

~~~
jschwartzi
I would rather know about something early so that I can fix it. If your entire
business culture is one of berating people for making mistakes and introducing
bugs, I can guarantee you that there are some really good latent ones that
will bite you in the ass some day. God help you if peoples' lives actually
depend on the code you write.

~~~
AceyMan
I'm won't be the first HN'er to note that the business of aviation has evolved
a culture much like the ideal being discussed.

You can see it when you read NTSB AARs, TSBs, even the regs (FARs) themselves.
Even the language is chosen so as to avoid shame.

When blame is ascribed it's explicit and for the purpose of explication of
root causes, but, more generally, the tone of the narrative is always, "we've
critiqued _the process_ and here's how we see to improve it."

People are only seen as participants in the process and aren't targeted for
blame or shame.

The amazing safety statistics of commercial flight speak to the efficacy of
this philosophy; software project management would do well to adopt much of
these strategies, I'd argue.

