Absolutely. Not saying speed is never an important metric, but virtually all complicated engineering and construction projects are difficult to schedule and exceed their time budgets. If the end result is worth it those birthing pains are quickly forgotten. But a poor output will never be forgotten.

Sure, agreed, which is not to say that time budgets don't exist, and aren't exceeded :).

I think waterfall style development works for one person inside one's own mind, but not beyond that.

A lot of the stuff I see from 20 year olds these days is monstrously over-engineered and Rube-goldberg like. Many keystrokes, sure, but less thought. This also yields bloatware that hogs resources and is hard to install and maintain.

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....

More thought and less typing young padawan.

But there are four big constraints on waterfall:

- it takes considerably longer

- it produces no visible results until right at the end

- all but the smallest changes require restarting the clock and budget

- it requires a small team at the start and a big one at the end (an observation dating back to Brooks)

Also, disclaimer, I didnt actually read the article :o

Trouble is that this approach rarely works beyond a very small team.

Seems to me, that the recent spate of online coding interview techniques are basically looking for people who type fast. I suspect that they're finding people who are actually "10X" coders, and people who have memorized the typing out of the solution.

(EDIT: A problem with such 3rd party companies, is that the incentives are subtly misaligned, as they are for any recruiter. If they can present a good image, and a steady stream of candidates who produce videos where they're going claka-claka-claka on the keyboard at a good clip, like a hollywood hacker (which runs and compiles) then they're golden. It doesn't matter to them, if they're missing out on good, thoughtful candidates. False negatives are the order of the day.)

I think the bigger misalignment is the time horizons for success (placement vs successful performance), but that's something that'll get figured out as the interview companies build up their track records and keep track of how long their placements stay in their new jobs.

edit: I'm 42, if the matters.

What they mean is that you can't be fast (on a track) without being smooth, and that typically beginner-to-intermediate drivers/riders are trying to be fast in ways that make them less smooth, and ultimately (and counter-intuitively) makes them slower. So the advice is to forget about being fast and concentrate on being smooth. The speed will come.

I do think this has value as an analogy for software, but it is in concentrating on your tooling and methodology - smoother operating will deliver real value faster than just trying to type fast.

In software smooth is fast because you didn't have to bug squash and refactor. But even if it isn't faster, the grandparent comments point was that it doesn't matter as much as being correct anyway.

Most problems in software engineering are caused by only optimizing for speed.

"A stitch in time saves nine."

"Haste makes waste."

Speed helps you deliver more.

Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees.

Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quick as the task can appreciate)

> That doesn’t mean be sloppy. But it does mean, push yourself to go faster than you think is healthy. That’s because the task will come to cost less in your mind; it’ll have a lower activation energy. So you’ll do it more. And as you do it more (as long as you’re doing it deliberately), you’ll get better. Eventually you’ll be both fast and good.

Take the time now to do it as well as you know how to do; but you're also correct, and taking too long to do the thing is useless, as well as overbuilding.

It might in the short run.

Take coding hacks for example. It is fast in the short term, but might cost you double in the long term.

Not saying that quick hacks can never have their place, but saying that being fast might cost you time in the long run.

So faster is not always faster, and does not always help you deliver more, depending on the timeframe.

Fully agree, including some of the sibling comments.