There's a tradeoff you're going to have to make a lot of the time: simplicity vs. precision.
Simplicity often lacks detail and nuance. That's why we build and do more complex things - to get more precise, specific outcomes.
Choose simplicity unless there's a good reason not to.
Complex systems have more of a damage of collapse. Add complexity carefully, and in a way where you can roll it back if the added-complexity doesn't add enough benefit.
If you look like at one of my time tracking sheets, you'll see a pretty complex thing. But it gradually, slowly grew into that. If you were starting from scratch, don't start with something complex. Start with something simple. Track 3 things max.
Consolidate as time passes. Cross out things that you no longer need to track, either because it's not relevant any more, it's automatically successful, or because tracking wasn't producing gain there.
I used to have a "Research" category and a "Learning" category on my time tracking. They're slightly different, but I combined them to "Research/learning" - I lose a little bit of fine grain detail, but gain simplicity. And simplicity is good.
Start with simple. Add slowly. Complexity is a huge tax and increases the chance of collapse. You should be getting a big gain if you're going more complex.
Hey Sebastian, thanks for bringing this up, very useful reminder.
I always found Einstein's quote "Everything should be made as simple as possible, but not simpler." to be a great guiding principle for anything I do, but especially useful in my engineering/startups endeavors.
Reflecting on "Simplicity Vs Precision" I wondered if it was really about Precision or maybe something else. You wrote:
"That’s why we build and do more complex things – to get more precise, specific outcomes"
But why do you want more precise, specific outcomes? To follow your example, if I were to split "Research" and "Learning" in two fields, would I do that for the sake of precision/granularity? Or would I do it because of a temptation to achieve perfection, or have maximum control, or fear of missing something out?
Michael mentioned a "huge temptation to solve every problem at once" and I think he's onto something there. I wholeheartedly agree with "Choose simplicity unless there’s a good reason not to.", but I think that most people have problems with that statement due to unconscious temptations/feelings: risking to be perceived as naive by presenting a simple solution or giving up control because of what feel like blunt tools is enough of a good reason to increase complexity. Feeling in control is emotionally a big gain.
This is where I think the "not simpler" in Einstein's quote comes to the rescue. Based on conversions I've had the concept of simplicity seems to be an easy sell when you don't have the responsibility on the outcome. On the other hand decision makers will always find themselves at unease when facing that same topic.
When we have to pick what we track we are decision makers and it seems to me we react better to the proposition of "not simpler" or "enough complexity" than straight up "simplicity". Behind the scene it's the same thing, but it might help some of us to avoid rejecting this great principle.
This is so important, but also requires a lot of discipline to do properly. When designing a new system, there is a huge temptation to design it to solve every problem at once. It takes a degree of restraint and patience to hold back and develop something simple that only addresses the major problems to start with, then expand later, once the first stage is running smoothly.
I think it comes down to never having more than a handful of variables that have to be consciously monitored. Track 4 or 5 things, then once those 4 or 5 become a habit and are being monitored subconsciously, then add another few. I think the complexity limit is largely imposed by the limits of the conscious mind - the subconscious can deal with much more.
I am having a hard time wrapping my head around this. I need to know more about what you do, because this life sounds amazing.
And when I read the bit about research/ learning, I knew exactly what you meant. A keen difference, but simplicity wins. Of course, you know the precision it takes to research and the precision it takes to learn.
One of the things I've gotten tremendous amounts of mileage out of it is tracking my time, habits, and life each day.
To put it simply - I now realize it's impossible to understand how your life is going without some careful observation. There's a lot of time each day, and knowing where that time goes, what you ate, what you did and didn't do... it's almost impossible to get a good picture of your life without some kind of measuring.
I'm going to you my newest tracking template, and then I'll give some analysis. Before I start though, I'd like to share a quote -
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.” -John Gall
Thus, if you want to track your time, please do not attempt to track 20 things at once, because it's unlikely to work. I started very simply, as I described in "The Evolution of My Time/Habit/Life Tracking" - I'd recommend you read that post if you want to do something like this.
In Part 1, we talked about the primary problems with estimating software development accurately:
But we ended with the uplifting message, which is if you plan for the former (by multiplying out your estimates), and make sure you adequately track the latter, then your estimates - when taken in aggregate - will probably be ok. And by ok, I mean better than 90% of other developers.
But who wants to be a 10 percenter, when you can be a 1 percenter?
I also promised Agile was going to solve all your problems ever when it came to estimating. This may not have been 100% accurate. What we are going to do is look at a whole bunch of Good Ideas(TM) that the Agile folk stole, curated, and invented when it comes to estimation.
It turns out that we humans get a little weird about time. However much you believe "six hours" is "just an estimate", however much buy-in there is from the team about this, and however many times you've accepted that there's always hidden complexity, if a six hour task takes eighteen hours, everyone gets a little squirrely.