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!
Refactoring and Clean Code
I spent all of June learning about refactoring and clean code, as well as applying everything I learned.
This post goes over everything I learned, what my experience was and how I’m planning to turn refactoring into a habit.
Everything I Learned
What is refactoring?
Refactoring is a process of improving the readability, modifiability and ease of debug of existing code. It is not about adding new functionality. Refactoring transforms a mess into clean code and simple design.
Here are some of the basic categories of refactoring techniques:
Refactoring techniques
Quick summary of each category
Method composition:
Much of refactoring is dedicated to how we write methods. In most cases, excessively long functions are the root of evil. All techniques in this category aim to streamline methods, improve readability, remove duplication, and increase ease of future modifications.
Favorite techniques:
The more lines found in a method, the harder it’s to figure out what the method does. This is the main reason for this refactoring.
Besides eliminating rough edges in your code, extracting methods is also a step in more readable code. It reduces duplication and isolates parts of the code for easier debugging.
Data organization
All of code is about data and the operations you perform on it. It is possible to write functional code without thinking too hard about the data you are handling. The techniques in this category help with replacing primitive data types with rich class functionality. Pieces of data that should be looked at together become members of a class rather than independent primitives. Proper data organization and method composition alone can bring major improvements in your code.
Favorite techniques:
Replace Data Value with Object
With replacement of a data value with an object, we have a primitive field (number, string, etc.) that’s no longer so simple due to growth of the program and now has associated data and behaviors. On the one hand, there’s nothing scary about these fields in and of themselves. However, this fields-and-behaviors family can be present in several classes simultaneously, creating duplicate code.
Therefore, for all this we create a new class and move both the field and the related data and behaviors to it.
Before replacing data value with object
After replacing data value with object
Simplifying conditionals
Conditionals have a tendency to get more complicated over time. In my experience, trying to untangle a conditional can be a frustrating experience. The techniques in this category help you write conditionals that are easier to follow, more expressive and robust.
Favorite techniques:
Replace Nested Conditional with Guard Clauses
When you have a group of nested conditionals and it’s hard to determine the normal flow of code execution, this refactoring comes in handy.
We isolate all the special checks and edge cases into separate clauses and place them before the main checks.
Introduce Assertion
In the case where certain conditions must be true for a portion of code to work correctly, this refactoring technique comes in handy. We replace all our assumptions with specific assertion checks.
My experience
I want to talk about my experience from 3 different angles. How my behavior changed, how I look at coding differently now, and the best practices I’m taking forward with myself.
How my behavior changed
Almost everything I learned made me respect OOP concepts more.
I started using multiple files more, I used classes, data structures and functions more intentionally and really thought about what code should look like before jumping into the mechanical side of coding.
Once code was refactored, it reduces the cognitive effort required from a future reader/owner. This made me a lot more productive - I was spending much less time and mental effort trying to figure out what code was doing. It was all in front of me.
How I look at coding differently now
Coding became fun again.
Over time, I have learnt that I enjoy making things. Podcasts, music, blog posts, or new features. I enjoy making high-quality things even more. I could feel a tangible improvement in my code quality and code health. I enjoyed looking at and writing new code once I refactored it or wrote it more intentionally.
Thinking, planning and implementing code at the same time is a great feeling. As I started writing more and more code, my process evolved. My current process is to think about what I’m coding using quick drawings on my whiteboard, then type out some pseudocode, and finally move pieces of the pseudocode around and write syntactically correct and complete code. The whole process leaves me more energized - I always feel like I’m in control. Bugs are caught quickly and easily. Harsh boundaries between different modules and methods take out any frustrations I would have felt from working with spaghetti code.
I have realized that writing code is an art and is about style. For example, consider the trade-off you need to make when writing function calls upon function calls. More functions and boundaries lead to more expressive code (which is good!) but might cause the reader to jump around different parts of a file in order to get to a particular function definition (which is not good). Performance aside, I will always prefer to write more functions in order to write more expressive code. I trust that readers and modern IDEs will make code navigation easy. That is my style. Someone else might write less functions, which makes the end result less expressive but slightly easier to navigate. That would be their style. Writing code is about style.
Best practices
Code can keep improving, settle for good enough
Your code can almost always be improved. Settle for ‘good enough’ and move on.
You need to move to other things, and constantly cleaning up old code is not an option. Once you think a piece of code is expressive, easily modifiable, understandable, and will be easy to debug in the future, move on. This brings me to my next best practice…
Keep a wishlist
I keep coming across code that frustrates me. I keep a track of such code and return to it when I have some downtime or I feel like cleaning up code.
For best results, know your editor well.
The quicker you are able to implement the changes you want, the quicker you can move. You do not want the tool to become a source of friction between you and clean code.
There are 2 golden rules to keep writing clean code without getting lost in the details:
The broken windows rule
Don’t leave any ‘broken windows’ in your code. Broken windows are messy pieces in an otherwise clean file. If someone (you included) looks at a ‘broken window’ in code, you’re more likely to feel okay with making a further mess.
On the other hand, if you see a well formatted, well written file, you simply do not want to be the one who adds the first bit of mess into the clean file. Don’t leave broken windows in your code, and maintenance becomes natural.
The campsite rule
Always leave the campsite cleaner than you found it. If you make any change to a file, make sure you’re leaving it in a healthier, cleaner state than you last found it. Even if the change is as small as deleting old commented out code or adding proper formatting, constant cleaning up can add up to big results.
Follow ups
I want to make refactoring a habit. All my follow ups circle around this objective.
Keep a running ‘Refactoring Opportunities’ list
I have a Notion page where I track code I’d like to clean up. I keep a track of what the current problem is, my initial ideas on how I’d change it, as well as the refactoring techniques I see myself using. I return to this list once/week and work on one of the entries in the list.
Share everything I learn
If I make a constant effort to share a change I made, I’m likely to hear other people’s opinions on it. More dialogue = more learning!
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.