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

111–120 of 144 posts

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

#111

Post by Retra »

jkaunisv1 wrote: post #101
marcosdumay wrote: post #47

Earlier quoted context omitted.

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

The phrase may put you off but I think the sentiment is sound. Too many dismiss something/somebody in entirety because of one flaw. I think it's better to try to find value in everything; even if it's 99% shit, you can still learn from that 1%.

Or you could find something that's 95% shit and learn from its 5%. You can't learn everything, so why would you spend your time learning the 1% good things and dealing with 99% shit? There are too many easy ways to find value out there to be spending your time panning for scraps in sludge.

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

#112

Post by nostrademons »

Retra wrote: post #111
jkaunisv1 wrote: post #101

Earlier quoted context omitted.

The phrase may put you off but I think the sentiment is sound. Too many dismiss something/somebody in entirety because of one flaw. I think it's better to try to find value in everything; even if it's 99% shit, you can still learn from that 1%.

Or you could find something that's 95% shit and learn from its 5%. You can't learn everything, so why would you spend your time learning the 1% good things and dealing with 99% shit? There are too many easy ways to find value out there to be spending your time panning for scraps in sludge.

What's your search cost? If you have to hit "back" on 5 articles that were 99% shit to find the one that's 95% shit, you were better off just taking your 1% tidbits.

(In practice, I've found that anything that's >50% shit or so isn't worth wasting time on. Stuff that's >50% good, informative stuff is usually qualitatively different from stuff that's 5% good informative stuff; go where the former is.)

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

#113

Post by Retra »

nostrademons wrote: post #112
Retra wrote: post #111

Earlier quoted context omitted.

Or you could find something that's 95% shit and learn from its 5%. You can't learn everything, so why would you spend your time learning the 1% good things and dealing with 99% shit? There are too many easy ways to find value out there to be spending your time panning for scraps in sludge.

What's your search cost? If you have to hit "back" on 5 articles that were 99% shit to find the one that's 95% shit, you were better off just taking your 1% tidbits. (In practice, I've found that anything that's >50% shit or so isn't worth wasting time on. Stuff that's >50% good, informative stuff is usually qualitatively different from stuff that's 5% good informative stuff; go where the former is.)

I think that's really a matter of what level of mastery you are looking to achieve, and how broadly you intend to achieve it. If you're looking to be the best of the best in one single, narrow subject, you might quickly run out of <50% shit resources and need to dig into some really bad stuff to find little, rare bits of good knowledge.

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

#114

Post by nostrademons »

Retra wrote: post #113
nostrademons wrote: post #112

Earlier quoted context omitted.

What's your search cost? If you have to hit "back" on 5 articles that were 99% shit to find the one that's 95% shit, you were better off just taking your 1% tidbits. (In practice, I've found that anything that's >50% shit or so isn't worth wasting time on. Stuff that's >50% good, informative stuff is usually qualitatively different from stuff that's 5% good informative stuff; go where the former is.)

I think that's really a matter of what level of mastery you are looking to achieve, and how broadly you intend to achieve it. If you're looking to be the best of the best in one single, narrow subject, you might quickly run out of <50% shit resources and need to dig into some really bad stuff to find little, rare bits of good knowledge.

If you want to be the best of the best in one single, narrow subject, then listening to what other people think is useless. Rely on direct experience instead; perform your own experiments, test out your own ideas. That's what it means to be the "best of the best": you're the one injecting new data into the ecosystem.

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

#115

Post by jkaunisv1 »

Retra wrote: post #111
jkaunisv1 wrote: post #101

Earlier quoted context omitted.

The phrase may put you off but I think the sentiment is sound. Too many dismiss something/somebody in entirety because of one flaw. I think it's better to try to find value in everything; even if it's 99% shit, you can still learn from that 1%.

Or you could find something that's 95% shit and learn from its 5%. You can't learn everything, so why would you spend your time learning the 1% good things and dealing with 99% shit? There are too many easy ways to find value out there to be spending your time panning for scraps in sludge.

Well, I was referring more to the situation where you're already reading something, or finished reading it. Obviously there is an opportunity cost that you could have sought out something better to read, but now that you're there - take what you can from it. In my experience a lot of people will dismiss an entire article based on one wrong fact or crazy opinion.

And when extended to people - just because someone says something stupid or wild doesn't mean everything they say is that way.

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

#116

Post by quietplatypus »

lectrick wrote: post #80

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…

This is why I love Haskell---the check, though approximate, is built in to the language as the type checker. Pair it up with the speed Haskell coder's best friend, "undefined", and you can be just 40 characters into writing part of a method and check it right there on the spot, getting into a good flow.

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

#117

Post by e12e »

fmavituna wrote: post #38

Speed matters and there are more ways to make things faster other than doing them often. 1. If you are coding ensure that your debugging environment is good (simplest example would be if you write HTML how long does it take to see the output or is it auto-refresh itself int the second monitor when you change the file?). 2. If you are building a project how long does it take to deploy? Do you have CI with a one button…

Reminds me of Mjoolnar's (author of vim) talk on 7 habits of effective editing 2.0; the core idea is essentially (my current interpretation): awareness: look for repetition - they are candidates for automation and/or being more effective. Rule of three: If you do something (anything) 3 times - figure out if it can be done more efficiently. In vim (or any other editor) an example might be shifting the indendation of code: maybe you only remember how to do it a line at a time; figure out how to work on blocks of code; figure out how to do it on a file - a whole project.

https://m.youtube.com/watch?v=p6K4iIMlouI

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

#118

Post by bjterry »

noskynethere wrote: post #73

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, thi…

This article reminds me of one of my all-time favorite articles. Quantity Always Trumps Quality by Jeff Atwood [1]. There is a bunch of commentary on it on Less Wrong [2], some of which is interesting. Also an interesting parallel to a Paul Graham post [3]:

> I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.

> For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

1: http://blog.codinghorror.com/quantity-always-trumps-quality/

2: http://lesswrong.com/lw/53e/just_try_it_quantity_trumps_qual...

3: http://www.paulgraham.com/hp.html

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

#119

Post by sombremesa »

vijayr wrote: post #81
sombremesa wrote: post #71

Earlier quoted context omitted.

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

I don't know. May be a month?

My apologies, I didn't expect you to know. I guess my purposes are better served by a survey.

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

#120

Post by lectrick »

quietplatypus wrote: post #116
lectrick wrote: post #80

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…

This is why I love Haskell---the check, though approximate, is built in to the language as the type checker. Pair it up with the speed Haskell coder's best friend, "undefined", and you can be just 40 characters into writing part of a method and check it right there on the spot, getting into a good flow.

I see that appeal of Haskell, and I think the strict focus on typing does catch many possible bugs... but I don't think it catches all the types of bugs that an actual unit test would, so I'm almost afraid that it's leaned on a bit too much.
Post reply on HN