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