4 ms·

The bit about working weekends and evenings was especially annoying to me. What people who do that don't realize is that pulling late nights and weekends for a

The bit about working weekends and evenings was especially annoying to me. What people who do that don't realize is that pulling late nights and weekends for a deadline more often than not just validates badly planned deadlines that were never going to work out. It's a vicious cycle: if you sacrifice your personal life to hit a deadline, then the people in charge of setting deadlines get a false idea of what "normal" is and you'll end up doing the same thing next time. It's not that there's never a valid case for working after hours (like, say, a dedicated on call rotation), but I'm pretty firmly opposed to doing so to meet a deadline. It's unfair to yourself and your co-workers to teach product/management/whoever that work can be planned out on the assumption that your team will pull late nights to make it happen on an arbitrary schedule.

WWLink 3y ago
Easy. This dude is probably a business owner trying to neg their programmers into thinking that they're easily replaced cogs in a machine that should give their job priority over their life.
dopylitty 3y ago
A dedicated on call rotation also isn't a valid case for working after hours. If companies want their infrastructure worked on 24/7 they need to hire 3 shifts to take care of it. If they don't want to pay for 3 shifts they should shut their business down after hours like a normal business, not exploit people by making them work 24/7.
- Aurornis 3y ago
  If you don’t like on call rotations then you shouldn’t be working on services that come with on call responsibilities. However, suggesting that every Internet business needs to shut down after hours is one of the more out of touch things I’ve read in this comment section. > not exploit people by making them work 24/7. That’s not what on call rotation means. You shouldn’t be “working 24/7”. On call should be a rare event.
mjr00 3y ago
Part of being senior is having enough business context to know when to pull late nights and weekends. If you're doing it because the gantt chart some PM created 18 months ago said project X would be done by next month but everything is off the rails, yes, it's foolish and unfair to work nights and weekends to make it happen. If you're doing it because re:Invent is in a month and your team has a new AWS service to announce, that's a much better reason. Or in the startup world, if there's a major client demo next week and you're quickly hacking in a new feature they've been asking for.
- simonbarker87 3y ago
  Maybe but then you are reinforcing bad planning and behaviour from management. Far better to reduce the scope or content so you don’t hit that deadline totally spent.
- lolinder 3y ago
  I agree that sometimes you need to do it in order to not totally screw up the business, but I think any case where you make that decision should require a postmortem where everyone involved in that deadline gets together and figures out why it couldn't happen during the team's regularly scheduled hours. If you do it quietly without making it very clear to the business that this was abnormal and should not happen again, then you're still feeding the false idea that it's okay to plan around late nights and long hours. An early stage startup is a possible exception as long as your entire team is on board with it and getting a satisfactory amount of equity compensation. But the entire team has to be on board with working extra hours, it can't just be you deciding that for the team.
- from-nibly 3y ago
  As your project manager I now know I just have to come up with a "good reason".
  - OmarShehata 3y ago
    The good news for everyone is, you can't just make up a good reason out of thin air! (unless you're lying). There's either a critical business need, or there isn't. This of course requires this senior engineer to be business-savvy enough to discern when there's a legitimate business reason given, and at big companies that may require knowledge of politics among the higher ups which may be opaque to most folks.
quatrefoil 3y ago
I don't think it's really about "the people in charge of deadlines". When you, as a senior engineer on the team, work crazy hours, all the junior folks on your team who look up to you (even simply because they also want a fancy job title down the line) copy that behavior. And then it becomes the new normal.
aaomidi 3y ago
Also when a senior engineer does this, it sets expectations for junior engineers. A senior engineer who does this is harming their team more than most other technical related things.
joshspankit 3y ago
> just validates badly planned deadlines I’ve spread this message far and wide across dozens (hundreds?) of industries. I’m sure we know but I think it’s helpful to be explicit: the mindset at the heart of this is not specific to software and can be found at pretty much every management level and it’s hurting everything. At “best” you have an endless stream of overworked employees who burn out and get replaced when they stop being able to “keep up” but even then the business has no idea what things actually cost. They can’t do budgeting, they can’t do calculations, every report based on employee productivity is wrong. Working beyond your means sets the company up for long-term failure.

WWLink 3y ago

Easy. This dude is probably a business owner trying to neg their programmers into thinking that they're easily replaced cogs in a machine that should give their job priority over their life.

dopylitty 3y ago

A dedicated on call rotation also isn't a valid case for working after hours. If companies want their infrastructure worked on 24/7 they need to hire 3 shifts to take care of it. If they don't want to pay for 3 shifts they should shut their business down after hours like a normal business, not exploit people by making them work 24/7.

Aurornis 3y ago
If you don’t like on call rotations then you shouldn’t be working on services that come with on call responsibilities. However, suggesting that every Internet business needs to shut down after hours is one of the more out of touch things I’ve read in this comment section. > not exploit people by making them work 24/7. That’s not what on call rotation means. You shouldn’t be “working 24/7”. On call should be a rare event.

mjr00 3y ago

Part of being senior is having enough business context to know when to pull late nights and weekends. If you're doing it because the gantt chart some PM created 18 months ago said project X would be done by next month but everything is off the rails, yes, it's foolish and unfair to work nights and weekends to make it happen. If you're doing it because re:Invent is in a month and your team has a new AWS service to announce, that's a much better reason. Or in the startup world, if there's a major client demo next week and you're quickly hacking in a new feature they've been asking for.

simonbarker87 3y ago
Maybe but then you are reinforcing bad planning and behaviour from management. Far better to reduce the scope or content so you don’t hit that deadline totally spent.
lolinder 3y ago
I agree that sometimes you need to do it in order to not totally screw up the business, but I think any case where you make that decision should require a postmortem where everyone involved in that deadline gets together and figures out why it couldn't happen during the team's regularly scheduled hours. If you do it quietly without making it very clear to the business that this was abnormal and should not happen again, then you're still feeding the false idea that it's okay to plan around late nights and long hours. An early stage startup is a possible exception as long as your entire team is on board with it and getting a satisfactory amount of equity compensation. But the entire team has to be on board with working extra hours, it can't just be you deciding that for the team.
from-nibly 3y ago
As your project manager I now know I just have to come up with a "good reason".
- OmarShehata 3y ago
  The good news for everyone is, you can't just make up a good reason out of thin air! (unless you're lying). There's either a critical business need, or there isn't. This of course requires this senior engineer to be business-savvy enough to discern when there's a legitimate business reason given, and at big companies that may require knowledge of politics among the higher ups which may be opaque to most folks.

quatrefoil 3y ago

I don't think it's really about "the people in charge of deadlines". When you, as a senior engineer on the team, work crazy hours, all the junior folks on your team who look up to you (even simply because they also want a fancy job title down the line) copy that behavior. And then it becomes the new normal.

aaomidi 3y ago

Also when a senior engineer does this, it sets expectations for junior engineers. A senior engineer who does this is harming their team more than most other technical related things.

joshspankit 3y ago

> just validates badly planned deadlines I’ve spread this message far and wide across dozens (hundreds?) of industries. I’m sure we know but I think it’s helpful to be explicit: the mindset at the heart of this is not specific to software and can be found at pretty much every management level and it’s hurting everything. At “best” you have an endless stream of overworked employees who burn out and get replaced when they stop being able to “keep up” but even then the business has no idea what things actually cost. They can’t do budgeting, they can’t do calculations, every report based on employee productivity is wrong. Working beyond your means sets the company up for long-term failure.