A layoff fundamentally changed how I perceive work

[ citation needed ]

Every job I've worked at has specified when we provide references, we're to say "X was employed from Y to Z" and if we would hire them again, yes or no. The employee described here would get a yes from me. The fact that they didn't go "above and beyond" will not help them get a job, at least if they happened to work for any of the companies I have.

> If people know you are a standout contributor then you will be hired quickly into desirable roles.

I guess we could quibble over definitions then, because I as a senior dev managing other devs am perfectly happy with someone who clocks in, does the work on-time and to-spec, and then clocks off as a "standout contributor." I've chastised a few people in my time for committing code on the weekends too, not because I don't appreciate their contribution, but because I consider it part of my job to prevent burnout, voluntary or otherwise.

Burned out devs turn out worse work, and they feel worse in the bargain. Textbook definition of a lose-lose. Whatever code is being a pain in the ass today is just that; code. It will be there when you get back from the weekend, it will be there when you get back from a doctor's appointment, it will be there when your kid is done being sick. Life matters. Code... does, but to a lesser extent.

> On top of that, carrying around bitterness and cynicism is just bad for you.

Which is why I don't want people feeling bitter about their job, and putting in the extra work to, by your own admission, be just as damn likely to get the axe for reasons that are out of your control? That's embittering as fuuuuuuuck.

> Pride in good work and pleasure in having an impact on customers and coworkers is good for you.

False dichotomy. I love what we build, and I want my subordinates to have fulfilling, happy lives. And I proportion my energy to both of those things in accordance with their importance.

The best way to avoid burnout in my experience is to work when you have "the itch" to do it. If you're feeling it on a Saturday, why not go for it? You might not be feeling it on Monday and will need the break then instead. If you forego the prime opportunity and then force yourself to do it later when you are not in the right mindset, that is when the burnout is going to get you.

- Forcing yourself to work on Monday. Burnout ensues. Will you be able to continue while burnt out?

- Skipping Monday too, seeing you only work four days a week. Will you be able to continue under performance expectations?

2. Do you really need to worry about this hypothetical future? If the bad manager shows up, are you going to stick around even if working hours remain the same? He is still going to express his badness in many other ways. He wouldn't be bad otherwise.

And you're right, this is a marathon, and working sustainably is absolutely the most important thing. One can do both. If you love what you build and you're leading a balanced life then I would say you're Doing It Right.

a) it makes me look a bit of a moron, because it implies they can't get their work done within office hours, and my job is to ensure that

b) they then expect that level of work regularly and will feel slighted if it stops being put in. See aforementioned comments about burnout.

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.

I reject the false dichotomy that my options are "work on the weekend when I'm excited to write code, or suffer and burn out during the week". Maybe that works for you, but I have to show up on Monday regardless of whether I wrote something inspired on Saturday.

> 2. Do you really need to worry about this hypothetical future? If the bad manager shows up, are you going to stick around even if working hours remain the same?

Weirdly, the bank expects monthly mortgage payments regardless of whether my manager is bad or not.

For what, exactly? If it is simply to appease the whims of your manager, you already have the bad manager. Another hypothetical future bad manager is the least of your concerns at that point. Chances are the hypothetical future bad manager will be less bad than the horror show you are already in.

> the bank expects monthly mortgage payments regardless of whether my manager is bad or not.

There is some risk there, but most tech people already price in that risk by demanding much higher than normal compensation at their job, allowing them to have their mortgages discharged before the bad manager arrives. You might get caught in the unlucky case, but on balance the good managers don't disappear that quickly.

It reads like the real problem was that the other developers fell into what developers seem to love more than anything: Pedantry. Instead of playing along with the false praise, they set out to prove the claim in the email wrong.

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.

I don't work more than 40 hours a week, but when I slack off I just do the work put in front of me. Rather than hours, it's about energy.

If companies want more than 40 hours a week, we can negotiate overtime. But I put extra energy in during the work week not because I think it makes me extra money or protects me from layoffs. I do it just because I think it is better.

I once had a coworker like that who hadn't taken a vacation in two years. I told him that vacation time was how the company funded his open source work, and suddenly he took his full five weeks off each year to recharge by coding different code.

There are more people involved in software creation than just you and your manager.

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.

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.

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.

You must work in one of those cults that stand around the meeting room to recite the commit log as if nobody in the place knows how to read, exclaiming "no blockers" to signify that the metaphorical torch is being passed on to the next person?

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?