Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speed matters: Why working quickly is more important than it seems

jsomers.net

Post reply on HN
Print view View original

21–30 of 144 posts

Re: Speed matters: Why working quickly is more important than it seems

#21

Post by modoc »

thomasahle wrote: post #13
shardinator wrote: post #2

I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection. But one good counter example does come to mind - designing a database schema. I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes…

I can think of lots of more things, where doing them fast initially makes sure you'll never learn them: * Typing on a keyboard * Sharpening a knife * Driving a car. It seems more like a question of doing things a lot and very focused, than focusing on speed initially.

All of my car/motorcycle track instructors were big believers in "Slow is smooth, and smooth is fast".

Basically go slow and work on the correct form/line/being smooth/etc... Once you have that down, you are ready to go fast and you will be better/faster than someone who hasn't gotten the flow down at a manageable speed first.

Re: Speed matters: Why working quickly is more important than it seems

#22

Post by kev6168 »

onion2k wrote: post #10

Yes and no. Do things fast when the cost of doing them wrong is low. If you're learning something, or doing something with low risk, then doing it as fast as possible is a really good idea (for all the reasons set out in the article). But... Do things slowly if the cost of getting it wrong is so high that you'll have no opportunity to try again. For example, don't pack a parachute quickly. The key is recognising that…

The parachute analogy is worth exploring.

Let's say in a life time, the accident rates due to packing a parachute quickly is 1/10000, and the fatal rate of the slow packing group is 1/1000000. Even though the fast group faces bigger danger than the people in the slow group (or people sitting at home), but other than the few who have the bad luck, the rest of them will practice way more than the other group, jump more times, go to more places, have bigger opportunities to become a world champion of parachute packing or whatever parachuting sports.

Sure, a few will be forgotten by the world.

The victors we see in the world are probably the people who are still alive in the fast group, and have produced lots of results because of their speed and being still alive. Someone in that group will pay a huge price, but it's not necessary you or any particular one.

Re: Speed matters: Why working quickly is more important than it seems

#23

Post by bunderbunder »

sheepmullet wrote: post #15
shardinator wrote: post #2

I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection. But one good counter example does come to mind - designing a database schema. I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes…

In general I disagree. I learned far more in 6 months at a "high quality" shop working excruciatingly slow than I did in the 5 years at the previous job where I banged out code as fast as possible. I feel like when you focus on speed you very quickly learn just enough to get the task done quickly. And then your progress stalls.

Perhaps it depends on your goals.

I find that when I'm doing any work that involves modifying existing code, there's a huge difference in how quickly I can work when I'm touching code that was originally written by people with different work styles. Usually I can sail through the more methodically-written stuff. When the time comes to make changes to code written by the people most fond of uttering, "The perfect is the enemy of the good," though, progress slows to a crawl. Adding new features without introducing new defects to that code is like trench warfare.

That said, much like the article says, the fast workers did tend to get assigned more new tasks. I think maybe this was a huge win for them. From a wider perspective, though, it's a bit tragic because it results in this inexorable downward spiral in terms of code quality. Of course that worked out well for them too because more defects meant more opportunities for them to cape up, swoop in, and save the day. I can't remember who it was who said, "Beware of your firefighters, they are probably your chief arsonists," but there's a lot of truth in that statement.

Re: Speed matters: Why working quickly is more important than it seems

#24

Post by bonesinger »

sheepmullet wrote: post #15
shardinator wrote: post #2

I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection. But one good counter example does come to mind - designing a database schema. I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes…

In general I disagree. I learned far more in 6 months at a "high quality" shop working excruciatingly slow than I did in the 5 years at the previous job where I banged out code as fast as possible. I feel like when you focus on speed you very quickly learn just enough to get the task done quickly. And then your progress stalls.

In that boat right now, but instead of 5 years in, 1.5 years in. I've been reading books on design patterns (we barely use them, you should get an idea of how bad it is here) and just in general trying to be better.

Re: Speed matters: Why working quickly is more important than it seems

#25

Post by falcolas »

Perhaps this applies more to shooting than software development, but...

Slow is smooth. Smooth is fast.

If I take 20 minutes more to code a module because I'm thinking about it, but spend 30 minutes less debugging problems with the module, that's fast.

If I take a day to respond to an email, but the person I'm conversing with gets the info they need, avoiding three more days of back and forth, that's fast.

