In many large software companies, code freeze season starts around late November. If you’re not familiar with code freezes, they are a period of time when newly committed code will not be released on a regular deployment schedule. So if you work on a mobile app that is updated weekly, no new updates will be deployed for those 4 weeks. New server versions will not be deployed on the backend, etc. Only critical hotfixes will be deployed.

Often they last about 4-6 weeks starting mid-November in US companies because the vast majority of staff at many of these companies take a lot of time off during this time and/or very critical high load situations happen, such as black friday sales or new years eve parties. It’s not a good idea to do updates during such critical moments or periods of low staffing, because you can create large money hemorrhaging outages while a lot of staff are on vacation.

Because the typical update cycle is being paused, there is also typically a last-minute rush to land your commit before the cutoff time. This can create a lot of stress for people, as they try to baby their change through a submit queue or similar under its highest load point of the year. Even worse, in an international company, you have people staying up until 3 am or 24hrs trying to desperately get their commit in before that code freeze cutoff time, set for an SF friendly time zone. The parallels to cramming for an exam all night long in college are very apt.

Something I’ve noticed about this last-minute rush is the people who tend to do it most are junior engineers. This suggests to me they haven’t learned how to create boundaries as a developer yet. Succumbing to implied pressure from your external managers and stakeholders and trying to be the hero that “gets it done” at the last minute for an artificial deadline.

I have a message for these junior engineers, you need to say no to your stakeholders and create boundaries. The vast majority of the time, it’s ok to go to bed and not make those deadlines. It’s ok if your feature ships out 4 to 6 weeks later with higher quality or to cut scope to make a deadline. Often when you assert your boundaries as an employee, you’ll be surprised about how it’s not a big deal more often than not, and your manager is a nice human being too.

If something is really important, your manager should have planned slack in their timelines to give space for hard code freezes, because it’s actually very important for the new feature to get done by a specific time. By being the hero, you are enabling your manager’s bad planning and resourcing skills and creating a potential burnout situation for yourself. On top of that, if your manager is unaware of your hero behavior, they are not even getting feedback that they planned badly.

If something is really important, management will give the appropriate amount of resources and time to get it done properly and set aside the less important things. If your management is not doing this, they are showing with their actions that it isn’t as important to them as you might think.

Also, by doing things in a last-minute manner like this, you are potentially creating even more total work for yourself. Code deployed last minute and sleep-deprived has a higher chance to be an outage and bug creator. If your reason for rushing for a code deadline is completely personal, because you just want your thing to be over with so you don’t have to think about it, or you were procrastinating and not working, it’s still not worth it to push for a last-minute low-quality commit. You’ll potentially make more work for yourself and everyone else you work with.

Your career is a long hike, not a sprint. Sprints make sense when you’re trying to outrun a bear / outage, but if you sprint 24/7 you’re going to get injured and go slower overall, with a lot more pain.

Advice about not deploying on a Friday or the start of a long weekend is a smaller version of the above advice. Avoiding working for companies that have long periods of crunch is another version of the above too.

Ok, how do I do that?

Added: Dec, 29, 2021

When I asked for feedback on this article initially, the most common thing added on was how to set these boundaries? You do this via multiple strategies.

The first step is to realize that you’re on a team, working together with your manager. Managers are human, and probably want to see the best for you and themselves. That means if there are issues or worries you have, you should probably communicate those in a constructive, positive way. Developing a good relationship with your team is very key.

Some jr engineers create stories or worries in their head about things they think are going to happen if they say no in some way, like “I don’t think we can make this in time” or worried they will miss out on some implied bonus if they don’t do it in time, without the manager even thinking about that at all. Often the first step is to just communicate your issue to your human manager, and make the implied concrete and find out if your manager even thought of those vaguely implied deadlines at all. You’ll often be surprised how much of a non-issue it is.

Real vs artificial deadlines

Also as part of this communication process, you should figure out how important the deadline is. If you slip the deadline, what would happen? Is this a real or artificial deadline?

• Real Deadlines
  • You do not fix an outage.
    • This bug is costing everyone a lot of money.
  • Some large $$$ contract goes away.
  • The company loses a bunch of money because the feature wasn’t live during a critical period, such as a holiday shopping season.
  • Do you hold up a bunch of people depending on your work to be done at a certain time?
  • Bad lawsuit stuff happens because of missed deadlines.
  • The startup will run out of money soon and getting the feature done is critical for more funding.
  • Or the public company equivalent: Your project not shipping by the end of the quarter might materially affect the stock price and everyone’s implicit compensation.
  • People are hurt or die if you miss your deadline.
  • I’m not going to get promoted. (Find out if this is actually real BTW via communicating)
• Artificial Deadlines
  • Nothing much happens at all. Everyone is on vacation anyway and they would barely notice.
  • Some internal OKR wouldn’t be closed out by the end of a quarter and instead would close out a few weeks later.
  • Some people are disappointed.

Key to figuring out how important a deadline is how real it is.

Negotiating an alternative

