The Valuable Dev

8 Sources of Stress in Software Development

Darth Vader stressing developer on a dinosaur

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

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 attack this Friday because my CEO announced me, just before going two weeks in holidays, 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 that time, and losing my job could have caused very bad consequences. After 30 to 40 minutes on my bed, which felt way more, I succeeded to calm 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 health?

I managed to stay one year in this company, enough to have 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’ve ever experienced.

I was disillusioned, empty, drained.

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

That’s why 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 necessarily to live longer, but to live better.

Now, in comparison with this pretty dark period of my life, I feel really, really good. What happened? Did I found better company to work with? This is a big part of the equation, but I had to do a lot of work on myself as well.

It makes sens: we are developer interested by our job. Therefore, we thrive to do a good work, whatever that means, and be proud of ourselves. The thing is, development is far from being easy, and doing mistakes, creating bugs, is common.

Sometimes, we will think that we are not fast enough. Other times, we will be utterly fast to discover that we misunderstood 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 can argue it’s somehow good. Let’s explore what are the real consequences of being stressed.
  3. I will brush on 8 common sources of stress for a developer, and, for each of them, the different solutions I found to manage it.

A small precision before going further: when I use the word stress, I mean psychological stress. I won’t speak about physical stress here.

Let’s now begin our descent in the Dungeon of Fear, where the horrible Monster of Stress is waiting for your punishment.

What is Stress?

Welcome to the Savanna!

Let’s imagine together a very appealing scenario: you’re in the Savanna, entirely naked, with a dull knife made out of a stone as unique 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 were not yet invented. You need to put your life at risk to be able to eat and survive.

Suddenly, you understand that a terrible lioness looks at you, hidden in the bushes. She’s hunting, and you might be the pray. How ironic, to finish as a meal when you’re desperately trying to find one; the cycle of life!

However, you don’t have the occasion to think about evolution and philosophical survival considerations. 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 of stress: a very complex mechanism which allows us to survive in life threatening situations. It’s the famous fight or flight response: both will require you to use your muscles more than anything else.

The Modern Savanna

stress leading speaking

Nowadays, it’s not very likely to meet a lioness in the middle of nowhere, at least in the western world. However, this stress mechanism can still save your life: if a car rush on you, you will be happy to be able to quickly jump on the side without even beginning to think 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 month, you will think about the presentation, about people who will, without any doubt, judging you.

You will be stressed.

Let’s now imagine that you completely fail your presentation. What could be the consequences?

  1. You lose your credibility.
  2. You lose your job.
  3. You lose your wife who wants a husband with good presentation skills (?).
  4. You lose your house after beginning gambling, drinking and using drugs.
  5. You will end up in the street.
  6. It’s winter and cold, sleeping in the street could be a life threatening situation.

Is it really comparable to my story with the lioness?

To be honest, the situation is more frightening than really probable: it won’t happen from one day to another, and you will have plenty of time to react and adapt. As humans, we are very good at that, too, and very resilient on top.

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

Since we speak about mind, let’s address something important before continuing.

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

What’s in “our head” is very real to us, and can have disastrous consequences.

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

Well, somehow you’re right. Somehow, you’re very wrong as well.

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 definitely 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 you, unlucky hunter in the Savanna, with your best friend the lioness, the one which tries to kill you. What happens, in your body, when you realise that your 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: it will be redirected to your muscles, to the detriment of the other organs.

Let’s look at the whole physical process:

  1. When your brain think there is a stressful situation, it will release some specific hormones which will create a chain reaction.
  2. Because you need energy, your heart will 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 want to reproduce yourself when your life is at stake, do you?
  5. The whole immune system is a costly thing. That’s why it shuts down. The threat is the lioness, not a virus.
  6. Your memory is enhanced! After all, if you can go away from the lioness, you need to remember it, in case your mother-in-law decide to throw you in front of one.

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 developer, 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, the evening, you’re still trying to write some article 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, your will survive.

