Becoming a better programmer

Recently we have started training one of our support guys, into becoming a junior developer.  It’s the 1st time we’ve trained someone on the team, who hasn’t coded commercially before.  It got me to thinking about what makes a good developer, and in turn how I can become a better developer.

I read a few other good blogs on this issue of being a better developer before starting this one.

• http://jcooney.net/
• http://arcanecode.com/2007/07/13/being-a-better-developer-in-6-months/
• http://hanselman.com/blog/

It also got me to thinking about how I have improved at developing over my career.  Here are some of the things I’m definitely better at now than I was at university.

• Naming of methods and refactoring.  I now use clear concise methods, both in their naming and what they do.  If you need to comment in what the method is doing, rather than that being obvious by the name, I think you are doing something wrong.
• Becoming less likely to jump to a new technology straight away.
• Building user interfaces that really guide the user from start to finish and require little or no introduction. SSW rules to have some great pointers here.
• Dotting the i’s and crossing the t’s in a project, getting it deployed and not having it sit in development or ready for deployment state.
• Searching Google (will it wasn’t there when I was at uni) but I now know when searching which paths it sends me down which are just plain ludicrous and which to follow.  Google can point you in one or two good directions when searching how to solve a coding issue, and thousands of wrong directions.

Then I started thinking, what am I worse at than I was when I came out of university.

• Becoming less likely to learn a new technology quickly (didn’t I mention about that in the positives above) – yeah but there are pluses and minuses to it.
• Deploying projects before they are fully ready.

My main tips to becoming a better developer

• Name your methods and classes will, if they don’t make good sense when you are developing them, you are going to have a lot of trouble maintaining them.
• REFACTOR REFACTOR REFACTOR!!!
• Build user interfaces that don’t need instructions and are in the main self explanatory
• Get involved in teaching others what tips & techniques you have acquired, this will crystallize them in your own mind and help your team.  Teaching will also show you where you are bluffing and don’t understand it, because if you don’t get it you certainly can’t explain it.
• Learn a new technology once per month, and use it in a mini project.
• Don’t let another member of your team become completely specialised into one technology – make sure you all have some awareness of what the other guys are coding.  My colleague is doing a WPF project, and I have no clue how it works, this shouldn’t happen.
• Get to know the users of your software and LISTEN to them, also if possible use your software in the field.
• Above all be passionate about coding and the software you write.