Developer Health: Don’t Push It

Man pushing an overloaded cart
Photo by Adli Wahid

I got really sick a few weeks back and it took me some time to get back into my comfortable rhythm of life. (Ok, I’m still working on that…) Regardless, I thought I’d share some lessons I learned from being sick that transfer well into other parts of my life. I think you’ll find it helpful, too.

My first lesson: Sometimes you just can’t power through it.

I have so much to do, I don’t have time to get sick. (As if anyone has time to get sick!) The problem is that if you try to tough it out and push through it, you might get a little more done in the short run, but you’ll end up making it worse later. As I heard a speaker say once, “You may not have time to take care of yourself now, but when you have a heart attack, you’ll have all the time in the world.”

As you get older, your ability to push through illness fades and it takes a greater toll on your body. Ultimately you just have to take the time off to heal, and it will take much longer if you don’t take that time. And trying to work when you’re sick is like trying to work when you’re tired. You just aren’t effective. And don’t even talk to me about going into the office when you’re sick! I think those days are long past by now!

So you need to listen to your body and take care of your health to be effective. But in thinking about this, it occurred to me that the same can be said about your code base. If you hacked together a bit of code so that you could hit a deadline, you can probably get away with shipping like that once or twice – as long as you make time to go back and clean it up later. (This is what we call “technical debt”). But if you make it a habit, your whole code base will start to be compromised, and the stability of your application will suffer. And adding new features or correcting problems will become harder.

If you make it a habit, your code will become fragile and people will be afraid to try and change it. It either needs massive refactoring or a complete rewrite – and who has time for that? Many companies have gone out of business in no small part due to the cost of bad code.

In the same way that maintaining a strong healthy body takes daily good habits, maintaining a robust, flexible code base takes daily good habits. Master these and your life will go well.

What habits do you practice daily – for your personal health and for your code health?

Read Code Like a Ninja

Woman reading code
Image by Gerd Altmann

“We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” — LarryWall, ProgrammingPerl (1st edition), OreillyAndAssociates

Uncle Bob Martin claims that we read code ten times more than we write it. Even if that’s an overstatement, it’s easy to believe that most of our time at the computer is spent reading code. And if that is true, why don’t we spend more time trying to improve our code reading skills?

I already know how to read! Reading is passive. Writing is active. Of COURSE I work harder to learn how to write well than I do learning how to read well. How many Hemmingways are there after all?

Ok, I’ll grant you that, but consider why we read code in the first place: we need to find a bug, or we need to add a new feature and figure out how to do that, or we just need to learn what some program does. This is purposeful reading. It’s much more effort to decode a computer program than it is to curl up with Harry Potter and the Sorcerer’s Stone. It’s more like studying in school.

When studying to learn something, we take notes, we highlight, we diagram things out, we draw lines between related concepts. In reading computer code, we pretend we are a compiler and a CPU and imagine what that program would do. If there is a way to optimize this kind of effort, we should find it and use it – if nothing else than to develop the virtue of laziness praised by Larry Wall above.

First, we need to understand how our brains work and approach our code reading exercise in such a way that it works with our cognitive limitations effectively. Then we need to understand the techniques we can use to maximize our time and effort spent for the kind of result we are trying to achieve. Additionally, we should know the tools that are available to facilitate our code reading efforts. Finally, just like any skill we want to develop, if we want to improve our skill set, we’ll need to know what exercises we can do to improve our ability to understand unfamiliar code more quickly.

Whew! So much to learn about something I already do most of every working day. Who has time to do all that?

You’re in luck because I’ll be discussing all of it this Friday. I will be doing a free webinar for No Fluff Just Stuff on Friday, January 13 at 1:00 EST: How to Become a Code Reading Ninja. It will be all online and over your lunch hour (or close enough), so come and check it out.

This is the first time I’m doing this, so I would really appreciate your support. Bring questions and any co-workers who might be interested. It should be a lot of fun! I look forward to seeing you there. Be sure to tell me, “Hi” when you get there!