[9rx]

> within office hours

You are running a factory over there? That makes the weekend perspective a bit more reasonable, given the constraints. Tech work, on the other hand, descends from agriculture. You work when the sun is shining and rest when it is stormy, metaphorically speaking. There is no reasonable concept of defined working hours. The brain doesn't operate on a set schedule like that, and trying to ignore that reality is where the burnout stems from.

If we were talking about tech, you certainly would look foolish applying factory concepts to an entirely unrelated field.

[roguecoder]

I was at one place where we tracked every bug introduced, and discovered more than 90% were in code written after 5pm. We dramatically cut our bug rate just by shutting down PRs outside of business hours.

The problem is that when our performance declines, so does our ability to judge our performance. We can feel more productive while actually doing a much worse job.

[9rx]

> more than 90% were in code written after 5pm.

Intriguing. Did you find that remained true through DST periods, assuming DST observance? Meaning, did you find that it was literally the clock that determined when bugs would seep in, or did bugs also increase if you didn't counteract times changes for whatever human factor (circadian rhythm?) made 5 PM significant?

> The problem is that when our performance declines, so does our ability to judge our performance.

Sure, but what sees performance magically decline at 5 PM?

If it was the clock, did you try removing the clock from the equation? Did bugs show up the same if developers had no idea what time it was?

If it was some other human factor, did you see uniformity across all participants? Were the "night owls" who were just getting started at 5 PM just as likely to introduce bugs after 5 PM as those who had been working since 9 AM?

[bckr]

If it were me, I would write the code, commit it, and open the PR Monday afternoon

[9rx]

That is what the individual is going to end up doing if they encounter the guy who thinks software is built on an assembly line, but is not ideal. The reviewer might get "the itch" before Monday. It would be a waste to see him fall into burnout because he had to artificially wait because you had to pretend to wait.

[roguecoder]

You don't burn out because you weren't working. That's not a thing.

I am concerned about how you describe coding as an addiction. That sounds like something worth bringing up with a therapist & investigating the root cause of. It can be literally dangerous to identify that much with only our work, especially in this economy.

But if you don't want to do that, if you have some rare code-or-die health condition, just contribute to some Apache project instead. The entire internet is build on projects people wrote that their companies didn't pay them to write. We don't have to give our whole creative selves to our employers.

[9rx]

> You don't burn out because you weren't working.

If you never had to work then you would never burn out, sure. But returning back from la-la land, most people are going to have to work. As was stated before, burnout ensues when one forces themselves to work when they are not in the right frame of mind to do so. If you code by the rule of the calendar, that is what is going to put you at risk of burnout. If you code when your mind says "Let's go" and stop when your mind says "That's enough", chances are you'll never experience it.

Denying a "let's go" moment on Saturday, to fight with a "that's enough" moment on Monday because the calendar says you cannot work on Saturday but must work on Monday is a good way to end up with burnout. But why fight it? Why not just work on Saturday and take Monday off? It is not going to make any difference in the end. The deliverable will be there at the anticipated time either way.

> I am concerned about how you describe coding as an addiction.

What is this addiction you are referring to? I can find no mention of it anywhere in this thread before this.

[ToucanLoucan]

Not a matter of when the office is open, it's a matter of how many hours have been worked vs what's expected. I'm obviously fine with folks working whenever they want, that's half the benefit of work from home in the first place. What I'm not fine with was this particular dude clocking in code at all hours all week, then putting even more in on the weekend. And mind you this is not simply from commits, it's from when he's emailing me his time spent on various tasks and I can see he's wildly passing the 40 hour mark.

[9rx]

> it's from when he's emailing me his time spent on various tasks and I can see he's wildly passing the 40 hour mark.

I'll grant you that it is red flag that he would want to take your energy telling how long something took. It doesn't even mean anything in the given line of work. An interesting problem might be given hundreds of hours of thought – in the shower, while sleeping, etc. – but only take 15 minutes to type afterwards. What would you report? The 100 hours? The 15 minutes? Invent some kind of weighting system to offset parallel activities? And for what? None of them mean anything.

The manager's job is to take the unnecessary burden of externalities off the rest of the team, but it is a team and that means it has to cut both ways. The rest of the team has to take the unnecessary burden of internality off the manager. If that was the best political way to say "please stop, you are needlessly wasting my energy", then that makes sense, I suppose. Or, perhaps a good manager is brutally honest above being politically sensitive? A team is, after all, characterized by their willingness to remain bonded even amid strife. Without that, you just have a group of people.