4 ms·

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 n

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.

byoung2 5y ago
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.
- khazhoux 5y ago
  > 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.
- swaggyBoatswain 5y ago
  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
  - khazhoux 5y ago
    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.

byoung2 5y ago

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.

khazhoux 5y ago
> 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.
swaggyBoatswain 5y ago
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
- khazhoux 5y ago
  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.