Boom! It's 2017. Oh my goodness, 2016 was the best year of my life by far. Knock on wood, everything is working. It's working marvelously, even.
One of my very few regrets is that I'm doing less ad hoc writing. I published 52 essays at The Strategic Review in 2016, the first half of which got edited into the book Progression; the second half will be in the upcoming Machina (rough guess on ETA: February).
TSR roughly doubled in size, all through word of mouth. (Thank you.) But I didn't blog as much as I used to, and I used to have a lot of fun doing this.
I've also learned a lot about making things happen in the last year, that I think might be useful to you. I'm going to be blogging a little more in 2017.
So without further ado, here's two things that have been huge for me.
DOING DELIBERATE WORK IN CYCLES
Two of the largest productivity gains I had in 2016:
1. Breaking all work into 30-minute "Work Cycles";
2. Breaking all projects into defined blocks of work with cycle estimates for them.
Cycles look like this --
It looks complicated, but it's really not. It's also hyper-powerful.
At the start of a Work Cycle, I answer:
*What am I trying to accomplish this cycle?
*How will I get started?
*Are there hazards present?
At the end of the Cycle, I answer:
*Were there any distractions?
*Things to improve for next cycle?
Don't be fooled by the simplicity -- it's extremely powerful.
Aside from ensuring you don't "just work on things" and have them take a long time, it also tracks accurately how energy and morale falls over work sessions (which then signals when it's time to take a break, or to re-scope the work), as well as creating a log of how long work takes to do.
It's very powerful.
BREAKING ALL PROJECTS INTO ACTIONS WITH CYCLE ESTIMATES
Kai and I refined Cycles, and we also taught it to a lot of people at things like the Ultraworking Pentathlon, as well as some demo trainings for high-performing friends, and a couple rounds at some top American universities. It always gets a rave reception; it's a way to really buzzsaw through work.
After I'd done Cycles for a number of months, I came to another huge levelup -- I started breaking all projects into actions, with estimates of how many cycles it'll take each action complete.
For the first time in my life, this let me reliably predict and control how much work I got done each week.
Things no longer "happened" or "didn't happen" seemingly randomly, I could break projects down into actions, estimate those into how long they'd take to complete (which after you run cycles for 6-10 weeks, you start to get a good feel of), and then look at the landscape coming up to figure out how many cycles I could run in the upcoming week.
It was all pretty straightforward from there.
EX, here's some writing I've got scheduled for this upcoming week --
And when it completes, I'll get to see how long things actually took. I couldn't overstate how cool and powerful this is.
For instance --
Again, those estimate ranges are all in half-hour Cycles. So when I estimate that writing Danger Flags #1 and #2 will take 21-41 cycles to write, I'm estimating roughly 10.5 to 20.5 focused hours.
For finishing Dubious Battle, I estimated it'd take between 23 and 47 cycles (11.5 to 23.5 hours) and it actually took 28 cycles (14 hours). Solid.
IMPLEMENTING THIS IN YOUR OWN LIFE
We of course have three sessions of guided Work Cycles scheduled for the next three Saturdays -- 7 January, 14 January, and 21 January -- at 12PM Eastern Time each Saturday for Ultraworking Pentathlon II.
If this type of productivity interests you, you might consider signing up:
If you can't make it, you absolutely can learn on your own though. Look at the top image and the instructions under it. Copy that to a spreadsheet. Work in 30-minute blocks. There's some subtle points and it does genuinely benefit from instruction -- there's slightly better and worse ways to cut up action, and re-centering if you start grinding or get stuck is a collection of skills -- but you can start doing it on your own.
The real key is standardizing the single element (30 minutes = Cycle) and measuring how many get done.
You don't need to estimate in the beginning; in fact, I recommend you don't do macro estimates when you start. Just work in Cycles and see how long things take to get done.
But once you know how much work you can complete in 30 minutes, you can then start to look at your week and say, "Okay, how many Cycles can I get in this week?"
From there, it's very straightforward to break projects in advance into the actions required, put estimates on those, and fit them all into the week. It's been a sea change for me; I can't put a precise number on what it's done for my productivity, but, umm, it's more than doubled.
THE KEY ELEMENTS
*Standardizing a unit of work (the one we use is "30 minutes = one Work Cycle")
*Keeping good real-time records on energy, morale, what you're trying to accomplish, and if it happened or not -- so you can see where you go down rabbit trails, when you're grinding, etc.
*Learning how much work you can get done in a good 30 minutes.
*Breaking projects into specific discrete complete-able actions.
*Estimate how many ~30 minute blocks it'll take to get those actions done.
*Measuring and noticing where your estimates were off, to adjust in future weeks.
Every single element of this is pretty simple in isolation, but once you build up the skill and knowledge to do it reliably, it's incredibly powerful. These were two of my biggest gains for 2016 -- which was overwhelmingly the best year of my life.
Here's to more in 2017, eh? And yeah, would love to have you at the Second Ultraworking Pentathlon if it interests you.
Thanks for sharing, Sebastian!
As I was reviewing my year yesterday, something drew my attention: in the 3rd quarter, I used the process you described to manage my work and it was the method that best gave me control of how much I worked and how well.
Everything else, from timetracking services as Toggl to not time tracking at all (task management) didn't come close. So, for 2017, I'm going full on working in Cycles and using that master spreadsheet. Thank you very much!
We're doing the Ultraworking Pentathlon again, from 7 January to 22 January.
The first Pentathlon was a really big success. We've incorporated feedback and the next one is going to even better.
The Big Idea
The big idea is very simple: there's hundreds of "known best practices" and 1% edges in the world that most people aren't doing them. There's also dozens to hundreds of little techniques, tricks, and advantages you can stack up to make your life run better.
Usefully estimating software projects is difficult, but not impossible.
A lack of understanding about why we estimate, what to estimate, and how to estimate leads to a breakdown of trust and communication between developers and managers.
Developers end up feeling guilty that they're not meeting their estimates, and at the same time defensive: they were just estimates after all, right? Managers feel exasperated that everything is taking three times as long as it should. What are they doing all day?
This article is about fixing your estimates, and your estimation process. It's split in to two parts - the part you're reading, titled "How to Estimate like an Adolescent", and the part you're not yet reading, titled "How to Estimate like an Adult - What to Steal from Agile".
As an aside, if you're in a position where someone else is estimating work you're doing, get out. The work will be late, you will be blamed, and you will be miserable. Programming is meant to be fun, and setting yourself up for accusations of professional incompetence and the niggling feeling that maybe you are incompetent is the antithesis of fun. Seriously, get out.