Still, these are stressful situations, and they are not 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? No worries, it’s only the top 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 might have sexual problems of any kind.
  • It has been shown that there are important links 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. Difficult to restore your energy in that case.

You know what can cause more stress response? 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 it, is useful to escape a lioness. For a developer, or anybody doing knowledge work, it’s an obstacle in the best case, a poison leaking in your entire life in the worst, opening the way for serious physical and mental issues.

What about the myth of the “good stress”? Did you hear one of your manager, or even your colleague developers, speaking about the “good stress which will makes you more productive and push you to finish your tasks”? I surely did.

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 a manager, who wants is feature as soon as possible, would possible know how to give the “good” stress without the “bad” one? How a developer, who wants to finish his side project and become rich, can control his “good stress” without risking the burnout?

Life will throw stress at us without the need of people imposing it for the greater good.

Now that we clarified what stress 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 realizing it. If we are too busy, we might fail to know how our body is reacting. We can even get accustomed to stress, for us to 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 find the most impactful. Don’t hesitate to complete it with your own experiences: the comment section is perfect for that.

1. The Impostor Syndrome

arrogance and insecurity are totally subjectives

The Problem

This is a big one which can happens to everybody: juniors, seniors, ninja, wizards, dinosaurs, guru masters or even universe deities.

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

We need to hide, as much as we can, before somebody reveal to the world our true nature: we are bad, inefficient developers.

Concretely, the impostor syndrome will instill fear and doubts in everything we do. It will push us to only do the easy tasks and try to avoid any challenge.

This is a bad attitude of course, since only challenges will stretch our skills as developers, and can bring to us motivation and the will to 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 hypnotize the user, forcing him to buy more of the delicious products for dog your company is selling.

As a good developer who knows what he’s doing, you open Google, praying that somebody before you solved the same problem. Obviously, flying dogs is not something everybody does (they should!), your deep research on Stack Overflow doesn’t bring you any result.

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, it’s even worth: we are not even able to do something easy!

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 20% of the price of every product on your e-commerce, silently, for days. Ah! Sweet remembering!

When you are in these situations, ask yourself: why the mistake was made at the first place?

Were you tired when you did it? Were you under pressure, from your bosses 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 as a powerful effect. When something is written, you can think about it from an external point of view. It’s not only weird thoughts in your brain anymore, it’s written and therefore exists in the world.
  2. You can go back in time and see if you did similar mistakes before. It won’t be pleasing if it’s the case, but it will be easier as well to see causalities, or, at least, correlations, and maybe find the root causes and some possible solutions.

After all, developers are first and foremost problem solvers: solving our own behavior 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!

Accepting Mistakes

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

Why? Because it’s impossible.

Everybody makes mistake. It’s useless to blame the others or ourselves about the mistakes we make. It makes everybody more ashamed, unsure about their 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 discover a bug, it’s the time between the discovery and the fix.

Concretely, 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 bug and therefore will increase your confidence. It will be easier to understand what the code is about with test, and to refactor it as well. They are a very precious safety nets.

2. Deadlines

The Problem

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

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

Let’s begin by the beginning: what’s deadline?

The Collins dictionary define 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 will bring 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, letting them swimming in a 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, at some degrees.

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 very 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 lead to optimistic and unrealistic deadlines. Bigger the feature will be, 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 trust their employees, its 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 trust them, by removing hard deadlines (among other things). A virtuous circle, if you will.

Especially when you know that these employees were hired by the one who gives the deadlines. Trying to put a lot of 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 hired the wrong people.

These are arguments you can give to your management, in order to soften the deadlines, to define them as hypothetical version 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 need to report to higher people, like investors for example, they should be able to explain as well everything I speak about here. Software deadlines are far from being exact science. Claiming the contrary won’t make it true, at every level. Something you know being not true is a lie, and a lie has really bad consequences.

Continuous Delivery

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

Indeed, if a company deliver 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 describe very well what continuous delivery is, and why top performers (measured by the companies’ market shares and profitability) seem to use it to their advantages.

If your company argue 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.

