I could feel anxiety in every single cell of my body–knots in the stomach, sudden tremors in the hands, dullness in the eyelids, and, the worst part, constant hypercritical sounds in the skull.

A naive sixteen-year-old, amongst a group of experienced developers, I felt like a perpetual outlander. Afraid of being “caught,” I frantically used jargon like DOM, CI/CD, and CLI, without knowing much about them.

I thought I would either land this gig and ship it flawlessly or become a no-good flop. Today, when I look back on myself, I was a disaster. My code was so terrible I can’t even look at it today. However, I haven’t become a “failure,” at least yet! But I learned a lot along the way.

Notably, I found out that I suffer from generalized anxiety disorder. After receiving multiple types of treatment, I found one particularly helpful with struggles in the workplace: exposure and response therapy.

DISCLAIMER: I’m not a health expert. The description of exposure and response therapy in this article is oversimplified and not intended to substitute a professional medical treatment. Always seek the advice of experts with any questions regarding your mental health.

Exposure and Response Therapy

Exposure and response prevention (ERP), despite its intimidating name, has a somewhat simple underlying principle: to get rid of your fears, you have to face them. By doing this, you change your perception of the novel and uncertain situations from something intimidating to something manageable.

In psychological terminology, the process of exposing yourself to your fears is called a behavioral experiment, which involves five steps:

1. List your worries

List your “what-if” thoughts. What are your fears? Why? For example, you may say: “I’m afraid of rejecting my boss’ unrealistic deadline. What if he fires me for saying no?”

2. Rate how anxious you are about each one

Now, give a 1–10 score to your fears based on how anxiety-provoking they are.

3. Identify your safety behaviors

Safety behaviors are coping mechanisms, usually based on avoidance, that keep you away from your fears. The main types of safety behaviors are excessive double-checking, procrastination, re-assurance seeking, and dishonesty. For example, you may avoid asking questions in Stackoverflow, worrying that other members may call your questions stupid.

Safety behaviors may relieve your stress in the short-term, but perpetually avoiding a threatening situation will increase your worry in the long-term. Besides, by hiding from the things you perceive as dangerous, you can never verify your thoughts and they become self-fulfilling prophecies. In the previous example, you’ll never know if your questions are genuinely “stupid.”

4. Design an experiment to face them

Pick the least intimidating fears in your list, based on their score, and find a simple way around their corresponding safety behavior. For instance, the next time your boss offers you a new task when you’re busy with several other projects, respectfully turn it down. Saying no to your boss may make you anxious or uncomfortable, but this is the whole idea behind behavioral experiments. If you’re not anxious while experimenting, something is wrong.

5. Record the outcome

a. What did happen? Did the disaster happen? Was your code broken? Did anyone make fun of you because you don’t know how Docker works?

b. If the catastrophe happened, how did you cope with it? If you wrote broken code, how did you and your colleagues reacted to it? What happened after Stackoverflow users called your question stupid? If you spent more time worrying, could you prevent the incident?

Safety Behaviors of a Developer

Since undergoing ERP, I have become more aware of the anxiety-provoking dynamics of IT jobs and the destructive safety behaviors that emerge from them. For the rest of this article, I’ll explain some of the safety behaviors that I find the most common and toxic in the industry.

Dishonesty

Software development is a broad discipline with countless tools, technologies, and theories. Not only there’s already a sea of topics to study, but the field also keeps growing faster and faster. As a result, developers are expected to a) know a lot of stuff, and b) be smart and learn things quickly.

Such expectations have led to a toxic environment in many developer circles, where you are supposed to know more than others, be smarter than others, and write better code than others (whatever that means). Most developers I know experienced environments crippled with image management and social status games, where everyone is afraid of admitting that they have made a mistake or don’t know something. Dishonesty, in this context, is a safety behavior to avoid social judgment. You may think that accepting the responsibility of a failure or admitting to being clueless about a topic may lead to loss of prestige (“what if others think I’m incompetent?”).

