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

91–100 of 144 posts

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

#91

Post by shkkmo »

grellas wrote: post #83

Speaking as one who is laid back in a personality sense, I could imagine nothing worse than a life lived non-stop frenetically under the imagined need to speed up all activity in the name of productivity. Take time to pause, reflect, think , and enjoy your life experiences. Even when it comes to work-related activity, there are times and places to do things quickly and there are times and places to do them deliberate…

> a life lived non-stop frenetically under the imagined need to speed up all activity in the name of productivity.

I don't think that is quite what the article is suggesting. I think it was reminding us to thinking about the effects of the speed at which you accomplish things. If there is a behavior you are trying to encourage in others (e.g. requesting a code review), focusing on responding quickly can be crucial to helping foster that behavior. Similarly, if there is a communication channel (e.g. Slack vs. email) that is not being adopted, holding yourself back from quick responses to those emails while responding quickly to Slack messages will help foster the transition.

This doesn't mean that you need to do everything as quickly as possible. It does mean that if there is something that you do slowly that you want to improve on, it may be helpful to be aware of the additional mental cost you associate with the activity so that you can compensate for it. Similarly, if you are trying to improve the quality of your writing, focusing on improving the speed of your writing (or even just the speed of your typing) while maintaining the same quality might pay off faster than just focusing on improving quality.

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

#92

Post by hinkley »

bonesinger wrote: post #24
sheepmullet wrote: post #15

Earlier quoted context omitted.

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.

Read Refactoring by Fowler. You'll learn far more why and how from his prescriptions than the GoF's descriptions.

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

#93

Post by kev6168 »

logicallee wrote: post #82
bunderbunder wrote: post #31

Earlier quoted context omitted.

Hostile to the idea, not the person. With some reason - there are a lot of pernicious myths that survive purely on the false mimesis you can generate by using made-up numbers. See: Politics.

I'm specifically saying that "You're attacking this analogy with made-up numbers and wild logical leaps" is too harsh a way to begin a comment here - it's not civil. The dude just said some hypothetical thoughts, you could have responded "Unfortunately I feel your numbers are not drawn from the real-world, and I think some of your conclusions take real leaps of logic. Specifically..." but hey it's just me. this place…

Yeah I thought we were talking hypothetically and in a very general sense (hence the obviously made up numbers to merely indicate some scales) about an inherently very general issue.

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

#94

Post by dgreensp »

thawkins wrote: post #70
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.

That's why this point isn't so related to the other two, because it's specific to the goal of getting better at something.

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

#95

Post by tilmonedwards »

edc117 wrote: post #78
tilmonedwards wrote: post #64

Earlier quoted context omitted.

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

For sure. If I'm dealing with a junior engineer, I take a much more hands-off approach. It ends up taking longer, but that's ok, because usually, the net long-term benefit of that engineer getting practice at self-directed research is much higher than the output of the task itself.

On the other hand, if I'm dealing with a "senior" engineer who's doing that, I'm actually less worried about whether there's been sincere effort. It's just the other side of the same coin: They've offered their learning opportunity to me, and I'm happy to take advantage of it.

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

#96

Post by mkagenius »

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…

Yeah, iteration on an idea is important, so, the faster you complete it (at least MVP) and put out to the world, the better it is.

Its one of the key lessons YC taught me.

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

#97

Post by dgreensp »

npizzolato wrote: post #84
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…

> Quantity Always Trumps Quality - There's a blog post by Jeff Atwood with this title. The point is, if you want to get better at something, do a lot, and don't worry about quality while you're practicing. I wholeheartedly disagree. My martial arts instructor had a saying: "Practice doesn't make perfect. Perfect practice makes perfect." I've found that to be true. After all, if you practice bad technique, how do thin…

"Quality" here means the quality of your result. If you are learning to paint/sing/code, it means how good the painting/singing/code is. The advice is to not "worry" about the quality, in the sense that if you are not producing good quality output, that does not mean you are doing anything wrong. When you are just learning something, the output will not be good quality! You need to produce a lot of crap results, and that makes most people uncomfortable.

I can relate what you're saying to my experience taking singing lessons, though even there, I find that making progress is all about turning off the inner judge while you practice. All you need to practice something is a bit of intent and a bit of awareness; it's not important that you "worry" about the quality of what you are doing, per se.

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

#98

Post by qznc »

shkkmo wrote: post #87
qznc wrote: post #79

Earlier quoted context omitted.

I like to call this "intentional incompetence" :)

I don't think that is accurate without an additional assumption about the reason you don't want to do something. If I prioritize quick responses and turn arounds to requests that are important, provide value, and allow me to improve important skills, that is not incompetence. If you de-prioritize items, regardless of their importance and value but simply because you don't want to do, that could quite conceivably be c…

... and if you consider that bad, inefficient process beyond your influence in the foreseeable future, then intentional incompetence is the good strategy to avoid doing it. Such situations easily arise once you work within larger organisations.

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

#99

Post by drumdance »

AnimalMuppet wrote: post #85
grellas wrote: post #83

Speaking as one who is laid back in a personality sense, I could imagine nothing worse than a life lived non-stop frenetically under the imagined need to speed up all activity in the name of productivity. Take time to pause, reflect, think , and enjoy your life experiences. Even when it comes to work-related activity, there are times and places to do things quickly and there are times and places to do them deliberate…

One of the tenets of Extreme Programming is, "Quit when you're tired." Why? Because it's faster. It's not faster today - if you kept working, you'd presumably get more than zero done. But you'd also create more bugs, and you'd come back more tired tomorrow. Coding is not an assembly line; your brain needs to be fresh. Taking time to pause, reflect,and think is the same. It's slower in the next minute, maybe in the ne…

As someone who's just finishing nearly four weeks of non-stop work including weekends, I approve of this message.
Post reply on HN