Originally published on March 10, 2021
How Can Software Development Teach Us to Engineer Away Anxiety?
If you read my first book, then you’ll know I’m a bit of a computer nerd. In fact, developing software is the primary way I make a living. While I love writing, it’s not yet quite as lucrative for me as programming computers is.
If you think about software development and the writing of mental-health-related content, you might conclude that the two subjects have almost nothing in common. And while you’d be right in some regard if you thought this, there’s more of a connection between them than meets the eye. Well, at least I think there is.
In this post, I’ll discuss what some of those specific connections are. And, better yet, I’ll position the conversation in a way that allows us to approach anxiety in a relatively new fashion.
So, just what are the connections between developing software and writing content about mental health? There are many, in fact, one of which I talked about in my first book.
That first connection stems from the fact that how we act (and how software programs run) comes down to our current internal conditions — our state, if you will. For us humans, we can think of “state” as how we’re feeling right now. For software programs, we can instead think of it as the data and variables said programs are paying attention to. More on this last point in just a minute.
The most important thing about state, for both us and software programs, is that it determines (or at least strongly influences) how we function. For example, when we’re in an unmotivated state, we’re unlikely to jump off the couch, strap on our running shoes, and head outside for a jog. Or, when we’re in an anxious state, we’re more likely to worry, pace around the room, or breathe in a shallow fashion.
The same concept applies to computers and software. For example, let’s say we’re playing a video game, such as Super Mario. By default, when Mario gets hit by an enemy, he becomes critically wounded, and the game or level starts over.
However, when Mario eats a mushroom, assuming it’s his first, he grows in size and takes on a new state. We could call this the powered-up state. Once in the powered-up state, Mario can withstand two hits from enemies before becoming critically wounded. Thus, we can say the video game keeps track of this state-based information and bases its gameplay upon it.
Now, of course, there are numerous different states that video games or software programs could and likely do track. There are also many other fun Mario games we could discuss together. But let’s forget all that for now. Instead, let’s focus on the fact that current conditions — whatever they may be — typically drive behavior in human beings and functionality in software programs.
Continuing down this path of “state,” we can draw a unique and essential conclusion about our own behavior and, more importantly, our mental health. That conclusion is that if we want to change our behavior, we may first need to change our state.
For example, if we’re not feeling motivated to work out, instead of forcing ourselves on a five-mile run, maybe we could get off the couch and do five quick jumping jacks. Though I obviously can’t make any promises, it’s more than possible that such an action could put us into a slightly better state overall, which might change our outlook on getting outside for that jog. Momentum often builds quickly once our state improves.
Or, if we’re feeling anxious, instead of willing ourselves to stop thinking negatively, what we might need to do instead is get ourselves out of our anxious state; in a more positive one, negative thoughts won’t find us as easily. Though we all have our own favorite anxiety-busting practices, we could potentially move to a more empowering state by dancing to our favorite song or immersing ourselves in cooking our favorite meal.
The main thing to remember here is that state changes don’t necessarily need to be immediate or abrupt. Instead, we can slowly pull ourselves out of one state and into another.
In fact, beating ourselves up for not being able to spring up off the couch or immediately turn off our negative thoughts only causes us to feel worse, which typically starts the state-and-action cycle all over again. Not great, as you can likely imagine.
Changing our state gradually and on our own time, oddly enough, leads me to the second connection between software and mental health that I want to discuss. That connection stems from one of the common ways engineers breakdown and complete tasks, and it’s what we’ll talk about in the next section.
Breaking Large Tasks Into Smaller Ones Can Also Help Engineer Away Anxiety
For a minute, let’s pretend we work at the cool new tech company in town. This week, we’re going to add some fun, new features to our mobile app. The biggest of those features is the ability to message other users on the platform.
About a decade ago, when I first started writing software, gargantuan tasks like these always seemed rather daunting. As soon as I started thinking about completing such tasks, doubts and questions would flood my mind. “How am I supposed to build this whole thing? Where do I even start? Do I have any idea as to what I’m doing?”
As you can likely imagine, these questions typically put me in an anxious state. In that state, I often overthought everything I was doing, stopped breathing fully and deeply, and worried whether I’d even be able to complete the task at hand. Luckily, however, I put such unhelpful thoughts and behaviors behind me once I learned the art of user story writing.
Though it’s not necessarily a mind-blowing concept, it’s still a handy one that thousands of techies use daily. In a nutshell, user story writing is the process of defining a task, and all of its details, in a written format. That format can be anything we choose, though some common ones involve Excel Spreadsheets, Google Spreadsheets, or project management tools like JIRA and Trello.
With our current example, we could start our story development process by writing our big “messaging” task in plain English. Something simple like “As a user, I want to message other users” will do. From there, we could add relevant details about the job itself, such as who will provide the designs for the feature or how it should function in specific states.
Now, the beauty of good story writing is that it forces us to break the task at hand into smaller pieces. These pieces are usually called subtasks, and they help us track our progress on the story, overall.
When building our messaging screen, there are countless different subtasks we need to complete. For example, we need to pull any previous messages from a web server or database and add them to the chat.
Next, we need to show each of those messages in the chat interface itself. And, finally, we need to add the ability to type and send a new message. Of course, these aren’t the only tasks required, but they make up the bulk of the work. Thus, we’ll focus on these alone, for argument’s sake.
From there, we could even break these tasks down further if we think it will streamline the implementation process. For example, if we’ve never before connected to a remote server and pulled down data, then we can break the task of pulling down previous messages into two parts.
First, we could write up some test messages and put them in a text file or spreadsheet that lives in our application. Then, we could have the app load that file (as if it’s our server) and pull its messages into the app. Setting things up in this fashion lays the groundwork for our second subtask — talking to the server and grabbing the actual messages.
The great thing about structuring our work in this fashion is that once we’ve completed the first step of loading messages from a file into the chat interface, we can focus squarely on connecting to the server. After all, if we’ve already written the code that packages our messages into a digestible format and shows them in the chat, then all we need to do to finalize the larger task is replace the notion of pulling the messages out of a file with pulling them from our server.
Of course, there are a million different ways we could apply this sort of logic. However, the main point to drive home here is that we can and should break large tasks into more manageable, smaller ones. These smaller ones, in the case of developing software, even help us more reliably keep track of our progress toward the overall goal — finishing and delivering the messaging feature.
Another thing these subtasks do is help us avoid unnecessary overwhelm. When looking at one massive task or story, it can be hard not to freak out or wonder how we’ll ever be able to get it done. But with subtasks, we break that enormous task into bite-sized chunks and focus our efforts on one item at a time until it’s complete.
Now, while I could sit here and write about software development all day, I’m sure you’re probably saying to yourself at this point, “Okay, dude, this is cool and all, but what exactly does this have to do with mental health?” That’s a great question, and it’s what we’re going to talk about next.
Engineer Away Anxiety, Even Outside of the Software Development World
At the beginning of this post, I said I’d position our conversation on the connections between software development and the production of mental health content in a way that allows us to approach anxiety in a relatively new fashion. Here’s where I’m hoping to do just that.
So, just what does that approach look like or mean? It means that when it comes to anxiety — whether it’s getting out of the anxious funk we’re in or doing something that scares us — we also need to break the task in front of us into smaller pieces and complete each one, one at a time. Doing so helps us keep a cool head throughout the execution of whatever it is we’re trying to do.
Now I’m sure that sounds both vague and confusing, so let’s round out our discussion today with one final example. For argument’s sake, let’s say you have to write a big paper for one of your classes. If you’re no longer in school, then I’m sure you’ve written a fair amount of essays in your life and can still relate.
When it comes to writing, many people get writer’s block because they don’t know what they’re going to say, while others get anxious because they have no idea how they’re going to complete the task in front of them.
I don’t know about you, but those sorts of roadblocks sound like they relate well to the example we just walked through. You know, the one where we took the hypothetical task of building a messaging screen in a mobile app, broke it into manageable pieces, and knocked each piece out one-by-one until we finished the job in full.
That’s what we’re going to do here as well. That is, rather than stew in our anxiety over the massive assignment, we’ll start by coming up with a bulleted list of the five main points we want to make in our paper. Then, we’ll find supporting information or documentation that helps back up each point.
Once we collect that supporting info, we’ll have everything we’re going to write about, so we can take a crack at our opening paragraph. In that paragraph, we’ll outline what we’re going to discuss in the paper and prepare the reader for the five bullet points we just brainstormed.
From there, we’ll write each body or bullet-based paragraph — one at a time. The important thing here is to never let the magnitude of the assignment, as a whole, work us up or make us anxious. Whenever we sense such feelings coming on, we’ll simply remind ourselves of the current subtask we’re working on, reconnect to it, and focus squarely on it once more.
Once we’ve written our body paragraphs, we’ll work on our conclusion. There, we’ll round out our paper by quickly recapping what we talked about and providing any concluding statements we wish to make. From there, we’ll have a first draft, which we can then read through and make continual tweaks to until we feel good about the paper as a whole.
And, so, just like that, we can write an entire paper without a crippling amount of fear or doubt that we’ll be able to do such a thing. This is what it means to engineer away anxiety — to break down the task in front of us in a systematic fashion, taking our focus off the high and distant mountain top above us and placing it on the next step on our path.
Now, of course, I realize that not all of us will be writing papers tomorrow. I also understand that not all of us are software engineers. But we can all be anti-anxiety engineers if we regularly apply the methods I’ve laid out here. Because let’s face it — all of us frequently face large and challenging tasks, regardless of the specific kinds they may be.
If we remember the parallels between software development and mental health that I’ve outlined here, then I think we can better position ourselves to skate past anxiety when these kinds of tasks show up in our lives. Moreover, if we recall such connections, then I think we can also remember to view these big tasks in a way that activates the fear circuits of our brains far less frequently.
This, as you might also guess, does one final and helpful thing. That is, it keeps us in more empowering and resourceful states. In these states, our creative and cognitive abilities are much more accessible to us and much more likely to help steer us away from any potential fear, uncertainty, or doubt we may face along the way.
Thanks for Stopping In. Want to Keep the Reading Train Rolling?
Then check out some of my other articles on mitigating anxiety. Here are a few recent ones that I recommend:
**Photo by heylagostechie on Unsplash