How to be the 10X programmer | Hacker News Reader

How to be the 10X programmer

blog-johnfn.herokuapp.com

53 pointsjohnfn19 comments

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.

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.

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.

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.

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

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.

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.

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...

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.

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).]

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.

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".

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.

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.

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.

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?

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.

In my opinion APIs are also very critical for flow, beside the programming language. If I see easily what I must use/touch to get things to work, I'll be productive. In contrast to big/strange named APIs where I need to read a lot of documentation to get the idea behind.

I think the author is misleading when he says that Python leads to more flow. Flow requires that some conditions hold, one of which is that it is just challenging enough to push conscious thoughts out. I experience flow much more in C++ than in Python, I actually enjoy the complexity. Most people don't get flow from testing because it isn't challenging enough. So what he is doing is lowering the challenge by documenting and removing what he views as "obstacles." He is on the right track, being aware of being in flow, what works for him. I imagine there will be a time when the things he mentions will actually knock him out of flow, and instead he will skip over them without thinking about them.

Reply on news.ycombinator.com