Anxiety-Driven Development

Lately, I have had to make incremental progress on a variety of concurrent projects. They vary in subject, duration, and expected delivery time. It takes considerable skill and experience to juggle it all and still meet and sometimes exceed expectations.

How do I balance it all? I anticipate the next incremental improvement that would have the most impact for the schedule I am planning to deliver for. The strongest signal that I pay attention to is anxiety.

What am I worried about? What do I fear will happen or be messy if a certain thing isn't the next to be delivered?

Constructive anxiety

Anxiety and stress can be used constructively. Without stress, there would be stagnation. Innovation comes with changing demands, needs, and competition.

With experience, projects and their tasks can be guided and prioritized by listening to one's anxieties. Typically, anxiety will come with pain. My trick to mitigate this is to keep my mind clear. I achieve that by writing what needs to be done, what I communicated, any decisions made, solutions and proposals. When information is safe to forget, I can let go and clear my mind — I can always go back to read what I need to know later.

Use GitHub issues, Jira, Trello, Taiga, bullet journals — whatever floats your boat in keeping your workload manageable and outside your head. Communicating to your future self and your peers is vital to constructively channeling your anxiety.

Once the information is outside of one's head, it will be far less painful to bear and process. Anxiety around the documented subjects will inform its priorities and, at times, define the scope and effort budget each task has.

As long as there is no crunch time, where tasks and duties can be chipped away on a predictable schedule, the risk of burning out is greatly reduced.

Anxiety is also useful in signaling whether you need help or if a task won't be delivered on schedule. One of the most important career lessons I had is learning to escalate and communicate when things aren't going as planned. Anxiety can nudge you to start these conversations and they are vital to meeting expectations with those around you.

Anxiety can be a part of a healthy and productive way to work, as long as it is handled carefully and acted upon regularly.

How others use anxiety and pressure

And as Brandon Sanderson said in It's Time to Come Clean:

The last few years have for been hard for many of us. These are strange times. In particular, these last few years have increased pressure in a few different ways — emotionally, and mentally. To the point where I could no longer continue working on my series and books as I always had been before. As this pressure mounted, something had to give. I thought I could handle it like I had before, but that proved optimistic. And so, the time has come for me to admit the truth. I've been lying to you. Over the last two years, I've acted with extreme irresponsibility. Because, I accidentally wrote an extra novel — in secret! I apologize. I couldn't help myself. We all respond to pressure in different ways. I, it might be said, responded characteristically.

After a successful launch of a Kickstarter, Brandon released four new books over the next year. As Brandon shares in his video, he found that with much of his travel and public engagement time minimized, he not only had more time for writing — he had more time for his family too. Brandon used the new pressures brought by the COVID-19 pandemic in a constructive way.

As the prolific author and blogger Cory Doctorow said in an interview in Examining Capitalism's chokepoints @Changelog:

I write when I’m anxious. So lots of people are paralyzed when they’re anxious; what I do is I outrun all of my problems by disappearing into work.

On the surface, this quote would suggest an unhealthy relationship with anxiety. Running away from problems by working? That sounds like workaholism.

Any coping strategy to stress and anxiety can be harmful when taken to an extreme which endangers the wellbeing and happiness of the individual and those around them. The important part is harnessing what you are feeling to benefit yourself and those around you.

Cory harnesses his anxiety to write. The topics he writes about are likely tied to what he is anxious about too. His anxiety is used constructively to share his ideas to the world.

Anxiety and you

Anxiety and pressure can be used to further our own goals. Anxiety, when channeled in a useful and constructive way, can help us identify and improve the world.

Those that harness anxiety and pressure have a certain characteristic: they improve the world around them when they feel anxious. Many of them know the source of their anxiety; their efforts are thus targeted in resolving or mitigating specific sources of anxiety.

To positively harness your anxiety, you need a reliable method to reduce it. That method should incrementally improve something in your life — something that you care about.

To intentionally harness your anxiety, you must consistently identify specific what-ifs that you have the capability to change, and your method addresses those specific what-ifs.

When I am under pressure I write about what worries me — ideas on how to resolve those worries, the difficulty of acting on those ideas, and what I can incrementally do to achieve them. Each step is refined with feedback that I pull from my anxieties.

Software development vs software engineering

“Software development” and “software engineering” are often used interchangeably. For this article, “software engineering” will come with a specific characteristic: engineered software is intentionally designed to gracefully handle intended and unintended circumstances in a wide variety of configurations.

What is it that distinguishes engineering from other disciplines? … One of the pioneers of software engineering, in fact the first software engineer, identified a key behavior that is essential to an engineering approach. … The vital shift in focus from what happens when everything works as we expect to the engineering focus on what could possibly go wrong.

Thinking about how things may go wrong and actively exploring those unhappy paths, is to my mind, is at the heart of a good engineering approach. Working hard to simplify things so that we reduce the corners in our software where nasty problems can hide is the difference between good systems design and bad. This seemingly negative mindset is actually the opposite of that. This is at the core of good engineering, and it works at every level. ― The Difference Between Developers & Software Engineers by Continuous Delivery

