> A company/product/feature is never going to live or die on that 30 hours of coding that you managed to squeeze into 48 hours.
Sort of.
Several 'death marches' over my career were in fact necessary for business reasons. Large penalties can exist in contracts when deadlines are not met. No one is going to reschedule CES, the Christmas shopping season, or the Superbowl for you because you were running behind. In some cases, missing a deadline throws off the schedule of hundreds or thousands of people in your organization who depend on your work. It's true that many times it doesn't matter, but many times it does absolutely matter. I'd like to think I got to where I am in my career because I'm willing to put in the effort to make those sorts of deadlines.
> My reasons for doing these marathon sessions was a lie.
My reason for doing it is because it's the job. I came into engineering with the expectation that it is an important job that often demands much of you but also affords you with a great deal of flexibility and self-determination. I get to take off time whenever I want and WFH whenever I want because I accept that there will be times when I absolutely cannot do whatever I want.
It depends on the specifics of your job as well. Some indie game dev can probably just delay their release a few days. Embedded devs are often on a schedule dictated by hardware schedules, production schedules, factory availability, shipping time, etc. etc. Just because the job is software doesn't mean it has to resemble any other software job.
> Large penalties can exist in contracts when deadlines are not met.
If you are cutting it so close that an extra few hours are the difference between delivering or not, _ the project has been a failure for quite a while _
Some things cannot be easily foreseen and you have to fight some fires. That's fine. But let's not normalize lack of planning.
I don't work in coding but as sysadmin. And the same stuff applies.
Projects with multimillion dollar outcomes are somehow managed by people who don't stoop to ask your team anything in the planning phase.
Instead they come in the implementation phase and want you to jump. Then you point out the resources required - in writing - and the fires are burning...
At that point, I may help or may not depending on whether they pay good overtime and it suits me.
> Several 'death marches' over my career were in fact necessary for business reasons. Large penalties can exist in contracts when deadlines are not met.
This is why management should be setting internal deadlines LONG before the actual deadlines. If they fail to do this, it's their fault, not yours (as the engineer).
If you play up to their illusions of success by telling them "it'll be fine, we can do it" (I've done this -- a lot) then of course they'll go along because you'll be the one to blame when the deadline isn't met.
Setting yourself up as the one to blame for promises outside of your control is a very, very bad thing to do.
> No one is going to reschedule CES, the Christmas shopping season, or the Superbowl for you because you were running behind.
This is WRONG. Of course they reschedule things for CES. If a product isn't ready in time for some event, the company WILL find a way to deal with it.
This is what took me a very long time to learn.
Nobody cares about CES. Not in the big scheme of things.
> I get to take off time whenever I want and WFH whenever I want because I accept that there will be times when I absolutely cannot do whatever I want.
Taking a couple weeks off is nothing. Tell me a story about how you take off a couple weeks every 3 months -- you don't. Because, in order to meet the "demand" you speak of, you're not actually going to use those times off.
There are something like 104 weekend days in the year. Now combine that with non-work hours there are in a year. Now add a standard amount of vacation days per year in tech companies (like 4-6 weeks?). That's how much time you're giving up by working nights and weekends.
> Embedded devs are often on a schedule dictated by hardware schedules, production schedules, factory availability, shipping time, etc. etc. Just because the job is software doesn't mean it has to resemble any other software job.
But it isn't the responsibility of the hardware developer to ensure timelines are appropriately padded.
The reality is, and this is especially true in hardware, non-software related delays happen all the time. It needs to be accounted for either way.
Sort of.
Several 'death marches' over my career were in fact necessary for business reasons. Large penalties can exist in contracts when deadlines are not met. No one is going to reschedule CES, the Christmas shopping season, or the Superbowl for you because you were running behind. In some cases, missing a deadline throws off the schedule of hundreds or thousands of people in your organization who depend on your work. It's true that many times it doesn't matter, but many times it does absolutely matter. I'd like to think I got to where I am in my career because I'm willing to put in the effort to make those sorts of deadlines.
> My reasons for doing these marathon sessions was a lie.
My reason for doing it is because it's the job. I came into engineering with the expectation that it is an important job that often demands much of you but also affords you with a great deal of flexibility and self-determination. I get to take off time whenever I want and WFH whenever I want because I accept that there will be times when I absolutely cannot do whatever I want.
It depends on the specifics of your job as well. Some indie game dev can probably just delay their release a few days. Embedded devs are often on a schedule dictated by hardware schedules, production schedules, factory availability, shipping time, etc. etc. Just because the job is software doesn't mean it has to resemble any other software job.