Originally published on March 10, 2021
How Can Software Development Teach Us to Engineer Away Anxiety?
If you read my first book, you’ll know I’m a bit of a computer nerd. In fact, developing software is how I currently make a living.
Now, don’t get me wrong — I love building the Get Out of Your Head® brand and would be thrilled if given the opportunity to lean into it further. However, at the moment, it doesn’t exactly pay the bills. So, until I decide to take a “leap of faith” into self-employment, all I can really do is keep working hard and hope the publishing stars eventually align.
Of course, that’s not to say such an arrangement is all bad, though; truth be told, having a stable job in the tech sector has been super valuable for my writing endeavors — not only because it’s kept the proverbial lights on but also because it’s helped me uncover several unexpected connections to the mental health realm.
It’s such overlapping concepts and perspectives — ones that help us ward off our psychological foes (or “engineer away anxiety,” as I like to say) — that I want to cover in this blog post.
The first one I’d like to discuss goes something like this: our current internal conditions or emotions (which we can refer to as our “state”) influence, if not determine, how we think and act.
For example, when we’re hungry, we’re much more likely to eat something than when we’re not. And when we’re nervous, we tend to do things that mirror our inner sense of fear, such as pacing around our rooms, ruminating, or breathing shallowly.
The same concept applies to computers and software.
For instance, if you’ve ever used Microsoft Word, you’ll know that, in order to save what you’re working on without using a menu or keyboard shortcut, you’ll need to hit the little floppy disk icon near the top of the application. That said, unless you’ve modified your file since last saving it, that icon will either be grayed out or unresponsive to your clicks.
This phenomenon depicts state management in action: the program keeps track of its current configuration (ex: “no changes” or “revisions detected”) and alters its behavior accordingly. And that means, when it comes to that little floppy disk, if you want your clicks to register, you’ll need to keep tapping your keyboard.
Okay, so I’d imagine this general concept makes at least some sense by now. The problem, though, is we still haven’t explained how it relates to our mental health. Yet, fear not — that’s where we’re heading next.
To put it plainly, the reason this engineering-oriented logic is so critical for our well-being is it shows us that one of the best ways to change many of our undesirable behaviors is to first change our state.
For instance, if we’re feeling apprehensive, instead of willing ourselves to stop thinking negatively (a very challenging assignment), we’d be better off trying to get ourselves into a different, more empowering internal configuration. That way, our actions will shift naturally and mirror our new frame of mind.
We could do such a thing in a myriad of fashions, be it going for a walk, dancing to our favorite song, cooking a new dish, or something else entirely. Yet, no matter how we achieve such a feat, the end goal will be the same: to evoke some uplifting emotions and have them push fear aside while placing us back on a calmer, more productive path.
Engineer Away Anxiety, One Step at a Time
Alright, so we’ve got that one down — onto our second and final technology-meets-mental-health connection: the importance of breaking overwhelming tasks into more manageable pieces to avoid distress.
To help explain this one, let’s pretend you just joined the tech world and are set to develop a big feature for your company’s new mobile app: the ability to message other users.
Given the size and scope of this addition and your lack of previous experience, you’re quite nervous about it. As such, you ask yourself a slew of fear-inducing questions, such as, “Where do I even start?” and “How will I ever get this done in time?” Unfortunately, you don’t have great answers to either of those inquiries. Thankfully, however, your apprehension soon retreats as you learn a critical, accompanying skill: the art of user story writing.
In brief, this term refers to a process from the software world where a product team spells out its work as if it were the customer. As it pertains to your big messaging project, what that might look like is jotting down your end goal (“As a user, I want to message other users on the app”), then adding necessary, relevant details, such as how the feature should appear or function in certain scenarios.
Now, the beauty of good story writing is that it forces us to break the task at hand into smaller, more approachable chunks. Most of the time, those pieces will come in the form of subtasks, which help us better define our overarching mission and track our progress on it.
In terms of your hypothetical assignment, there are countless of these supporting chores to draft and complete. For example, you’ll first need to load the current user’s prior conversations from your firm’s web server and show them on the screen. Then, you’ll need to let that same individual tap into a specific chat — something that requires even more subtasks (fetching that discussion’s history from “the cloud,” displaying its pre-existing contents, and providing a way for users to send additional messages). And finally, you’ll have to build a tool that allows customers to start entirely new exchanges.
In my opinion, and echoing what I mentioned a minute ago, the best thing about thinking in this manner is that it pushes us to componentize our work until we understand its scope in full or have identified and separated out the one or two pieces we don’t yet know how to accomplish.
As a further example of that, let’s say you’re getting ready to build your company’s big messaging feature but have never connected to a remote server before. Instead of allowing that one chore to overwhelm you or spoil the entire undertaking, you could tackle what you’re more familiar with first, then split the daunting task of fetching old messages into three clarity-seeking parts.
Specifically, for task one, you could type out several test messages, copy them into a text file in your app, and have your code load that file (as if it were a web server). Then, for task two, you could find a colleague who knows how to connect to your organization’s database and leverage his or her expertise to write a script that facilitates such an action. And finally, you could bring both pieces together by tactfully merging your work from steps one and two.
What makes structuring things this way so helpful is that it isolates your uncertainty and puts a plan in place to mitigate it. After all, once you’ve written the code to grab and display your file-based messages (a chore you already know how to perform), you’ll have an app that looks like it does everything it’s supposed to. And that means you can then focus squarely on connecting to your organization’s server without feeling disheartened about the magnitude or seeming perplexity of the assignment at large.
Now, if you’re thinking that all of this software talk sounds a lot like “taking things one step at a time,” you’re right. And, despite that phrase’s potential cheesiness, it’s honestly a pretty sound strategy, as it helps us simplify our pursuits, build confidence, and address what we don’t know with slightly more poise.
And even though it may feel like this process only applies to writing computer code, I can assure you that’s not the case; the same principles are in play for a multitude of other disquiet-inducing tasks on our plates.
For example, maybe we have to give a presentation to a large audience next week. Instead of stewing on it and worrying about how we’ll ever deliver a composed and coherent pitch, we can sit down and break said undertaking into smaller parts — namely, researching our subject matter in depth, creating an eye-catching slide deck, rehearsing our lines, traveling to the site of the presentation, and, finally, giving it in person.
Though it doesn’t take a genius to determine the most unsettling of those five subtasks, it still makes little sense to dwell on it, as doing so would only cause the entire endeavor to become shrouded in fear. Thus, to help us avoid undue trepidation and build momentum, we should focus on the remaining four — the ones we know we can accomplish without concern.
The same goes for many other distressing duties, such as writing ten-page papers or cleaning our houses. That is, to prevent such projects from engulfing us, we must separate and reduce them into well-defined jobs and focus on the ones we’re most comfortable with until we’re either done with our work or feeling confident enough to turn and face the troublesome pieces that remain.
And while I admit that this technique isn’t appropriate for all dread-provoking situations, it’s still an invaluable skill to have in our toolkits because it helps us approach our difficulties from a higher, more observant level. As we strive to live in alignment with it, we’ll not only take our original computer-oriented insight to heart (by regularly putting ourselves in more empowering states), but we’ll also act like seasoned technology professionals more frequently and “engineer away anxiety” with greater ease.
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:
Einstein Applied to Anxiety: The Case for A New Approach to the Problem
“Breath Focus Outcome”: An Anti-Anxiety Mantra
**Above image designed and owned by Brian Sachetta © 2023