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 (2015)

jsomers.net

Post reply on HN
Print view View original

31–40 of 177 posts

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

#31

Post by Ma8ee »

kd5bjo wrote: post #22
skybrian wrote: post #7

It seems like this should work the other way too? If you want to break a habit, add a delay. This seems like a good idea for a browser extension. Maybe sometimes you want to undo the work that the website did making things go faster?

I’ve seen this used to good effect with coworkers that habitually ask for help before trying to solve the problem themselves. Instead of ignoring them or complaining that they’re wasting your time, wait to respond for a few minutes so that you’re no longer faster than looking the information up for themselves. Obviously this only works over some kind of messaging service; face-to-face conversations have significantly…

I often just ask my coworkers to give me a minute to finish the detail aim working on at the moment. I don’t think it is rude to let them wait a minute or even five when they come and interrupt my flow.

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

#32

Post by amelius »

kstenerud wrote: post #3

"when you punch someone you need to pull your arm back, before you launch it forward. If you don’t your hit will be weak." It's a cute way to think in opposites, but unfortunately as punching advice, it's untrue. Punch force comes from body mass x acceleration, not arm mass x acceleration.

The problem with punches is the reaction force. Better to not punch at all.

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

#33

Post by lewisjoe »

amelius wrote: post #30
lewisjoe wrote: post #25

When I do dev stuff with a slight sense of urgency, the probability of my mind wandering somewhere else goes down drastically. At this mode, my mind uses all available time slots to make the best of them. For example, by the time my program compiles, my brain visualizes possible breakage scenarios and possible solutions, in case the compilation fails. I could be on confirmation bias here, but this seems to be a neat…

Yeah, but could it also increase risk of stress, anxiety, burnout?

True. Too much of anything is bad. I keep this mode on for as long as I don't get mentally tired. Usually, that's a span of 2-3 hours.

Surprisingly, at the end of the day (typically after two/three of these zones) I feel more fresh, satisfied and productive. But that's just me.

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

#34

Post by rb808 »

skybrian wrote: post #7

It seems like this should work the other way too? If you want to break a habit, add a delay. This seems like a good idea for a browser extension. Maybe sometimes you want to undo the work that the website did making things go faster?

My data plan goes to 3g (feels like 2g) speeds when my data runs out. Its actually awesome, I still get email etc, but browsing crappy content becomes really slow so I avoid it. I wish you could buy cheap 3g only plans

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

#35

Post by rb808 »

Actually this is great advice, I should do it more. I already found it was great writing essays back in school - instead of painfully trying to be perfect, just knocking something out becomes a first draft. Same with getting kids to tidy the room, making it a fun race instead of slowly considering each piece gets chores done more quickly.

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

#36

Post by codegladiator »

andrewstuart wrote: post #24
codegladiator wrote: post #23

Earlier quoted context omitted.

Wouldn't modern times make it more relevant ? I would choose "don't worry about speed, make it happen first".

No I think speed is a primary feature, not a secondary one. As the article says, users relate completely differently to a responsive application.

The point remains that modern hardware is already super fast. Besides, avoiding "premature optimization" is to avoid efforts to speed up parts of your code which were never a bottleneck. No one is arguing for writing slow code.

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

#37

Post by skohan »

lewisjoe wrote: post #33
amelius wrote: post #30

Earlier quoted context omitted.

Yeah, but could it also increase risk of stress, anxiety, burnout?

True. Too much of anything is bad. I keep this mode on for as long as I don't get mentally tired. Usually, that's a span of 2-3 hours. Surprisingly, at the end of the day (typically after two/three of these zones) I feel more fresh, satisfied and productive. But that's just me.

Sounds a bit like the Pomodoro method: focus intentionally for short periods, and then rest intentionally for even shorter breaks. It's a bit like interval training for the brain.

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

#38

Post by adhdbrain »

monsieurbanana wrote: post #8
skybrian wrote: post #7

It seems like this should work the other way too? If you want to break a habit, add a delay. This seems like a good idea for a browser extension. Maybe sometimes you want to undo the work that the website did making things go faster?

That might be a really good idea. Over the years I've tried multiple website blockers, but I keep turning them off (no judgment please...). Artificially slowing down those time waster websites instead might do the trick. Not so slow it becomes unusable (or I'll turn it off) , but slow enough that over time I start associating it with a bad experience.

Try LeechBlock (https://addons.mozilla.org/en-US/firefox/addon/leechblock-ng...).

It's been a lifesaver in tackling my internet addiction. It has the useful 'delay option' and other nifty features that helped wean me off social media sites.

Personally, I have it installed on all my desktop browsers and Firefox on Android. I give myself half an hour quota per day for the time waste websites (Youtube, Twitter, FB, Insta, etc) after which a 60 second delay rule kicks in. I've found that my monkey brain almost never bothers waiting for a minute for the page to load unless it's absolutely necessary.

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

#39

Post by skohan »

raxxorrax wrote: post #16

> I’ve noticed that if I respond to people’s emails quickly, they send me more emails And I thought they wanted argue for faster replies... But I think there is some truth to that. If a task seems overwhelming, it can sometimes help to look back at something you already completed. I don't have that impression for programming at work, since I have a set schedule anyway, but for projects outside of that the kick-off se…

I think timing is so important with communication. Even sending a message like "got it, I will get beck to you tonight" within a couple minutes makes you seem a lot more responsive than a more detailed message an hour later.

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

#40

Post by skohan »

illuminati1911 wrote: post #13
sejtnjir wrote: post #10

Earlier quoted context omitted.

Not every product is maintained for years. In many cases it's good to be able to choose between a quick solution and a good solution, as long as these are concious decisions and some record of accrued technical debt is kept.

Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start. At least according to my experience and everyone I know in the industry.

But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks.

I also thing it is vastly overstated how difficult it is to incrementally refactor a project which is "fucked". It's always possible to break it into smaller pieces, and gradually improve the codebase until it is manageable and easy to work with.

Post reply on HN