You’ve likely often heard of programmers talking about change logs. Whether you’ve heard good things depends upon the developers with whom you’ve interacted.


At least keep track of it somewhere.

Sometimes, I think we get a little exhausted writing change logs. This ends up manifesting itself in half-baked commit messages or in lack of a changelog.

But if you’re a programmer responsible for leading a project be it as a freelancer or as part of a team, the importance of a changelog should not missed.

Two Reasons For a Changelog

First, to make sure we’re all on the same page, a changelog is as follows:

A changelog is a log or record of all the changes made to a project, such as a website or software project, usually including such records as bug fixes, new features, etc.

This may not seem like a big deal. This is true especially when you’re running a project from beginning-to-end. I mean, why track all the changes that go into the project when you’re the one implementing them? Wouldn’t you have the most familiarity with the code since you wrote it?


1. Re-learning Your Work

The likelihood that this is the only project on which you’ll ever work is pretty low. And as you become more familiar with new projects, you tend to forget concepts in previous work.

When it comes time to revisit this past work, it will take you that time to re-familiarize yourself. Furthermore, if someone else comes on board between when you started and when you resume work, they have to play catch up by reading through the source code and whatever notes you may have left inline.

That’s no fun for them and that can just add to the amount of time it takes to complete a project.

2. Where What Went Wrong

If you’re diligent about writing good commit messages, then you should be able to look back at your source control and find where you introduced certain changes.

And each time you tag a release, then the changelog should include at least the content from the commits of that release (if not more). This way, when the client comes back asking:

  • Where did this change?
  • When did we decide to introduce this?
  • Why isn’t `xyz` working anymore?

Then you can look back through the changelog to help pinpoint where something changed and the rationale behind it.

Developing a Habit

It takes a while to develop a habit like this. I’m not great at it but I’m better than I was just a year ago. And it’s something that I want to continue getting better at doing.

Of course, there are other reasons we should be tracking our work in source control and in changelogs. If you’re not doing anything at all, though, perhaps this post is enough to spur, ahem, change.