I just finished an exciting book that was loaned to me by a friend who wrote his own excellent book, Getting Started with Dojo. (Shameless shill, but it really is good).

As a developer and a manager of other developers, I am bombarded by the latest, greates, hypest new way to streamline and silver bullet the way I make software. As a developer, I am just as guilty of being excited by something just because it is shiney and new. This book was exciting because it wasn’t about hype and buzz, it was about working on your basics.

The Argument for Personal Improvement

As developers, at the end of the day, we are craftsmen. We are artisans, technologist, engineers all at once. Newer practices like Scrum and XP are not about making us better developers, but about giving us more control over our work, which is a really important key to success.

But making yourself a better developer is hard. It take discipline and constant vigilance. In my experience, a group of mediocre to decent developers can be  successful if the team is well organized and the business is sane. Methodologies like Scrum are so popular because they help with organization and sanity. They can take that team more success with less effort.

Conversely, I have seen great developers single-handedly wrestle a bad team and insane business unit to a “sucessful” software release. The problem is, a bad business usually won’t be sucessful even with good software. So, as a manager, fixing the team is usually more crucial than making mediocre developers super developers.

However, as an individual, Scrum won’t make you a better developer. It won’t help your hone your skills. It won’t help you develop  critical skills and talents that separate the software laborers from the craftsmen.

Personal Software Process.

When I started in this industry, the Software Engineering Institute had something called the Corporate Maturity Model (CMM).  But that was a long time ago, and while is was looking at shiney thngs like RUP, XP, and Scrum; the CMM has expanded into the CMMI, the Corporate Maturity Model Intregration.

The CMMI has evolved into an umbrella processes for sub processes which focus on continuously improving the

• the individual
• the team
• the whole corporation

My new favorite book, Best Kept Secrets of Peer Code Review focus on one set of these processes.

I have done code reviews for years now, but the idea of a personal review was new, simple, and made a lot of great sense.

Self Review

A personal code review simply involves reading through the code and using the review checklist to look for errors.

Each developer should keep a checklist for self reviews. This checklist will be unique to yourself. It should be a list of 10 to 20 things that you want/need to improve upon in your coding.

The goal of a checklist is to list things that if you did a better job at, your code would be better. This might include things like:

• Make sure that it has an up to date unit test
• Is the code properly commented?

Also, call out mistakes or bugs that you often find in your code. For example, if you find that you get a lot of NullPointerExceptions in your code; you should add:

• Check for potential NPEs

Keep It Small

The PSP emphasized on keeping self reviews small. Focus on around 200 SLoC or small-ish units like methods or small classes. Also review often, review early.

You don’t want to save up a bunch of code for the end of the week and then try to wallow through a giant self review. Best Kept Secrets of Peer Code Review actually sites some studies that show how code review productivity drops after about 45 minutes. So if you are taking longer than this, you are getting diminishing returns.

Follow the Checklist

1. Pick the first item on your checklist. For example, “Do you have good commenting?”
2. Read through your new code, reading for this specific checklist item.
3. Make corrections as you need
4. Record the correction/improvement
5. Go to the next item in the checklist
6. Rinse repeat

Don’t try to read your code for multiple checklist items at a time. To be successful, you want to give each checklist item your full attention as your do the read through.

In the above example, as your read through the new function you just wrote, you are asking yourself should I have a comment, a better a comment, or a simpler comment at each line.

This is why you don’t want to have more than 20 items in your checklist. It would take too much time.

Honing Your Craft

Recording your fixes is important!

As you use your list, you will find that you stop making some of the mistakes. This means it is working! For example, after you check your code for comments a dozen times; you start to think about the comments while you code. You will find that you don’t need to keep checking for it.

But look at the number of mistakes you caught. That is a mistake that you prevented from taking time from multiple developers in a peer review, or that your stopped from delaying a build in QA, or worste yet; found by a customer. These mistake counts are not records of your failings, these are the crital eye of a craftsman looking over his or her own work.

More so, these are the savings a craftsman makes by measuring several times and cutting once.

For more reading, the full PSP.