30 July 2007 in General | Comments enabled

Lately I’ve been thinking a bit about how developers progress and evolve into better developers, partly inspired by recent pod casts from folks like Scott Hanselman about how to become a better developer in six months.

Before I go further, I don’t believe any endeavour has a point of perfection, even the best in a field is striving to do even better. Nobody is immune from needing to increase their skill level and if you think you are or can’t be bothered then change fields – you’re likely just holding others back by being a stick in the mud.

How do I try to become a better developer?

  • Work with the best. I have the fortunate situation of working with a couple of the best developers I’ve ever met. Working on solutions with them, nutting out how to tackle a problem and general knowledge sharing has enabled me to learn a considerable amount from them.
  • Reading blogs isn’t enough. I used to believe that simply consuming huge volumes of information from blogs and software development related sites would make me a better developer. I’ve since come to realise it only helps in making me aware of the possibilities but doesn’t help me practically. Now when I spot a blog post about something that takes my interest I’ll try and pull down some code or implement what is being shown. Actually doing things is far better than just reading about them.
  • Subscribe to mailing lists. Blogs and various sites are good to keep track of but it’s quite a learning experience to track mailing lists for projects that you’re interested in. Even tracking mailing lists in areas that you won’t be using day-to-day are great for providing perspective on what other developers are up to, for example, I watch the Moonlight mailing list about the Silverlight port to run on mono / linux. Mailing lists provide the nitty gritty detail about what is going on behind those blog posts that just trumpet new versions.
  • Actually write code. This one seems like a no-brainer and relates closely to point two – if you’re thinking about how something could be done then just write it up. I have a ‘research’ folder in my dev directory so where I spike up silly little bits of code just to see how something might work. Writing, combined with the reading I’m already doing, provides a complete learning experience.
  • Participate in discussion. Too many people are happy to be wallflowers and just watch others discuss and debate topics that relate directly to them. Why wouldn’t you share your thoughts if it affects you or is directly related to you? Usually fear of being cast as wrong about something or looking stupid. I try to take the approach of always sharing my thoughts no matter how stupid I may look – either I’ll be corrected and learn from it or I’ll look like I’m super clever. Ideally over time you’ll tend towards the latter. Never be ashamed or afraid of engaging in conversations and debates.

As you can see, much of my view about becoming a better developer is tied to a “use it or lose it” attitude being augmented with giving yourself new ideas seeded from other people. One thing to remember is that the evolution happens gradually over a long period of time, applying rules like this doesn’t mean on Monday I’m going to suddenly be a developer God.

I’m happy to hear if anyone else has habits that have helped them evolve as a developer.

– JD

Average Rating: 4.7 out of 5 based on 288 user reviews.

6 comments. Add your own comment.

Johnny-johnny says 30 July 2007 @ 09:02

You should name this post “5 ways to become a better developer” and then seed it to Digg. I’d Digg it!

James Newton-King says 30 July 2007 @ 11:56

When I’m working on projects, I find I learn a lot by questioning whether I’m doing something the best way. If it is something that I’ve never done before, rather than rocking in and hacking out a solution using what I already know, I always do a search on Google for references, blog posts and forum posts. I look at what others have done and learn from them.

John Rusk says 30 July 2007 @ 21:32

For me, _reading_ code has helped a lot. I used to work in Delphi, and you could actually step through Borland’s class library in the debugger, which was a great way to see some good clean design in action.

I also like the suggestions here: http://samizdat.mines.edu/howto/HowToBeAProgrammer.html

Aaron says 30 July 2007 @ 21:48

Another crucial thing is to use documentation. Not just search for snippets on google or ask for the solution. Learn how to use a API-Documentation or the (poor looking) Documentation. Bite you through and learn how to find the pice of information you want in a 1500 pages manual.

dugg it.

Skinny says 31 July 2007 @ 09:04

The same can be said for any endeavour, not just developing – use it or lose it.

To get good at anything network with your peers and learn from their successes and their failures, then go-ahead and make a few mistakes yourself.

traskjd says 31 July 2007 @ 10:12

Johnny: Thanks for the digg :)

James: Quite right, often stepping WAY back and looking for more elegant ways to solve a problem is much better than just trying to optimise the same way you have always written code.

John: Being able to step into the class libraries with Delphi was a nice, it is something I do miss but reflector makes up for it. I consider Reflector to be the best documentation out there :)

Aaron: I concur. We have tried very hard with the documentation for LightSpeed to be above the rest in terms of quality and helpfulness of the documentation. It is noticeable however that most people still ignore the documentation because of previous bad experiences with other applications documentation.

Skinny: Quite right! Fortunately in software it seems to be generally accepted that you must continue to “sharpen the saw” but often I see in other industries that sticking to tried and true is very much the status quo (some industries it’s required, I don’t really want my airline pilot trying new stunts all the time!).

Thanks for the comments :)

– JD

Leave a Comment

Name (required)

E-mail (required - not published)


Your comment: