[lijok]

Working continuous overtime is one of the worst diseases you can inflict upon your company.

1. By making changes outside of work hours (comitting code as a software dev), you're upsetting your teammates understanding of the state of the project. Ever had on-call push a 200+ LOC change after hours to hot-fix a bug, then had to have a two hour meeting next morning to figure out what changed and how to re-do the fix properly? When you make changes outside of hours, you put your teammates into that position every time.

2. You upset your teams and your companies understanding of their capacity. Because you are not beholdent to work overtime by the contract, if you decide to take a break from overtime for whatever reason, projects will start slipping with no perceptible root-cause. This is a really bad spot to put your team into.

3. You're likely to become the "rockstar". This isn't necessarily a bad thing, but can be damaging to companies that do not now how to work with them - see https://neilonsoftware.com/difficult-people-on-software-proj....

4. You will eventually start burning out, there's no question about it. Burn out doesn't affect just you, it affects the company. Once you start burning out, all sorts of interpersonal and quality problems will develop that will jeapordize a (hopefully) otherwise healthy team.

5. You will ocassionally ping your teammates outside of work hours, some of whom, due to various reasons, will feel a need to respond, or "hop on for a quick check". Yes, the teammates are in control of their actions, no, that does not excuse you from regularly pinging them outside of work hours. This is especially nefarious if there is a power imbalance, such as a more senior engineer (or a rockstar) pinging a more junior engineer.

If you're finding that you need to continuously work overtime to meet deadlines, speak with your manager, this is a problem for them to solve, not you.

[2devnull]

I disagree with some of this. I think if you work with international teams, half of the time of day stuff is in play no matter what. But in general I sort of agree that we should all try to work slower/work fewer hours, for the good of society. But we shouldn’t harass those who have more time and interest in the work they’re doing and want to work more, or those who might need more breaks or work most optimally at a slower pace. We should care about workers collectively and individually, I think.

[from-nibly]

We shouldn't.harras people. But working extra is working to build a machine that HAS to be worked extra. You are solidifying the fact that work CAN'T get done in the normal hours. And then when the company goes to replace that person they will have to pay extra to get the same thing.

Even if you forget the workers. It's not good for the company.

If you want to be selfish, no judgement, sometimes you gotta do that, but don't be confused about the fact that externally it does harm.

[lijok]

Fully agree.

If you have international teams, they shouldn't be working on the same project, if it can be avoided. Having teams with different working hours work the same project sabotages communications.

[certifiablysane]

I have to disagree vigorously based on my current experience. My team, working on a single project/product, is globally distributed. There are team members in APAC (New Zealand), Europe, and America, and (IMO) we do very well at communicating and producing solid results.

It does take specific effort, mainly expressed in written communications in tickets/issues and other more ephemeral channels (Slack in our case). You have to think carefully about what information must be shared and how to do so. You can't just drop a random comment and hope for a good interpretation. There needs to be a "call to action": a question, a request for specific activity/response, or a suggestion (or several) for possible next steps. There also needs to be trust built between team members, which takes time and similar effort.

But when this is unlocked to its fullest potential it becomes an absolute super-power. The problem you were facing when you finished the day? Fixed by your team-mates when you start the next day, some more progress (hopefully), and they hand back the next problem to solve. Apparent velocity goes through the roof and personally I find it incredibly satisfying.

Mind you, this is all coming from an all remote/all async company. I can potentially see problems if you had two part-teams in separate time-zone separated offices with minimal overlap. Then you'd potentially run into the usual human tribalism and culture drift, and communications aren't necessarily going to solve that.

[ghaff]

At large companies, it's unavoidable to a certain degree. In my case, it's mostly East Coast to Europe though which is pretty manageable. Asia to US is definitely tough. You're either going to have people on late-night calls or getting up in the middle of the night. It works for the odd sync but is tough on a regular basis.

[jjav]

> Having teams with different working hours work the same project sabotages communications.

Not really, but you have to become good at written communication. Which has a lot of benefits beyond the immediate one.

In companies where everything happens by people huddling together real-time, the result is (nearly always) that nothing is documented, which leads to disaster longer term.

I've loved working on projects where the team is globally distributed so that there is activity 24hrs and you work with people with zero overlap on working hours.

Instead of relying on ephemeral hallway conversations, you need to build a culture of updating tickets with informative content, documenting plans, and so on. This fill the immediate need of daily communication but more importantly now you have everything documented and a paper trail of every decision and bug fix which is incredibly valuable.

[pavel_lishin]

> But we shouldn’t harass those who have more time and interest in the work they’re doing and want to work more

I mean, sure, we shouldn't harass anyone.

But if they're working 12 hour days, and pinging me on Slack at 7pm, they're the ones harassing me. If they're producing 5 times the lines of code that I am because they're workaholics, thus causing me to spend half my day playing catch-up to their unreasonable schedule, that's also not great.

[ipnon]

In my experience having a “rockstar” or hero programmer on your team is the surest indication of a management failure, either in velocity, priority, or hiring.

[em-bee]

i don't see how #1 is relevant. if you have code reviews, the problem simply goes away. if my work day ends at 6pm and you check in a change at 17:50, it is really better than had you made that check-in two hours later. i'll see it in the morning and deal with it as usual.

that on-call hotfix is a completely different problem that has nothing to do with people working overtime.