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

71–80 of 144 posts

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

#71

Post by sombremesa »

vijayr wrote: post #67
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…

don't pack a parachute quickly. Write a to-do list app super fast, but take time with medical software...

How long do you think Workflowy took to conceptualize and implement?

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

#72

Post by thawkins »

travjones wrote: post #57
gress wrote: post #56

Earlier quoted context omitted.

Sounds like you're advocating a return to strict behaviorism.

Strict behaviorism? I'm advocating for the experimental analysis of behavior (sometimes referred to as radical behaviorism). When applied to practical human problems, it is referred to as applied behavior analysis. The study I cited provides support for the authors conclusion. However, his description is flawed because it doesn't provide means for prediction and control of behavior.

It sounds like he is trying to substitute jedi mind tricks for personal discipline

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

#73

Post by noskynethere »

I see a lot of responses that seem to reflect what I consider a misunderstanding of the real advantage of speed.

It's not to get the same amount of work done in a shorter time (the management fallacy referenced in some of the comments).

The point of speed is to increase the number of feedback opportunities. Each feedback datum allows for slight course corrections / confirmation of original hypothesis.

By analogy, think of it like sample size. If you accept time as a primary constraint, then faster iterations (even if you accomplish less!) tend to give you more samples. More samples mean less variance.

Making decisions on a better model (less variance) is very appealing to me.

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

#75

Post by CPLX »

rrss1122 wrote: post #63
_yosefk wrote: post #59

Earlier quoted context omitted.

"What software projects have stood the test of time? The ones that were painstakingly thought out and progressed slowly." I kinda think that the opposite is true, or at least as true as your statement (meaning that at least as much half-baked stuff rushed out the door 'stood the test of time' as did stuff that took a lot of time to ship.) Unix, C, Windows, PHP, JavaScript...

To offer an example of a project that has stood the test of time far longer than the ones you mentioned, consider Fortran. The first compiler was released in 1957, several years after it was first proposed. The specification took a couple of years to complete. This was over 60 years ago, and even now they are releasing an update to Fortran (Fortran 2015). Even in the examples you mentioned, Unix, C, and Javascript ar…

This feels like a classic example of survivorship bias. Based on the nature of computing resources in the 1950's and academic culture in general, it's likely that all language/compiler projects of the era were planned deliberately and slowly. One of them survived.

So all projects that have "stood the test of time" for that length of time have that attribute. Also having that attribute are all the projects of that era that failed miserably.

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

#76

Post by skybrian »

One apparent counter-example is that when practicing the piano, some common advice is to play pieces much slower than you think is necessary, but play them correctly. Then speed up once you have the right habits.

But the overall goal is to learn new pieces as efficiently as possible. Someone who is efficient at practicing will make much more progress (and have more fun doing it) than someone who isn't.

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

#77

Post by otoburb »

onion2k wrote: post #44
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…

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…

Here are some stats measured in micromorts[1]:

Skydiving (US): 9 out of a million chance of death per jump

Skydiving (UK): 8 out of a million chance of death per jump

... where 1 micromort = 1 in a million probability of dying

[1] https://en.wikipedia.org/wiki/Micromort#Leisure_and_sport

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

#78

Post by edc117 »

tilmonedwards wrote: post #64
doki_pen wrote: post #48

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

In addition to that, I like to try to answer every question I can at work, even if I have to just go Google it myself. Telling someone you don't know and they should just Google it is robbing yourself of an opportunity to 1) learn it yourself, and 2) explain it to someone else (which is a GREAT way of making sure you really understand it). Plus, people seem to like it when they ask something, and you help research th…

I agree with you completely here, but you definitely have to be careful, particularly as you become more knowledgeable. Some developers get into the habit of simply asking every time they can't find an answer, or giving up after only a few minutes trying, without realizing that the searching builds a better foundation than the answer many times.

My general rule has been - always ask what they've tried first. If it seems a sincere effort has been put into it so far, by all means help out. It may be something you know immediately, but there is value in teaching people to learn for themselves.

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

#79

Post by qznc »

_yosefk wrote: post #61
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…

One good takeaway: be slow at things you don't want to do a lot. Be slow in answering the kind of email you don't want to receive again, etc.

I like to call this "intentional incompetence" :)

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

#80

Post by lectrick »

As a developer, what this means to me is:

For every piece of code you write, there should be a unit test covering it that you can run fairly instantly with 1 keypress which catches at least internal-consistency errors. (Integration tests would cover external-consistency errors, but when you're refactoring/adding/deleting code, internal-consistency is violated far more often than external consistency, in my experience.)

Once you experience this for yourself, you will NOT want to go without it. It allows you to IMMEDIATELY get back to coding without waiting for test runs to finish and without creating bugs unknowingly that you only catch much later.

Post reply on HN