4 ms·

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 sof

by lijok 3y ago

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-projects/developers/the-rockstar 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.

ipnon 3y ago
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.
2devnull 3y ago
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.
- lijok 3y ago
  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.
  - ghaff 3y ago
    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.
  - certifiablysane 3y ago
    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.
  - jjav 3y ago
    > 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.
em-bee 3y ago
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.

by lijok 3y ago

ipnon 3y ago

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.

2devnull 3y ago

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.

lijok 3y ago
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.
- ghaff 3y ago
  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.
- certifiablysane 3y ago
  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.
- jjav 3y ago
  > 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.

em-bee 3y ago

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.