Hacker News Reader

Comment by edw519 | Hacker News Reader

OP's title is a little too abridged for me. "Code fast" could mean too many different things. Many programmers whose code I maintain look like they adhered to the school of "Don't think, code fast."

I would prefer: "Code something small fast."

What's "something small"? It could be a just the core of what you propose with no features or embellishments. It could be a subset of the problem at hand. It could be one case of a general problem. It could even be a guess.

The point is that if it's small enough, you can code it fast and test it right away. If it's just right, you can build upon it. If not, you can quickly amend it and retest.

Many huge applications have started out as a tiny core with less than 50 lines of code, probably written by one person in less than an hour. I suspect that's the idea OP was getting at.

View on HN

What I was getting at was that increased speed in coding has nonlinear effects n your time-to-solution and that students should code sooner --- before they have the solution in hand --- rather than waiting until they think they know the right answer.

Coding for classes should be done quickly and exploratively. But because students either can't code fast or won't code before they have the whole solution mapped out, this (measurably better) solution technique is unavailable to them.

> nonlinear effects

Can you explain this? If you are a slow programmer and just did exactly the same as the fast programmer, just slower, how can that be a nonlinear slowdown?

At some point trying something else is slower than figuring it out "dry" on paper and coding a pre-thought solution. Thus the nonlinearity. If trying is faster, you can try before you know exactly what you are trying,and figure it out as you try.

So the slowdown is less than linear then. If you do it the stupid way and still try it out it's linear. So if trying it out on paper is faster...

Something is wrong with your logic, both because I can't follow it and because it contradicts all the "anecdata" I have collected during my career.

The logic is simple. Suppose that a fast programmer can do some task in time t. We have a slow programmer who programs twice as slowly. In the worst case all of time t spent by the fast programmer was spent programming which is what the slow guy is slow at. In that case our slow programmer will take 2t, a linear amount of time. If the slow programmer had an alternative strategy he would only use it if it reduced the time to complete the task. Therefore the time is linear at worst.

Note that even if the slow guy is 1000 times slower it's still linear.

Please explain why the logic isn't right. Could it be that the logic is right but that slow programmers tend to do things on paper first, which is not the best strategy?

Because slow programmers don't program first. They program last, and do "big design up front" on paper. This is because the cost of a bad idea is hours wasted, and despite the logical coherence of various "expected value" arguments, students are loathe to risk having wasted multiple hours doing the wrong thing. Because humans' internal risk functions and utility evaluation functions are not linear and bayesian, people who code slowly also code differently, and those differences further slow them down with the goal of having less wasted time. In an effort to reduce their variance, they unknowingly increase their time-to-solution.

That sounds right. I still do that when I'm working with a new programming language/library that I can't yet use well...

The point is that the slow programmer won't do just exactly the same thing as the fast programmer. Speed can make a qualitative difference; it affects what you are willing to do, not just how long you take to do it.

Reply on news.ycombinator.com