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

#61

Post by _yosefk » Fri, Aug 07, 2015, 3:20 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…

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.

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

#62

Post by g_delgado14 » Fri, Aug 07, 2015, 3:34 PM UTC

I feel like there's a bunch of data over-fitting going on here. The examples here are merely the ones that fit with the author's model, are they not? I'm sure I could have had a theorem that points to the idea that "fast work is catastrophic", gone back in time, and shown how the slow individuals / components of a system were significantly more effective than the fast ones.

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

#63

Post by rrss1122 » Fri, Aug 07, 2015, 3:37 PM UTC

_yosefk wrote: post #59

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…

"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 are all run through standards bodies now. It took years for C11 to be finalized. It's been years since ES6 has started development. PHP7 has taken a few years (and a version update before even being released).

Windows, depending on who you're talking to, can be a good example of half-baked, or an example of why half-baked is terrible, with regards to Windows 8 and Windows 10 releases.

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

#64

Post by tilmonedwards » Fri, Aug 07, 2015, 3:40 PM UTC

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 through it with them. They come back to you again, which gives you another free opportunity to share someone else's learning, and you quickly turn into that person who either knows everything, or knows where to find out.

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

#65

Post by squozzer » Fri, Aug 07, 2015, 3:46 PM UTC

I am not sure if the writer has thought out the drawbacks to working quickly but there is probably some benefit to deciding quickly.

The writer mentions that faster employees have more work assigned to them. Woo hoo, but what happens when the work queue fills up faster than it can be emptied? Then the once-fast employee now seems slow.

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

#66

Post by vijayr » Fri, Aug 07, 2015, 3:52 PM UTC

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…

May be you and your parent comment are both right? Release the first few versions very fast (even if it is not good) and if it is successful, then slow down, redesign etc? Examples include PHP and JS

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

#67

Post by vijayr » Fri, Aug 07, 2015, 3:54 PM UTC

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...

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

#68

Post by bentcorner » Fri, Aug 07, 2015, 3:57 PM UTC

Retric wrote: post #46

klibertp wrote: post #39

Earlier quoted context omitted.

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.

I bemoan the death (or near-extinction) of text-input games. I learned entirely on my own how to touch type by playing classic Sierra adventure games and spending a ton of time in DOS. I never would have done that if I had gotten into computing a few years later with the transition to mouse-based UIs.

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

#69

Post by thawkins » Fri, Aug 07, 2015, 4:10 PM UTC

raldu wrote: post #50

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

Ok, i will hold up my hand, im a software manager, and nothing fustrates me more than developers trying to do everything at break neck speed and just plain geting it wrong. They either fail to read or understand the requirements in the rush to get started, or they will rapidly push out a pile of shit, and fein suprise when it repeatably gets rejected by QA. My best guys are the ones who take the time to read tbe specs and talk to the stakeholders about what they want, and who spend time making sure that what they produce will pass muster. Those guys are golden, they are worth 10 of the immature speed freaks.

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

#70

Post by thawkins » Fri, Aug 07, 2015, 4:13 PM UTC

dgreensp wrote: post #36

There are actually three lessons here: * Momentum - To stick with something and finish it, you need to use momentum. Lacking momentum, projects languish. Quoting author Steven Pressfield: "Second only to habit, momentum is a writer’s (or artist’s or entrepreneur’s) mightiest ally in the struggle against Resistance." * Waiting is painful. That's the point behind the examples in the middle section (waiting for an email…

I dont want you "practising" with my product, i'll take quality over quantity any day. If i want crap i'll outsource it.