Hacker News Reader

Comment by khazhoux | Hacker News Reader

Like most analogies, this one fails completely. It's well-understood that the security guard does nothing but stay alert 99% of the time. He very explicitly needs to "do nothing" for long stretches of time.

Software development operates largely on trust that everyone on the team is putting in real effort. The manager trusts that when it takes you a week to finish a task, it's because it actually took a week of work, not a few minutes on Monday and then you watched YouTube vids and were on your XBox the rest of the week. And not just the manager -- everyone at the company would almost certainly like to move faster, and wouldn't be happy to know that features and bugfixes could be landing 5x faster, except for people who figured out that no one's checking up on them.

View on HN

everyone at the company would almost certainly like to move faster

Not necessarily true. This is certainly the case at a startup, but at a more established BigCorp, things move slowly, and the ability of an engineer to work at a slower pace is an asset. You may be waiting on legal approval for weeks or months, or a software review from infosec, signoff from finance on integration testing for a new payment processor, or any number of processes that are not banging out code as quickly as possible (these are all actual examples from my company). In these cases, you shouldn't have to BS your way through a standup, but you will have times where a week goes by and you haven't written a single line of code, and that is exactly what the job requires.

> you will have times where a week goes by and you haven't written a single line of code, and that is exactly what the job requires.

OP is not saying that sometimes he's idle. Of course there are times when things move slowly.

OP is saying that in his entire software development career, he works 0.5-1.0 days a week, and never more.

Or demoing to stakeholders, gathering business requirements, communicating new content that needs to be received etc. Those are all important reasons to go slower too

Moving too fast doesn't benefit anyone

By "everyone would want to move faster" I mean: ship your product, whatever it is, at a high level of quality, sooner rather than later.

I'm not sure I'm familiar with any software project were people were glad it took as long as it did.

Reply on news.ycombinator.com