This is going to be an odd publication, that falls more into the “life tips” or “self help” category, than into “programming”. But bear with me.

What is “clean software”? Software that has very few bugs, that has readable and maintainable code, that has good documentation and a lot of automated tests and metrics. How do you get clean software? Each day you fix and improve things. As I wrote a month ago – you should fix bad code as soon as it appears (or in the next sprint/iteration), and you should have code reviews to make sure everything committed is fine. You must write good unit tests, even though it might feel redundant. You must eliminate all bugs before writing new code (one of Joel’s 12 points). You should document everything that you write, so that it’s clear what it does and why. And you should have a project plan (Joel’s test, again). As a programmer you know these things, and you are aware that they make better software. And now the metaphor – the development of your life is like the development of a software system – if you follow some best practices and principles, it will be better (obviously?). If you apply the “clean software” approach to your own existence, it is likely to improve in the long run. What do I mean:

• health issues – in case of any discomfort or pain, fix it immediately. Run the “automated tests and metrics” in a hospital, and find out what is it. If you fix it early, it won’t get more complicated to fix later. And don’t let these issues stack.
• you don’t improve your code only when there’s a bug – you improve it daily, as soon as you see a potential for that. Do that with your diet, daily routine, exercise plan, harmful habits, etc. If you do it, you’ll get way less “bugs” in the future
• human relationship issues (not just romantic relationships) – if you have any issues with that, analyze them (like you analyze your code), find spots for improvement. Don’t let things degrade in quality, because soon enough it will be very hard to refactor (e.g. fix a friendship). Again, fix “bugs” as they appear.
• review your actions. Like every good code review, this one is best performed not by the author, but by a peer. Friends make good reviewers.
• have a project plan. It doesn’t have to be detailed and exact, but a good TODO list is always welcome. Generally it’s good to know where you are going, at least short-term. But be agile – don’t make a problem out of a failed expectation. Simply rescope.
• general problems – sometimes the system breaks, sometimes life’s tough. Fix the bug that broke it (that is, the reason for having the problem) and restore the backup (get where you were in the start). Document the issue so that it doesn’t occur again.
• have fun – you are programming because it’s fun, right? And you wouldn’t program, if it weren’t fun. Do so in real life as well, otherwise the desire for keeping up with other “best practices” diminishes.

Of course, this is all not that easy even in software development, let alone in real life. But applying the structure and determination of your “clean software” development practice in real life can make it “cleaner”.