Speed matters: Why working quickly is more important than it seems • Hacker News Board

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

#41

Post by dec0dedab0de » Fri, Aug 07, 2015, 2:04 PM UTC

avian wrote: post #30

> 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 replie…

I was going to quote the same line, but add that I don't want anyone to send me more emails. Who could possibly want more emails?

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

#42

Post by NumberSix » Fri, Aug 07, 2015, 2:07 PM UTC

I am reminded of the story of how Leonardo da Vinci took three years to paint The Last Supper and produced only a small number of paintings, generally considered masterpieces, during his life.

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

#43

Post by mattlutze » Fri, Aug 07, 2015, 2:09 PM UTC

sheepmullet wrote: post #18

mattlutze wrote: post #12

Earlier quoted context omitted.

The implied benefit is that repetition improves quality, so more repetitions, more quickly, means your quality will improve more quickly. You need to self-reflect after each iteration, mind you, to make sure that you learn each time you do the thing. But, this is necessary for skill progress whether you're going fast or slow. (And, having to make the corrections can be as informative or more so, depending on how you'…

"The implied benefit is that repetition improves quality, so more repetitions, more quickly, means your quality will improve more quickly." Yes, but that's frequently not the case. Developers at "sweat shops" tend to write far more code, and work many more hours, than the average dev at a top tier software house and yet they are usually much worse devs.

>> You need to self-reflect after each iteration, mind you, to make sure that you learn each time you do the thing. But, this is necessary for skill progress whether you're going fast or slow.

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

#44

Post by onion2k » Fri, Aug 07, 2015, 2:14 PM UTC

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…

To be honest, if packing a parachute takes an hour longer and increases the chance of living by 100* I'd say that's worthwhile. But then, I also wouldn't call 1/10000 an especially high risk. We face those sorts of odds just driving a car and they don't put many of us off[1].

If the probability of death from packing a parachute quickly were 1/100 then I think your argument would break down somewhat. Like I said, you should spend the appropriate time on something depending on the costs and risks associated with it. "Do everything fast" is wrong, but so is "Do everything slow".

[1] In 2003 the annual risk of being killed as a car user were 1/15261. http://www.medicine.ox.ac.uk/bandolier/booth/Risk/trasnsport...

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

#45

Post by agumonkey » Fri, Aug 07, 2015, 2:17 PM UTC

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…

Don't bang frenetically on walls too. It's very very good to be able to reach deep understanding without hyperfast iterations. There will be times where you don't have that luxury too. Make haste slowly, balance.

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

#46

Post by Retric » Fri, Aug 07, 2015, 2:31 PM UTC

klibertp wrote: post #39

collyw wrote: post #27

Earlier quoted context omitted.

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

Measure your writing speed. Aim for 70-80 WPM. If you get that speed then it's a) enough and b) it doesn't matter at all if you "touch type" properly or have invented your own typing system.

The advantage of touch typing is on a good keyboard/desk/etc you can do it 10 hours a day for 30 years without wrecking your hands. That said, most programmers don't actually type that much so it's not nearly as important.

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

#47

Post by marcosdumay » Fri, Aug 07, 2015, 2:32 PM UTC

brlewis wrote: post #40

From the comments, I think readers are generally failing to take an opportunistic attitude toward this article. Dig out useful ideas and ignore what doesn't help. Yes, there are situations where working too quickly will bite you, so you can't always do it. But the key idea here is that by working quickly you reduce your expectations of how costly a new effort is. Then you'll actually start it. Inertia is a powerful a…

"Opportunistic attitude" looks too much like "confirmation bias" to me to be comfortable with it.

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

#48

Post by doki_pen » Fri, Aug 07, 2015, 2:40 PM UTC

How do mere mortals become wizards to their peers? They take the time to read documentation and code and really understand the tools that they are working on. What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly. Of course there's a balance, and our current system of financing software projects rewards fast and loose, and there will always be a place for fast prototyping to help understand the problem, but to create something truly amazing takes a lot of time.

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

#49

Post by jamesrcole » Fri, Aug 07, 2015, 2:41 PM UTC

Some other reasons why speed can be good:

- You can only hold so many details in your head at once, and you can only sustain that collection for a limited duration. Holding those details there can be crucial for doing good work and the faster you work the more you make use of them.

- Doing good work often requires a lot of experimentation and iteration. In a number of circumstances this may only be practical if you can do them fast enough

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

#50

Post by raldu » Fri, Aug 07, 2015, 2:51 PM UTC

Before anything, the obsession with speed seems like a management fantasy that tries to squeeze more out of workers in less time. We shouldn't forget that we're all human, and there are myths and facts related to working fast.

Working "fast" is tricky. The ironic conclusion part of the article is an example to that. People will miss the point and screw up more while trying to be "faster". However if a task becomes more automatic, it will become faster, which means that actually doing something "fast" would consume less energy, since it is more or less automated and unconscious, while "trying" to be fast would consume more energy.

The key here seems to be that just do something "a lot", and it will become faster by itself through time by being more and more "automated". But take your time, and stop worrying about speed. Speed is just pressure which will bring more pressure as you do stuff faster. Don't create unrealistic pressure.

Another key is garbage collection. Just get stuff "done", and get rid of the old tasks, or treat your long to-do items as "later" lists. If something really matters, you will do it anyway. You won't even need a to-do list to keep track of your "important tasks".