Learn one thing a day
Date: 2009-10-03 13:58:55

I came across an interesting post about a month or so written by Chad Fowler on Tim Ferriss' blog where he suggested that a useful way of ensuring that we are always improving is to ask the question 'http://www.fourhourworkweek.com/blog/2009/07/28/the-big-question-are-you-better-than-yesterday/[Am I better than yesterday?]' at the end of each day.

I really like this idea and I think it fits in quite nicely with the approach that I take which is to try and ensure that I learn one new thing each day.

I find that it encourages me to be more inquisitive than I might otherwise be and helps avoid the problem of just cruising through the day and just doing the same thing day in day out.

When we start working on a new project it's quite easy to achieve this because we don't know much about the domain, we might not be familiar with the stack, there's existing code to get familiar with and so on.

It's much more challenging after you've worked on the same thing for a while and it's certainly tempting to conclude that there's nothing else to learn and that you need to work on something new to learn new things.

To an extent that's true because I find that a lot of what I learn comes from working with different people who have completely conflicting opinions on the best way to do things but there's certainly ways to keep on learning even after we've got past the initial http://softwarecraftsmanship.oreilly.com/news/2008/10/11/the-firehose[fire hose] learning stage.

== Continuously question what you're doing

This is http://www.markhneedham.com/blog/2009/09/25/tdd-it-makes-you-question-what-youre-doing/[much easier when you're pair programming] but certainly possible even when working alone.

I think what you question probably depends on what interests you the most so for me that tends to be a lot around how we can test code more effectively and how to make code more expressive and explicit wherever possible.

In order to do that I'm often looking for patterns that help to describe approaches that worked well and if we get something wrong then I want to try and discover what we would need to do when encountered with a similar situation in the future to not make that mistake again.

Fairly closely linked with the idea of questioning what we're doing is to try out other approaches and see if they work out better than what we're currently doing.

For example my colleague Matt Dunn and I were recently discussing where the factory and builder patterns were more applicable for object creation in different contexts.

We already had the factory pattern implemented in one section of the code so we spent a little time playing around with the builder pattern to see if that would have worked out better.

I think this appraoch works quite well because you can quickly see the potential problems you might encounter with another approach which might not be entirely obvious if you only talk about it.

== Trawl the code base

An approach which I find quite useful once you are becoming reasonably comfortable when working with a code base is to start trying to find bits of it that you haven't done much work on or that you are curious to learn more about.

For me this exploration tends to guide me to the edges of the applicatins I work on and the interaction with other libraries that we are making use of.

A couple of examples of ares that I've explored on projects I've worked on have been the way that we make use of a dependency injection container which can often seem a bit 'magical' and  the 'glue code' that we use to integrate with libraries like Hibernate.

If my intrigue is great enough then I'll probably end up looking through the code for those libraries as well.

There's nearly always something new to learn there as the design of frameworks tends to be a bit different than the design of applications from what I've seen.

== And if that doesn't teach you anything\...

At some stage we probably reach a  point where we're really familiar with the code base and there doesn't seem to be much else that we can learn from a project.

If this is the case then I've found that http://www.markhneedham.com/blog/category/dotnet/f-dotnet/[learning a new language], taking part in http://www.markhneedham.com/blog/category/coding-dojo/[coding dojos] or participating in a http://www.markhneedham.com/blog/category/book-club/[book club] can not only be quite useful for helping to learn new ideas/techniques but also perhaps giving you a new perspective on your project code base.

It's also interesting to talk to other people to see what they're learning as it can give you ideas of some areas that you might want to improve in as well.

I think people working in software development generally have a desire to learn new things and most of the time it's quite easy to find those opportunities so these are just a few ideas for things I try to do when it feels like I'm cruising too much for my liking.