Any job can be stressful, including software engineering. But what is stress exactly, and is it bad?

Stress is just the body’s response to a new or challenging situation. Doesn’t sound too bad. Normal and healthy. But how do you know when you are too stressed?

In software engineering, we face new and challenging situations on a daily, or at a minimum, weekly basis. There is always some library, framework or class developed by a co-worker that we have to grok. And sometimes it’s not so easy to understand a whole new paradigm, programming language or even just a quirk of a language that you thought you knew well.

If you add to this the need to learn a topic and an impending deadline together, you are most definitely going to feel stressed. And the longer you take to understand the topic, the closer the deadline gets and the more stressed you will feel.

And the above doesn’t even consider imposter syndrome, unreasonable deadlines, scope creep, pull requests, NPM audits, broken pipelines, and mass redundancies (read. twitter).

But don’t worry. You’re following the agile manifesto, and your team has this in the bag. Right?

As an aside, I googled an image for this article. I only used the word stressed, and the first result was the above image with a person stressed out over a laptop. If this isn't indicative of professional jobs being stressful, I don't know what it is.

All of the above points are real issues that need to be addressed in a professional workplace that develops software.

How can software engineers reduce stress?

There are several things that you can do to make software engineering less stressful. The most important is to do whatever you can to remain healthy.

Here is a list of practical ways that can help to manage stress as a software engineer:

• Moving – sitting down for long hours is not suitable for anyone, and software engineers spend a lot of time pouring over a keyboard trying to get the job done. The evidence has been clear for a long time now, if you don’t move enough, then your health will suffer. Just look at the Harvard Medical School post on the subject
• Diet – a well-balanced diet is also key for managing or reducing stress. The less junk food and alcohol you consume, the better your body will feel, and the mind will follow
• Sleep – Sleep decreases cortisol levels (cortisol is known as the stress hormone), aiming for between 7-9 hours is the goal each night. As a bonus, adequate sleep can help boost your immune system
• Reduce caffeine – too much caffeine can raise your cortisol levels, so the amount you intake per day should be low enough not to cause issues

Specific ways for Software Engineering to be less stressful

Software engineers trying to reduce stress, specifically from their workplace, need to find preventative ways not to introduce it in the first place or to be able to step away from excessively stressful tasks.

The only way to manage your workload efficiently and practically is to list all your activities to see if you have the time to complete everything.

Without adequately planning your workload, you are going to be stressed. Planning is essential in reducing a software engineer.

Set expectations upfront

The earlier you let your company understand what they can expect of you, the better. Everyone has lives, and not everyone lives for work, although some do.

When your company asks above and beyond what you’ve agreed to, you are presented with an opportunity.

If you agree to do the work, you can address your previous agreement so that your manager understands that this is not the expected norm but a nice thing you’re doing to help out.

If you don’t want to do the work (you don’t need a reason if you’ve already discussed your company’s expectations of you), you should be confident to say no. If necessary, you can draw on your previous discussions.

What does an average day look like for a software engineer?

Meetings, coding, pull requests, learning & researching. That about sums up most days for a software engineer.

For meetings, we can easily allocate time on our calendar for these.

For pull requests, it’s a little bit more difficult. I try and spend the start of each day, while I’m fresh and awake, doing code reviews and the rest of the day working on my tickets. This way, I can allocate a set amount of time to the pull requests, which helps out the team, and the rest of my time is divided between meetings and coding.

Even with planned time for pull requests, you are still going to have to spend more time outside of the allotted block to review urgent requests or even updated requests that you may have marked as needing more work earlier on.

Taking into account meetings and pull requests, you can start to get a better picture of the amount of time you have available to get tickets completed. With this knowledge, you can start assigning work for any given sprint more accurately.

Planning for the (un)expected

Software development tickets can be very hard to estimate. If you are tasked with working on a new area of the code base or anything green field, you really can only give a ballpark estimate. And this estimate can easily be days away from what you might have originally thought.

To this end, you must add bloat to almost all your ticket estimates. Engineers often overlook the time it takes to do the required documentation for the work they complete. Whether that is addressing comments in Jira or even just writing an accurate pull request description, these things can take a lot of time, especially for any complex ticket.

Without this bloat in your ticket estimates, getting an accurate goal for your sprint will be very difficult. The more sprints you do where you don’t meet the planned workload, the worse you will probably feel, and that could be avoided with more careful planning.

You don’t want to look at burndown charts that don’t burn down. And you don’t want management to look at burndown charts that don’t burn down. If the reporting on work completed isn’t taking into account the whole picture of your workload, then it isn’t worthwhile.

What if your workplace is creating unnecessary stress?

Sometimes your workplace may be the root of your stress. It’s important to try and do what you can to manage your workload and stress, but sometimes it may not be achievable.

If you feel you have tried to help the business work better as a group in reducing stress and being more effective, then it’s completely acceptable to move on to a new venture where this isn’t the case.

Conclusion

Making software engineering less stressful is all about planning. If you can plan effectively and set up a manageable system, you will find the job much less stressful. Set upfront expectations and stand your ground if these expectations are not met.

Without appropriate planning, you are asking for trouble, regardless of how responsible a worker you might be. Reports of your efforts won’t include your intentions, just the work completed with no context.

If your company is putting too much work on your schedule and they refuse to relent, you can either look for other opportunities, try and help change the culture or seek outside advice.

Don’t forget to check out my other articles here which contains links to common concepts and examples in React.

Also, you can follow me on Twitter/X here! And now, mastodon: @bernieslearnings@mastodon.social