Phil WinstanlyToday's article is provided by Phil Winstanly, an Application Development Manager at Microsoft.

Often found on twitter causing trouble (and getting into bother) via @Plip. Loves code, loves learning and loves helping developers get better at what they do.

Well, here we are, Microsoft’s very own equivalent of Radio 4’s “Thought for the day”. I’m not a Vicar or a Rabbi, but I do have very strong beliefs around my own personal religion, that which we all share, the art of software development and the craft of cutting code.

The more experienced we become as developers a pattern I see is that we seem to change less. Maybe it’s a mantra of old dogs and new tricks. Technology often moves more quickly than any individual can keep pace of it which leads us to occasionally retreating into the comfort of technology and techniques we know and love, they keep us productive right?

If you’re not surrounded by other coders day in day out then working in isolation can very quickly lead to a stagnation of your skills and abilities unless you’re determined and driven to force yourself to learn and grow.

Why improve? Your code can always be better, we all make mistakes (even you!). Writing code which is more easily maintainable, has fewer bugs when pushed into production with a lower support cost is a goal we should all aim for. Plus, it makes us happier developers.

So how do you go about improving your code and approach? (And, there’s ALWAYS room for improvement). Firstly I think it’s important to have an open mind, and accept that you might do things a certain way because “you’ve always done it that way”, look at what you do and why you do it, your naming, your file structure, how you lay out projects and solutions, what problems might be caused (or are already occurring!).

Once you’re being honest with yourself, it’s time for the real litmus test of your ability to be open to criticism. Get a colleague or friend (although not in the pub, that could get messy) to look over your code, discuss it and be open to other ideas and concepts. Read through line by line, look for patterns, often one change in approach can have dramatic results.

Once the wounds have healed and your friendships have recovered from the slight disagreements that happened when you had a look at one another’s code, it’s time to let the machine have a bash. You might be familiar with Stylecop which will look at your code and aggressively suggest improvements changes to make the code match a set of rules it provides. Run your code through it, you might be surprised what it picks up. Ignore the rules you don’t like.

There are also third party tools which can keep you on your toes and will suggest ways to change your code as you type, the two big ones are CodeRush and Resharper. Personally, I find them too intrusive when I’m hacking away, but I know lots of people can’t code without them anymore, your mileage may vary.

Finally, don’t be afraid to admit your mistakes, learn from them and improve. It’ll make you happier!