
Why I Strive to be a 0.1x Engineer - ingve
http://benjiweber.co.uk/blog/2016/01/25/why-i-strive-to-be-a-0-1x-engineer/
======
cpdean
Throughout my career I've definitely been lumping the skills described in this
article about not doing work in with the whole "10x developer" catch phrase.

Like:

Customer needs a CMS.

Clyde looks at the requirements for the CMS. He sets off to write hundreds of
thousands of lines of code by himself, complete with CI, continuous
deployment, tests and documentation because he is a very good developer.
Through the course of the project he leverages his years of experience and
background in CS and engineering to make a well-factored body of software that
will be maintainable for years. He did this in only a couple months.

Bob looks at the requirements for the CMS. He thinks "I know, I will use a
good application framework and an ORM". Bob writes a couple thousand lines of
code with all the tests and stuff that Clyde had. Bob's tests and app code,
however, are more focused on the customer's needs, making in maintainable for
anyone who can read the documentation of the software he's chosen to use. It
takes him a couple weeks.

Alice looks at the requirements for the CMS. She realizes the customer will do
just fine with Wordpress with a couple of tweaks. She sets up a hosted blog so
nobody has to actually maintain it. She has better shit to do with her time.

Alice did the least work but that doesn't make her less productive. You're
solving problems. If you do work to solve those problems, fine, but having
more "output" doesn't make you go from a 1x to a 30x engineer.

~~~
nickpp
Sounds great in theory. But what about the business perspective? Alice fixed
your problem but Clyde gave your company a new product which can bring revenue
and become even more profitable that your existing products.

Remember Slack? They needed to chat. Alice said "let's use mIRC". Clyde
implemented an IRC clone. Now Slack is a billion-dollar business...

~~~
nmat
If you want to post animated gifs and embed youtube videos you can't use IRC.
Everything depends on the requirements. To find the right solution you have to
understand what your client needs, not what he thinks he needs.

~~~
placeybordeaux
Yes you can, plenty of IRC clients let you post animated gifs, some would let
you embed youtube videos I am sure.

~~~
st3v3r
Nope. And you have no guarantee that the server supports sending that, or that
anyone else is using the same IRC client.

------
aidanlister
One of the first mentions* I saw on HN about the elusive 10xer was an article
about the exact types of gains the author of this article is talking about --
a 10xer knows where to apply their effort and as such is an order of magnitude
faster in achieving the business outcome, not producing LOC.

I feel like the author has wrapped up some sensible expectations for any
senior developer and then soiled the content with a clickbait title.

* something to do with using a sticker printed on a transparency instead of some computer vision project.

~~~
LoSboccacc
sadly it's precisely what business are not gonna doing. measuring developers
by LOC instead of business outcome allows to detach their worth from their
productivity, albeit the metric is flawed in many ways it's better to say 'you
produced X LOC, here's a 100$ raise' than 'your solution saved us 100M$,
here's a 100$ raise'

~~~
Tiquor
I've worked in multiple fortune 500 companies and startups at the entry and
now management level and been involved in Web Development for 20 years. I've
never seen a LOC report except when we run some games with the other devs to
see # of changes in GIT or other source control.

~~~
ones_and_zeros
Can you tell me which companies you've worked for that determined developer
value by the effect on the bottom line? Because I'd like to send them my
resume.

~~~
OpenDrapery
Yes. Just because we all recognize that LOC is a shitty metric, doesn't mean
that the industry has figured out what a good metric is. Measuring developer
productivity and impact remains an unsolved problem. It still amounts to gut
feel, and mostly whether or not your manager likes you or not, i.e. how much
of a thorn you are to him/her.

------
karlb
Two more quotes about this subject:

Jeff Atwood: “the best code is no code at all. Every new line of code you
willingly bring into the world is code that has to be debugged, code that has
to be read and understood, code that has to be supported. Every time you write
new code, you should do so reluctantly, under duress, because you completely
exhausted all your other options.”

