Changing How I Work: Touch-it-Once and Always be Closing
Recently, I’ve been working on multiple projects of varying levels of complexity. Unavoidably, this leads to many open loops and slow progress across many projects. That… is frustrating.
Not only do I not get the satisfaction of ‘closing’ projects out, I’m also distracted from working on other things when something from a previous project resurfaces & needs my attention.
This materializes in many ways: if you ever write/own fragile code, you know it is prone to breaking. More fragile code = more likely it will resurface asking for maintenance after you thought it was ‘done’. Another example: if you don’t read specs/documentation with a keen eye, you will need to come back to it later to process it properly again.
Problems that resurface this way have been a big time suck and source of frustration for me recently. I want to make a change in how I work day-to-day to avoid this. It’s a new approach!
The Mentality and Approach
I want to focus on doing good quality work that I ruthlessly push to completion. In other words, focus on:
Touching-it-once:
Do things right. This is going to require more attention and focus, but reduces the need to come back to it later. You touch it once, and then you’re done. No need to come back.
Completion centric planning:
Ruthlessly close open loops. Finish and complete things on a day-to-day basis. Always be closing! (Casey video)
This is how this would translate:
Write cleaner code to ensure reliable systems
Comb through documentation and specs and process them properly so you only do it once. There should be no need for constant revisits.
Here’s some other benefits I’m hoping to see:
Better estimates: less unexpected problems popping up = more reliable estimates on what I’m currently working on.
Easier planning: I don’t need to worry about lingering things from other projects. Just get them out of the way so yo need to plan for lesser variables!
Less open loops: just feels better. Open loops eat up my attention from other things. OPEN LOOPS ARE POISONOUS!
How do I enforce this thinking?
Reduce planning overhead and have a bias to action.
Have ‘deliverables’ each day - clear, tangible things that need to be complete at the end of a day. Adjust scope of the tasks themselves if you don’t think it is realistic to finish them in a day.
Let’s see how it goes!
How I Decide What to Learn
There’s so much to learn. New languages, tools, techniques, theoretical concepts. How do I pick what to learn next?
Anything I learn (at some level) needs to be 3 things. These are:
Fun to learn
If I’m spending my free time or extra work time learning something, it should be fun. It’s like a hobby, I’m doing it completely out of choice - I can’t do that with topics that are not fun.
Relevant
Anything I learn should be relevant to what I do for work.
DevTea has this podcast episode where the host talks about what skills are important. He compares the main skills of a job to the trunk of a tree.
For example: algorithms, fluency with libraries and packages are parts of the trunk of a data scientist.
Then there’s the branches and leaves. These are the auxiliary skills that might not be at the core of the job, but improving these skills will make you better at your job. For example, fluency in scripting, your text editor, etc.
Anything I pick must be relevant. It must be either in the ‘trunk’ of the things I learn or the ‘branches’.
Immediately applicable
If something I learn is immediately applicable to the projects I’m working on right now, I’m able to get immediate hands-on experience with it. Otherwise I don’t think I am extracting any value of a newly gained skill.
TLDR: the sweet spot is here
And that’s how I pick what to learn next.