Oral hygiene - word about automation

How do you make sure you still have teeth in your thirties - you look after them since day one. While your parents are catching up with sleeping after several heavy in 'mommy my tooth is coming' nights you should be starting cleaning your teeth. Well, your parents should help teach you that.

Is it enough to know how to brush your teeth? Not really - far more important is to know why you should be doing it. Is it sufficient to have them brushed consistently? Still not - a special ritual has to be integrated with other rituals you have. What in case when you don't have any rituals? Well if you don't sleep every 24 hours, or eat at least once a day then state of your teeth is not your biggest problem.

So we condition ourselves to brush our teeth right after a wake up, or right after eating, or right before leaving to school. After some time it costs us more effort not to do it than otherwise. What we are doing here: we automate the process.

That takes off a lot of hassle - like checking whether teeth should be cleaned in the first place, figuring out where to fit it into our busy schedules etc.

Additionally it's the only way to do anything consistently for a longer time period (try exercising every now and then and check your average).

The same stands for your project hygiene - if you want to have something done consistently, you have to make sure that activities required are integrated into your daily routine. Automation is the key. Fortunately computers come handy there, as there is nothing they do better than stick to the clock and doing repetitive task.

And believe me if you want your project clean you need to brush it every single day. Build up your tasks, schedule them and make sure that results are being delivered every morning.

Soon enough lack of report in your mail will feel like dirty teeth and you will be able to be in software project in your thirties.

Covering your tracks - let your codebase follow your skills

We've all been in situations when somebody dug up a piece of code from 1997, in a far far away module, authored by us and still containing some not the best of the breed code construction. We've spent too much time catenating Strings instead of StringBuffers, we left behind empty catch blocks, we double-iterated over a map first for the key and then for the value, you name it. We would never do it now, but there were times when we weren't that expert. When it happens there is usually a lot of joy for others when it's spotted, not so cool for us though.

There are several things we can get out of it: first of all if we want to see our programming skills evolving we just need to review our code in chronological order - it's all documented there. Now as we already know how to fix ourselves a nice evening of memories, full of emotions, recalling how fragile and naive developers we were some day, let's think about some more practical aspects of that discovery. Thus the second: people are still running this code and depend on it, and the third – if your portfolio is to be complete it doesn't look to good.

It seems like a good idea to – whenever you learn something new – review your earlier work and update it according to new information you’ve just gathered.

How would you go about that?

You can read the whole code, spot where you used a 'deprecated' technique and replace it with a 'better-new' approach. A single review of such kind may be months to years in time cost depending on how productive you are, and there is a high risk that your manager will beg you to make sure that you will not learn a single thing afterwards.

Then you can use string analyzing tools: simple 'grep' or any other string find software would reduce this time greatly (if you are using home-made one please make sure that you are using StringBuffers for heavily changing strings). You will still get a lot of noise (false positives) and miss a lot of problems (false negatives), which will require a lot of manual analyzing - nevertheless it will be much faster than reading through the whole codebase.

And then there are dedicated tools for that - greps which have kind of regular expressions based on the structure of programming language you work in. That's the fastest I know. Choosing such tool you need to make sure that (one) you are able to integrate it with your work, (two) you can define the pattern you want to find easily, and (three) you are able to define patterns in a way which allows you to reduce noise to minimum (patterns are not to generic (false positives), or too specific (false negatives)).

Once you have such product integrated with you - as soon you learn something new, you can make sure that code you created in the past follows.