If I take a week longer to iterate through a project idea, but nail the implementation, then I can know that I'm pivoting because the idea was wrong, not the implementation.

Re: Speed matters: Why working quickly is more important than it seems

#26

Post by bunderbunder »

kev6168 wrote: post #22
onion2k wrote: post #10

Yes and no. Do things fast when the cost of doing them wrong is low. If you're learning something, or doing something with low risk, then doing it as fast as possible is a really good idea (for all the reasons set out in the article). But... Do things slowly if the cost of getting it wrong is so high that you'll have no opportunity to try again. For example, don't pack a parachute quickly. The key is recognising that…

The parachute analogy is worth exploring. Let's say in a life time, the accident rates due to packing a parachute quickly is 1/10000, and the fatal rate of the slow packing group is 1/1000000. Even though the fast group faces bigger danger than the people in the slow group (or people sitting at home), but other than the few who have the bad luck, the rest of them will practice way more than the other group, jump more…

You're attacking this analogy with made-up numbers and wild logical leaps. What is the real risk increment to packing a chute hastily, and does the real number help or hurt your position? Now make the stakes really high. Also consider the possibility that your choices have externalities, and others around you may not want to share their jumps with someone they perceive to be that reckless idiot who's going to get himself killed.

You didn't give specific numbers on how often someone can jump, but consider the realistic bounds on how much more often a person who packs hastily can skydive. How often is this person jumping? Are we in a scenario where the amount of time it takes to pack a parachute is really the limiting factor, to the point where the hasty packers can jump "way more?" Seems like what that would mean in concrete terms is that as soon as you hit the ground you're going to hit the john, re-pack your chute, and immediately be back in the plane. Is that a realistic scenario?

Re: Speed matters: Why working quickly is more important than it seems

#27

Post by collyw »

thomasahle wrote: post #13
shardinator wrote: post #2

I have to agree. My personal experience suggests if you want to get good at something, keep doing lots of it and aim for speed rather than perfection. You'll end up being speedy and get closer to perfection, than if you just try for perfection. But one good counter example does come to mind - designing a database schema. I'm trying to wrestle with what the difference might be. I think Markov processes, e.g. processes…

I can think of lots of more things, where doing them fast initially makes sure you'll never learn them: * Typing on a keyboard * Sharpening a knife * Driving a car. It seems more like a question of doing things a lot and very focused, than focusing on speed initially.

Tried to teach myself to touch type. I can kind of do it, but its just so slow compared to my normal typing.

Re: Speed matters: Why working quickly is more important than it seems

#28

Post by DrNuke »

Entrepreneurs would say that speed is the signal of mature markets: more and more effort for less and less return. Mobile games were very profitable in 2009-10 (low effort, high return), balanced in 2012 (speed was important at that stage), unbeatable and unbearable as a business in 2015 (however fast you are, you're just playing a lottery).

Re: Speed matters: Why working quickly is more important than it seems

#29

Post by logicallee »

bunderbunder wrote: post #26
kev6168 wrote: post #22

Earlier quoted context omitted.

The parachute analogy is worth exploring. Let's say in a life time, the accident rates due to packing a parachute quickly is 1/10000, and the fatal rate of the slow packing group is 1/1000000. Even though the fast group faces bigger danger than the people in the slow group (or people sitting at home), but other than the few who have the bad luck, the rest of them will practice way more than the other group, jump more…

You're attacking this analogy with made-up numbers and wild logical leaps. What is the real risk increment to packing a chute hastily, and does the real number help or hurt your position? Now make the stakes really high. Also consider the possibility that your choices have externalities, and others around you may not want to share their jumps with someone they perceive to be that reckless idiot who's going to get him…

I found your response to the guy a bit hostile, he's still using a hypothetical analogy too.

Re: Speed matters: Why working quickly is more important than it seems

#30

Post by avian »

> I’ve noticed that if I respond to people’s emails quickly, they send me more emails.

An alternative explanation would be that if you don't take your time to understand people's mail and just rush to answer them as quickly as possible, things that would take two mails to communicate now end up being a thread of ten mails, two phone calls and an in-person meeting.

Nothing is more infuriating than a person that replies 30 seconds later with a message that suggests they didn't read past the first sentence.

I don't know the author or his ways of responding to emails, but in my experience the above often applies to people that value speed above all else.

Post reply on HN