In software, we have the concept of forwards and backwards compatibility when we are talking about changes. (I talk about them briefly here) There's something I mention that over obsessing with forwards compatibility can lead to getting stuck, after all we cannot predict all the changes that may happen in the future. However, there is a whole onslaught of best practices in software that when applied give you a fairly good likelihood that your software will be forwards compatible. At the same time, there may be developments in the future we cannot even predict. And maybe we shouldn't really worry about (I'm looking at you quantum computing).
What came to me as a realisation today is that I apply these same principles in my real life. Maybe that's why I have an easier time than most to deal with push safety. Thing is, at this point in time, I am in exactly that place that I wanted to avoid in software engineering. Over obsessing with the forwards compatibility and planning, to the point where I cannot make the change, for fear things will break.
I am at a place where I am running all the future scenarios and trying to not allow anything to break, which in life is even harder than in software engineering. But as I mention in my post about push safety, there are times when we need to allow things to break. And as long as we know they are going to break, we can handle them breaking. And it is so much easier to get stuck in life on forwards compatibility. All the comparatively simple processes in software have nothing on the full complexity of life. And while in software there may be an easy way out if ruminating enough as, ultimately, software is a very finite collection of processes, life is exceedingly more complex.
So what is holding me back in my real life? Why is it so hard to let go. I have let go of a lot of things in my personal life over the years. Some voluntary, some not. But generally, they had reached a point where it was easy to let go. Even when it was not, I was eventually able to do so. So, what if something is not broken, or not fully broken? However, in order to make progress, I would need to break it?
I think one approach I have taken in the past is to focus so much on the negatives that it would seem broken, and I can think of one case where I would even go as far as to subconsciously sabotage it. Ensuring that it would break. Through seemingly no fault of my own, surely! (of course not, entirely my fault, and fully in my control, that is the whole point of self-sabotage) This is undoubtedly not a very healthy approach to say the least. Ultimately what I am doing here is instead of conquering my fear of change, is creating an even greater fear of not changing. So anxiety all around! Yay!
If I have any good news is that (I think) I am very good at dealing with getting stuck when it comes to software engineering. So maybe what I need is going through the ways to move forward with software development and translate them to real life applications.
Step 1. Be aware that things may break. In software there are rare cases where we cannot predict or test how something will behave under the change. We can be aware of what those things are, but testing them is sometimes not an option. Often because there are too many moving parts. In real life, that's a much larger number of things. Everything has an onslaught of moving, unpredictable parts, which is other people. So maybe the first step is, instead of walking around carefully not to break anything, make a list and bring awareness of what could break.
Step 2. Split the list. Among the things that may break, some will be more and some will be less likely to break. I am prone to catastrophising, so unless reigned in, I will put everything in the high likelihood category. And even if I put them in the unlikely category, I would still feel about them the same way. So maybe I should change my categories. Proposal: Things I need not to break, Things that I can handle breaking, Things that I do not want to break, Things that are better that they break;
Step 3. Minimise the breakage time, and communicate breakages. So yeah, things will break. Maybe what we need to do is notify of breakages. Like when games do a server update, or there's a major version update of a service. Notify everyone, in this case the multiple parts of my brain, that during a specific period, there is a high likelihood that things will be broken. It is deciding on a timeline -- a year or two -- when we allow things to break without worrying that they won't be ideal. If it is a planned outage, then I will be more emotionally prepared for it. That is not to say that fixing the breakage and dealing with it won't be stressful, just less so. If they don't end up breaking, amazing. But if they do, it is an expected thing, it is finite. But most importantly, acknowledging that things will break, may unblock this change from happening, after all there is only so much preparation one can do.
Step 4. Establish a list of best practices that when followed add little overhead with maximal protection against breakages. It may be harder to define these in life. And at different stages in life, they may be different. Savings are a simple one. (And the trickiest one of all. Despite this being the very reason one has savings, why does it feel so bad to dip into them?) There must be others. There are likely plenty I already have built for myself, and it may just take a while to acknowledge them. This is a process. This post in itself is the beginning of this process.
I am still working on this and likely will for a long time. It's strange how easy I used to find it identifying something stuck on forwards compatibility in my work, yet so blind to it in my real life. I am impatient with change, yet more reluctant to change than I thought I was. I put everything in place so as little as possible goes wrong when I do change, but what is that but reluctance to change? I claim to embrace change, yet I have constantly walked the safe path, even if that safety was engineered. And mind you, I do, and I have changed a lot in the last year alone. And yes, a lot of change can happen in safety, and safety is good. But there are changes that will inevitably break things. Maybe what I need to learn is how to voluntarily break those things and be ok with them. After all those are the major changes that ultimately I seek (this is why they call them major versions in software, haha). Major life changes, like transitioning from a degree to a software engineering role, often feel natural in hindsight. But as I now contemplate a shift in career or life path, expecting the same smoothness is counter-intuitive. Things will break. But maybe the new thing will be so much better.
Interested in learning more? Feel free to explore my coaching here and book a free intro call to discuss how I can help you.