34 min. read

March 22, 2020

career

8 Sources of Stress in Software Development

8 important sources of stress for software engineers and possible solutions to managing stress and anxiety.

matthieu-cneude

Matthieu Cneude, Backend developer

darth-vader-stress

I remember it vividly: me, lying on my bed, cold and shaking. The room was literally turning. I was dizzy, angry, sad, and full of reproaches, mostly toward myself. My nerves were breaking, and my body was reacting. I couldn’t move.

It was a Friday, around 11pm, after coming back from work. Working from 8am to 11pm straight was not an exception. Panic attacks were no exception either.

It was 10 years ago. I was working in a very small web agency as a beginner web developer, without any prior professional experience. I knew how to code (I was coding little projects for 10 years already) but the pressure of my company was very, very intense.

I had one of my biggest panic attacks that Friday because my CEO announced, just before going for two weeks holiday, that he might fire me. The reason: I was “too slow”, “not productive enough” and he “should not have hired me”. No further explanations or even concrete examples.

My situation was precarious at the time, and losing my job could have caused severe hardship. After 30-40 minutes on my bed (it felt like way longer), I succeeded in calming myself down, worked all week-end as well as crazy hours during the next two weeks, to show that yes, I could be faster and more productive. Who cares about my health?

I managed to stay one year with this company - enough time to gain the experience necessary to find something better. I was totally burned out: my self-confidence was destroyed, my mental and physical tiredness were the highest I'd ever experienced.

I was disillusioned, empty, drained.

This is the consequence of stress: subtle physical reactions which can take massive proportions, affecting your whole body as well as your fragile mental health. I've had to cope with stress with every company I worked for, and each time I was managed better. better.

I would like to share what I learned with you. Our health is more important than anything else (at least work related). You need to nurture it, preserve it, take great care of it, not really to live longer, but to live better!

Now, looking back on this pretty dark period of my life, I feel really, really good. What happened? Did I find a better company to work with? It does factor in, but what it mostly comes down to is that I put a lot of work into myself.

I get it, we're developers extremely interested by our jobs. So we thrive to do good work, whatever it takes, and be proud of ourselves.

Sometimes, we think we're not fast enough. Other times, we're so fast that we discover a misunderstanding in what we needed to do.

In this article, I will brush over the basics concerning stress:

  1. Let’s define stress itself. A problem well stated is a problem half solved.

  2. We all know that stress is bad, but some may argue it’s somehow good. Let’s explore what are the real consequences of being stressed.

  3. I will talk about 8 common sources of stress for a developer, and, for each of them, the different solutions I found to manage it.

A side note before going further: when I use the word stress, I mean psychological stress. I won’t be speaking about physical stress here.

Let’s now begin our descent into the Dungeon of Fear, where the horrible Monster of Stress is waiting to punish us.

What is Stress?

Welcome to the Savanna!

Let’s imagine together a very appealing scenario: you’re on the Savanna, entirely naked, a dull knife made of stone is your only weapon. It was a present from your mother-in-law. You’re still not sure if it was an attempt to help you or to kill you.

You’re out in the wild because you need to bring some food to your family, waiting in a sumptuous and well decorated cave. It’s not easy, supermarkets and mass production have not yet been invented. You'll need to put your life at risk to be able to eat and survive.

Suddenly, you see that a terrible lioness is looking at you, hidden in the bushes. She’s hunting, and you might become her prey. How ironic, to finish as a meal when you’re desperately trying to find one; Ah the cycle of life!

However, you don’t have the occasion to think about evolution and philosophical survival. Instead, your brain shuts down. All the emotions and legitimate questions you had earlier are all replaced by fear. Your heart begins to work harder, your blood pour in your muscles, your breath becomes shorter.

Without even thinking about what you’re doing, your legs begin to quickly move and you start the sprint of your life, trying to escape the predator.

Congratulations! You just experienced a high level stressor: a very complex mechanism which allows us to survive in life threatening situations. It’s the famous fight or flight response: both require you to use your muscles like you've never done before.