We often think that a big feature will please even more the customers than a small one (big is often linked to impressive), it’s a very good way as well to develop functionalities for months, without being certain that the company’s customers really want or need it.

Even if the customers themselves gave the idea for this big feature, the company could be totally wrong on the implementation itself. The UI can be awful for the actual customers, there could be misunderstanding or the customers don’t know what they really need.

It might sounds like edge cases, but my experience yells at me that it’s far from being the case.

Calibration Tests

Finally, if you want to improve how to measure your estimations-deadlines, 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, it’s true, can help you measuring really anything, mainly with statistical and probabilistic approaches.

3. Lost in the Technology Twister

arrogance and insecurity are totally subjectives

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. Difficult to know what to learn, how to learn it and what to use in what situation.

Developer 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 will 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 where languages, frameworks, tools are build on, you don’t have to learn actively every trend popping up. Indeed, you will be able to adapt quickly if you have to work with them.

This is one of the mission of this blog: helping you acquiring these foundational building blocks, to 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

We are million of developers out there, competing on roughly the same technical skills to get the job of our dream. We are very proud to put on our CVs the programming languages we know (and the one 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 it means.

When we send our CVs, we expect companies to be illuminated by the depth of our knowledge, the speed of our typing, the efficiency we have to ship complicated feature. We are doing hackaton, we train for the silly tests company 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 behavior can be very stressful. How do you know how good you are, compared to the others? Because you have more stars on Github? Because you did 10 years of Computer Science study at MIT? A lot of doubts, questions can arise very quickly with a lot of wrong answers.

These thoughts can stay with you all day long, imposing to your body and your mind a 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 to 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 cheer amount of stress. It’s even more true with the possibility to do remote job, and, therefore, to compete with your pairs on a way larger geographic scale.

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 do wonderful coffees.

Finding a specialty can be very difficult and won’t happen from one day to another. You need to keep your ears open, see what problems company have they can’t really 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 will see you. Your positioning.

Another idea: trying to develop skills that developers generally lack. For example, soft skills like 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 one, you might create valuable outcomes.

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

5. Legacy Applications

The Problem

Each time you open the application you’re working on, fear grow suddenly in your heart. Cold sweat appears on your forehead. Your hands are shacking.

It has been developed 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 new 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 on 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 behavioral consistency?

As Gerald Weinberg nails it 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 to write 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 bring.

6. Lack of Mental Energy

The Problem

Using your cognitive abilities will drain your mental energy pretty quickly. Obviously, coding require you to use your brain, sometimes intensively; at the same time, your brain is the organ which consume 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 cheer 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 minutes nap can recharge your mental energy batteries.
  • Have a drink in a quiet environment. Water or tea are the best, coffee can makes you even more stressed. Energy drinks are the worst. Sugar mixed with high dose of caffeine never reduced 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 degrees. Do something different from what you are 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 going back on the productivity road. In my experience, it could be a day, or even more 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 always 100% effective all day long and, if you know people who are really like that, they might hit the burnout wall at one 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 did already a lot of progress on the matter. It’s not impossible.

If you company is very strict with your break and what you should accomplish per 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

arrogance and insecurity are totally subjectives

The Problem

Open spaces is the favorite startup organizational trend of the 21st century: take a big room, put 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 is not the only thing we communicate to each other in open space: stress can be communicated as well very effectively between coworkers.

The Possible Solutions

A good headphone 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 savior to me.

These are my two favorites:

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 oblige 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 strength our 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 is not necessarily a good think. 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 can be a real problem I saw in the past. Everybody has tendency to think that productivity is always good, but it’s a common pitfall a lot companies fall into.

Second, you can’t do anything if some processes above you in the chain, 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 to your project manager to prepare low priority tasks in advance, for you to work on them when you don’t have anything more 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

throwing chronic stress away

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

  • Stress is a natural response to a threat. Thanks to it, we were able to survive and creating 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, many things.
  • Chronic stress has very bad consequences on our physical and mental health.
  • Many things can be a source of stress: the 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 while 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? 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 will speak about it in a future article.

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

Take part in the discussion