As the amount of items we need to finish for a given day grows, one or both of these natural tendencies seem to occur.
This phenomenon is so common that it’s become a very overplayed meme.
My hope is that there’s a solution, and that the solution can be found from a fundamental principle of the software world — finding the right abstraction.
Everyday both in software and in the real world we deal with different levels of abstraction. When you start your car, you don’t need to worry about sending a signal to your starter solenoid, rotating your flywheel, or making sure fuel is properly mixed with air and sent to your piston cylinder device — all of that is abstracted away from you so you can focus on driving to your destination. When you create a React component you’re (typically) not concerned with how React’s reconciliation process works to make DOM diffing more effective — React.Component is an abstraction layer over that complexity. This allows you to focus on what is more important to you, which is probably building great user interfaces.
The right abstraction will offer huge dividends while the wrong abstraction can be detrimental to a project.
Theoretically, this same principle can apply to our goals as well. The right abstraction layer over our goals will allow us to focus on our own personal progression while the wrong (or no) abstraction layer will leave us overwhelmed while focusing on the implementation details.
Essentially I want to take a more declarative approach to accomplishing my goals.
Before creating an abstraction, we need to know what we’re going to abstract. We’ll be attempting to abstract my goals for the month of August.
For some context if you don’t know me. I’m the sole engineer of a startup called Spero which is connecting everyone in the world affected by Cancer. We’re currently in beta on iOS only and in the next month we hope to launch on Android as well as launch out of beta. I run React.js Program which is a linear approach to learning the React ecosystem. I currently have three of the eventual five courses finished and there are 27,000 very friendly students encouraging me to finish the final two courses. I’m co-authoring a book on React called Full Stack React. I’m also married (with no kids).
My August goals.
If I get caught up in the implementation details, I’ll fail. I always do. I tend to focus on the fact that I “have so much to do” rather than focus on “doing”.
The obvious abstraction over those goals is in using productive hours in order to generalize “accomplishment”.
Productive Hours = Hours Logged * Productivity Percentage
My hope is that by focusing entirely on increasing the amount of productive hours I output, I’ll limit feeling overwhelmed with the details while maximizing my productivity.
After analyzing all of my goals, I think the realistic number of productive hours it will take to accomplish them is 400.
Now comes the question of measuring productivity. This one is easier than it seems. I’m using Rescue Time which keeps track of my time spent on my computer and gives me a daily/weekly/monthly breakdown of total time and also gives me a productivity score for that time.
The only other metric that will count towards my “total productive hours” count is exercise which is easily trackable. *Note. I won’t be including any “personal/family” goals in the 400 hours but be confident that my Wife and I have a very loving and happy relationship, despite the crazy hours.
In order to hit 400 productive hours, I assume I’ll have to work ~15 hour days for the month of August. I recognize I’m extremely lucky/blessed/privileged that I can focus so much attention on these superficial things but I plan to take advantage of that as long as I can.