> 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 i

> 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.