Revisiting Our Work

I recently watched David Heinemeier Hansson’s (@dhh) video on code comments and refactoring. While it’s interesting to see how he tackles these code changes, the most interesting thing to me is what he said he does with the codebase.

“I read through the entire codebase of Basecamp 3 and try to make things better that I don’t think are good enough, or revisit decisions that we’ve made earlier that I think now I have a better idea of how to do”

There’s a lot in that statement, so let’s unpack it.

First, he reads through the entire codebase! The fact that he does this shows great care for what he does and believes in.

Second, he makes changes where he doesn’t feel like the code is good enough. While many of us have ideas about what is “good” or not, I’m sure we’ve all gone back through older code and just known when we’ve seen it.

Lastly, he revisits past decisions that can be better handled now. Programming is an ever-changing space and developers are enhancing their skills and knowledge on a daily basis. So why shouldn’t our code reflect our most up-to-date understandings?

DHH isn’t the only one who does this though. Taylor Otwell (creator of Laravel) does something similar.

Going through code and documentation that you’ve already worked on isn’t the most glamorous job, even quite tedious, but necessary. It’s silly to think that something that was done years, weeks, or even days ago is still “good enough” for today.

I know I’ve fallen into the habit of not revisiting what I’ve worked on long ago — and maybe some projects don’t need it. However, if the public is using it — like in a current site, app, or package it might be time to take a look through for improvements.

Next Steps

I’m going to take a hard look at my messenger package (which needs some love) as well as a few side projects that I haven’t worked on in a while. What projects are you going to look at? Let’s share some successes. Send me a tweet or screenshot on Twitter, or leave a comment below.