Semantic versioning the self

“Semantic versioning” is a process used to label and track product updates. As explained by John Romkey:

“…when you see a version number like 10.3.2…

– “10” is the “major” version number. This changes infrequently (once a year in Apple’s case) and indicates substantial changes that may not be backwards-compatible. These may be a significant user interface overhaul, removal of support for certain frameworks or types of apps, or the addition of a shiny new functionality.
– “x.3” is the “minor” version number. It changes when new functionality is added without breaking old software.
– “x.x.2” is the “patch” number. It changes when a release fixes bugs whilst adding no new features and breaking no old software.”

When I read the above, I began to wonder, “Is the notation system of MAJOR.MINOR.PATCH useful outside the domain of software?” Answer: Yes. We can use semantic versioning, not only on software, but on the self.

Consider the three concentric rings of belief:

We hold few “set” beliefs, multiple “stable” beliefs and many “shifting” beliefs. This three tier structure is analogous to semantic versioning’s MAJOR.MINOR.PATCH notation. Set beliefs are few, rarely updated, and have significant consequences if changed. Stable beliefs are more numerous, infrequently updated, and have minor consequences when changed. Shifting beliefs abound, are frequently altered, and have mostly superficial consequences. But how do we label them? It’s easy with software. But with the self? Not so.

The first roadblock to figuring out the semantic version of the self is determining a scheme for allocating the major version number. How do we decide what number we’re currently on? In my eyes, the best way to do this is using milestones. I’ll use myself as an example.

– Matthew Sweet, Version 0.x.x. A foetus in the womb.
– Matthew Sweet, Version 1.x.x. Baby.
– Matthew Sweet, Version 2.x.x. Toddler.
– Matthew Sweet, Version 3.x.x. Primary school.
– Matthew Sweet, Version 4.x.x. Secondary school, football player.
– Matthew Sweet, Version 5.x.x. Secondary school, basketball player.
– Matthew Sweet, Version 6.x.x. College, basketball player.
– Matthew Sweet, Version 7.x.x. Late teen, layabout.
– Matthew Sweet, Version 8.x.x. Late teen, burgeoning interest in health and fitness.
– Matthew Sweet, Version 9.x.x. Early twenties, aspiring strength and conditioning coach, voracious reader.
– Matthew Sweet, Version 10.x.x. Early twenties, practicing S&C coach, newbie writer, BJJ practitioner.
– Matthew Sweet, Version 11.x.x. Early twenties, burgeoning writing obsession.
– Matthew Sweet, Version 12.x.x. Mid-twenties, evolving writer, part-time freelancer, committed BJJ practitioner.

Figuring out that I’m on version 12 was easy. But what about MINOR version number and PATCH numbers? First, the latter. PATCH numbers change too fast to be tracked. Software is clean and defined in comparison to human nature. It’s comparatively easy to patch. The self isn’t; we’re always being conditioned by reality and by our interpretation of it. So PATCH number essentially remains x, indeterminable. But what about MINOR version number? That’s possible to allocate, but still tricky. I’ll use myself as an example. Let’s take the transition between Matthew Sweet, Version 10.x.x. and Matthew Sweet, Version 11.x.x.

MS.V10 aspired to make a career out of strength and conditioning, and concurrently, began writing. MS.V11 was obsessed by writing and elevated it to the status of a serious pursuit. What happened in between? Let’s see.

– Matthew Sweet, Version 10.1.x. Took a job running a bootcamp and had a few personal training clients. Began a daily blog.
– Matthew Sweet, Version 10.2.x. Began shadowing and helping out a friend—another coach—in his gym.
– Matthew Sweet, Version 10.3.x. Bootcamp imploded. Took a more hands-on role with my friend’s business. Writing is helping me process ambitions, reflect, and determine actions.
– Matthew Sweet, Version 10.4.x. Persist as above, except reading and writing about philosophy, strategy, mastery and history has taken precedence. Less interest in learning about movement and health.
– Matthew Sweet, Version 10.5.x. Feel ambitions to coach wax and wane, and at the same time, joy and satisfaction from writing and thinking multiply. Realise that, at some point in the future, I will have to choose between writing and coaching.
– Matthew Sweet, Version 11.x.x. Bring that choice into the present. Abandon coaching, and shortly after, move to a different town.

As you can see, the MAJOR and MINOR version numbers I allocate myself are, basically, dependent upon the narrative(s) I choose to notice. Which is a problem as I’m a notoriously unreliable narrator, like everyone else. Consider it another way. Trying to gauge the shape and extent of our set and stable beliefs is akin to a mirror trying to see itself. It doesn’t work. What we see is distorted by the very act of looking, and by other psychological biases—like the availability heuristic, for instance.

So. Semantic versioning the self is possible. But it’s determined by the stories we tell ourselves and choose to live by. That can be either a plus or a minus, depending on your perspective. And yes, I’m aware this isn’t much of a conclusion. So let me provide one more insight.

From semver.org comes the following passage:

“In the world of software management there exists a dread place called “dependency hell.” The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.”

Reduced down: the more lines of code there are in previous versions, the more lines of code there has to be in future versions to ensure compatibility. That’s true of software, but it can be true of the self too. “How?” you ask.

In 2009, Paul Graham—founder of Y Combinator—penned a short piece called “Keep Your Identity Small”. The main drive of the piece is that problems arise when ideas merge with identity. Graham cites religion and politics as examples. Someone doesn’t just agree with the tenets of Christianity; they become a Christian. Someone doesn’t just see the validity of liberal values; they become a liberal. The counter-balance to this is the deliberate divorce of ideas and belief from identity. The former are things you are persuaded of. They are open to debate. The latter is something else. “The whole is greater than the sum of its parts” works here. We are more than our ideas. And by keeping our identity small—by incorporating less lines of code—we make it easier to update our MAJOR version number.

I’m certain Graham didn’t have this interpretation in mind when he wrote his essay. But meaning is for the audience, not the author, to make up.