Image management is a productive evolutionary tool (you don’t want other tribesmen to think of you as a substandard member), but, in the workplace, it could become very unproductive very fast. Especially, when people with good intentions, pressed by their insecurities, resort to untruthfulness to preserve their status. Most of the developers I know have been dishonest, in varying degrees, throughout their careers, for various reasons. In my experience, though, by writing down your worry and conducting a behavioral experiment to confront it, you can overcome the vicious cycle of dishonesty in the workplace.

The next time someone asked you if you’ve worked with a new technology that you haven’t heard of, say no, and show curiosity. Then, record the outcome of the conversation. You’ll probably see that the world is not as threatening as you think!

Procrastination

While many consider procrastination to be a passive act, I have seen many more examples of active procrastination among developers. While you’re supposed to fulfill a task that intimidates you, usually because it’s ambiguous or novel, you simply start doing another task, a simpler yet less urgent one, to feel productive and avoid facing your worries (see: https://shouldideploy.today/). This may seem like a productive strategy, but constantly avoiding novel situations will bring bad news.

When you find yourself procrastinating on a novel task, instead of questioning your will-power, find the underlying perceived threat, and conduct a behavioral experiment to face it.

Excessive double-checking

Software development is more about making decisions and less about typing. Writing clean code, therefore, is the art of making decisions that will save time, performance, and mental sanity. The complexity and the sheer volume of these decisions, however, could lead to analysis paralysis. As a software developer, you have to constantly deal with emergent complexity, and the complexity in action is seldom like in theory. Consequently, you can never find the perfect architecture for your software. If you recently have graduated from college, though, you may still have the mindset of a college student looking for the right answer–an approach that will cause disappointment in the real-world.

Understanding three points can help you overcome paralyzing anxiety about the quality of your code:

1. Getting things done is the only real best practice in software development, as the rest of them are made up and will soon be outdated. Your job is not to write perfect code, it’s to generate revenue. If your code helps your organization, its quality, as defined by clean code factors, is a secondary concern (but not something to be ignored).
2. Consistency is often more important than flawlessness. Creating a simple style guide and sticking to it significantly reduces the number of decisions you have to make during development.
3. You don’t have to ship a perfect code, you don’t even have to ship a good code! In most cases, you can first make it work and then make it good enough. By quickly building a not-so-clean software, you’ll find a clear idea of the complexities that the final architecture has to accommodate for, which is rarely identified at the beginning of the project.

Avoidance

Software development, inundated in innovative tools and technologies, is not the neophobic's heaven. Software engineers, regardless of their level of expertise, may still have gaps in their knowledge as a result of the fast pace of the industry.

Even though this high rate of change makes the IT industry more attractive to some people, it could also make you anxious about being outpaced.

Many experienced developers, faithful to previous technologies or afraid of feeling like a newbie again, avoid learning and using new technologies. Junior developers, likewise, threatened by the sea of information in front of them, don’t implement their knowledge in new projects, waiting until they “learn enough.”

Avoiding novelty, however, is a sure-fire way to getting outpaced by the industry. While mastering all fads isn’t necessary or helpful, hiding in the safe zone hurts your mental health and productivity. Personally, I believe hiding from concepts and tools like ORM, serverless architecture, and PWAs, fearing that I may feel dumb trying to learn them, has been one of the biggest mistakes I’ve made in my career.

Conclusion

Even though software development seems like a tranquil profession, it is full of hidden mental health threats, and, to be productive and fulfilled, you should develop the soft skills necessary to handle these threats.

Working in a dynamic industry with tight deadlines and high expectations, however, many developers neglect their mental health. To me, the most crucial soft skill for IT experts is the ability to handle worry and anxiety.

I, as a developer who has been dealing with generalized anxiety, found exposure and response therapy a helpful and easy-to-use technique to control my worries in the workplace and improve my self-efficacy. I hope it helps you too!