Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

This month I ended one job and started another. My decision was based in part on the fact that a portion of my old company (including me) was sold to another company. This resulted in me being abruptly pulled away from my team and my boss, both of which I liked a lot, and from the cool rearchitecture we were working on; That, as well as all of the uncertainty of transitions like this, made it an ideal time to make a break.

So, having made the decision to move on, what was the most important criteria in my job search? Outside the usual things (tools, environment, professional-growth) I added a new criteria to the top of my list; as the old real-estate saying goes: location, location, location.

My previous commute was 50 minutes each way; my goal was to get my commute down to a maximum of 25 minutes each way, preferably less. Actually I was able to get it to quite a bit less; my new commute is just 10 minutes, which gives me a whopping 1 hour 30 minutes of my life back per day.

So what does this move get me? more family-time(hey kids, my you've grown) and free-time(blogging! exercise?), less money spent on gas, less wear and tear on my car, and less traffic related stress. And with a 5 minute drive home for lunch it means eating healthier and more time with my wife without the kids. It also means I can be there for parent teacher conferences and similar things without taking half a day off from work.

As much as many of us long for work-life balance, it's been my experience that it still falls to the bottom of the list in light of more practical concerns. The real question about work life balance is how can more of us have it and have it more often?

With telecommuting being nearly unheard of in I.T. (unless you know something I don't) the best we can do is either take a job closer to home (not easy but not impossible) or move closer to work (seldom practical and certainly not popular with my wife). Oddly enough it's customer service jobs that seem to be taking the lead in telecommuting and then only when the companies can work it decidedly to their advantage. My hope is that more companies will open campuses or small branch offices near the suburbs where developers actually live; well that and that more companies will see that I.T. staff are exactly the kind of people who could excel in a teleworking environment (even if for only a few days a week).

There are probably longer commutes somewhere in my future (hopefully far far away) but I am enjoying a more balanced life now and I plan to make the most of it. I hope that you have the opportunity to do the same.

Another excellent talk from Jared Spool for all of you web developers out there. In this podcast he talks about the scent of information and how your content and design should suck, by which he means pull users toward the information that they are looking for. He also explains what trigger words are and how they allow your users to find the content that they are looking for. He also walks you through several user testing scenarios on different websites and gives a lot of real world examples; there's really just a ton of great tips and information here.

If you're one of the guilty parties who leave dead, commented-out code in the code base please stop.

Seven reasons to delete dead code:

It's dead.

The dead code is only valid/useful in it's original context and as the code continues to change that context will quickly disappear.

It's in source control history anyway (in it's original context). You are using source control aren't you?

When you checked in your changes to source control you should have noted in the comments box that you deleted the code and why (assuming the deleted code was important).

In the future neither you nor anyone else could really trust that the code is valid even if it does need to be put back in place; it's probably just as fast to rewrite it as to validate it.

If people do need similar functionality they might be tempted to use the commented code as a crutch without really understanding what it does, and when they do really bad things will happen.

The code will stay there... forever. No one else will delete because they won't know why it was removed and they'll be afraid it contains some magic bullet that may be needed sometime in the future (after all it must have been left there for a reason). In three months even you won't remember why you removed it, your comments will seem unclear and you won't delete it either because you'll be just as afraid as everyone else.

I'd like to jump back to number 4 right quick... you are filling in the source control comments when you check in a file, aren't you? This takes 60 to 90 seconds tops and really improves the value of your code history. When someone looks at the comments they should see at a minimum the ticket or project number (or emergency situation) that instigated the changes and a 1 to 3 sentence summary of what you did.

And don't cheat and check in 60 files at once and put "updated for ticket 0974". Though this is better than nothing, in most cases checking in each file individually and commenting on that file in the context of the ticket is much more useful e.g. "ticket 0974: added a link to header menu to point to the new analysis engine (only available for administrative role); fixed menu formatting problem; removed commented, dead code from my previous changes.". Now if someone reviews you're changes they can look at your comments, do a file compare to the previous version and understand exactly what you changed and why.