Next up is to work with your stakeholders and to figure out together how you could meet the deadline in an alternative way:

• “I can’t get it done by that time, but I could get this reduced scope version out by that time probably.”
• “I think I could achieve it, but I would need extra help to achieve it by that time.”
• “We might be able to do it by then, but it will involve spending a lot of money for quicker solution X.”
• (After digging into what they really want) “So as I understand, what you want to achieve is X. I have this idea of doing it in this more minimal way vs the original design that we could reach by the deadline, do you think that would work?” Thinking of a new solution that cleverly makes everyone happy would probably impress your stakeholders too.
• “I really would like to achieve that thing by time X, but if I do, I would have to delay or cancel other projects, like Y. What would you like me to prioritize more?”

And when you get external requests:

• “I understand that fixing bug X is important to you, and we are working on it, but we can’t give you any explicit deadlines.”
• “We can’t prioritize this bug right now, because we are really overloaded with our current workload. I totally get why this is super sucky right now, and I acknowledge it, but this other situation is more important that we are working hard on. We will get to your issue once we are done this higher priority thing.”

Often people work with you well if they understand the entire context of things, and understand how things are going. Sometimes your stakeholders, like your manager or bug reporters, are far more understanding when they are aware of how much work something is, your other priorities, and showing that you care and understand their issue. When people do not understand your full context, they can assume that you are basically free to do their thing. Communicating how things are going really helps everyone figure out what is going on.

Also key to the above negotiation strategies is to bring the costs of actions upfront. People often try to get as much ‘free’ stuff as they can, and by revealing the prices of actions, they are significantly more discerning in what they choose. Often people ask for things without realizing the cost of such actions, and part of negotiations is making them realize what those costs are.

I tried all of the above, and it didn’t work

If you’ve communicated the situation, understood if the deadline is real or not, made the implied concrete, and tried negotiating with your stakeholders about what can be done and still haven’t solved your issue, then it’s time to make a decision depending on the situation.

They pushed for the bullshit artificial deadline

One example is your manager has gotten the full info, and despite all of the above, decided to ask you to rush to meet an artificial deadline anyway. You can decide to directly tell your manager no in this situation, or realizing that would probably not go anywhere, because your very polite and indirect ‘no’ was basically ignored, go ahead and work hard for the artificial deadline. You could also decide to work reasonable hours and just not make the deadline. It is up to you and your read of your current situation.

When your manager ignores your honest attempt to figure out something reasonable, this is a good indication you should probably change teams. If you decide to work hard for the deadline so you can transfer easily, that is probably the smart thing to do in some situations. Sometimes companies have a culture of working hard for artificial deadlines, like many gaming companies with their infamous ‘crunch’ and you will have to change companies or even industries. What to do from then on would be up to you.

A lot of real deadline emergencies happen frequently

A less malicious version of the above is your team running into real emergencies at a very high rate. This is more of a meta-issue of your team situation, and you should work with your manager in reducing the incidence rate of these emergencies. You could do that by hiring more people onto the team to deal with the workload, getting space to reduce the emergency rate instead of working on new things, changing the planning process to give the proper amount of time for projects. Your manager is probably stressed out too and would appreciate you being proactive in fixing issues. Leaving the team as a ‘vote’ to show that the team’s problems need attention via a high attrition rate is another option if the above doesn’t work.

A high emergency rate is usually something you can fix, and you shouldn’t give managers too much slack if it happens too often, especially if you communicated it. It might even be your fault if your estimations are too tight.

I procrastinated and it’s mostly my fault TBH

In this case, you should probably work to meet the deadline if it’s a real one and figure out why you procrastinated later on. Maybe you don’t like the work anymore, maybe you’re really smart and have ADHD, so you were never diagnosed because you were able to do well enough in life. Maybe remote work or working in an open office plan really hurts your productivity.

Also please consider if your overall code quality will suffer if you push through, you might make more work for everyone if you don’t do it right.

It’s actually a real deadline and it doesn’t happen that often / it’s a startup

Then it would be up to you to work extra hard to meet the deadline or not. Also working in startups often means your working more than usual, in exchange for potentially outsized rewards, but that is a different story. If you’re in a startup, make sure it’s possible to get an outsized reward. If it’s not, you should probably go somewhere where it is.

Preventing issues from happening in the first place

Another key part of not working crazy hours for a deadline is preventing these situations in the first place. This is the fine art of estimating and planning, and you should be proactive in this process to make sure deadlines are not set too tightly and you have enough slack. A more meta way of preventing these situations is not being in them in the first place, so choosing the right company, team, culture, and projects is often key.

Also while you’re in the middle of projects, be aware of hard cut-offs like code freezes, and while you’re doing your project, see if it will become an issue in the future. Seeing problems on the horizon and preventing them is often a lot less work than fixing them last minute, and your manager will be able to work with you in fixing them far more easily. Also, managers like it when you do part of their job for them like that and keep them up to date on potential roadblocks and fixing them before they become stressful emergencies.