3 ms·
This sounds like people who quote "slow in, fast out" in racing. Just like here it's not true. It's a "rule of thumb" for beginners. It has use in that conte
by erik_landerholm 7y ago
This sounds like people who quote "slow in, fast out" in racing. Just like here it's not true. It's a "rule of thumb" for beginners. It has use in that context. The way to win a race is fast in, fast out, same with software.
edit: I'm 42, if the matters.
- hammock 7y agoSure but is everything a race?
- ska 7y agoI think there is a different connotation to "slow is smooth, smooth is fast", but agree it isn't really a great analogy for production, because it is about learning. 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.
- ehnto 7y agoThe point is not to be fast but to be correct. In racing, smooth is fast because you didn't mess up and run off line or crash. 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.
- kthejoker2 7y agoThe problem is momentum has two vectors, speed and direction. Most problems in software engineering are caused by only optimizing for speed.