Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.

This is episode 40, in which I'll talk about the paradoxical advice, "if it hurts, do it more often."

If you’re enjoying these tips, please subscribe in your app. You can leave a rating and better yet, a comment in your app, too. I also accept subscriptions to @WeeklyDevTips on twitter and comments and requests for topics there or in the show comments, too. Thanks for all of your support!

If It Hurts, Do It More Often

I've meant to do an episode or article on this topic for a while. It's advice I've been giving to my mentoring and corporate clients for years. Let's dive in after a quick plug for this show's sponsor, devBetter.

Sponsor - devBetter Group Career Coaching for Developers

If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. devBetter is a small group of motivated developers meeting every week or two, and staying connected in the meantime via a private Slack community. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com.

Show Notes / Transcript

I've given the advice "if it hurts, do it more often" for years, but in preparing for this episode I did some research on the phrase to see where I might have picked it up. I found a few articles, including a nice one from Martin Fowler, which I've linked from the show notes. I'll describe my own thoughts and how I usually present the concept, and then add in some of the interesting elements Fowler and others expand upon.

"If it hurts, do it more often." On its face this phrase makes no sense. Putting your hand on a hot stove hurts... so, should you do that more often? Of course not. The advice applies to business and software processes, and the implied context is that whatever "it" is, it's something that you need to do as part of your process. You'll find that a list of painful-but-necessary activities involved in shipping working software includes almost every step of building software. Compiling. Integrating. Deploying. Installing. Debugging. Testing. Pretty much all of these activities are much more difficult and painful if you try and do them rarely compared to if you do them all the time.

So, if you find yourself looking at your process and making decisions in order to minimize how often you perform some necessary part of your process because it's painful, I'm going to go the other way and say do it MORE OFTEN, not less. There's a scene in the Tom Clancy story Clear and Present Danger in which Jack Ryan is in a briefing with the President, who is having to deal with some scandal involving a friend of his. The President's team are advising him to distance himself from his friend, but Jack speaks up and advises just the opposite. Instead of distancing, go the other way. If the press asks if you're friends, tell them you're LIFELONG friends. Don't give them anywhere to go with it. Everyone is aghast at this advice, but of course the president takes the advice and presumably it works out well for him. I feel just like Jack Ryan when I'm giving the counterintuitive advice of doing things more frequently despite how painful they are. It's only natural to minimize pain, and the obvious approach is avoidance. But this just increases how much pain there is when the task must, eventually be done.

When you force yourself to perform part of your process more frequently, the pain decreases dramatically. There are several reasons for this. The tasks becomes more familiar, you gain proficiency, you haven't forgotten what you did last time, and there's been less time to add scope and complexity between steps. All of these natural effects of putting less time between repetitions of the task result in less pain. There are also steps that your team will almost certainly take to reduce pain, like automation. If you have a painful task you do twice a year, it's almost certainly not worth automating. The effort involved in automation will only be recovered a couple of times per year. But if you are performing that same task every month, every week, or every day it very quickly starts to make sense to automate the parts of the process that you can. And once it's automated, the pain drops dramatically.

A client I work with used to have very painful deployments. They would only deploy every month or two, and doing so was always a big source of pain. Many team members would come into the office at 4am on a weekday to get ready for the deployment. The goal was to complete the deployment before customers came into the office that day. There were a lot of QA and dev team heroics. Most of the time, he deployment wouldn't be 100% successful, and often 2-3 or more additi...