Me, v.43.001
An idea has been sticking with me lately. It’s from this TED Talk on being the best version of yourself.
The speaker argues that when we skip updates to the software on our computers and phones, we are inviting the opportunity for viruses and other performance issues. These viruses slow down our devices and make them less effective and efficient.
We don’t want that to happen so we update them often, even if it’s not always immediate or daily. Some of these systems update themselves daily, no action from us is required, because it’s so important.
But when it comes to ourselves, the operating system of us, are we updating and upgrading ourselves every day?
The Latest Me Version
This idea was particularly relevant and impactful to me because I listened to it on the day before my birthday.
As someone who thinks a lot about self-improvement, I would have been interested in this idea anyhow.
But the speech made me consider that I was about to release a new “version” of me: version 43.
When we ask what’s new in the latest version of iPhone or other smartphone software, what we are really asking is “did the work that went into this new version give me anything useful? Anything I want?”
I wondered whether version 43 of me is all that much better than version 42 and, if so, how and why?
So, I’ve decided to try measuring myself under what I am calling “Version Philosophy.”
Version Philosophy
In this philosophy/analogy/whatever, you are simultaneously the software developer, the product, and the user.
Every birthday is the release of a new version of You. In my case, V.43.
Each day until your next birthday is the release of an updated version. So my birthday was V.43.001 and will end with V.43.365, being followed by V.44, and so on.
The question then, at the end of each day is, what version of my software am I truly operating on?
Did I actually upgrade to a better version, or is V.43.002 pretty much the same as the prior edition?
Worse, what if V.43.100 isn’t much different or “better” than V.43.001?
More fundamentally, how do you even know this version is better to begin with?
The book Designing Your Life talks about how everything we do and make is oriented around solving a problem. Chairs solve the problem of tired legs, AC solves the problem of being hot, and so forth.
So, the first step to success in Version Philosophy is identifying what problems you want or need to solve.
I need to lose a little bit of weight. Version 43.002 needs to include a plan for exercise and healthier eating than V.43.001 had.
I want to do more writing, creating, and other projects. V.43.100 needs to be running a program that provides instructions for how I will accomplish those things in my day.
Once I know that the software version needs those things, I then need to make sure that the current version of it properly executes those functions. If it doesn’t execute well, I should evaluate whether it needs that functionality and, if it does, find where it is breaking down.
In Practice
Below is a running (draft) outline of what I think this development process looks like. These thoughts are somewhat haphazard right now, as I work on taking a broad concept and breaking it down into distinct parts.
Version Creation and Evaluation
- Purpose: What is my software supposed to achieve (who am I supposed to – or who do I want to – be?)
This can get as existential as you want, but ultimately you are crafting a simple but compelling story about who you want to be. The idea of who you currently are will come later.
I do one or two specific check-ins on this step every year but, in reality, you’re checking in on this all the time.
Questions to ask: Who was I made to be? Who do I want to be? What was I built to do? What things do I value?
- Design: What problems is the software of me trying to solve (what do I want to do, be better at, and spend my time and energy on)?
Identify specific components of your life that you want to be executing on and create plans for getting that done. If you want to be a writer, create a plan for writing and goals by which you will measure it.Questions to ask: Where do my interests and my purpose meet/align? What are the first steps I should take to be better at whatever it is I want to do?
- Evaluate and Re-design: What parts of my software worked either well or poorly? What parts are missing? What parts are extraneous? What parts should be removed?
This is a daily check-in with yourself where you look at how you’re doing on achieving your objectives (if you have measurements, great), and consider whether you’re satisfied, want to see bigger results (and how to obtain them), or just want to bail on an idea altogether.Questions to ask: Did I learn anything from doing a given activity and, if so, what? Do I want to continue performing each of these functions? What do I need to do to perform my functions better (at a higher level, more consistently, etc)?
- Release Update: What’s in this new version of the software and what am I going to do with it today?
When you wake up in the morning, you are automatically running the new version of your software. It’s up to you what you do with that program now. Everything your software does should be in line with item 1 above. As you progress through your day, you will execute steps 2 and 3 in the development process, perpetuating the release cycle.Questions to ask: Do the contents of this version excite me (ie, am I looking forward to a day filled with using this system)? How far can I push this software today? If I use my software properly, what will I accomplish? If I use my software properly, what negative outcomes will I avoid?
Schedule
Remember, every day is a new software release.
This philosophy isn’t questioning whether you upgraded to the latest version.
Rather, it is a question of whether you put any meaningful work into building upon previous versions of your software.
Every release should be an improvement, even just the 1% standard many people adhere to, over the previous version.
Major shifts between versions don’t have to happen on an annual basis or according to any other specific measurement. This may be a departure from how most software orgs would number their iterations, but that’s unimportant.
What matters is knowing that you don’t have to wait for a specific point in time to eliminate a major item from the software of you. If V.43.095 and every version prior included a goal of getting certified in using CAD software, it’s perfectly fine for you to device that V.43.096 doesn’t include that at all.
But you should avoid the frequent inclusion, removal, and re-inclusion of things at all costs. It slows down your system, distracts the user (YOU) from the program’s purpose, and prevents the overall growth of the product (again, YOU).
In theory, V.44.001 of me isn’t a radical departure from V.43.001, at least in terms of purpose. The variation should be in the mechanics of the system, and its efficiency and effectiveness.
For example, V.1.001 of me was talking, but not very well. V.2 of me still included talking, but it was executing at a much higher level.
That’s the goal here. Whatever functions you have in a prior version of you should now be operating at a much more expert level.
When Google first came out, if you misspelled a word by even one letter you would be lucky to get anything relevant. Often it would just tell you it didn’t find anything.
Now, a few dozen versions later, it can predict what you’re going to type. It’s still doing the same basic function, but it is doing it at a much more expert level. It just took a lot of small iterations on that function to get to this point.
Keep Things Simple
The last consideration in this framework (for now). The more functions and features you try and pack into a software program, the more difficult it is to run it.
Overcomplicating your software is also a surefire way to prevent you from improving on each release. You can only develop so many “features” at any given time.
As the saying goes, if everything is important then nothing is important.