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

161–170 of 177 posts

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

#161

Post by RangerScience »

papln wrote: post #158
koonsolo wrote: post #101

40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made. Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it". I'm in the "Slow is s…

> "Slow is smooth, smooth is fast" "A stitch in time saves nine." "Haste makes waste." Speed helps you deliver more. Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees. Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quic…

Haste != Speed.

Take the time now to do it as well as you know how to do; but you're also correct, and taking too long to do the thing is useless, as well as overbuilding.

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

#162

Post by rraghur »

joshlegs wrote: post #157
api wrote: post #110

Earlier quoted context omitted.

Another 40 year old here: I mostly agree and I've also found that thinking deeply about a problem for a long time before trying to build anything pays huge dividends. In particular I spend a long time thinking about how I can simplify the design to save implementation time, which means actually building it is faster. I also think a lot about UX and DX: simplifying installation, interface, maintenance, removing unnece…

36 yo here. I've found that it is incredibly easy to 'overthink' and therefore overengineer things, and I've seen a LOT of my coworkers fall into that trap. Analysis paralysis is real, and delivering something and then being able to iterate on it is a massive step in overcoming that. Way wayyyy too often I've seen people try to think of all the edge cases before starting work, and that's just not a viable approach to…

I agree... For personal projects, if I find myself overthinking something, it's time to just put together something that works.. that usually resolves a bulk of 'what if' questions that were freezing me up in the first place. However, it also means a decent amount of refactoring/or sometimes even junking what is tried out.

Trouble is that this approach rarely works beyond a very small team.

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

#164

Post by romwell »

invalidOrTaken wrote: post #150
SomeOldThrow wrote: post #111

Earlier quoted context omitted.

This is giving money to the rich. Don’t put in any more time than you need to; no product is worth that.

It's not a war. The rich are to be feared and pitied, like all humans.

>It's not a war. The rich are to be feared and pitied, like all humans.

Fear and pity them all you want, but your health is not theirs. Don't give away the only thing you truly have, and the only thing you can never really get back.

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

#165

Post by naasking »

alimbada wrote: post #49
wallace_f wrote: post #28

Earlier quoted context omitted.

Not ideal, but mistakes and experiments seem to be the best way people learn.

There's nothing wrong with making mistakes in experiments . However, when you're building financial systems, there's absolutely no room for mistakes.

> However, when you're building financial systems, there's absolutely no room for mistakes

Then I can assume that all of your financial software has verification proofs and/or is fully model checked? If not, then clearly there is room for mistakes even in finance.

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

#166

Post by _bspline »

koonsolo wrote: post #101

40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made. Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it". I'm in the "Slow is s…

28 year old here, I couldn't agree more.

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

#167

Post by koonsolo »

papln wrote: post #158
koonsolo wrote: post #101

40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made. Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it". I'm in the "Slow is s…

> "Slow is smooth, smooth is fast" "A stitch in time saves nine." "Haste makes waste." Speed helps you deliver more. Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees. Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quic…

> Speed helps you deliver more.

It might in the short run.

Take coding hacks for example. It is fast in the short term, but might cost you double in the long term.

Not saying that quick hacks can never have their place, but saying that being fast might cost you time in the long run.

So faster is not always faster, and does not always help you deliver more, depending on the timeframe.

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

#168

Post by sejtnjir »

stcredzero wrote: post #135
skohan wrote: post #50

Earlier quoted context omitted.

The point is there's a balance. I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project. It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always , but in my experience i…

I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project. The point of code quality is to enable the company to change its mind or add new features. Over-perfectionism that gets in the way of this is going too far. At one co…

Smart devs know they probably get the abstractions wrong until the third iteration. This sounds like a sane policy.

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

#170

Post by peterbell_nyc »

stcredzero wrote: post #109
koonsolo wrote: post #101

40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made. Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it". I'm in the "Slow is s…

Speed doesn't matter as much as WHAT you deliver. Seems to me, that the recent spate of online coding interview techniques are basically looking for people who type fast. I suspect that they're finding people who are actually "10X" coders, and people who have memorized the typing out of the solution. (EDIT: A problem with such 3rd party companies, is that the incentives are subtly misaligned, as they are for any recr…

I think there are misalignments, but I'm not convinced that false negatives are one of them. If I can fill all my req's with amazingly talented, lovely and capable people, it doesn't really matter so much to me if there are other amazingly talented, lovely and capable people that get rejected unreasonably in the process (unless it starts to create reputational risk).

I think the bigger misalignment is the time horizons for success (placement vs successful performance), but that's something that'll get figured out as the interview companies build up their track records and keep track of how long their placements stay in their new jobs.

Post reply on HN