Robert Galanakis: “The fastest code is the code which does not run. The code
easiest to maintain is the code that was never written.”

~~~
coldtea
> _Robert Galanakis: “The fastest code is the code which does not run. The
> code easiest to maintain is the code that was never written.”_

Obviously that has limits, else the best MVP would be empty space.

~~~
Tiquor
It didn't say the best product. It said "fastest" and "easiest to maintain"
code, which are only two of hundreds of factors for success. Many of which are
not code related.

------
johnloeber
The fundamental point ("less is more") is a good point that is needlessly
obscured by a layer of buzzword-talk ("10x engineer", etc.). Using the
buzzword-talk makes for a nice clickbaity headline, but as a consequence, the
author spends at least 30% of the article addressing and explaining things
related to the buzzword of choice. Such discussion is of little substance.
Ultimately, the article can be distilled to a few central tenets (e.g. "don't
build anything unnecessary -- think about the human costs of maintenance"). I
consider this somewhat ironic: the article, which is chiefly about avoiding
cruft in production, contains a fair amount of cruft.

------
Ensorceled
This whole article misses the point of what productive means and why 10x
developers are paid hundreds of thousands of dollars at Google et al.

Basically, the author has defined 0.1x to be EXACTLY what people mean when
they say a 10x Engineer.

All of this "non-productive" stuff they are mentioning is the actual
productivity that the 10x Engineer delivers. Somebody who writes hundreds of
thousands of lines of unnecessary code is, by definition, not a 10x Engineer.

------
EliRivers
In the interests of context and actual references regarding the 10x thing, I
have canned response that I churn out:

The 10x programmers thing; from a 2nd edition of Peopleware, the 10x
programmer is not a myth, but it’s comparing your best to your worst – NOT
best to median (it’s also not about programming specifically; it’s simply a
common distribution in many metrics of performance).

The rule of thumb Peopleware states is that you can rely on the best
outperforming the worst by a factor of 10, and you can rely on your best
outperforming your median by a factor of 2.5 (this of course indicates that if
you are that median developer, middle of the pack, you’re already a 4x
developer under this numbering scheme).

Obviously, this is a statistical rule, and if you’ve got a tiny sample size or
some kind of singular outlier or other such; well, we’re all adults and we
understand how statistics and distributions work.

Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence
(1981) as its sources.

[ “Peopleware”, DeMarco and Lister, 1987, p45 ]

~~~
droithomme
> it’s comparing your best to your worst

To be clear, DeMarco found clustering, so it's not _your_ best to _your_
worst, where _you_ refers to a given organization. The gap appears only when
looking interorganizationally. In the measured comparable tests they did one
company had a lot of highly effective programmers, another company had a lot
of ineffective programmers, and it wasn't common to find mixtures of both
kinds at any given company. So at a given company it will appear that everyone
is similarly productive, and the people there may tend to believe 10:1 is a
myth. The 10:1 is only apparent when comparing people interorganizationally.

Also, of course the productivity was not in terms of LOC per hour, but was in
terms of several elements regarding solving a given problem correctly. In
general the highest productivity people solved that given problem in 10x less
time using 10x fewer LOC and 10x fewer bugs than the lowest productivity
people who used more LOC to accomplish the same thing, introducing more bugs
in the process, and taking more time to do so.

------
celticninja
when I started as a trainee dev I was paired with a more experienced dev on my
first project and one of the things he was fond of saying was our first role
was to challenge the need to build anything at all. This had a significant
impact on the project by identifying quite a lot of features that the
requirements document had classed as necessary but the users and managers who
would use the system confirmed tat they were nice to haves and would not be
needed for at least 18-24 months as the functionality that was needed for them
to be useful was not built. 2 years later and the functionality has still not
been built and it has no time frame for making it into production. Cutting out
those jobs early on saved a lot of hassle, time and money and I have carried
that thought process with me as we go.

Do we really need to do it?

~~~
amelius
Why not just sort the list of requirements according to urgency?

At least, that way, you'll be prepared for the less urgent features when you
get to them.

~~~
yitchelle
> Why not just sort the list of requirements according to urgency?

This is a noble idea except that there is more than a dozen ways which
"urgency" can be measured. Do you measure by its deadline, where the
requirement is sourced, its dependencies etc.

~~~
amelius
That might be true, but I fail to see why the originally proposed method is to
be preferred.

------
efaref
What a fool. Only doing what is necessary rather than spending hours and hours
reinventing pointless wheels or introducing pointless abstractions is one of
the key techniques that 10x programmers use.

There are counterpoints to many of his arguments, too. For example, using
existing software is good, unless that software is a bad fit. You can end up
with a Rube-Goldberg-esque monstrosity, held together by duct-tape that is
impossible to use ("enter your back-end SQL query here in this tiny little
text box") or impossible to maintain.

~~~
buserror
I completely agree. For each 'oh look I found a plugin/library that does that'
you can end up with

\+ something what you need-ish, PLUS crap you don't \+ a layer of glue code to
your codebase that will be as hard or harder to maintain. \+ your famously
fantastic imported code will have it's bugs, that will be hard to find (as
it's not owned) \+ nobody will 'know/own' it, so any tweaks will be duct
taped. \+ it will diverge upstream, will at some point your version become
fallow, and you end up with 'code sclerosis': you can no longer extract the
old and get a new, fresh version.

So yes, all that time and headache you will spend for your 'quick win' could
have been spent solving the problem for YOUR use case by paying the price
upfront and writing the code.

I've seen that so many times it's not even funny. There is also the manager's
version of that, with the world famous "I found that library online, does JUST
what we need and only costs $5k, and we even get SUPPORT!11!!"

~~~
joshmanders
This, so much this.

I would never want to work for a company who's business model is shoehorning
random libs together into a frankenstein just to quickly get that client out
the door and a new client in.

~~~
marknutter
Wouldn't that be a little like a construction worker fashioning his own
hammer, cutting his own boards, fabricating his own cinder blocks, etc?

~~~
joshmanders
Sure if you were rolling everything yourself. But you can still use pre-built
solutions.

As a developer I use frameworks to aid in my building, like a construction
worker uses premade hammers. But if a building needs a specific type of board,
cutting our own wood is a viable option, or molding our own blocks.

The foundation is solid, but we build on top of it so our house is unique and
to specifications, not just a cookie cutter run of the mill house that
everyone else has.

------
gmac
_The times I feel I’ve made most difference to our team’s effectiveness is
when I find ways to not build things._

"We will encourage you to develop the three great virtues of a programmer:
laziness, impatience, and hubris." — Larry Wall, Programming Perl (1st
edition), O'Reilly[1]

[1]
[http://c2.com/cgi/wiki?LazinessImpatienceHubris](http://c2.com/cgi/wiki?LazinessImpatienceHubris)

~~~
zimpenfish
Ironically, almost all Perl code I've dealt with contains large helpings of
the last two in the form of layers of ever more complex NIH code as each new
set of people work on the code.

~~~
jschwartzi
I've hacked in stuff like that when it becomes apparent that the CPAN solution
could not be made useful in a reasonable amount of time. I've only had this
problem with the SOAP implementations, thus far. Except SOAP::Lite.

------
mgkimsal
I may have missed this part in the article, but the "0.1x" moniker, as a
reaction to the "10x" label... seems to miss the point.

The "10x" type folks I know are "10 times as productive" as others _precisely_
because they know how to deal with some of those issues in the 0.1x list -
push off new features, reduce amount of new tech introduced, drop old
features, etc.

Knowing how to focus on the things that provide the _most_ value in the
_least_ effort - but still move the project forward - that's where my
understanding of the 10x label always was based. Maybe I'd had it wrong and
people were always focused on "lines of code"?

Or maybe this was the point the OP was making anyway, but it went over my
head. I know only a handful of places that have ever really looked at pure
"output" (of code, for example) as the primary productivity measure.

~~~
SomeCallMeTim
>Maybe I'd had it wrong and people were always focused on "lines of code"?

No, the original studies talked about 10x _productivity_ , not 10x lines of
code. The more productive developers also produced fewer lines of code for
similarly complex tasks, and it was easier to debug, to understand, and to
modify. They also frequently would produce net-negative-lines-of-code on
productive days.

Article is clickbait with a strawman premise, no question. I think it
particularly attracts the clicks of 1x developers who like to think the 10x
developers aren't anything special. There are certainly many more 1x
developers.

The top-voted comment as I write this frames someone who recommends WordPress
as a solid engineer. Enough said.

~~~
st3v3r
"The top-voted comment as I write this frames someone who recommends WordPress
as a solid engineer. Enough said."

What's this mean? The top-voted comment describes a scenario in which
WordPress does meet the business needs, and yet two others decide to go and
write from-scratch code. Whereas the other one has time to actually solve the
problems the business has.

If you're trying to be a WordPress snob, then you're missing the point
entirely.

~~~
SomeCallMeTim
WordPress-as-a-service can meet business needs. But WordPress is an awful idea
outside of that. Someone is needed full time to keep it and its plug-ins
patched. I would laugh at just about anyone who suggested a self-hosted
WordPress as a reasonable solution to anything.

There are other sites where you can get managed CMS hosting (wix.com,
squarespace.com, even wpengine.com etc.) to build a CMS on.

To suggest that "WordPress" is a good solution at this point should get you
laughed out of the room. wpengine.com is a reasonable solution. "WordPress",
hosted on your own server, is a disaster waiting to happen.

I actually tried building something, not on WordPress, but Drupal, and as a
result can't imagine recommending anything that's PHP-based being a good
technical solution.

Call me a PHP snob then. It's so horrible to work with I can't imagine that
other solutions can't be better.

~~~
st3v3r
So one, you completely missed the part about her suggesting a hosted solution,
and two, you're being a snob about stuff for no other reason than to be a
snob. I don't think anyone can take your assessments about this stuff
seriously.

~~~
SomeCallMeTim
>So one, you completely missed the part about her suggesting a hosted solution

Hosted != wpengine.com, hosted can mean a managed site with CPanel installed.

> you're being a snob about stuff for no other reason than to be a snob

No, I avoid using or recommending technology that is insecure-by-design. That
includes PHP and just about everything built on it.

>I don't think anyone can take your assessments about this stuff seriously.

Considering how much I make consulting about "this stuff," I have no worry
about how seriously I'm taken. Sorry if I've offended a technology you like,
but it's really pretty awful.

------
eibrahim
Great clickbait title but I do agree with the point of the article. I know
"excellent" programmers that their first reaction is to crank out as much code
as possible. My reaction is always: let's find a plugin that does this, I am
too lazy to write it from scratch. Most of the time it gets the job done
faster with fewer bugs.

~~~
xaduha
Yep. It always helps to take a step back and ask yourself what you're trying
to achieve here.

------
andmarios
As there is “more than needed” there is “less than needed”, thus adding, not
adding, removing or not removing features should be given equal consideration.

What I strive for, is to be a “textbook” engineer. I'd like my work to be as a
textbook example, something a newcomer could use to learn the technology I am
working on or that a new maintainer would have no trouble understand what I
did.

Of course I'm failing at it. :)

------
iagooar
> Let’s not build that feature. > Is there existing software that could be
> used instead?

Where is the fun of being a software engineer, then?

~~~
rglullis
If you become reasonably good at finding existing solutions to the problem at
hand, and you save 90% of yours and company's time, then it frees you (and the
business, and consequently society at large) to pursue any other new problems
that haven't yet been solved. Software is a means, not an end in itself.

To me, solving known problems and doing the same thing over and over, just
changing the tools, is akin to digging holes and covering them again. And what
is the fun in that?

~~~
jakobegger
I see that line of thinking a lot in the iOS dev community. Lot of people
publish components, and lots of people just stick together published
components.

Of course, each of those components is a dependency. It's not unusual to see
an app use a dozen third party frameworks.

Every time that an OS upgrade comes along, you need to hope that non of the
dozen frameworks you are using breaks, and if one does break, hope that it is
still maintained. If not, you will have to get familiar with an unknown
codebase at the most inopportune moment...

Also, usually existing components do only 75% of what you need, and lots of
stuff you don't.

If you write everything yourself, you will never depend on other people to
maintain code that you use, and you wont include lots of bloat that you don't
need.

~~~
st3v3r
At the same time, I've seen rationality like yours result in people building
their own versions of things that are available in the standard toolkit.

~~~
jakobegger
Why not? Sometimes the stuff in the standard toolkit is crap.

I mainly work on the Mac, and the classes provided with AppKit vary greatly in
quality. Most parts work really well, but others are really buggy. For
example, after years of struggling with IKImageBrowser, I just wrote my own
grid view. It would have saved me a lot of trouble if I'd have done that in
the first place.

~~~
st3v3r
For a limited few things, maybe. But the vast majority of things don't need
that. I'm dealing right now with someone who wrote their own autocomplete text
view, which doesn't work properly now that I've fixed their mess with auto
layout.

~~~
jakobegger
I'll have to do that soon as well... I get lots of requests for auto-complete
in my app, but it looks like Apple's built-in autocomplete is unfortunately
not flexible enough for my needs (eg. it has it's own ideas what a word is
that aren't compatible with SQL)

------
ones_and_zeros
A lot of this blog post assumes that developers have a voice at the table. In
my experience at smaller software companies/startups the model can best be
described as WDD, Whim Driven Development. If someone has a whim, the
developer provides the way.

~~~
ryandrake
This happens a lot in companies where the CEO drives product decisions.
There's nobody to push back on ideas, so you end up with developers
implementing every half-baked idea that comes out of one person's mouth.

In grownup companies, where you have a product manager and that person has a
boss and that person has a boss, the product manager has to justify his
decisions to people and has to get feedback, and perhaps has to convince
people before he/she's let loose on the engineers, so you get a lot less time
wastage on people's whims.

In really big-boy companies, engineering and QA has a stake and can push back
on harebrained ideas too! The best places have it where there's a product
manager, a project manager, an engineering lead, and a QA lead, and they all
are empowered to get into a room and have to agree on whether what we're doing
provides business value, whether it's feasible, and if can be done by the
deadline.

Of course, in any case if you've got senior leadership who engage in seagull
management, all bets are off.

------
norswap
10x more productive is 10x more selective [1]. So yes, 0.1 in a sense.

[1]: [http://yosefk.com/blog/10x-more-
selective.html](http://yosefk.com/blog/10x-more-selective.html)

------
hguant
I think a core problem that the author identifies is that it's very easy to
find markers of programming ability, and those are the things we've optimized
for, while its much more difficult and time consuming to determine if some one
has good judgement. You can be an amazing engineer, but being an ok engineer
with good judgment ("do we REALLY need to do this?") generates more value.

------
innertracks
Recent related experience:

About a month ago a friend asked for help with his arduino project. He was
having difficulty figuring out obstacle navigation. Getting the compass to
work combined with the math strategy had him puzzled.

My suggestion, based on my experience as pilot, removed the compass and the
math calculations. We both had a great time working with the implications of
this new approach.

Offering a fresh perspective from a different domain was very valuable.
Reducing the complexity of the solution to his problem made sense to me, felt
good, and delivered an easier to maintain "product".

My friend is about 70 yo and has been developing software professionally since
his early 20's. His resume is filled with pretty cool projects with notable
peers in tech over those 5-ish decades. There was something very affirming
about being able to help such an accomplished engineer in this manner. I
learned a lot in that hour.

------
jmilloy
This is absolutely ridiculous. Obviously a 10x engineer is not the one who
churns out lines of code, but instead the one who produces results without a
lot of code.

> I have observed that some people are able to get 10 times more done than me.

There are many poor definitions of "getting things done". Why waste time using
them?

------
mattiemass
I think there is a ton of subtly and trade-offs around choosing to do vs not
do something. Of course not doing something is better in the abstract, but
that isn't always an option. I'd be much more interested to read something on
how to best make these kinds of trade-offs.

------
Justsignedup
Things to note about 10x developers:

I have only been able to group developers into the following categories:

\- not competent

\- competent

\- competent + problem focused

I would never hire non-compitent developers. They suck. They make terrible
decisions and code. They are many.

I would be careful hiring competent developers. In fact a competent developer
is usually a junior developer who needs proper mentoring. I would push hard
for getting that developer above competent.

The last type of developer is the golden goose. They can code, but they are
focused on solving problems NOT writing code. They focus on what problems need
solving, can they be solved later, what is the price of solving such problems.
All that while being competent at making code.

So thinking of someone as 10x or 0.1x is an error IMO.

------
dumbfounder
He has a point when you are talking about a large company. It is hard to
extract the full potential of most 10x engineers in this setting. Difficult,
but not impossible. Put those people in R&D or in some leaner group creating
the next thing, not the current one. If what they make doesn't have a net
positive impact then throw it away.

In a small startup the 10x'ers are critical. When you don't have a product
sitting around and deciding what to build is probably worse than giving up.
MVP it over and over until you have something. 0.1x'ers please don't apply.

------
ksk
This is a great idea. The problem is convincing management to keep you
employed. :)

Whenever I see another 100mb update for trivial software, I'm reminded of
Raymond Chen's blog on this topic -
[https://blogs.msdn.microsoft.com/oldnewthing/20061101-03/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20061101-03/?p=29153)

------
purpled_haze
Have been on board with this idea for some time, but, that said, here's some
criticism of the specifics:

> Is there existing software that could be used instead?

Agree, up to a point. Very few OTS/SAAS solutions are practical financially
and customized, and if they are (as in a company that adds those crazy
features you want to their SAAS app)- watch out! Those companies products will
end up hitting a wall eventually because they will have coded themselves into
a corner. Note: this actually because the company you are using didn't use the
0.1x engineer philosophy.

> Let’s not build/deploy that development tool.

Maybe. But it depends. How often is human error affecting your process in a
very time-consuming way? You wouldn't say CI is a bad thing would you? What
about using an IDE when you've got developers or a development language that
best lends itself to an IDE? You would buy that IDE right (unless you're
really, really cash-strapped- compare it to the cost of a few days of your
developer's time)?

> Let’s not adopt this new technology.

Maybe. How about instead- let's adopt what are solid winners technology-wise
that will help us attract new talent _and_ develop features more quickly. And
when we do that, we first do in small pieces that are independent to prove it
out, then eventually we commit to using it as much as it makes sense so that
we don't end up with 3 tech stacks to maintain in ten years.

> Can we achieve the same thing with a technology that the team is already
> using and familiar with? “The best tool for the job” is a very dangerous
> phrase.

Sure, mostly. But don't get a shitty open-source IDE instead of paying $600
for a good one, or force developers that use UI tools to use vim because
you're too darn cheap either, even if it would do the job. On the other hand,
I agree- don't just buy things. Really let your dev teams hash it out and
choose appropriate tools- don't dictate anything without getting feedback and
adequate buy-in when it comes to tools.

> Let’s not automate this.

Again- what about CI and scripts that can help make developers work
consistently, more productively, more efficiently overall, and with fewer
errors?

Sure- if you are a one-man team, you might not need continuous deployment yet,
but please don't sit there and have devs pulling oars in your wooden sea
vessel as the hovercrafts speed past you in the race.

------
rocky1138
I think the correct definition of a 10x developer includes what you're
describing as a 0.1x engineer. It's not that they are simply more prolific,
but that they are more prolific, impactful, and efficient.

------
bsbechtel
The best company in the world is one where it has 0 cost, requires 0 effort,
and generates billions of dollars in revenue. It doesn't exist, but that's
what everyone should strive for.

~~~
meric
This whole business of the universe spawning humanity to generate billions of
revenue required no effort or cost on its part. All the effort was spent by
the life forms it allowed to happen.

What you said reminded me that time I rejected a $10k contract and told my
wedding photographer client to signup for a $40 per month product instead, and
saved them $9520. I didn't see any of that money, however.

------
bitL
Is this a satire? Can't tell from the text itself...

~~~
kelvin0
I am profoundly surprised that someone would characterize this text as being
even remotely satirical. What gives you this impression? What industry and
perspective do you have on the points made?

~~~
bitL
Are you serious? The whole article seems like a parody - (intentionally?) not
understanding what 10x means vs unnecessary bloat and then proceeding on...

------
rubyfan
The sad truth is the larger the organization the more removed and individual
engineer is from defining the work and prioritizing its business value.

------
anonfunction
I've often joked that 10x programmers were the ones who used multiple cursors.
Seriously though, I would argue that writing a lot of code, even if it's not
all going to be the next cash-cow for your company, is good for the hackers
soul. It also adds intellectual property and infrastructure to your company.

~~~
jon-wood
Adding infrastructure for its own sake is a terrible idea. Someone is going to
have to care for that infrastructure, its going to be another thing to keep on
your mental model of how everything fits together, and in many cases it's
going to be another thing that needs changing when the requirements change
later.

~~~
anonfunction
Obviously just adding more moving pieces for no benefit is a waste of time.
However there are many areas that can be improved or even entirely automated
with software.

My bigger point was that writing code is not "a bad thing that should be
avoided" because I think it helps programmers understand the problem and can
add more value than debt. Even if it may change at some unknown point in the
future.

------
afro88
In other words, your team doesn't have an effective lead dev, and you'd prefer
to fill that gap rather than just build build build. Fair enough.

With a decent lead to direct them to the right tasks I'd much rather a 10x
than an 0.1x

~~~
mruniverse
It's more than fair enough. Why would you want to build build build?

Most of the ideas coming from the business side aren't that good. I think
that's what he's saying.

------
nanch
Click-bait title, maybe a better title is 'how to be more effective'?

All of the tasks mentioned are valuable assets to the business. Operational
support, developing new features, understanding dependencies, building tools,
communication - they're all part of the job man.

53 upvotes and these goober comments reminds me that HN is mostly <21 years
old; time to move on.

~~~
kelvin0
Move on to what? Care to explain. You mention 53 upvotes, is that good or bad?
I detect cynicism but I am genuinely interested in your point.

~~~
nanch
I'll move on to an HN with an older demo, or no HN at all. OP posted a click-
bait trash article and people are upvoting; it just makes me wonder if this
site has any legitimately talented programmers at all or if they're busy
actually doing things in the real world; my guess is the ladder and that real
devs would only post a show hn.

Young programmers I guess. Don't mean to hate, but I used to enjoy HN.

~~~
jlg23
Got anything about the article's content you want to complain about or is it
just the choice of words?

Just because you got it all down does not mean that the very same topics won't
be discussed again and again by the next generation. And you know why? Because
YOU (and me) apparently failed to provide the next generation with a
"programming bible" that answers all questions once and for all.

Let's try not to be the "young, hip executives" Zappa complained about:
[https://www.youtube.com/watch?v=GowCEiZkU70](https://www.youtube.com/watch?v=GowCEiZkU70)

Last but not least: with age comes wisdom or so they say. Sometimes it is
wiser just not to comment at all.

