I recently came across a interview with Dave Hoover where he talks through the idea of working as an apprentice software developer and suggests some ways to do this more effectively.

I think the easiest thing to get wrong in software development is to over estimate our ability and there is even a study that proves that theory. Hoover refers to this as 'having an accurate self assessment'.

If we work on the same project for a while then we’re going to get pretty good at navigating that code base and we’ll probably be able to solve any problem and add any piece of functionality fairly easily which only helps fuel the belief.

Although it’s very difficult to avoid I don’t know if there is actually much value in comparing ourselves to others in terms of skill level. All that tells us is whether in our opinion at a given point in time we are better or someone else is better.

I think the most valuable thing that we can gain from working with people who totally outclass us or mentors ahead of us in the field is that we can see the areas in which they are much more skilled and then we can start asking questions to work out what steps they have taken to become that good.

Guiding the conversation so that we can learn how others first became knowledgeable in a certain area, what books they would suggest as a starting point and so on is much more useful in helping us to improve.

It seems like everyone you speak to will have a different opinion on what are the best things to learn, so I find that it’s useful to remember that we aren’t going to be outstandingly good at every single area of software development. There are just too many different areas for that to be possible.

There will also likely be suggestions to study the classics and while I think it is useful advice I do think that sometimes it’s not immediately applicable and there may well be more recent books on a topic which are more accessible to us when we are first learning.

We need to reach the stage of learning a subject where our curiosity guides us towards the classics at which stage we can ask for advice on which one might be good to read.

Ravi Mohan has a cool blog post where he defines the 'book chain' pattern which suggests that getting suggestions on a useful order in which we could read books from more experienced practitioners would also work well.

I’m lucky enough to work with quite a few people who are very motivated by becoming really good at software development so there’s no shortage of peers to network with.

On a one to one basis we talk through the things we’re doing on our projects which has the added benefit of forcing you to know what you’re talking about because the other person doesn’t necessarily have the context to fill in gaps you miss in your explanation.

My colleagues Dave and Liz have been organising 'project flashlights' in the ThoughtWorks Sydney office every week where people can present a problem they’re trying to solve on their project or something interesting that they’ve been doing which works well for encouraging people to bounce ideas off each other.

I tend to code with colleagues outside of work in coding dojos or just randomly at least once a week and I think taking some time to practice with other people can be quite useful.

I’m not sure if it works so well when we’re totally novice at a skill but certainly even with just a few weeks experience using a new language I’ve found that working through problems with others helps me learn much more than if I work alone.

Beyond that there are code katas to practice on and another bit of advice that I still haven’t taken is to work on open source projects to embrace a different type of coding than we might get on our normal projects.