It is really easy to get bogged down in the minutiae. We can start thinking of all the steps that need to be done to get a specific result, and lose sight of the end game: the result itself.
I have a lot of issues with David Allen’s Next Actions, mainly that if you follow the procedure as written you will spend all your time figuring out the next possible physical action, writing it down, and then doing it, only to update the system itself. Changing a light bulb becomes a long list of tasks that most of us would perform without having to analyze what the next physical action is.
Next Actions In Changing A Light Bulb:
- Get new light bulb
- Get ladder
- Unscrew old light bulb
- Screw in new light bulb
- Put away ladder
- Drive to recycling facility
- Drop off light bulb at recycling facility
- Drive home
No one would write down all those steps, even though the system calls for it. And maintaining the list would be more taxing than changing the light bulb!
Still, knowing this about Next Actions, and knowing my objections, I still have a tendency to write them down. But they aren’t useful.
At work, though, I have evolved a different approach.
Rarely am I afforded the luxury of working on one thing. I usually have several coding projects going through the phases: design, initial coding, testing, code review submission, fixes and deployment. It’s more of a free-for-all, and I can be yanked away to any of the phases without warning. Even the order phases themselves, with their inherent relative importance can be shook up if there is a breaking change that needs to go out. I may have a piece of code that needs corrections for the next release, but if the system is broken, everything else is on hold until it is fixed. These fixes may not be fast and easy, either. I’m in the middle of a multi-week refactor that is considered a breaking fix because it affects the data structure down to the core (and lesson learned: never trust another department’s narrative about how their data goes into the system)
I have had to develop a system of keeping on top of what I do, and where I am with each project. It’s not enough to have a general list of next actions, because my physical next action in 90% of the cases is “write code.” That’s not descriptive, and not helpful. Even if I were to write down what my thought at the moment was, chances are it is going to be wrong. And wrong logic means rewriting, something to be avoided at all costs.
So what do I do instead? Instead of next actions, I write down the particular problem I am trying to solve.
My current problem list on the breaking fix:
- Product key generation in [x] is incorrect
- Product key generation in [y] is incorrect
- Product key in [x], [y], [a], [f], [fs] and [p] are generated, need to be lookups
- All product key data in the tables is incorrect and needs to be fixed
The problem I left behind when I was put on this breaking fix has a note in my notebook as well: “LTV formula inaccurate for roll up”
I don’t write out the problems in great detail. I use shorthand. For example the third item is actually “Product key lookups”. I know what streams are involved, what problem is at han
