Remember how Justice Gray started that little fad about becoming a better developer in 6 months?

Well, that was a while ago and most of you failed. Badly.

So here's a simpler challenge, some ways to be a better programmer in 6 minutes.

You've got 6 minutes, right?

Go for it!

Use a bigger font size. This is ridiculously easy -- but it works. Go to your favourite IDE, and crank the font-size up. I switched from 10pt to 14 pt. The difference is that a lot less code fits on the screen at once. The effect is: you're forced to write shorter methods. And that's a Good Thing . (Scott Hanselman recommends that one)

Make hard-coded strings look ugly. I learnt this from Joe Cooney. Go to your favourite IDE, and set it so that literal strings stand right out -- for example a yellow background with a red font. Make 'em ugly. Damn ugly. This will encourage you to perform less hard coding, and to notice when you are embedding strings in your text.

Pick an 'obscure' keyword and master it Do you fail to yield? . Is there a keyword you never use? Every keyword has a purpose. Learn to master those mystery keywords and your powers will become extraordinary. Here are lists for a few .net languages: C#, VB.net, F#.

Increase code-coverage by 1% Don't kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%. Most likely, that means going from 0% to 1%. And that's the biggest improvement of all. Find a particularly ghoulish regular expression. Or a critical piece of business logic. These things can't be trusted without tests.

Read the code from an open source project Sometimes, when I'm looking at the code of a complete stranger, I get that same, weird feeling I get when I'm creeping through my neighbour's house. Picking up their stuff, looking through their fridge. Learn to overcome the creepy sensation, and bring on the learn. Maybe start with Hanselman's Weekly Source Code series.

Run a static analysis tool against your code Use fxcop, or StyleCop, clone detective, ndepend, the code metrics feature of VS 2008, or any other static analysis tool of your choice. Uncover your greatest weakness. Even a cursory glance at the output will leave you distraught at just how much room you've got for improvement.

Pick an ugly method to refactor You know the method. That method you're particularly ashamed of. That one that's long and ugly and horrible. And it's crucial to the whole application. You don't have to polish it from a turd to a diamond, but just neaten it up a little. Rename a variable. Hoist part of it out into a separate method. Start simple. The momentum will increase. Watch out.