The Modern Savanna

conference-stress

Nowadays, it’s not very likely to meet a lioness in your daily life - at least in the western world. However, this stress mechanism can still save your life: if a car is rushing at you, you will be happy to be able to quickly jump on the side without even thinking about it.

We have a problem though: we, humans, are not very good at distinguishing real threatening situation, for example somebody with a weird mask trying to kill you, and more casual scenarios with less impact, like doing a presentation in front of strangers.

In both case, our body will react similarly, even if these situations are, obviously, very different.

Let’s take this presentation example. You’re a good developer from a good company and you know that you need to do a presentation in two months.

However, you have difficulties to speak in front of people. For a month, you'll think about the presentation, and about people who will, no doubt, be judging you.

You'll be stressed.

Let’s imagine you completely fail your presentation. What are the possible consequences?

  1. You lose your credibility.

  2. You lose your job.

  3. You lose your wife because she wants a husband with good presentation skills (?).

  4. You lose your house from the gambling, drinking and using drugs which ensue.

  5. You'll end up on the street.

  6. It’s winter and cold, sleeping in the street could be a life threatening situation.

Is this really comparable to my story with the lioness?

To be honest, the situation seems more frightening than it actually is: it's not going to happen everyday, so you'll have plenty of time to react and adapt. As humans, we are very good at that, too, and very resilient as well.

Still, stress will pop up even if the danger is highly hypothetical and far in the future. Your mind is good a tricking you.

Let’s address something important before continuing.

For those who think that stress (and mental health problems in general) “is only in our heads”, as it doesn’t exist and thus, is not “really” a problem, well, you’ll be happy to learn that we live mostly in our heads.

What we imagine is still very real to us, and can have disastrous consequences.

It's not that bad, you might think. A bit of stress never killed anybody!

Well, somehow you’re right. Somehow, you’re also very wrong.

The Consequences of Being Stressed

This part is highly simplified: I don’t want to go into the details, first because it’s not the subject of this article, and second because everything which is related to our body is too complicated for me. I’m not a doctor, a neurologist or a psychiatrist. Being a developer is complicated enough, thanks.

If you’re curious, I would recommend the fantastic book Why Zebras Don’t Get Ulcers by Robert M. Sapolsky. It’s well explained, funny, and definitely a deep dive into stress mechanisms and their consequences.

Short Term Stress: Fight or Flight?

Let’s go back to the unlucky hunter in the Savanna, with his best friend the lioness, the one who's trying to kill him. What happens, in his body, when he realises that his life is in danger?

Well, as we saw with our lioness, your muscles need energy. After all, you need to run, and fast. If you’re a bit suicidal, you might try to fight as well.

When I say energy, I speak roughly about the fat and sugar in your blood which is redirected to your muscles, to the detriment of the other organs.

Let’s look at the whole physical process:

  1. When your brain thinks there is a stressful situation, it will release specific hormones which creates a chain reaction.

  2. Because you need energy, your heart begins to work harder. Therefore, your blood pressure will raise.

  3. More fat and glucose (sugar) will be present in your blood: your muscles need energy, as I said.

  4. No energy is given to your reproductive system anymore. You don’t need to reproduce when your life is at stake...do you?

  5. Your whole immune system is costly to run, so it also is shut down. The immediate threat is the lioness, not a virus.

  6. Your memory is enhanced! After all, if you manage to get away from the lioness, you'll need to remember it, just in case your mother-in-law decides to throw you in front of one again (you'll be better prepared)!

Now, let’s imagine that you need to go to work everyday, where:

  • Your management is pretty impatient for you to ship the new super-duper-feature-which-will-disrupt-the-market.

  • You have bugs popping out of nowhere, which need to be solved immediately and quickly.

  • Dave, your colleague, is trying to climb the hierarchical ladder by proving to your boss that he’s better than you.

  • You work in a noisy open space and you struggle to really focus.

At home, in the evening, you’re still trying to write articles for your disturbing-the-developer-world technical blog, feeding up your Github account (with well crafted code), read articles about the last trends to stay up-to-date and employable.

