This week guest Joe Zack talks about how to apply the power of habit to break bad coding habits.
This week guest Joe Zack talks about how to apply the power of habit to break bad coding habits. Joe is a software developer based in Central Florida. He is a host of the Coding Blocks podcast and is particularly excited about Search Engines and the JAMStack these days.
Does your development team need a force multiplier to level up their quality? Contact Ardalis Services to see how we can help.
Hello my name is Joe Zack, and I’m a long time developer and podcaster over at Coding Blocks. I’m also a huge sucker for the Business-y PopSci Self-Help kind of books that you see on Top Seller lists. I like to take the lessons from those books and try apply them to my programming.
One book I particularly enjoyed was "The Power of Habit" by Charles Duhigg, check the show notes for a link. This book describes the building of habits as the process of taking explicit procedural actions, and turning them into implicit declarative actions.
And hey, that sounds kinda like programming to me! We programmers figure out precisely what operations need to occur to fulfill our requirements, and we write programs to automate those operations so that we can deal things at a higher level of abstraction. That enables us to combine and compose these programs to solve even bigger problems without getting tripped up on tiny little details.
"The Power of Habit" book promises that building good habits is much like building a SOLID API. You spend the time up front building good habits, and then you get a multiple of that time back with reduced maintenance costs over time.
But what if your API isn’t so SOLID? What if you’ve developed some bad habits that you would like to change?
Well then, you’re in luck - because the book spends a lot of time looking at how habits can be changed and I’m here to share some of that with you.
An example of a bad programming habit that I have is only considering the "happy path” operations that need to happen to meet a requirement. I tend to focus too much on how to make something work, and not enough on how to handle problems that might arise in the real-world.
In writing about changing habits, author Charles Duhigg encourages me to determine the cue, routine, reward, and craving in this bad habit. If I can determine those 4 aspects of the habit, then I can figure out how best to change it.
In this example, I can look back and see that my undesirable behavior most often occurs when I’m estimating tickets, so that is my “cue”.
The “routine” is my act of imagining the work that needs to happen to fulfill the requirements of the ticket and then estimating how long that will take.
My “reward” is that I can get back to programming, which is an activity that I enjoy a lot more than estimating. In fact, the consequences for my bad estimates are typically deferred until I actually start working on those tickets.
The final aspect of a habit is the “craving”. This is the anticipation of the reward. Knowing that I can get back to “real work” once I complete my estimates provides an incentive for working quickly, rather than accurately.
According to the book, the trick to changing habits is to recognize the cue, craving and reward - and to replace the routine.
In my example, a good tactic would be to replace my current imaginative process with a more disciplined approach. Perhaps adding together a separate estimate for the happy path and one for dealing with exceptions would encourage me to look at the bigger picture and would lead to a more accurate result.
I’m going to give this a shot, and see how it goes. In the meantime I hope that you take a moment to consider how healthy your programming habits are. If there are any habits that you are unhappy with, then remember that you can change them by recognizing the cue, craving and reward - and changing the routine that you perform in response to those stimuli.
Keep doing the right thing, and eventually you’ll codify that habit into your mental muscle memory so that the good behaviors flow without you having to think explicitly about it and you can operate efficiently at a higher level of abstraction.
Thanks for having me on the show Steve!