This past November I had a bad collision during a soccer game. I was playing goalie and came out to challenge for a ball when another player crashed into me, their knee hitting the side of my knee. I was lucky that the collision didn’t cause any major damage and I was able to finish the game. I was sore for a few days, but, all in all, things seemed to be mostly okay. Still, I experienced some lingering pain, particularly when running. Over time, things seemed to be improving. Until Christmas Day. On Christmas Day, I decided to go out for a longer run. I ended up running eight miles through about six inches of snow. I normally love running in the snow, but something felt wrong that day. As I ran, my knee started hurting more and more. I should have stopped and walked, but I didn’t listen to the pain. As a result, I re-aggravated a small knee injury and had to take more than a month off running. To this day, I’m still working myself back to the speed and distances I was able to run before.
I believe there’s an important lesson to be learned here. Your body feels pain for a reason. Pain is a way of letting you know that you need to pay attention because something might be wrong. As a software developer, I’ve learned this lesson repeatedly as well. Years ago, when I was writing code in React.js, I worked on a component that felt more complicated than it needed to be. I ignored the fact and pushed on. Eventually I got the component working, but it was always brittle. We eventually hired a new engineer with much more React experience. They looked at my component and kindly explained that I picked a terrible approach. After spending a little time reworking the component, it was faster, simpler, and more reliable. In both cases I ignored the information from pain and paid the price.
Pain can be a valuable signal that something isn’t quite right. The trick to using pain to your advantage is knowing how to use that signal. In my running, I’ve learned that certain types of pain indicate that I have a strength or flexibility imbalance that I need to correct. Other types of pain mean that I’ve injured myself and need to rest. In software, pain might mean I’m using the wrong tool for the job or that I need to refactor. Just like in athletics, it takes time and experience to learn to interpret these signals.
With that in mind, how can you use pain to your advantage? The web application framework, Ruby on Rails is a great example of how this can work. In Rails, the Rails way is made incredibly simple. Once you start moving out of their preferred solutions, things get more painful. This is a signal that you should pay attention. It doesn’t mean you shouldn’t choose that path, just that you should be careful.
We do this in our organizations too. Often, we create procedures that make it very simple to do the right thing and hard to do the wrong thing. When we do that, we encourage our people to do the right thing. The trouble comes when it’s easier to do the wrong thing than the right thing. For example, if you have a new feature development team that throws code over the wall to the support team, they likely won’t think about building software that is easy to support. If instead this team must support their own software, that pain will guide their decisions.
How have you used pain to aid in making better decisions? I’d love to hear your thoughts at mmangino@triumphpay.com.
