Working as a software developer comes with many perks: you can work remotely (or from coffee shops), you get to see your work used by thousands of people and you are almost forced to learn continuously. But one of the most interesting perks is the ability to reproduce processes and metrics from software development in real life.
Let me explain.
Working With Versions
As you already know, applications come in versions. It is something so common that hardly anyone wonders why is this happening, why do we actually use versions.
Well, imagine an app, called Skype, without versions – it’s just called Skype, and that’s it. How would you know what features does it have? How would you know how compatible is with your device or operating system? How would you know if it’s the latest release or an older one?
Versions are milestones in the life of a product. That’s how we know what we can actually use from that package.
Now, take this up a notch and think about yourself, as a person. We don’t work with versions when we want to describe the life of a person, we work with age, measured in years. Personally, I find this useless (when I don’t find it ridiculous, that is). What real relevance my age has? It is a very wide metric and also a very coarse one. It can, at most, tell if I’m young, mature or old. And that’s it.
But even in my “young” period, I may go through many, many versions of myself. In one version I will have a certain set of skills, while in the next one I may have an improved one. In one version I will relate in a certain way, while in other I can relate in very different ways, consistently.
If we’ll use versions instead, borrowing from software development, we may be able to understand ourselves (and others) better.
Here are just two simple parallels: obsoleting features and superseding requirements.
Obsoleting Features
If some feature gets improved in an app, its former implementations are obsoleted. They may still be present in that app, for compatibility reasons, but they are not considered useful anymore.
Similarly, if some way of doing things in our lives is improved, the old ways of doing the same thing should be obsoleted.
Let’s take our reactions, for instance. Reacting with anger to certain events may have been one of our features. We may have even considered this a very good feature: “this guy crossed me on the highway, I’m gonna swear the hell out of it”. Or: “that person said something bad about me, I’m gonna smear the hell out of their reputation”.
Because it made us feel good in the moment, an angry reaction is considered, by many people, a good feature to have: oh, man, I’m so relieved now, I “just let out some steam”. In reality, an angry reaction is a very bad “feature”. It destroys our inner balance, it generates violent ripples outside and its long term effects are very toxic.
So, if after a lot of work on ourselves, we get to improve our reactions to the point that we can consciously avoid anger, we’re literally obsoleting that “feature”.
But here comes the interesting part: after we obsoleted angry reactions, we may be again in a context in which other people saw us reacting with anger. Surprise-surprise, our current reaction is very different now. And people may have the impression that we’re somebody else.
In a sense, we are. The version of “us” they still have in their minds is very different from the current, live version.
Usually, when this happens, some distance appears between the persons involved. Because “we don’t recognize you anymore”, the people around us tend back up. It shouldn’t be that way.
Instead of accepting this distance, a better approach would be for us to step in and communicate the fact that only one feature changed, not the entire app. Actually, the entire app got improved by this new feature.
Superseding Requirements
While developing an app, some requirements in the roadmap may change. Either they are not possible at the moment, or a better, more useful requirement will include or improve the current one. When this is happening, we say that we are superseding a requirement.
Similarly, if some goal in our life is not necessary anymore, or when something better, more useful comes around, we should supersede the old goal.
For this one, I’m going with a personal example: ultra-running. When I was really into “pushing my limits” as a runner, I was following goals more and more ambitious. I went from 5k races, 10km races, half-marathons, full marathons, 50km ultra-marathons up to 100km and even 222km ultra-marathons. “Pushing through” was the requirement.
But then, at some point, I discovered something more beneficial, namely “letting go”. I observed this during a 48 hours race, after almost a day of continuous effort. Somehow, “pushing through” wasn’t as beneficial as “letting go” anymore. So, I superseded the “pushing through” goal, accepted that I wont finish that race and just “let it go”. I felt very well afterwards.
Unfortunately, this process of superseding goals is difficult, because we tend to develop strong attachments to our goals. We identify with them, and when something better comes, we fail to see it – or even if we see it, we fail to follow through, by fear of not “losing ourselves”.
So, instead of seeing ourselves as one monolithic “me”, it may be more useful to see ourselves as stacked up versions of the same app. In our current version we may want to implement certain requirements, but let’s try to be open, understand that things may change, life will change, and in the next version some of our current requirements may be superseded by something new.
And that “something new” is usually way better than what we have, if only we would take the time to see it and accept it.
Image by Christopher Kuszajewski from Pixabay