Obviously, these are no life threatening situations: if you make mistakes at work, if you don’t have a blog, or if your Github account is empty, you'll survive.

Still, these are stress inducing situations, and they aren't short term anymore.

Anxiety and Chronic Stress: The Sickness of our Era

modern-stress

You see, problems grow exponentially when short term stress becomes long term stress.

What happens, then?

  • Your blood vessels will get stronger in order to regulate the high blood pressure.

  • As a result, more pressure will be needed to balance the regulation.

  • The never ending rise of the blood pressure will cause blood vessel inflammations.

  • The cholesterol and fat, more abundant in your blood, has a tendency to stick to blood vessel inflammations.

  • This fat can eventually block your blood vessels: welcome stroke and heart attacks!

Doesn’t sound too good, does it? It’s only the tip of the iceberg:

  • Your immune system will be constantly low. Welcome, diseases!

  • Your memory won’t be enhanced anymore, quite the contrary actually: long term stress will disrupt the whole memory mechanism for you not to remember things.

  • Men will suffer sexual problems.

  • It has been shown that there is a strong link between depression and chronic stress.

  • Chronic stress is responsible of 75% of cases of insomnia. If you’re still able to sleep, you won’t sleep well. It'll be increasingly difficult to restore your energy in that case.

You know what can cause more stress responses? A lack of energy. Which can be caused by a lack of sleep. Which can be caused by chronic stress. A nice vicious circle we have here!

Stress, as we saw, is useful to escape the lioness. but for a developer, or anybody doing knowledge work, it’s an obstacle, and in the best case, a poison which leaks into your entire life - and at worst, the cause of serious physical and mental issues.

What about the myth of “good stress”? Have you heard one of your managers, or even your colleagues, speaking about good stress which makes you more productive and pushes you to finish your tasks? I surely have.

I hate it. It’s not like I have a button I can press to produce “good stress”. It can be difficult to know if we are stressed at all, who knows if we have “good” or “bad” stress? How do we control that? How does a manager, who wants his feature as soon as possible, possibly know how to encourage “good” stress without the “bad” one? How can a developer, who wants to finish his side project and become rich, can control his “good stress” without risking burnout?

Life will throw stress at us without the need for people to impose it for the greater good.

Now that we clarified what stress is and why we should avoid it, let’s see how to manage it as a web developer.

8 Important Sources of Stress and Possible Solutions

Sometimes, we can be stressed without even realising it. If we are too busy, we might fail to know how our body is reacting. We can even get accustomed to stress, and believe it’s the normal state we always lived with.

That’s why it’s important to know what thoughts, assumptions, believes or actions can cause stress as a software developer. Obviously, everybody is different: try to see for yourself if these situations create a state of stress.

Here’s a non-exhaustive list of the sources of stress I found the most damaging. Don’t hesitate to complete it with your own experiences: the comment section is perfect for that.

1. The Impostor Syndrome

insecure-vs-arrogant

The Problem

This is a big one which can affect everybody: juniors, seniors, ninjas, wizards, dinosaurs, guru masters and even universe deities.

The impostor syndrome is the feeling that we are not worthy. We have the impression that we don’t know how to do our work properly. We feel like frauds, only creating bugs and crashing our production servers. We wonder why the company we work for even pays us, and we might doubt if anyone else will ever value us if we lose our job.

We need to hide as much as we can before someone reveals to the world our true nature: that we are actually bad, inefficient developers.

The impostor syndrome will instil fear and doubts in everything we do. It will make us avoid challenges and only stick to easy tasks.

This is a bad attitude since it's the challenges which stretch our skills as developers, and the challenges which bring motivation and help us excel in our craft.

To really understand what happens, let’s imagine that you are assigned to code a very important feature: animating dogs for the homepage of your company.

The dogs need to fly all over the page following a special path which needs a very complex algorithm, in order to hypnotise the user, forcing him to buy more of the delicious products for the dog your company is selling.

