Always leave the campground cleaner than you found it.

This little rule can have a great impact on our profession. It basically means to check-in our code a little better than how we found it when we checked it out.

Imagine you’re working for a bank that just opened, and your job is to create a module to handle the creation of new customer accounts. You might decide to call the entity being managed Account throughout the system. The name you chose is simple and appropriate, your implementation is very well written and is 100% covered by tests. You could say you did a pretty good job.

A few months go by and the bank’s business is going well, so they decide it’s time to have two kinds of accounts: savings and checking. A new programmer joins the company and is in charge of implementing the logic to handle checking accounts, so it’s time to revisit your code. Even though your implementation was great, it only handles savings accounts, so the introduction of another account type just deprecated your code’s clarity. Now the system has references to Accounts and CheckingAccounts, and when we read just “account” it’s not clear wether we mean savings or checking.

Every future developer working on the bank’s system will appreciate if the person implementing the CheckingsAccount would take a few minutes to update the Account class to SavingsAccount. With that simple change, the system regains clarity.

I hope you see how your contributions don’t have to be big or time consuming. After you do your part, just do a little bit more, such as refactoring a long method, or changing a variable name to something more appropriate.

All code has room for improvement, and if we follow this rule we’ll end up with a codebase that keeps getting better as time passes, instead of degrading. Imagine the quality of code we’d have in our projects If everyone in our team would do that.