I've always been a fairly ambitious person, particularly when it comes to my career. Unfortunately, my path into the software development industry wasn't exactly a straight line.
For several years, I managed a community theatre while doing freelance web development on the side. The theatre provided a steady income, while web development was really where I wanted my career to go. Eventually, in 2015, at the age of 28, I returned to school to get the piece of paper that would formally demonstrate what I already knew how to do.
After graduating two years later, I entered the software development industry as a junior developer. It was an interesting position to be in, considering I already had years of freelance development experience and a considerable amount of management experience behind me.
I was happy to finally be pursuing the career I wanted, but I was also conscious of how much time it had taken me to get there. I wanted to make meaningful progress, and I didn't particularly want to spend another several years somewhere simply because I had become comfortable.
There's nothing inherently wrong with being comfortable in a job. In fact, I would argue that enjoying your work and being happy with your circumstances is a pretty good thing. The problem is when comfort turns into complacency, and you stop paying attention to whether you're actually progressing towards the things you want.
The opposite can be equally problematic. We've all had days when something happens at work that leaves us frustrated enough to consider updating our résumé immediately. Sometimes that frustration is entirely justified, but making a significant career decision while you're still angry isn't necessarily the best approach either.
I wanted a way to account for both situations. Something that would encourage me to periodically reassess my circumstances, while also preventing individual experiences from disproportionately influencing my decisions.
Naturally, I created a spreadsheet.
The Professional Advancement Satisfaction Clock
I called it the Professional Advancement Satisfaction Clock. Not exactly a catchy name, but it described what I wanted it to do.
The premise was simple. Whenever I started a new position, I would give it an initial balance of two years, or 730 days. Every calendar day that passed would subtract one day from that balance. Eventually, the clock would reach zero, at which point I would need to seriously consider whether I was still making the career progress I wanted.
Of course, two years of doing work that I genuinely enjoyed, with opportunities for advancement and professional development, shouldn't be treated the same as two years of stagnation or frustration.
To account for this, the spreadsheet included what I called a Turning Point Log.
Whenever something significant happened, whether positive or negative, I would record the experience and assign it a value in days. Positive experiences added time to the clock, while negative experiences subtracted time.
For example, imagine having a particularly unpleasant meeting where someone's behaviour leaves you questioning whether you're in the right environment. Rather than immediately acting on that frustration, you might decide that the experience was worth subtracting 60 days from your clock.
On the other hand, perhaps you receive a substantial salary increase, a promotion, or an opportunity to take on work that meaningfully contributes to your professional development. You might decide that experience was worth adding another 180 days.
The numbers were completely subjective, and that was intentional. I wasn't trying to develop a scientifically accurate measure of job satisfaction. I was simply assigning a weight to experiences based on how significantly they influenced my perspective.
This actually worked rather well.
If something particularly frustrating happened, I could record it, assign it an appropriate value, and carry on with my day. I had acknowledged that the experience mattered without allowing it to immediately dictate what I did next.
It also worked in the other direction. Positive experiences were recorded and given their own weight, rather than gradually being forgotten as new frustrations inevitably appeared.
Over time, the spreadsheet provided a much more complete picture of how things were going than whatever I happened to be feeling on a particular afternoon.
Importantly, the clock continued counting down even when nothing particularly interesting happened. That was part of the point. If I spent two years doing essentially the same thing without making any meaningful progress, I wanted a reason to stop and consider whether that was really what I wanted.
The Horizon: A Time to Reassess
The date on which the clock's remaining balance reaches zero is what I now call the horizon.
Think of it as a point on the calendar when you've committed to reassessing something. You establish an initial horizon when you start the clock, and your experiences can move that date forward or backward.
If something positive happens and you add 180 days, the horizon moves six months further into the future. If something negative happens and you subtract 60 days, it moves approximately two months closer. Meanwhile, the clock continues counting down as each day passes, gradually bringing you closer to that date.
The horizon isn't fixed, and that's what makes the concept useful. Rather than arbitrarily deciding that you need to make a change every two years, you're allowing your experiences to influence when it might be appropriate to reconsider your circumstances.
One thing I want to make clear, however, is that reaching the horizon doesn't mean it's time to quit your job.
The clock was never intended to make decisions for me. It was meant to identify a point at which I should deliberately reassess my circumstances rather than simply continuing with the status quo.
Perhaps I was still learning, taking on new responsibilities, and enjoying my work. In that case, there might be no reason to make any changes at all.
Alternatively, perhaps I had become stagnant, wasn't developing professionally, or had started to recognize that my longer-term ambitions weren't particularly compatible with my current circumstances.
That might mean having a conversation about career advancement, pursuing additional training, changing responsibilities, or considering opportunities elsewhere.
The important thing was that I would be making a conscious decision about what came next.
I also appreciated having a record of the experiences that brought me to that point. A bad week can feel considerably less significant when you can look back at six months of otherwise positive experiences. Similarly, one particularly good day shouldn't necessarily erase months of ongoing concerns.
The spreadsheet gave me a little distance between what I was feeling and what I ultimately decided to do about it.
From Spreadsheet to Bearings
I continued using variations of this approach, but maintaining everything in a spreadsheet was never particularly convenient. It worked, certainly, but manually recording experiences, maintaining calculations, and trying to visualize changes over time wasn't especially elegant.
Eventually, I decided to turn the concept into a proper web application.
The result is Bearings.
Bearings takes the original spreadsheet's approach and makes it considerably easier to use. You create a clock, give it a starting balance in days, and record turning points as significant experiences occur.
Each turning point has a date, a title, an optional description, and an impact expressed in days. Positive values extend the clock, negative values shorten it, and zero allows you to record an experience without changing the balance.
The daily countdown happens automatically, whether you open the application or not.
Bearings takes care of the calculations and shows you how many days remain, where your current horizon sits, and how your turning points have influenced it. Adding a positive or negative turning point immediately updates the balance and its projected horizon, without needing to manually adjust anything.
It also provides a graph showing how your balance has changed over time, including the positive and negative turning points that influenced it. This was one of the things I particularly wanted to improve over the spreadsheet. Seeing the history of your experiences, rather than simply looking at the current number, makes the information considerably more useful.
You can review previous turning points, update their values or descriptions, and see how those changes affect the overall history. There is also a fictional example that you can explore without creating a clock or modifying any of your own information.
I also wanted to move beyond the original spreadsheet's exclusive focus on career progression.
Although that's why I created the system, there's really no reason the same approach couldn't be applied to other aspects of life. Perhaps you're working on a long-term personal project, trying to grow a business, or evaluating some other commitment that you want to periodically reassess.
You can create multiple clocks, each with its own starting horizon and turning points. The initial period doesn't need to be two years, either. That was simply the timeframe I originally chose for myself.
The application doesn't particularly care what you're tracking, which is rather the point.
Why I Didn't Want to Build Another SaaS Product
There was another decision I made fairly early in developing Bearings, and it had very little to do with the countdown itself.
I didn't want to build a SaaS product.
As a software developer, I'm perfectly capable of building an application with user accounts, a database, authentication, and all the usual infrastructure required to store and synchronize information on a server.
But I really didn't want to do that here.
Consider the kind of information someone might record in Bearings. Depending on what they're tracking, their turning points could include deeply personal reflections about their employment, relationships, finances, or other aspects of their lives.
Why on earth would I want to be responsible for storing all of that?
If I built Bearings as a conventional SaaS application, I would suddenly be responsible for protecting an entire collection of potentially sensitive personal information. That would mean dealing with authentication, access controls, retention policies, account management, and all the other security and privacy considerations that come with operating a service containing user data.
And, of course, there's always the possibility of something going wrong.
None of that seemed particularly appealing, especially for an application whose entire purpose is to help people privately reflect on their own experiences.
The simplest way to avoid having to protect a database full of people's personal reflections is to not have that database in the first place.
So that's the approach I took.
Bearings is a local-first web application. The application is delivered through the website, but your clocks, turning points, and notes are stored locally in your browser. That reflection data isn't sent to my servers, and you don't need to create an account to use the application.
I don't have a database containing everybody's experiences, because I don't need one.
Naturally, storing information locally introduces a different set of considerations. Clearing your browser data, losing a device, or experiencing a storage failure could result in losing your records.
To address this, Bearings supports exporting your information as a JSON backup file, which can be restored later or used to move your data to another device.
I also implemented optional synchronization with Google Drive. Rather than sending your reflections to a database operated by me, the application can synchronize them with storage in your own Google account. This is entirely optional, and the application works without it.
There are some important limitations worth mentioning. Backup files contain your notes in plain text, and synchronized files are not password-encrypted. You should therefore be mindful of where you store them and who has access to your device or cloud account. Synchronization also requires the application to be open, online, and authorized.
I don't want to suggest that storing something locally automatically makes it secure. There are still responsibilities and risks associated with protecting personal information, regardless of where it lives.
But from my perspective, not collecting or hosting that information in the first place is a considerably more sensible approach than building an entire infrastructure around data I have absolutely no reason to possess.
It also means I don't have to operate another SaaS platform.
I'm quite happy with that arrangement.
Keeping Things in Perspective
Ultimately, Bearings is a fairly simple application built around an idea that I originally found useful for managing my own career.
I wanted to avoid becoming complacent, but I also wanted to avoid making impulsive decisions based on whatever had happened most recently. Recording turning points and assigning them a weight gave me a way to acknowledge individual experiences while keeping the bigger picture in mind.
That doesn't mean the system is perfect. The values are subjective, and there's nothing inherently meaningful about a particular number of days. Something that feels important today might seem relatively insignificant six months from now, and the reverse can also be true.
The clock isn't a substitute for judgment, and it certainly shouldn't be treated as an instruction to remain in a genuinely harmful situation just because there are still days remaining.
It's simply a way of keeping track of how your perspective has changed over time.
For me, the most useful part is having a reason to periodically ask whether I'm still moving in the direction I want, without allowing every frustrating experience to become a reason to immediately change course.
Sometimes the answer will be that something needs to change. Sometimes it will be that things are going rather well, and there's no particular reason to do anything differently.
Either way, it's nice to arrive at that conclusion deliberately.
Not bad for something that started as an Excel spreadsheet.
If you'd like to try it, Bearings is available at withbearings.com. There's a fictional example you can explore before creating a clock of your own.