On anxiety & premature optimisation
In this blog post I will discuss how the following framework can apply to instances of both premature optimisation & anxiety, and how others caught in the junction of technology and anxiety can utilise it to rationalise their thoughts:
- Identify Concerns and Opportunities
- Evaluate Impact and Outcomes
- Decide on Actions
- Set Limits
- Reflect and Adjust
Preamble...
I understand computers much better than I understand people. And I barely understand computers, so lord knows how I get through the day, really.
I often find it helpful to intentionally view the real world (the Outernet) through the lens of computing:
- the same skills one uses for discussing technical problems with nontechnical audiences can be used to discuss emotional issues with those who relate less,
- knowing how to organise and assume leadership of groups is a lifesaver for larger social events, and
- treating anxieties as premature optimizations can help rationalise them.
This last one in particular is something that clicked for me recently, & the one I want to talk about here.
Drawing parallels
From a very high-level perspective…
Premature optimization, cited as the root of all evil, is spending time and effort on hypothetical problems – building a highly sophisticated infrastructure to support millions of users when you have a half-featured product and five customers, or building a component into your design system for an element you use exactly once. A lot of these problems are ones to be aware of, and having awareness of them can help you prepare in the long run – but acting upon them now could be an unnecessary use of resources.
Anxiety, cited as the root of all evil, often involves worrying about hypothetical problems. The “what-if’s” of the world. How would I cope if I lost my job tomorrow? What if my friends just pretend to like me? What if my dog doesn't love me anymore? A lot of these problems are ones to be aware of. Having awareness of them can help you prepare. But spending the effort trying to solve them when they are so detached from your actual reality could be an unnecessary use of resources.
There are plenty of parallels between the two of them, but in my day-to-day life I treat them completely differently; whilst I try to be conscious and critical of premature optimisation, I let hypothetical anxieties sit in my mind for hours on end, expending time and effort on them. Taking the same critical approach I take towards optimisation towards the anxieties I have lets me rationalise and process them in a clearer way. Is this a problem I can solve? Is this a problem I need to solve? Is this a problem I need to solve now? Or, most importantly, is this a problem?
A process for premature optimisation
A broad-strokes process used for identifying premature optimisations could be as follows, using the case study of deploying an application to the cloud.
- Identify Concerns and Opportunities:
- Deploy the application on Heroku for ease of setup and maintenance
- Set up a scalable infrastructure on AWS to handle large scale from the start
- Evaluate Impact and Outcomes:
- Heroku: Lower upfront cost and effort, suitable for small to medium traffic, and easy scaling up to a moderate level.
- AWS: High initial setup complexity and cost, but suitable for handling very high traffic and scaling extensively.
- Decide on Actions:
- Given the expected current small user base, deploying on Heroku is more appropriate. This avoids the premature optimization of building a large-scale infrastructure that is not yet needed.
- Set Limits:
- Decide on a threshold of user activity or other performance metrics that would trigger a reevaluation of the hosting needs (e.g., response times, server load, monthly active users).
- Reflect and Adjust:
- Monitor the application’s performance and user growth on Heroku. If the thresholds are reached, reconsider the scalability options & possibly transition to a more robust AWS setup.
This flow helps you identify and mitigate premature optimisation – the “imaginary problem” you are solving is having too many users. Whilst this could be a problem in the future, it is not yet and solving for it would slow other, higher-priority tasks.
The same flow can be applied to anxieties.
Applying this in the real world
Navigating the emotional complexities of a new relationship can be challenging, but by analysing your anxieties the same way you would with technical optimisations, you can prioritise where to spend your energy. Let’s look at some examples:
- Identify Concerns and Opportunities:
- What if my partner doesn't like me as much as I like them?
- What if things end badly?
- Evaluate Impact and Outcomes:
- Difference in Attraction: This is a common worry. Whilst possibly causing distress, it's often exaggerated in our minds.
- Relationship Ending: This is a concern! Relationships can end, but preemptive worry can obstruct the relationship's natural growth and the enjoyment of the present.
- Decide on Actions:
- Reasonable Optimizations: Invest in getting to know each other, sharing experiences, and maintaining open communication. These efforts build a robust foundation for whatever the relationship may become.
- Premature Optimizations: Constantly analysing texts or conversations to assess their feelings, or worrying about the end before it’s anywhere in sight, diverts energy from enjoying the relationship.
- Set Limits:
- Remind yourself to avoid overthinking interactions or potential future issues. Communicate openly about real problems you have with your partner, which will help you spend your energy and worry in more useful places.
- Reflect and Adjust:
- After some time in the relationship, reflect on how your actions and boundaries have affected its quality and your emotional state. Were your initial worries addressed effectively through your chosen actions?
And with this process complete, the initial anxieties have been rationalised and the actions you could take upon them have been prioritised.
Closing thoughts
To summarise, the generic steps of this process are:
- Identify Concerns and Opportunities:
- Take the time to reflect & identify the [potential optimisations OR anxieties]
- Evaluate Impact and Outcomes:
- Analyse each of these and list the significance of them, as well as what you would achieve by following them through
- Decide on Actions:
- Using the previous analyses, decide which actions are reasonable and which are premature
- Set Limits:
- Set a threshold or action points to pursue which will help you decide if it’s time to re-evaluate the solution
- Reflect and Adjust:
- Reflect on this process, decide what changes you need to make, and iterate on your solutions
Framing anxiety as premature optimisation resonated with me and provided a clear, practical way to rationalise my own concerns. This analogy was the moment that 'clicked' for me, & I share it with the hope that it helps other anxiously technical and technically anxious people.
P.S: In writing this blog post, I learned that it wasn’t an original thought at all. In fact, there’s a whole field of study dedicated to using computer models to understand anxiety which I am keen to learn more about.