It is not enough for software engineers to focus on unhappy experiences. They prioritize what should change and how much effort they can expend to achieve their goals and mitigate risks. Along the way, they continuously balance their capabilities and resources with the project. With each success and failure, they learn the nature of the problems they solve and the risks they face.

By shifting our focus from what works to what could possibly go wrong, we become proactive problem-solvers, capable of building robust and reliable software solutions. Embracing the possibilities of what could go wrong allows us to identify potential risks, adopt a systematic approach, conduct thorough testing, and learn from failures. ― The Engineering Mindset: Embracing the Possibilities of What Could Go Wrong by Plan Fast Blog

It just so happens that a fair proxy to assessing risks and effort required is one’s own anxieties.

Optimal settings for anxiety-driven development

As engineers, we proactively address risks. With experience, we identify and document risks, produce plans, and methodically decide on resource allocation, and timelines, and so on to be successful. We cannot predict the future; we will even make mistakes, we learn from those mistakes and improve our processes to account for what we learn.

Organized software engineering is rigorous, high-detail, and slow — compared to software development. It takes time to research the problem, invent test cases, implement the solution, and verify the solution across many test cases and configurations.

What if you are under pressure, working on projects alone, and you have the experience and history of delivering solid solutions in those conditions?

There is a way to lighten the rigorous nature of engineering, while releasing robust products we can be proud of. It works best when the level of detail is aligned with one's role. For example, someone that contributes code will have to be deeply involved with every detail of its evolution for anxiety to provide accurate feedback.

Should the scope change mid-project, there will be a lag time of when anxiety can provide accurate feedback. Any engineer, manager, or otherwise, will need to thoroughly understand the new scope before listening to their anxieties again.

Harnessing anxiety to engineer software

The first step is to write down the work as ideas and concerns come. It should not surprise anyone with experience in managing projects: the work that needs to get done should be written down. It could be with tickets, bullet points in a journal, or index cards on a cork board. The work must not be held in one's head, otherwise anxiety will be unspecific and unhelpful.

If you are busy with a task and you discover a risk or gap, write it down! It does not need enough detail for someone else to understand, as long as future you in two weeks or two months can understand it.

The second step is, when choosing the work to do, regularly assess and order the tasks that are coming next. Rely on your anxiety to point out what task worries you the most if it isn't done.

Take the time to think of a solution for the top few tasks. Like before, the goal is to clear your mind so your anxieties are specific and useful. A second goal is to then estimate a level of effort. This estimation could be written down, or kept in memory, as long as not too many tasks are kept in mind.

If you find that a task might take more than a week, that is a good sign to break it up. Individual tasks should comfortably sit in memory and have a well defined scope. Although anxiety is a part of the process, the tasks themselves should not be stressful. It is fine to take extra time in a theoretical space to break things apart — you might even find that there are better and simpler solutions after making tasks fit into a comfortable size.

Now, with ideas and efforts documented, reassess the top ideas again and choose the task that, if not done at all, would worry you most.

For example, suppose an application has had database performance issues lately and application performance degrades each day at peak business hours. On the other hand, something constantly logs 100 gigabytes a day to the database and its storage costs are going up an extra $1000 every month. Which of these might cause a bigger mess? Downtime? Or breaking the budget?

Downtime would cause the most people pain, not just customers, but also support, sales — all sorts of people that I know on a first name basis. I would prioritize this first, if I had to choose between those two.

Empathy is an important skill in anxiety-driven development. You don't need a cost–benefit analysis based on projections and made up figures if you can make a quick and accurate decision in the moment with empathy.

As you act to complete the task, explore the happy and unhappy paths within the scope of that task. Do what it takes, within the level of effort decided, to make sure you don't have to come back to it later.

Without an engineering approach, software developers “move fast and break things;” they release buggy products that require rollbacks and multiple follow-ups to improve. They create more work for themselves and others in cleaning up the messes and making customers whole. All this extra work burns them and their peers out.

It takes less time to double check your own work than to clean up a mess. As you develop with this method, double check your work. Take a step back and pretend you've never seen it before. Role play as one of your peers and verify the assumptions in every change you are releasing. QA your own work and the areas around your work. With empathy, take the seat of a customer and try it out. Use the same equipment they use and see how your work holds up. Make something you can be proud of.

Once you are done with it, let go. Allow yourself to forget. Again, your anxiety can only be directed and specific if your headspace is clear.

Once more, take a fresh look at the world around you and see what worries you. Your feelings might have changed since the last iteration. You might have learned something new.

Flow diagram of anxiety driven development

Final thoughts

Anxiety can replace a lot of tedious rational decision making and empower you to respond to the world in a flexible and agile manner. Your anxiety is subjective and the conclusions you reached can be challenged by others. As a practitioner, you will have to continuously learn from your peers and the environment. You must apply empathy of your peers and customers to make better decisions in the future.

Anxiety-driven development does not have to be stressful. You can deliver consistent, robust solutions by following an engineering approach, even under pressure. As long as you communicate to yourself and your peers what you are expecting of your work, you will make products you can be proud of.