

How to be the 10X programmer   - johnfn
http://blog-johnfn.herokuapp.com/entry/4

======
danielrhodes
Couldn't disagree with this article more. What the author is saying is that to
be a 10x programmer, you should be building scaffolding all day (instead of
actually tackling the problem at hand and getting things done). The part about
no margin for error is also ridiculous and is the type of thinking that
results in aversion to risk rather than a process for dealing with errors.

The reality is that there are different types of coders who are better suited
for different types of tasks. When you mismatch a coder to a task they aren't
well suited for, results are not great. Some are super fast but there is
little regard for how it was created (great for trying out new ideas that need
validation), others are more methodical and better for tricky things that need
to be done right.

~~~
johnfn
Your point about scaffolding kind of distorts the point I was trying to make -
it's a false dichotomy to say that you either build scaffolding or get things
done, and I didn't intend to favor scaffolding over the other.

I think your point about error is more valid. When I wrote about errors, I was
thinking about more serious errors, but I don't think I wrote that, and I
think it changes my argument some.

------
polyfractal
Eh, I'm going to quibble with your assertion that other professions have more
error tolerance than programming.

A bricklayer that makes a chimney collapse could very easily make the bathroom
collapse too. Arguably, the bricklayer has even _less_ margin of error because
if he messes up, people could be physically injured or killed.

I'm a neurobiologist. While doing dissections I separate the hippocampus from
the cortex. If I don't perform that dissection well, my cultures will be
contaminated with excessive cortical neurons and that will bubble through all
my results. Typically not noticed until weeks later when the neurons are
mature. If the errors were subtle enough these might get propagated into a
journal article and published as Scientific Knowledge.

When I worked fast food waaaay back in high school, if I dropped a burger on
the floor, I would back up the entire kitchen because our orders were no
longer flowing correctly.

------
ajankovic
That final remark about Rasmus is unnecessary and not in the spirit of the
article. I agree PHP was not designed for developing highly complex
applications, but you have to consider how much flow PHP actually created when
developing small websites and web scripts.

~~~
johnfn
You're right, it was a dumb joke and it was in bad taste. I have removed it.

~~~
YourAnMoran
Submitting an essay for others to judge, and then altering it after receiving
criticism is not quite doing it right. Mistakes are okay, covering them up is
not however. In my opinion a better way to deal with the issue is to cover the
bad joke with strikethrough formatting, followed by rationale for doing so.

~~~
systemtrigger
I disagree. Someone found a bug in his essay and he removed it. No point
repeating it to future visitors. In general, the final copy of a document does
not include strikeouts.

~~~
veidr
Yeah, but it's pretty much accepted that once an article is publicly posted
(much less submitted to a popular reposting site) it _is_ final.

I find that most good blogs tend to mark such after-the-fact revisions in a
manner similar to that suggested above. Otherwise, there is no coherent
article for the readership to discuss. There's the version you read, which is
different from the version I read, which is different from the version Alice
will read tomorrow...

~~~
johnfn
Yeah, but in this case, the removed part was small, not related to the rest of
the article, and the most common reaction to it would be "you should remove
this".

I was actually not aware that there was an accepted finality to online writing
though, so that is something I should keep in mind.

------
MaysonL
I think of myself, and enough other people have considered me, as having been
(at least some of the time) a 10x programmer.

And yet: one afternoon ( _many_ years ago) I came in to work, and my boss
called me into his office. He was holding a copy of Time magazine, and looked
angry.

"Page 23."

Woops! The border around the picture at the bottom was glitched. Turned out to
only occur for pictures with vertical line count of the form 4n + 3: even line
count or 4n + 1 were fine. Luckily, the bug had been noticed before millions
of copies had been printed.

"The only reason you still have a job, is that the compression routine you
added let Time push back their photo deadline by a full day." [I believe that
at the time, the communication between their headquarters and their regional
printing plants was over 4800 bps leased lines. Note that the compression
routines achieve ~50% lossless compression, looking at only one scan line at a
time (core was tight in those days: some of it even _was_ literally core).]

------
bjoernbu
I really dislike the footnote [3]. I think he shouldn't argue that the
remaining margin of error doesn't matter, but instead should argue that it
happens less often.

This is why safety critical systems are sometimes verified using model
checking and so on. In some cases (airplanes, etc) even the best programmers
cannot garuantee a necessary level of quality.

In your every day app where a user could crash teh program by using an obscure
value, this still IS a significant problem. Especially if the error happens
rarely it mike take a lot of time to be noticed for the first time and might
have critical impact (loss of money?) by that time.

The important point is that the great developer will introduces less of those
subtle errors.

------
hoschi
There is a link error: "flow" should link to
<http://en.wikipedia.org/wiki/Flow_(psychology)>. You forgott the trailing ).
Beside that, the title of your articles is just "Hi".

------
hoschi
How do you think code checking tools (FindBugs), buildsystems (Maven), version
control systems (Git), ... has an impact to your productivity/flow? I think,
this tools helps me a lot, because I just must write code, commit, write code,
commit, ... and all other stuff runs automagically in background.

------
jpadilla_
I like more the idea of "The idea is that a 10X programmer does 10 times the
work of a mediocre programmer." in 10x less time.

------
georgieporgie
Good piece, but I felt like it was a bit disjointed. Specifically, it jumped
from "10X" (productivity) to "-10X" (hindering others) without much segue.

I'd love to see more discussions of flow on HN. I'm particularly interested in
the statement that Python leads to more flow for the author.

~~~
johnfn
This is a good point. I actually trimmed this out of a larger piece, which is
probably why it feels that way. I've edited the first few paragraphs to make
it a little less jumpy - thanks for the comment.

Aside (not directed at you): I watched the article drop from #6 all the way
down to #20 in the space of a minute. Does anyone know why that might happen?

~~~
polyfractal
I doubt it was your article being bumped down; it was probably the rest of the
articles being bumped up. Weekday mornings are very active.

