When it comes to writing documentation, nobody wants to do the job. And whatever documentation does get written is quickly outdated because nobody wants to update it, either.

The most accurate documentation of how a system works is the code itself, but even “self-documenting” code falls short of describing why it was written that way. The next best thing is that little bit of text that gets attached to every code change: the version control log message. Read more on Commit Messages – the Easiest Documentation You’ll Ever Write…

In the last two years, I’ve worked on a few projects passed on to me by other teams. Inheriting an existing codebase can be a challenge, given you weren’t there when architectural decisions were made, you are less familiar with the project domain and client needs, and you are just new to the codebase.

Read more on Four Steps for Inheriting a Codebase…

When you need to add a major bit of functionality to your system, what’s the first thing you do? Naturally, you start looking through whatever package repository is appropriate for a solution that fits. While there’s nothing inherently wrong with this, it’s important to think of the trade-offs made by adding external dependencies. Read more on A Case Against Dependencies…

Every project eventually hits a point where a big change needs to be made, and it’s going to break everything. And you’re going to be the one stuck putting it back together.

Whether it’s a language or tool change that causes your application to no longer compile, a third-party SaaS service change that breaks features throughout your app, or just a big refactoring, eventually you’re going to have to bite off more than you can chew. After having been faced with situations like these many times, I’ve developed a coping strategy. Read more on Getting Ready to Break Everything (in 5 Easy Steps)…