As a developer who knows what he’s doing, you open Google, praying that somebody before you solved the same problem. Flying dogs isn't something common (it should be!), and your research on Stack Overflow doesn’t bring any results.

That’s when the impostor syndrome can kick in: when we fail. If we judge the failed task as easy, or if everybody else does - we beat ourselves up over it.

The Possible Solutions

A Development Journal

There will always be times when you will feel useless after crashing your production server, corrupting a lot of data because of silly mistakes or lowering the price of every product on your e-commerce website by 20%, silently, for days. Ah! Sweet remembering!

When you meet a situation like this, ask yourself: why the mistake was made in the first place?

Were you tired when you did it? Were you under pressure, from your boss or from yourself? You might have been angry to some colleague because he didn’t want to listen to some of your arguments? Maybe you were trying to do too many things at the same time?

Having a development journal, a place where you write every single frustration, bug or difficulty you encounter in your daily job, can be very, very valuable:

  1. Writing what goes wrong has a powerful effect. When something is written, you can think about it from an external point of view. It’s no longer a weird thought in your brain anymore, it’s written and therefore exists in the world.

  2. You can go back in time and see if you've made similar mistakes in the past. It won’t be pleasing if that's the case, but it'll be simple to identify causations, or at least, correlations, and maybe find the root causes and dig up some possible solutions.

After all, developers are first and foremost problem solvers: solving your own behaviour might be a hard task, but it’s not impossible, and will improve your self-esteem.

I personally use jrnl for that in the terminal, but you can use whatever you want. Even a real notebook will do!

Accepting Mistakes

According to a study described in the book Accelerate: The Science Behind Devops, top performers don’t avoid mistakes.

Why? Because it’s impossible.

Everybody makes mistakes. It’s useless to blame the others or ourselves with the mistakes we make. It only makes us more ashamed, unsure about our capacities, full of doubt and therefore, more prone to make… more mistakes. Yes, again a vicious circle.

As Frank Wilczek was saying:

"If you don’t make mistakes, you’re not working on hard enough problems."

What’s important is the MTTR (Mean Time to Restore). It’s the time you (or, in general, your company) need to recover from a mistake made. For example, if one of your client discovers a bug, MTTR is the time between the discovery and the fix.

You need to set up processes in order to recover from mistakes as quickly as you can. If these processes are automatised, it’s even better.

Automated Tests

Last but not least, automatic tests (unit tests, integration tests for example) will bring down the number of possible bugs and therefore will increase your confidence. It will be easier to understand what the code is about with testing, and to refactor it as well. It's a precious safety net.

2. Deadlines

The Problem

When we speak about stress, deadlines are the elephant in the room.

“Of course we need some deadlines!” says your manager or even Dave, your colleague developer. Everybody agrees, deadlines are necessary, otherwise nothing would ever get done.

Let’s begin at the beginning: what’s a deadline?

The Collins dictionary defines it as:

"A deadline is a time or date before which a particular task must be finished or a particular thing must be done."

The real question is: how to determine accurately a deadline, given a precise task? This question alone brings to light many problems:

  • How to accurately know how long a task will take? If it’s even possible to be 100% accurate? Should it be an estimation, instead?

  • Should the deadlines be fixed in stone, forcing every developers to respect it, whatever the cost?

  • Should deadlines be used to pressure developers, forcing them to swim in the poisonous lake of stress?

A deadline can be a tool. Like a hammer, it can be useful: it can gives you a concrete idea when the task will finish, even if there are big chances you’re wrong. If you know that, then deadlines can indeed help you forecast your future to some degree.

Like a hammer, it can be used as a weapon as well, in order to pressure everybody.

In a company setting, I rarely saw deadlines being realistic, or even useful.

Can you predict the future? Do you know how long a task will take, knowing that software development is a complex mix of hundred of tiny details nobody can apprehend at once?

That’s exactly why judging something as “easy” to implement without implementing it is a big mistake, and leads to optimistic and unrealistic deadlines. The bigger the feature will be, the more difficult it will be to predict correctly how much time it will take.

The Possible Solutions

