
Doing More with Less Code - itamarst
https://codewithoutrules.com/2016/08/25/the-01x-programmer/
======
drKarl
This post is flawed, starts with the wrong proposition that "10x programmer"
means a programmer that writes 10x as much code, that is, it uses number of
lines of code as a metric which is a completely wrong metric (If programmers
were paid for lines of code, copy-pasting would be best practice, and all kind
of verbosity and unnecessary code or boilerplate, even dead code would be
everywhere.

With code, less is more, less code to do the same means easier to read, easier
to maintain, less bugs. So, a 10x programmer means a programmer who is 10x as
productive, that is, delivers 10x as much features, fixes 10x as many bugs or
not even that, since sometimes you have to do refactoring which improves the
codebase a lot in several ways but doesn't provide as a result either features
or bugs.

Actually I would expect the mythical 10x programmer to produce LESS code for
the same functionality, and most probably be reducing the amount of code
littered by other lesser programmers and starting refactorings that would
create abstractions, split classes and make the code more modular, that would
have as a result deleting classes and methods, and overall reducing the number
of lines of code rather than increasing it...

~~~
randallsquared
> If programmers were paid for lines of code, copy-pasting would be best
> practice, and all kind of verbosity and unnecessary code or boilerplate,
> even dead code would be everywhere.

Huh. Is _that_ what it "would be" like.

~~~
wry_discontent
I have technical leads tell me to copy paste code all the time instead of
making better abstractions. It drives me slightly mad.

~~~
Pfhreak
I've generally followed the rule of thumb:

If you're doing the same thing in two places, ok, if you are doing the same
thing in three places, refactor.

Let's me get away with copy pasting while I'm quickly prototyping something
out, but reminds me that I need to clean it up before I try to iterate again.
Plus, it's unlikely that I'll hit the right abstraction on the first or second
time I see a problem. Better to wait until I've seen it three times before
refactor.

~~~
cema
I am of a different persuasion. Even if you are doing one thing, but it is
indeed a _thing_ , refactor it as a separate abstraction. You will end up with
a better set of building blocks.

~~~
ricksplat
all the better for maintaining a clean suite of unit-tests too!

~~~
cema
True.

------
jasode
_> You've heard of the mythical 10x programmers, programmers who can produce
ten times as much as us normal humans._

I'll repeat what I've said before on the "10X" label which causes so many
arguments...

To make peace with the "10x" label, I suggest people just think of it as a
_figure-of-speech_ instead of a rigorous mathematical term. We don't get hung
up when people say _" Star Wars IV was ten times better than Phantom Menace"_
or _" I'm not even 1/2 the football player I used to be."_

Even if people were to use a new term such as _" 3-Sigma Programmer"_[1]
instead of _" 10X Programmer"_, the ensuing debates _would still be the same._

E.g. _" Some people say 3-σ programmers write string parsing loops that are
better in speed and quality than 99.7% of the other loops but that 3-standard-
deviations-above-the-mean is a myth... etc"_

Argument pattern is the same: take a label, any label, hyperfocus on some
_literal_ meaning to the exclusion of all else and debate why that
mathematical interpretation fails in the real world.

You can interpret the label(s) literally as math or as an _English meme_. I
propose that one of those interpretations will keep your blood pressure from
rising.

As a counterpoint to the article, if a programmer knows how to convert a Ruby
program with 100 lines and rewrites it in C/C++ in 600 lines so it executes
15x faster and uses less memory so the company can better utilize densely
packed virtual machines in a cloud deployment, that's what many would call a
"10x programmer" even though none of the inputs & outputs are mathematically
"10" anywhere. The programmer wrote _more_ lines of code so that another
metric of effectiveness was optimized. The LOC increased but that's
irrelevant.

[1][https://en.wikipedia.org/wiki/Standard_deviation](https://en.wikipedia.org/wiki/Standard_deviation)

~~~
dr_zoidberg
Just to extend your example, that programmer would be a 10x programmer if the
achieved goal (runs 15x faster and uses less memory) is valuable to the
company.

Adding value depends on the context. If the main problem for the company is
that the feature set is not attractive to clients, then speeding things up 15x
and using less memory may not make a difference. If however, the feature set
is amazing, but customers complain about the product being slow and eating up
too much memory, then said programmer is adding a lot of value, thus
"becoming" a 10x programmer.

------
beaker52
For years I've held the belief that my job (software developer/whatever) is to
do as little as possible but it's mostly been met with bewilderment and
disdain from most people I've offered it to.

~~~
bsmith
This applies to an even greater extent in a highly resource-constrained
environment (such as my startup). My job is as much about what I choose NOT to
do as it is about what I actually decide to take on; as .5 of only 1.5
software engineers at my workplace, the lion's share of my role relies on me
placing the correct bets on what features (or automation workflows) to
implement.

------
fumplethumb
A lot of comments here are focusing on the 10x label meaning. I agree that the
author wrongly suggested this applies to LOC, but these are great points for
any developer:

\- Use the sharpest tool in the shed (programming language, framework, etc)

\- Leverage existing code

\- Reflect on the problem up front before writing any code

\- Relentlessly question if you really need the feature you're adding

~~~
rpazyaquian
These things are the most important things I've learned over my career, and
it's astonishing how few people actually do this at _all_ , let alone well.
Things like that are the reason I'm moving more towards design, architecture,
and project management, because people are generally fucking awful at it.

------
razorsese
About the LOC measurement

[http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...](http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt)

~~~
_asummers
My previous job's commit diff was -15k, while still writing a lot of the
features. I smiled when I saw that.

------
hitecherik
The article mentions using libraries to save time.

It's worth remembering that when using a library one should know how it works;
not knowing how it works may cause bugs and make development last even longer.

~~~
nulagrithom
It's not like you need to pick through the entire source though. You just need
to read the docs. Reading the docs will likely be faster than writing your
own.

I've seen people write their own XML parsing libraries, try to handle dates +
timezones on their own, and write REST API helpers for products that already
had official packages. In each of these cases, even a brief look at some docs
and a wild-ass-guess would've been more productive. It's super frustrating to
watch.

------
alfonsodev
In my last project I used, ng-admin + postgrest for the administration panel,
postgrest behind a small gateway with oauth2 (nodejs rocky + oauth2) to feed
the user facing app. Uploads are done directly to S3 that automatically
triggers lambda functions to update the database. In the old times I would
have done all these with Symfony and it would have been lots more of code.

I also learnt to appreciate more unix command line tools, I think twice if
need to write an script, for instance to do webscrapping, sometimes you can
get what you need just using curl | pcegrep | uniq | sed, and move on, if you
then have the need for more scrapping then yes, it makes sense to invest the
time on using a library, scripts etc.

------
vinceguidry
Unless you're in a leadership role, only half of those ideas are going to be
available to you.

Also, if you are constantly switching directions without also constantly
coming to a deeper understanding of your problem space / market, then all
you're doing is destroying momentum rather than creating it. Deeper
understandings require orders of magnitude more time, data, and effort to
understand the data.

Eventually you'll get that insight but in the meantime it's better to just
keep moving forward.

~~~
marcus_holmes
the sounds of a hundred thousand project managers rolling their eyeballs at
the prospect of every junior programmer thinking the project doesn't need to
be done, or the feature request is pointless.

------
Waterluvian
Every time I refactor something in the code my goal is a PR with net negative
lines.

But it takes experience and maturity to not to silly things trying to hit this
goal. Sometimes it's just not possible.

0.1x as a term exists only because it's cute.

Instead, perpetually try to be a 0.9x programmer.

~~~
vonmoltke
> Every time I refactor something in the code my goal is a PR with net
> negative lines.

Assuming your customer doesn't use cost per LOC as a metric...

~~~
Waterluvian
That would be awful. I'm glad I have yet to experience that yet. Not sure I
could tolerate non beautiful code for the sake of a business metric.

------
rxm
Hardy's rule can be adapted to programming: to code it better, think it
gooder. One big difference in productivity comes from making good design
decisions early on and not taking shortcuts that weeks later turn into
spaghetti hacks.

~~~
collyw
To me this is the most important thing i have learned in 15 years of coding.
Its also the reason why I hate interview "tests", I don't come up with a good
design straight away. I prefer to get in idea of what is needed, then think
about it for a few days while working on other stuff.

~~~
dangravell
If someone uses interview tests in that way they're doing it wrong.

That's not what interview tests are for; they're for demonstrating a base
level of competence and how you think about code during a discussion of the
code. Also for acting as a catalyst for more discussion about programming.

------
davelnewton
"10x Dev" doesn't mean "10x Code" it means "10x Productivity" (which hopefully
translates to something meaningful for the business). That almost _demands_ a
language that allows concision.

