PeterMilovcikSoftware development can sometimes be quite stressful.
As a software developer with twelve years of experience, I've managed to reduce this stress to a productive minimum. Stress has a high impact on health. Therefore it is crucial to have it under control.
I've put my insights together, and here are my stress reduction learnings and recommendations.
How does stress look like?
Source: https://media1.tenor.com/images/1f28506bc57faea4c2a5c6044f4ed8f9/tenor.gif?itemid=4423168
or like this:
Source: https://media0.giphy.com/media/VuqeWMAga2Iw0/source.gif
How stress DOESN'T look like?
Source: https://media.giphy.com/media/zyclIRxMwlY40/200.gif
or like this:
Source: https://thumbs.gfycat.com/BigheartedEveryAsiansmallclawedotter-size_restricted.gif
Source of Stress
There are many sources of stress: information overload, too much to do, deadlines, multi-tasking, overtimes, bugs, unknown, and so on.
But, there is one excellent reason not to stress. And it is HEALTH. Stress has a significant impact on our health. If you are young, you might not realize that so much, but once you are getting more experienced and maybe you've got some gray hair (like me), you may see that stress can cause quite some health issues.
How to develop software with less stress
Disclaimer
This blog post contains tips, tricks, and techniques based on my own experience, and not all of it may work in your situation.
No Silver Bullet
As with many things, there is no silver bullet, no single solution for reducing the stress level. Keep this in mind when you would like to reduce your stress. Therefore, here in this blog post, there are many tips which, when combined, could positively impact your stress level.
Work
There are three types of work:
- Planned work
- Unplanned work
- Planning work
Planning work should be on this list in the first place since usually, it happens as the first step.
Unplanned work is some unexpected work, something unknown which we didn't count with. This type of work is very harmful. It's quite destructive to the project, but also your stress level.
So it turns out that from a stress point of view, planning work is fine, planned work is also fine, and the real problem is hidden in unplanned work.
Unplanned Work
What is unplanned work?
Unplanned work is a silent killer. You might not even realize that it is something negative: It's just something that we didn't expect. We didn't know about this thing. Why would it be something negative?
The problem is that it affects what is planned, and that's the source of a lot of negativity. Let's read about it down below.
Unplanned work is time theft. It steals time from planned work, which very often leads to time pressure stress.
Its source is the unknown, work interruptions, failed changes, emergencies, bugs, low quality, etc.
How to deal with unplanned work?
It's essential to realize that unplanned work is negative. There is nothing good about it. One might even say that it's pure evil.
So, the first step is to say "NO!" to unplanned work.
Source: https://media1.giphy.com/media/xq42Y1CBoniLK/source.gif
Is it possible to have no unplanned work at all? Of course not! But it's important to try to minimize it as much as possible. If we succeed, the stress level reduces dramatically.
Improve Planning
Easier said than done, but here is an idea to think about when you will participate in the next planning session.
There are two important phenomena:
- Dependent events
- Statistical fluctuations
Dependent events are a series of events that must take place before another event begins.
Statistical fluctuations mean that the length of events and outcomes are not entirely deterministic.
Each of these alone is not a big deal. It's the combination of these two phenomena that are the issue.
You can see it in this picture:
Source: https://i.pinimg.com/originals/73/99/64/739964599e6777e23673b45361fe1b02.gif
Shorter Feedback Loops
Shorter feedback loops can help significantly to reduce unplanned work.
What does it have to do with less stressful development? Let's look at a long feedback loop to understand it.
Let's say that you did a change in code, and you have to wait a long time for feedback to know if this change was good or bad. Even this waiting when you are unsure if you did a good job might be stressful, but if this change was wrong, it's even worse. It's usually harder to find a problem and even harder to fix a problem. This increases the stress level.
On the other hand, if you have a shorter feedback loop, the wait time is shorter, so you know sooner if you did a good job or not. It's much easier to find a mistake and fix it. Compared to the long feedback loop, the stress level is much lower.
Let's imagine that there would be some development practice that would enable very short feedback loops; let's call them micro feedback loops. So short, that it would be an integral part of software development, and wait time would be almost unnoticeable. Compared to the long feedback loop, the stress level would also be virtually unnoticeable, and that's a good thing.
Good news! There is a development practice that enables such micro feedback loops. More about it a little bit later.
Bugs
Let's take a look at bugs - you know, these mysterious creatures which crawl at night into our code to bite you and users of your software.
Sometimes they are called defects. I like how J.B. Rainsberger talks about it. He states that these bugs should be called by real name, which is "mistakes". Mistakes are made by real people, not by some mysterious creatures. We, as software developers, must take responsibility for our mistakes in code.
If we take a look at mistakes when we discuss unplanned work, mistakes create unplanned work of type rework. You thought that what you did is done - it's complete, but it's is not. You have to make some additional changes to fix the mistake.
Mistakes
Why we make mistakes? There are more reasons, and one of them is stress. The problem is that when we are stressed, we tend to make more mistakes, and when we make mistakes, we are more stressed. This situation can spiral very quickly, and fixing it is pretty tricky. It's only logical that we should focus more on preventing this from happening.
What does it have to do with short feedback loops?
If we have a short feedback loop, we find mistakes sooner, and it is usually much more comfortable to fix them. That leads to less stress. Less stress means fewer mistakes.
Opportunities to Learn
But, there is another layer. Those mistakes are, in fact, opportunities. Opportunities to learn - about your code, about the way how you write your code, how you think. The code is trying to tell you something. It's not very obvious. You must listen to your code carefully to understand it. Why is this mistake there? What is the reason behind it?
It's such a pity that this huge learning opportunity is so often unnoticed.
If you have a long feedback loop, you have a single opportunity to learn, and even this one is not often taken. On the other hand, if you have many short feedback loops, you have many opportunities to learn. Take them and learn as often as possible.
How to Achieve Short Feedback Loop
Many developers still tend to write production code first and then do the testing. I've heard that there are still some developers who do the manual testing of their features, which they just write. They run the application, wait, and then click here and there to test functionality. They maybe attach a debugger or traces to see if code goes where it suppose to go, that variables have expected values, and so on.
The problem with this sequence "code first, then testing" is even if you try to write automated tests. It's often much harder to write automated tests if you wrote production code first. It's even harder if you tend to write a large amount of production code first and then automate testing.
What developers usually tend to do if they find writing automated tests difficult? They blame automated testing. They feel incompetent or damnatory.
Come on! It's 2020! We can do better!
It's much better to write an automated test first and then write production code. There are so many benefits, and if we want to talk about stress, the main advantage here is that it shortens the feedback loop. Therefore we can find and fix our mistakes sooner, which leads to less stress.
Another benefit is that we can hear better what the code is trying to tell us. It's trying to reveal something to us, something hidden if we didn't pay enough attention. We can see this opportunity much easier if we write our tests first and then the production code.
There is another great opportunity with this sequence: to take a step back and think about our code. How good is it? How well organized is it? Does it tell its intend clearly?
If we cook in a kitchen, we might make some mess. If we didn't clean the kitchen after every cooking, the kitchen would be very messy.
The same applies to code as well. It's much easier to clean up a little mess than to do "big bang" refactoring. So let's incorporate this little cleanup routine into our feedback loop sequence: "test -> code -> refactor" and repeat. Of course, it's the test-driven development (TDD).
One of the main benefits of TDD is that it reduces stress. And let me be clear about it. It does not just help to reduce stress dramatically, but it also feels great to do TDD. You got feedback that you did a good job with every passed test, and if you have a failed test, it's easy to have it passed quickly and to do refactoring with confidence.
Better Work Organization
Once you get more experienced and move from a junior position, you might notice that you have more working streams going on. You could drive team goals, participate more in planning sessions, maybe you become a mentor or coach for other new members of your team or other relevant topics that are not part of a product backlog. Sometimes it might be challenging to decide what you should focus on first. It seems that everything has the highest priority.
Too Much To Do
If you have too much to do, you don't know what to do first, and everything seems to be urgent and important, be aware that this might be an enormous source of stress.
People tend to solve this problem by doing many things at once - to do multi-tasking. The issue with multi-tasking is that you have to do context switching. It wouldn't be such a big deal if context switching wouldn't cause mistakes. The more you switch the context, the more mistakes you tend to do. And the more mistakes you do, the more stress it produces. The more stressed you are, the more mistakes you make.
Remember the severe mistake <-> stress spiral.
Time Management
Imagine that you wake up in the morning and come to work to start working on your task. You've planned to focus on this task, and after a few hours, you get a well-deserved break.
The reality is often different. After some time you might get interrupted by somebody, your colleague asks you what do you think about the latest political situation, or what's your opinion about the latest Star Wars movie, or if you know about the broken build.
Let me be clear here, it's okay to talk about these things with your colleagues, but it's not okay if these interruptions cause your stress level goes up. If it happens occasionally, it's okay. The problem is when these kinds of interruptions happen too often.
You've got back to your task and try to concentrate as soon as possible. Still, you might be interrupted again by some important/urgent email. Notification dialog pops up, calling for your attention, and your stress level goes again a little bit higher.
You've got back to your task again. Still, after a while, there are other interruptions: stand-up meeting, product owner asks you about a quick rough estimate, a remote colleague calls you to discuss an important topic, junior colleague needs your help to solve some issue, a team meeting to discuss open points about some future work, etc. You see the pattern.
Time goes by, and it's lunch. Let's finish your meal quickly. The task is waiting for you! So, hurry up. Finally, you got some time to focus, but only until another round of interruptions starts again.
It's at 5 pm. You feel wasted, but the task is not finished yet, so you decide to stay longer. The next day it's the same, and the day after.
Interruptions Management
It's hard to manage time. You can't have more of it. You can't stretch it. So, what to do instead? Manage interruptions! But how?
Mono Tasking
If you do mono-tasking instead of multi-tasking, you don't switch context! And if you don't change context, you produce fewer mistakes, which leads to less stress.
Pomodoro
Source: https://www.thedissertationcoach.com/wp-content/uploads/Tomato-Blog-e1552651017344.jpeg
Manage interruptions using the Pomodoro technique. You set the timer (e.g., 25 minutes), and if timer rings, you stop working on the current task and take a break (e.g., 5 minutes). After four Pomodoros, you take a more extended break (e.g., 15-30 minutes). Every interruption that happens during these 25 minutes, you either plan for some next Pomodoro slot in the future or if it's something quick, you can handle it during a break. It does not just help to reduce your stress level, but it also helps to finish tasks earlier.
It's crucial to stop when the timer rings. I know, it sounds crazy. You finally got into the zone and, now you should stop? Yes, you should stop and take a break!
Take a Break!
Stand up from your desk and move. Take a little walk, get a glass of water, get a coffee (or tea, if that's what you prefer), use toilet (you know, you drink often), get a snack, exercise (stretch your neck, back), take a nap (during the long break), chat with colleagues, or try to meditate.
Your stress reduces, and your health thanks you!
Focus
Source: http://www.undp.org.fj/gifs/wp-content/uploads/2015/02/Bruce-Lee.gif
You might argue that these breaks are bad for your focus. The opposite is true. The thing is that those breaks will help you to focus sooner, to get into the zone faster (after you practice Pomodoro for some time).
If you are looking for the online Pomodoro tool, check Pomodoro Tracker, it's excellent, and it's free.
Email Pop Up Notification
If you are a software developer, your primary tool to work with should not be your email client, but your IDE! Turn off those email pop up notifications that just grab your attention. Everyone could wait a couple of minutes (or even hours) for your answer. Plan time (a Pomodoro) to check emails, and it's often better not to have that time scheduled in the morning.
Deadlines
So many software developers stress about deadlines. I understand it, I've been there.
What is the deadline? Well, it's a line, and it's dead. So, let it rest in peace.
If deadlines stress you, it's not the deadlines to blame.
It's the unplanned work that causes this stress! So, instead of blaming deadlines, reduce unplanned work (see above how to do that).
Priorities
"What should I do now?" It might also be a source of stress. Conflicting priorities, everything seems to be the top priority; everything needs to be done now.
There is a recommended way how to handle these conflicting priorities:
The Eisenhower Matrix
Source: https://upload.wikimedia.org/wikipedia/commons/3/33/7_habits_decision-making_matrix.png
However, it didn't work very well for me. As a software developer, I could not delegate many tasks or eliminate them as I would like to. So tasks are stacked in both DO or PLAN quadrant.
So, I made some adaptations which suites me more. I removed quadrants as they are defined, but keep the urgency and importance axis (with switched the orientation of urgency axis) and introduced two significant but straightforward rules:
- Tasks could not be stacked. It means that there are no two tasks that have the same importance and urgency.
- Choose tasks from top right to bottom left.
It is simple. If you need to do something, you just write it on a sticky note and find a place for it on board, review priorities from time to time, change them, etc. When you finish the task, you just remove it from the board.
Estimates
Estimating and planning might also be a source of stress. Here is a solution: Don't estimate. It's hard, it's stressful, and it's not accurate at all.
What if you could have historical data about your work? Could you have better results? If you have these data, try #NoEstimates.
What you need are two measurements:
- Throughput - Units of work per unit of time,
- Process Time - Units of time per unit of work.
Source: https://cdn.dribbble.com/users/2098846/screenshots/5807505/traffic_dribble.gif
Overtimes
Don't do overtime for a long time!
It's not healthy, the longer you do overtime, the more mistakes you start to make, and more mistakes lead to more stress.
Physical Clutter
One of the easiest ways what to do to reduce stress is to clean your work desk. Do it often and regularly. Try to minimize the things you have on the table.
Source: https://media0.giphy.com/media/oCGjUWkj8vz9u/source.gif
Development Practices
Let's imagine a car called "Development practices."
and you have five passengers (roles):
- Manager (Project, Product, Line, etc.)
- Product Owner
- Scrum Master
- Developer
- Tester
Which role should be the driver? Who should be behind the driving wheel?
Of course, it should be a software developer! Who knows the most about development practices? But, is it the case in developers' projects?
So often, developers tend to excuse themselves from not doing TDD, because somebody doesn't allow it or doesn't give them the effort. And it's not just about TDD. It's also about refactoring, pair programming, testing, code reviews, clean code, etc.
You, as a software developer is the driver of development practices. You should learn about them, experiment with them to find what works best for you and your team to do them effectively and to do the best quality work you can. You are responsible for it. You are paid for it.
Conclusion
Stress is very harmful and can cause a lot of issues to your health. Be conscious about it; don't forget about it. There is no silver bullet - a single solution to reduce stress. The way how you, as a software developer work, has a significant impact on your stress level, keep this in mind when you experiment with development practices in your project.