No Deadlines

The best solution to me would be: no deadlines. The task is done when it’s done. You can still give some rough estimations, if everybody knows that they are not fixed in stone. They need to be called rough estimations too, for everybody to really understand it, not deadlines.

It’s not a dream. I saw that working effectively in real companies.

If a company trusts their employees, the management should know that they would do their best to accomplish their tasks, and provide value as much as they can. It’s even more true if the company’s employees are empowered by the fact that they know and feel their management trusts them, by removing hard deadlines (among other things). A virtuous circle, if you will ;)

When you know that these developers were hired by the person who gives the deadlines. Trying to put pressure because “otherwise they won’t work as much” or “to accelerate the completion of a task” is admitting that the company's hiring process was wrong and they hired the wrong people.

These are arguments you can give to your management, in order to soften the deadlines, to define them as hypothetical versions of the future, and not as the only and obligatory future you should respect even if you need to work 15 hours a day.

If your management needs to report to higher people, like investors for example, they should be able to explain what I've just spoken of. Software deadlines are far from being exact science. Claiming the contrary won’t make it true, at any level.

Continuous Delivery

Studies show that companies using continuous delivery perform better than the concurrence.

Indeed, if a company delivers small features very often, developers won’t have to suffer short and/or unrealistic deadlines for the next big features. Again, the book Accelerate: The Science Behind Devops describes very well what continuous delivery is, and why top performers (measured by the companies’ market shares and profitability) seem to use it to their advantage.

If your company argues that every feature they ship needs to be big, you can always turn it around and show how a big feature can be divided into small chunks.

Calibration Tests

Finally, if you want to improve how to measure your deadline-estimations, I think taking calibration tests can be pretty useful. By default, people have tendency to be optimistic in any estimation they make. Calibrating yourself could help to be more realistic. Again, to some extend.

Calibration tests and, more precisely, the general idea of measuring is very well described in the great book How to Measure Anything which can help you with measuring anything - mainly with statistical and probabilistic approaches.

3. Lost in the Technology Twister

technology-twister

The Problem

Technologies evolve at a speed we can’t really control: everyday, a new JavaScript framework pops up, new CSS properties appear, new tools and other trendy stuff emerge. It's difficult to know what to learn, how to learn it and what to use in what situation.

Developers can easily burn out if they try to read every single newsletter out there about Back-End, Front-End, DevOps, keeping track of their dozen of RSS feeds and hundred of daily articles on Medium.

This can be seriously stressful to feel totally out of this continuous flow of information, unable to catch with everything, especially when you apply for jobs where they ask you random questions about random technologies.

The Possible Solutions

I’m a big fan of the first principle mental model. If you know enough basics, the foundation which languages, frameworks, and tools are build on, you don’t have to actively learn every trend popping up. With this mental model you'll be able to adapt quickly if you have to work with them.

This is one mission of this blog: helping you to acquire foundational building blocks, which will increase your value as a developer.

In short, you should not try to learn deeply or master everything out there, a very rough ideas about the last frameworks and tools should be enough. What’s important is how long you need to adapt when you need to work with these new technologies.

The real good new is: the foundational knowledge, these first principles, barely change. We are still using functional or object oriented programming for example, for decades. Good practices are always the same, and have been proven to work, despite a lot of ongoing debates (which are curiously solved for years in many other engineering area, namely automated testing for example).

Don’t try to learn everything at once: one step at a time, consistently, on a regular basis, is the key.

4. Staying Competitive

The Problem

There are millions of developers out here, competing with roughly the same technical skills to get the job of our dreams. We're proud to put on our CVs the programming languages we know (and the ones we think we know), surrounded by one, two, three, four or five little stars, to show our scale of efficiency.

We show our Github projects with pride, to prove how much better we are from the “average developer”, whatever that means.

When we send in our CVs, we expect companies to be impressed by the depth of our knowledge, the speed of our typing, the efficiency we have to ship complicated features. We use hackaton, we train for the silly tests companies might ask us to complete, to show that yes, we are FizzBuzz evangelists.

