Hacker News Reader

Comment by kator | Hacker News Reader

I've heard people say laziness is important. However that is a misnomer, the reality is the best inventors and engineers are sort of long-term lazy. They will spend 40 hours building something to automate a thing you can do in 15 minutes. But, they know that they or others will push that button so many times the 40 hours will come back quickly over time.

An example of this is a strong senior engineer might take a lot of time laying the foundations of a project, the scaffolding needed to really make coding a breeze and enjoyable in the future. This is because they're lazy, they want the future to be easier so they invest today to make the future just a little bit easier.

View on HN

Related XKCDs:

https://xkcd.com/1205/

https://xkcd.com/1319/

https://xkcd.com/974/

The mouseover text of that last one is very relevant to the discussion.

Yep, here it is for everyone that doesn't want to waste a browser tab:

"I find that when someone's taking time to do something right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they're a master artisan of great foresight."

#974 is great! I know I have been guilty of #1319, when I really should of just done the repetitive task instead of spending so much time thinking it would save me some time in the future.

>They will spend 40 hours building something to automate a thing you can do in 15 minutes.

That's because building something new is exiting and interesting, while doing something boring for 15 minutes is ... boring?

The point is more that by saving those 15 minutes, it's a cumulative saving for all future use cases. Though, I don't think I fully agree with this in all cases. It can be hard to predict when something really is going to be used often enough that this is important.

IMO you build the minimal thing that does the job, then after understanding the use case go back and refactor to deal with the accumulation of 15 minute pain. Doing it right at the beginning is the definition of premature optimization.

And on the topic of building new, this is a mistake many developers make: that it's easier to build new, then to refactor existing. What they fail to realize is that the old code they think is too difficult to maintain is battle tested, in production, has operational understanding associated with it. All software goes through this cycle, and so while it's fun to build something new, you are inviting debt while doing so b/c of the unknown production issues and edge cases that need to be figure out after it goes live. It's not always wrong to rewrite, but IMO, it's a last resort. BTW, this is why SOA is important: strong defined contracts/APIs between services allow for components to be replaced with a higher degree of confidence.

And will start to pay for itself after repeating 120 times. Although, this assumes the 40 hours includes any necessary maintenance. Let's be honest: It doesn't. Although, your coworkers lack proper checklist vigilance, and forgetting steps may have other costs!

Totally agree. I think when people hear the word "lazy" they think "incompetent", like "they didn't know how to solve the problem, so they took a lazy route by not doing it very well" when this is not what is meant by the phrase at all, it is exactly what you said.

I would also say that it's doubly important with the experience because I've seen people spend far too much time one something that they think will save them time in the future, but that future changes. It's a balancing act.

Reply on news.ycombinator.com