We are on Hacker Rank to see who’s the best, who has the biggest brain, who’s the smartest, using flawed and entirely subjective gamification mechanisms.

This (extreme) competitive behaviour can be very stressful. How do you know how good you are compared to the others? Is it the number of stars on Github? Is it the 10 years of Computer Science study at MIT? All these measurements create doubt.

These thoughts can stay with you all day long, putting your body and mind under constant stress.

The Possible Solutions:

Adapting to the Company’s Needs

First things first, being the best technical guy out there is overrated. Let me explain: a company should not really care if you can find a way to compute the pascal triangle in O(n) time, but they should care whether or not you can answer their specific business needs and solve their business problems.

Every company has a specific business model, and, as a developer, your job is to add value to this company by automating things. Mostly with code.

Stop competing with the whole world: show the company you want to work for how you can solve their specific problems, in concrete ways. If you have enough experience, show them how you did it in the past. Explain why you know their specific business domain.

Show that you know the basics of your “craft” and, therefore, that you can adapt very quickly to many technologies, many business models and many ways to automate their processes.

If you are rejected because you can’t pass their coding tests (which has nothing to do, most of the time, with the day to day work in the same company), change your strategy and try to find a company which can answer your need.

Beating the Concurrence

Being generalist is not a very good idea to beat the concurrence when you search a job. Simply because the majority of developers out there are generalists.

You know what occurs when you try to compete with the whole world on the same positioning? A lot of stress. It’s even worse with remote jobs - you now have to compete with developers from around the world.

Try to narrow down what you are very good at: find yourself a speciality, something useful to solve people’s problems. You could be specialised in APIs, for example, or into e-commerce logistic softwares.

You will then appear as an expert, compared to the guy who can code in PHP, Javascript, Java, Python, CSS, C++, can fix the kitchen sink and make wonderful coffees.

Finding a specialty can be very difficult and won’t happen from one day to another. You need to keep your eyes open, see what problems companies are having which they can't solve, and bring specific solutions. Being a specialist doesn’t mean that you will stay all your life in a boring niche: it’s mainly about how people see you. Your positioning.

Another idea: try to develop skills which developers generally lack. For example, soft skills in communication or a good understanding of marketing. Everything which can help a business to create value. That’s what you’re payed for at the end of the day: if you can mix some problem solving and technical skills with other useful ones, you might create valuable outcomes.

We are coders, but we are also good problem solver, and solving problems doesn’t always require code.

5. Legacy Applications

The Problem

Each time you open the application you’re working on, fear grows suddenly in your heart. Cold sweat appears on your forehead. Your hands suddenly begin to shake.

It has been in development for years, by dozen of developers who ran away, a long time ago. They couldn’t cope with the growing complexity and the technical debt piling on, and on, and on. It takes days, sometimes week, to implement simple features.

Each try is the equivalent of a dive into the abyss: you never know what will break, what random bug will pop up, what surprise is lurking for you, ready to show itself when everything is pushed on the production server.

On top of that, you have no clue what’s the purpose of some parts of the application: the documentation has never been written, the specifications have been forgotten.

You are living the Nightmare of the Legacy Application.

The Possible Solutions

You might think that rewriting the whole “thing” from scratch would be the perfect solution, but it can be a very dangerous one as well.

Your management might not allow it for very good reasons: it’s expensive and it could block many resources (developers) for months.

Moreover, if you have no clue why the application ended up that way, you might do exactly the same mistakes while rewriting it. In short, creating a legacy application from… a legacy application!

Maybe the developers had too short deadlines, problem which is more relevant to the company culture and still not solved? Maybe nobody really knew what problem the application was supposed to answer, letting the developers implementing more or less what they want without any behavioural consistency?

As Gerald Weinberg says in his fantastic book The Secrets Of Consulting:

"If you use the same recipe, you get the same bread."

To avoid following the same recipe, you need to know what recipe lead to the disaster you need to maintain. In other words, you need to know how to avoid reproducing the same mistakes. That’s why a total rewriting can be a very risky task.

Instead, I would go for a step by step approach:

  1. You need to understand the business model of your company enough to understand what your application is supposed to do, and why.

  2. Tests can be a good way to understand the bounded contexts (the different, independent parts) of an application. However, writing unit tests can be a real challenge for a legacy application. Acceptance tests can be more useful in that case.

  3. When you understand what your different bounded contexts are, you can separate your application in different micro services. As I explained in my article about simplicity and the KISS principle, an application is simpler when it stays small. However, be sure to understand the challenges and drawbacks the micro service architecture brings.

6. Lack of Mental Energy

The Problem

Using your cognitive abilities will drain your mental energy pretty quickly. Obviously, coding requires you to use your brain, sometimes intensively; at the same time, your brain is the organ which consumes the most energy.

The result? Experts agree on the fact that you can’t focus and be productive more than 3 to 4 hours a day!

Here’s my experience:

  1. The average knowledge worker (including developers) usually “work” 8 hours a day.

  2. Your mental energy will be drained, trying to focus for a long time. If your environment is noisy or, in general, disturbing, it will be even worse.

  3. You will feel more and more tired as the week goes by.

  4. Tiredness will taint your productivity.

  5. Lack of productivity and tiredness will cause a sheer amount of stress, which will increase your tiredness. Vicious circle power!

The Possible Solutions

First, you should not feel ashamed if you’re not 100% productive every minute of each day. If you feel that you have difficulties to focus, that you’re tired, just stop what you’re doing. Meanwhile you can:

  • Go for a walk.

  • Have a quick nap if your company allows it. If not, try to explain to you company’s management that a 10 minute nap can recharge your mental energy batteries.

  • Have a drink in a quiet environment. Water or tea are the best, coffee will make you even more stressed. Energy drinks are the worst. Sugar mixed with high dose of caffeine never reduces stress. Avoid them. If you don’t like tea in bags, you can try loose tea. There is a world of difference between them. #tealover.

  • Go chatting with other colleagues.

  • Call your girlfriend / boyfriend / friend / dog.

In general, if you can do any physical activity, even if it’s only walking or even standing, it can recharge your mental energy, to some degree. Do something different from what you've been doing, and come back to your code with a fresher mind.

Sometimes, it won’t be enough. You might need to wait for a longer period of time to really solve your problems or to recharge entirely, and to get back on the productivity road. In my experience, it can even take a day, or a full weekend if I’m really drained.

Patience coupled with acceptance will be your best allies here. Punishing yourself because you think you’re not productive enough will simply drain your energy even more. Nobody is 100% effective all day long and, if you know people who are really like that, they might hit the burnout wall at some point.

To be clear, I’m struggling with all of that myself, but I try to be realistic on how I feel and when I should slow down. It won’t be perfect, but I've made a lot of progress already. It’s not impossible.

If your company is very strict with your break and what you should accomplish every day, obliging you to stick your nose on your screen constantly, please, find another company. We are not robots, and everybody treating you as such will only push you to the burnout.

Burnout is one of the worst possible scenario, you should try everything to prevent it. No job is valuable enough for you to experience that.

7. The Open Space Trend

open-space-problem

The Problem

Open spaces are the new favourite organisational trend of the 21st century: take a big room, put in some desks, ask everybody to work in there in order to be more “agile” and “improve communications." Which leads to a chain of events:

  1. The Open space will be noisy.

  2. You will have difficulties to focus.

  3. You won’t be productive.

  4. Stress will pop up.

Last but not least, ideas are not the only thing we communicate to each other in open space: stress can be communicated very effectively between coworkers.

The Possible Solutions

A good set of headphones could be a partial solution. If you can’t listen to music while working, there are plenty of website which can let you mix different natural sounds (birds, forest and so on) or even white noise, which can help you focusing. It might sound silly, but it’s a real life-saver for me.

These are my two favourites:

However, wearing headphones several hours a day can be tiring as well. If you can’t deal with the open space noise, here are two possible solutions:

  • Ask for the the IT team to be isolated its in own space. Your colleagues in marketing, HR, customer support and sales will, more likely, do most of the noise. Not because they want to, but because their work obliges them to often communicate on the phone, Skype, and so on.

  • Working from home. My experience: I’m more productive being from time to time at home, since I know the environment and I can control it, according to my needs. Here’s a study about home office and its benefits, in case you want to convince your company to allow it.

8. Having “Nothing to Do”

The Problem

I saw, in some companies, developers (including myself) having repeatedly nothing to do, that is, no new tickets or tasks assigned directly to them.

Since the strength of a whole chain is the strength of its weakest link, as the theory of constraint shows us, the end of the chain, the developers, depend a lot on the processes before them.

Let’s imagine that the management is slow to validate features: the development team can run out of work quickly. Since societal pressure push us to believe that we should always be busy at work, having nothing to do can create boredom, stress and strengthen feelings of impostor syndrome.

Continuously searching for something to do, in order to justify our salary to ourselves, can be quite tiring and stressful.

The Possible Solutions

First of all, as the theory of constraint shows us again, being always busy isn't necessarily a good thing. Let say that you have some QA processes, which come after the development phase: if the development team is very productive and the QA team can’t really test everything you’re producing, by lack of time and/or resource, your productivity will be the QA worst nightmare, and the features won’t be delivered quicker.

It's a problem I've seen in the past. Everybody has a tendency to think that productivity is always good, but it’s a common pitfall of many companies.

Secondly, you can’t do anything if the processes above you are too slow (or totally stuck). As a developer, you can explain to your management that they need to find the weak process and make it faster. You can even propose solutions if you have some idea about what’s happening.

Third of all, you can ask your project manager to prepare low priority tasks in advance, for you to work on when you don’t have anything else to do.

Meanwhile, when you run out of work, you could: * Refactor and improve your code. * Add more automated tests. * Come up with ideas how to improve the processes you are aware of. * Read some articles about development. Even if it feels like being lazy, increasing your knowledge is part of our work. We are not coding machines.

Even if it feels less satisfactory than building things, it can be very useful as well. Remember, the goal is to provide value to a company, not building things blindly because it feels good to do so.

Banning Chronic Stress from Our Lives

stress-monster

There is a lot more to say about stress and how to deal with it. Nevertheless, let’s summarise what we learned:

  • Stress is a natural response to a threat. Thanks to it, we were able to survive and create the Internet. It’s still very useful today in life threatening situations.

  • Chronic stress is a response to what seems threatening. Depending on the person and its environment, it can be many things.

  • Chronic stress has very bad consequences on our physical and mental health.

  • Many things can be a source of stress: impostor syndrome, the technologies changing at a fast pace, deadlines, the expectations from your colleagues or from yourself… All of these problem have possible solutions we need to work on, actively, day after day.

We need to understand that we are not our day job. We are developers, but it’s not only what we are. Having lack of efficiency, sometimes, doesn’t make us a bad, or a useless person.

We should makes our health (physical and mental) a priority way higher than our daily job! There are plenty of companies out there, but we have only one body, one brain, possibly one life.

Chronic stress can easily become a habit and, like every habit, it can be difficult to see and to replace with something else.

Learn to stop your run toward success and fame and try to ask yourself some questions: do you feel less stress when you’re on holidays? Why? What could be the cause of your stress when you’re at work? How to solve it? Did you try to work less? If yes, do you feel more relaxed when doing so? Or more stressed?

In short: learn to know yourself. Experiment with yourself, learn how you (your body and your mind) react depending on your actions.

A very important word for the end: as I did at the beginning of the article, if you’re experiencing a high level of stress in your life, speak about it. Speak with your family, girlfriend / boyfriend, friends, colleagues. Social support is very important, I'll write more about it in a future article.

The subject is quite taboo in our field, since stress is often associated with weakness. However, it’s important to try to solve the problem before having serious health issues and experiencing a disabling burnout.

Related Sources


Note: this article was first published on Matthieu's website The Valuable Dev