Mark Needham

Something which has become quite apparent to me recently is that I learn things far more quickly if I try it out myself and make mistakes than if I just rely on someone else’s word for it but some more experienced colleagues seem able to use information explained to them fair more effectively and don’t necessarily need to go through this process.

While reading through the Dreyfus Model one of the ideas that is suggested is that once people reach the level of ‘Proficient’ at any given skill then they are able to learn from the experiences of others without needing to experience something themselves.

Andy Hunt sums this up quite nicely in Pragmatic Learning and Thinking :

Proficient practitioners make a major breakthrough on the Dreyfus model: they can correct previous poor task performance. They can reflect on how they’ve done and revise their approach to perform better the next time. Up until this stage, that sort of self-improvement is simply not available.

Also, they can learn from the experience of others. As a proficient practitioner, you can read case studies, listen to water cooler gossip of failed projects, see what others have done, and learn effectively from the story, even though you didn’t participate in it firsthand.

If you’re not at that level yet it therefore seems to be the case that it’s necessary to experience this situations in order to learn effectively.

The trick thing then is to engineer an environment where it is possible to learn but not one where you jeopardise a code base by doing so.

In a way this is what we did with the setter/constructor injection problem that I described previously – Erik pointed out the disadvantages that we would get from using constructor injection on a class which many classes derived from but I didn’t fully appreciate his concerns and I couldn’t picture the problems we would face until we spent a bit of time putting the dependency into the constructor and I was able to see how this dependency would cascade down into the 30 or so sub classes.

Since we were trying out a setter based injection approach alongside the constructor injection based approach in a time boxed exercise we were able to just throw away the constuctor based injection code when we saw that it wasn’t quite going to work and so no harm was done to the code base.

I sometimes feel that a similar type of learning is probably going on in other situations as well.

One fairly common area of contention on projects I’ve worked on is around whether or not we should put stub/mock calls in a setup method in a test fixture.

On a project I worked on a couple of years ago we ran ourselves into a world of pain by putting mock/stub calls there because when we wanted to test a specific interaction in a test there would often be an unexpected failure because of those calls in the setup method.

It was never entirely obvious what had happened and we would end up wasting a lot of time before we realised what had happend.

As a result of that I’ve been pretty much against that approach although I can see why we might want to do this. It becomes very tedious typing out the same setup code in each of our tests.

Abstracting away that common setup into a method or series of methods which we explicitly call in each test provides one way to solve the problem but it takes the test setup one more click away from us when we’re analysing test failures so I’m not sure whether it solves all our problems.

My current thinking is that perhaps we can make use of the setup method as long as all the tests defined in that test fixture require exactly the same setup but that as soon as we are writing a test which requires a different setup we need to pull that test out into its own test fixture.

The problem with this is that we end up splitting our tests based on how they test interaction with a dependency which seems very strange to me.

I still don’t have the answer for the best way to solve this problem but I think I know a bit better from having experimented with some ideas than I would have by just listening to someone tell me about their experiences.

From my understanding of the Dreyfus Model, someone who’s really good at unit testing wouldn’t necessarily need to do this but would instead be able to learn from someone else’s experiences just by talking to them about it.

I’m assuming that they would be able to do this because they have a wealth of similar situations to relate your stories to and they can therefore fill in any gaps in the knowledge they have.

I think this aspect of the Dreyfus Model helps identify why just explaining something from your experience rarely seems to be successful – unless the other person is ‘Proficient’ at the skill in question they won’t easily be able to relate your experience to the problem without some experimentation of their own.

Perhaps there’s more to it and I’m way off the mark but this theory at least seems reasonably plausible to me

One of the quite common sayings that I’ve come across when discussing student/teacher type situations is that it’s the teacher’s responsibility to present the material to the student in a way that they can understand and that if the student still doesn’t understand then the teacher hasn’t done their job properly.

I believe that this approach is also followed in the UK education system nowadays and while it makes sense in a way I don’t think it’s a particularly useful belief to have as a student since it seems to encourage you to be quite passive in the learning process.

I find that when you are in a situation where you are the student it is probably quite likely that you are aware of the best way that you understand new material whereas the teacher doesn’t necessarily know and, unless they have the ability to work out which way you will understand best, they will probably explain something in the way that they would like it explained to them.

If you don’t know the way that you learn best then it’s quite a useful thing to try and work out.

I’ve worked out that I learn best when I can find something I understand already that I can link it to and as a general rule I understand things way better when I can work out a way to visualise it, usually by drawing a diagram or finding an explanation which includes a diagram.

My colleagues seem to have picked up that this is the way that I understand things best so wherever I happen to be working there will likely be stacks of papers with different diagrams on them!

I also know that it often takes me a few times before I understand something but that once I understand something I don’t tend to forget it.

It used to really annoy me that I didn’t understand concepts as quickly as some of my peers at university but now that I’ve noticed that pattern I tend to write down the concept or bookmark it if it’s on the web and then come back to it later when I might have learnt something else which helps me understand the other concept.

Maybe the responsibility really does lie with the teacher, and I particularly like the quote from the last slide of this presentation which says ‘If you can’t explain it simply, you don’t understand it well enough’ but it doesn’t do much harm to help them to help us.

I’ve also found that varying the way that I learn new ideas can sometimes be quite effective – for example there are now loads of videos available of people presenting on different technical topics and watching someone who knows a subject really well explain it through this medium can often make it easier to understand than reading an article about it.

One of the best ideas I’ve come across lately was from Pragmatic Learning and Thinking, which suggests discussing what you’re learning with others.

This is useful because you get the chance to see how well you understand the topic by trying to explain it as well as getting their views on the subject.

From our experiences running a technical book club it’s often quite surprising how varied people’s opinions are despite reading/watching the same material.

It seems to me that perhaps the most important skill in the world of software development is learning how to learn new things and these are a few of the ways that I find work for me. I’d be keen to learn ways that other people are doing this too!

Since we discussed the Dreyfus Model in book club a few weeks ago I’ve noticed that I’m more aware of my own level of skill at different tasks and references to the model appear more frequent at least amongst my colleagues.

These are some of the things I’ve been thinking about:

How do we use the model?

Alan Skorks has an interesting post where he discusses the role of the Dreyfus Model in helping to build software development expertise concluding that it doesn’t help very much in developing expertise within a team.

In Pragmatic Learning and Thinking Andy Hunt suggested that one way to make use of the Dreyfus Model is to analyse the skill level of people that we interact with and then adjust the way we present information to them accordingly which I think is a good idea but requires a reasonable amount of skill to do.

I’ve found that it’s actually quite revealing to just analyse your own level of skill and I hadn’t realised how many things I am a novice at and just rely on a series of steps/instructions to make any progress and get quite frustrated when one of those steps doesn’t work because I have don’t yet have the ability to problem solve effectively in that area.

I had an example of this a few weeks when trying to port our code from Subversion to Mercurial using hgsubversion and struggled to work out how to get it to work, in particular with the fact that the process always failed at the same revision with no real indication (that I could understand at least) of why that had happened.

I am a novice with regards to doing this. I was just following the instructions and since I don’t have any knowledge of the hgsubversion code base or even of Python I wasn’t able to progress much further.

In this case though there is an argument that even if we are not skilled at a particular task we still might be able to make use of a higher level of skill with problem solving in general to try and infer why something might not be working as expected.

Recognising which other skills might be useful to us when we are struggling with a new skill is perhaps a skill in itself and in this case Dave was able to do this more effectively than I was by suggesting different ideas to try based on his understanding of what probably happened during the porting process.

This allowed us to progress further even though we weren’t successful in getting it to work for the moment.

It’s ok to be a novice at some things

Having recognised that I am a novice at quite a number of different things I was questioning whether I should be trying to improve in all those areas that I had identified.

Discussing this with some colleagues though we came to the conclusion that there are so many different areas of skill in software development that there’s bound to be areas where we are going to be novice and if we don’t use those skills that frequently perhaps it’s fine that we don’t progress beyond that stage.

For more core technical skills it’s more important to raise our level although I think it might be difficult to identify which skills are important and which less so if we are a novice!

There seems to be potentially some conflict here with Marcus Buckingham’s idea of focusing on your strengths if our strengths aren’t aligned with the most important skills for software development.

On the other hand there are so many different areas of the field that it’s quite likely that something we’re good at will be important.

Experts and intuition

The way that those at the expert level work a bit differently to those at other levels is that they rely mostly on intuition when working out what they need to do but I think that there might be a bit of a trap here in that we assume we are an expert at something if we are unable to explain to someone else how or why we do it.

Although teaching a skill to someone else is a different skill than knowing the skill yourself, I think there is some overlap between them.

I have often found that when you try to explain something to someone else you are forced to really work out what you actually know around this area.

I think we probably learn more from teaching a skill to someone else than via any other learning approach and I currently measure my understanding of something based on whether I can explain it to someone else. If I can’t then I don’t know it as well as I thought.

The inability to explain something might indicate that we are an expert working by intuition but it might also indicate that we aren’t as skilled as we’d like to believe.

Justin Kruger and David Dunning’s paper titled Unskilled and Unaware of it, which discusses how people are liable to overrate their own ability and are even more likely to do this the less skilled they actually are, seems to provide some evidence that this theory might be true.

From my understanding of the Dreyfus model one would need to have gone through the previous levels before reaching the expert level so perhaps the perception of expertise wouldn’t actually happen for a real expert.

I’ve been watching one of the podcasts recorded from the Alt.NET Houston conference titled ‘Why blog and open source‘ and one of the interesting ideas that stood out amongst the opinions express is that people write about their experience in order to understand the topics better themselves.

I’ve found this to be a very valuable way of learning – in fact it’s probably more beneficial to the teacher than the student, somewhat ironically.

I’ve noticed that there are a few opportunities that we can take advantage of in order to increase our knowledge on topics by teaching other people about them.

By ‘teaching’ I mean explaining your understanding of a topic to other people rather than the traditional classroom approach where the ‘teacher’ is the expert and the ‘students’ are mostly passive learners.

Writing/Presenting

Blogging was the topic being discussed on the podcast, and I’ve found that writing about a topic is a pretty good way of organising your thoughts on that topic and seeing whether you understand it well enough to construct some opinions that you would have the ability to defend.

I’ve often found that when I start to write about a topic I discover some things about it that I hadn’t previously considered and of course the ability for people to give you feedback on what you write means that it can become a two way conversation. There have certainly been a couple of occasions when people with more knowledge of a topic than me have pointed out where my understand of something can be improved.

The same thing applies when presenting about a topic although the feedback will be more immediate.

Book Clubs

One approach we’ve been trying out in our Domain Driven Design book club recently is to split the sub chapters between each of the members of the group and then everyone presents their part in the next meeting.

The advantage of this approach is that everyone gets the opportunity to teach the rest of the group in a topic area in which they have more knowledge and/or have studied more recently.

If you know you need to explain something to other people then I think it encourages you to approach the subject differently than if you are just reading through it for yourself. You also need to understand the topic more clearly yourself and be able to put it into your own words to explain to other people.

Pair Programming

I think one of the situations that can be the most frustrating in pair programming is when you understand something really well and your pair doesn’t understand it as well.

The temptation is to wait until they’re not around to implement your ideas but this misses a great opportunity to explore how well you really understand the topic area.

The questions posed by someone with less knowledge on a topic than you will force you to come up with good reasons for your opinions that you can explain in a more simple way than you may be used to. We may be forced to come up with metaphors that make it easier to explain something and certainly coming up with these metaphors may improve our own understanding.

In summary

I think there are a lot of opportunities in the world of software development to teach what we know to others and although it may seem that we are doing a favour to other people, I think we will find that we learn just as much as them from doing so if not more.

Of course it’s not the only approach to learning but I’ve found it to be a surprisingly effective one.

An interesting thing that I’ve started to notice recently with regards to software development books is that I get a lot more from reading the book the second time compared to what I did reading the book the first time.

I’ve noticed this for several books, including The Pragmatic Programmer, Code Complete and Domain Driven Design, so my first thought was that perhaps I had read this books too early when I didn’t have the necessary context or experience to gain value from reading them.

A conversation with Ade led me to believe that perhaps this isn’t the case and in actual fact reading the book the first time pushes your thinking in certain directions even though you don’t necessarily realise it.

Coming back to the same book again seems like it should be a waste of time, but I think we have different ideas about what is important when it comes to developing software and therefore the book affects us in different ways despite the fact that the content is exactly the same.

With the three books I mentioned above, the first time I read each of them the advice seemed fairly obvious and continuing with this attitude I struggled to get much out of them.

The Pragmatic Programmer was the first one I re-read and the second time I read it I was getting into the idea of automation around build and deployment so the parts of the book which talk about automation really stood out for me. A lot of other places where automation would be useful became apparent to me from reading the book the second time.

I started re-reading Code Complete after a recommendation from Dave but this time my focus was heavily on the expressibility of our code as this is the area of coding that I am very interested in at the moment. Some of the ideas around variable naming are superb and are directly linked to some of the mistakes I have made recently in this area. It was very interesting for me to see this in a book I hadn’t picked up for a few years.

Domain Driven Design is by far the most recommended book amongst developers at ThoughtWorks and I am currently reading it for the second time but this time as part of a technical book club. I have learnt how the specification pattern can be applied on real projects thanks to examples show to me by Alex but in particular the idea of bounded contexts has started to make way more sense to me due to the fact that we didn’t follow this idea on a recent project and really suffered as a consequence.

I’m sure when I read these books again I will learn something else that I didn’t learn the first or second times.

More than just books…

I think this can also apply to the way that we learn other things such as different styles of programming.

For example, I studied functional programming at university but I never really saw the benefits that we could get from it – the lecturer just pointed out that it was ‘better’ than using an imperative language which didn’t really resonate with me.

Having played around with Erlang and F# a bit and seeing some of the problems we cause ourselves in non functional languages by having mutable state I am starting to understand and like it much more.

The realisation for me has been that we don’t have to understand or get everything the first time we do it, there are plenty more opportunities to do that.

And on a book specific level, to make sure I read books more than once to see what I get out of them the next time!

I’ve been reading Jeff Atwood’s post regarding Joel’s comments on the podcast about Uncle Bob’s SOLID principles and what struck me as I read through his dislike of having too many rules and guidelines is that there is a misunderstanding of how we should use these rules and I think at the heart of this understanding the Dreyfus Model might clear this up.

To briefly recap the different levels of the Dreyfus Model (you can read more about this in Pragmatic Thinking and Learning)

• Novice – Little or no experience in a skill area
• Advanced Beginner – Break way from rules and try some stuff alone. Have difficulty troubleshooting
• Competent – Develop conceptual models of problem domain & can problem solve
• Proficient – Try to understand larger conceptual framework around skill. Can reflect on performance and do better next time
• Expert – Vast range of experience to apply in just the right context

Given these levels at which any person may be at for a given set of skills, as Dhananjay Nene points out someone who is an expert in this area is not going to be referring to a checklist of design guidelines – they have already been past this stage and are at the stage where they can apply the ideas intuitively in the right context.

If you are at a stage where you still need to review your design with respect to the SOLID principles (or other appropriate design principles) – please take your time to apply the principles, learn if you are breaking them, understand the costs of doing so (I would recommend that involve a senior programmer / designer in the process) and then by all means make the best judgement. Principles distilled over time and experience should be adjusted preferably by those who understand the cost and implications of doing so, the rest should strive to reach that state first.

In which case the following statement on Jeff Atwood’s post makes perfect sense:

Like James Bach, I’ve found less and less use for rules in my career. Not because I’m a self-made genius who plays by my own rules, mind you, but because I value the skills, experience, and judgment of my team far more than any static set of rules.

But it shouldn’t be used as a stick to beat the principles because using them as a set of guidelines or rules is still very valuable for someone who is not so far up the Dreyfus Model as Jeff is for this skill.

I still think there is value in re-reading the principles even when you think you have got them ingrained in your mind and don’t need to keep on referring to them to write your code. I have often found that when I end up writing code which is difficult to work with it tends to be because I’ve broken one of the principles without realising that I was doing so.

Overall

To summarise I don’t see a problem in following principles/rules when you are new to a skill – in fact I think this is the best way to pick up good practices otherwise you are just guessing.

In order to progress up the Dreyfus Model we need to eventually start questioning the rules and working out when we should and should not apply them.

Leaving the last word to Mr Atwood…

Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substute for thinking critically about your work.

One of the things that I have been curious about since we started running coding dojos is whether people learn more effectively alone or when learning as part of a group.

Not that I think they are mutually exclusive, I think a combination of both is probably the way to go depending on what it is we are trying to learn and the way that we’re trying to learn it.

A new language

I think learning a new programming language is one of the times when learning on your own makes the most sense.

That way we have the freedom to try things out and understand how everything fits together without frustrating other people who may understand more than we do.

There comes a certain stage though where we have questions that we can’t answer and then I think it is quite useful to be able to work through the problem with someone else and get their input.

I’m currently learning F# and although I’ve been learning it alone it has still proved to be useful to talk through some of the ideas I’ve come across with colleagues and get their input on useful approaches to take for my future learning.

Technical Book Club

We recently started running a weekly Technical book club in the ThoughtWorks Sydney office. The first book we’re reading is Eric Evans’ Domain Driven Design.

The idea is that people read part of a chapter alone and then we come together once a week to discuss that area of reading. The idea of discussing what you read is one which is encouraged by Andy Hunt in Pragmatic Learning and Thinking, and I have certainly got more from reading the book and discussing it with my colleagues than I did from just reading it alone about 6 months ago.

We’ve been going through a few chapters over the last couple of weeks which we’ve found quite difficult to discuss but actually showing some code of how to implement certain ideas has made the sessions much more interesting.

For example last week two of the members of the group were able to show some examples of using the specification pattern which brought the ideas to life a lot more for me than just reading about them in the book.

I’ve found taking part in a book club brings a renewed focus when reading and others in the book club are able to explain areas of the text that I didn’t understand when I read it.

Coding Dojos

Coding Dojos are the ultimate when it comes to learning together. The format that we have used the most is to have one pair driving the code, rotating a new person in every seven minutes.

We started out solving problems in an area where everyone had a high level of proficiency but the last two weeks have tried playing around with libraries that not everyone had a great deal of experience with.

While there is learning to be gained from the latter, people seemed less keen to get involved at the keyboard on these sessions so I don’t know if as much was gained from these sessions as could have been.

In previous sessions though I think the dojo approach has been really good for helping us to ‘practice what we preach’ in terms of following good practices while at the keyboard. Having 4 or 5 other people watching you tends to encourage that!

I’m sure we haven’t found all the learning areas where coding dojos can be useful, but I’m veering towards thinking the maximum is gained when the majority of people have some experience with the technology being used.

Alan Dean looks to be taking the idea even further with his Open Space Coding Days which start next weekend. It will be interesting to see the feedback on the learning people were able to achieve in this environment.

While reading my colleague’s notes on a brown bag session on pair programming she gave I was reminded of my belief that we learn much more effectively when we are learning in a practical environment.

The bit that interested me was this bit regarding onboarding:

On board new team members to bring them up to speed on the overall goal and design, so you do not need to repeat basic details when you work with them on a story.

It’s fairly normal for the Tech Lead to give new starters on a project this kind of overview and although it is useful as a starting point, nearly everyone I have worked with is keen to see how these ideas are implemented in the code.

I think there is still a place for the presentation/context free style of teaching but we should look for opportunities to get people into the context of what they are being taught as often as possible.

Pair Programming

I’ve written about this quite a few times in the past so I don’t want to labour the point, but this is by far the most effective learning approach that I have seen so far.

It works especially well when at least one person is skillful in the technology currently being used. Obviously it works even better if both people know it but it is useful to have one person who has the ability to teach the other.

Being shown how to do something and then trying it out yourself is much more effective than having someone talk about it at a more abstract level and then trying to apply what they have taught.

For example, we have been discussing recently how to write better Javascript/jQuery code and all the things talked about make sense but it didn’t really click in my head until I got the chance to work with some colleagues who were really skilled in this area. I’m certainly not an expert but having this opportunity has given me the chance to improve more effectively.

Coding Dojo Style Learning

We have been holding some Coding Dojo sessions over the last couple of months in the ThoughtWorks Sydney office and I think they are really useful for helping to spread best practices.

For example, one of the key ideas of TDD is that we should take small steps, at all times making a change and then running the tests to make sure we didn’t break something. In a pair programming session it is quite easy to ignore this guideline and then suffer the consequences, but with 5 or 6 other people watching you make that mistake it is much less likely to happen!

I haven’t seen this approach used on a project yet, but Alan Dean has been posting on Twitter recently about using a Coding Dojo for a refactoring session on the code base he is currently working on.

This certainly seems like a more effective approach than talking about how the code base needs refactoring in a white boarding session without being able to show exactly what is meant.

And if you must whiteboard…

Although I think these other two approaches are more effective, the whiteboard is still an effective tool as long as we use it in an interactive way.

If it’s just one person drawing stuff out and others are not having any input then from my experience it’s not going to be an effective way to learn.

A far more useful approach is for the first person to start drawing out their ideas and the others can then add to this to check that their understanding is correct.

Although this is a useful exercise, it certainly makes sense to then go and try out those ideas in the code to ensure that you actually did understand what was being discussed.

Overall

I think the thing with all these approaches is that they are designed for small groups – with pair programming just two people for example!

I’m not sure how we could get the same effectiveness of learning with a bigger group – certainly the university style of lecturing is not the answer.

Whatever approach we take, keeping people involved and keeping it contextual is the best way to go.

Others in the blogosphere seem to be doing 2008 round ups around about now so I thought I’d jump in on the action.

Project Overview

• I worked on 5 projects this year writing code in C# 2.0/3.0, Java and Ruby.
• 2 of the projects were writing client side code, 2 web applications and 1 writing services.
• The domains I worked in were investment banking, insurance and an industrial automation system

What did I learn in 2008?

Probably the year in which I’ve learn the most so far and I’ve blogged a lot of it previously so these are just some of the main points that come to mind.

• I hadn’t worked on a legacy code base until this year but got the opportunity to work out how to put tests around code written in a non TDD way. I still have more to learn around this area and Michael Feathers ‘Working Effectively with Legacy Code‘ is probably the best place to learn it.
• I thought I had a reasonable grasp on coding in an Object Oriented way but I worked on a project in the second half of the year where I realised how much more could be done by sticking to the principles. We tried out object calisthenics in some coding dojos and I learnt a bit about the idea of managing the flow of an application through using lots of small fine grained objects rather than putting a lot of state into a smaller number of them.
• I’d heard of REST but hadn’t worked with this approach on any projects. I did on two projects this year and I think what it advocates ties in very nicely with my current preference for minimising state and keeping it simple.
• I worked on projects which all approach agile in a slightly different way. My favourite approach was on a project at the start of the year which was termed lightweight agile by one of my colleagues. Looking back on it now I suppose it was almost lean in a way – we had some process but not too much, information about stories was only shared just before it was needed and we spent really high percentage of the time coding. It just worked!
• I started writing this blog with some regularity and realised that putting your thoughts into words makes them much clearer in your own mind. I think sharing your learning is not only a good way of tracking what you have learnt but for providing a starting point for others trying to learn the same things so I intend to keep doing this.
• Twitter is a really good learning medium – I wrote previously of how I was using Twitter as a learning tool and since then it’s proved itself again with some interesting conversations about the Context/Spec framework Scott Bellware wrote and which Glenn Block is learning about, and some interesting ideas around Software Craftsmanship by Corey Haines and Cory Foy. I’ve not met any of these guys but Twitter has given me the opportunity to learn from them which I think is really great.

What do I want to learn in 2009?

There are bound to be areas of learning that come up which I hadn’t considered and I’ll gain knowledge in those areas, but these are some of the areas that I already know I need to improve in.

• Reading code bases – This is one thing I’ve ended up doing much more in 2008 than 2007, in particular reading the code of open source projects. Going to the source is one of the best way of learning different approaches to problem solving and I’m keen to learn techniques for doing this more effectively. I intend to blog my thoughts on different code bases as I did for Oxite as I find doing this allows me to gain more from the process.
• In my reading of open source code I’ve realised that code written for frameworks is much different than that written for applications. I’m keen to spend some time coding like this, just need to find an open source project that intrigues me enough now!
• Functional programming – I have played around briefly with Erlang and F# this year and in the latter part of the year I’ve had the opportunity to work with some of the functional features in C# but I haven’t practice for any length of time yet. I’m keen to see how doing so will influence the way that I write code in imperative languages. I imagine that if I work in the Java world at some stage in 2009 Clojure will be another language to look at.
• How to utilise coding dojos effectively – a more general area of learning than the others but I want to try and work out if/how we can make these sessions about deliberate practice to make them more effective for improving skills.
• How to apply lean on projects – I’ve been doing quite a bit of reading about the The Toyota Way and Lean lately and I’m keen to see how we can apply this principles on software projects. I think this will be in the form of applying agile principles more effectively but it will be interesting to find out.

One of the discussions we had at the Alt.NET conference back in September was around how important the environment that you work in is to your self improvement as a software developer and it came up again in a discussion with some colleagues.

I posted previously about my software development journey so far but to add to that one of the most important things for me about working at ThoughtWorks is the environment that it has provided me to improve myself as a software developer.

I am convinced that the environment you work in has a major influence on your ability to do this and therefore am not in complete agreement with some other posts I’ve read which suggest it’s more down to the individual and that some of these people don’t belong in the industry.

Why does the environment matter?

Individual motivation certainly plays a part in our development, but having the right environment as well creates opportunities to learn new concepts from colleagues that you might not have come across on your own.

When I talk about the ‘right environment’ I am referring to a workplace environment where you work with colleagues who are passionate about what they do and are have the ability and are willing to show others how to reach their level. This is something I am lucky enough to have working at ThoughtWorks.

Of course it is possible if you subscribe to the right RSS or Twitter feeds to teach yourself, but the value of having the opportunity to talk about them or try them out with colleagues cannot be underestimated.

I think one of the greatest benefits of these conversations is that they help guide you in the right direction or point out where you’re going wrong. It is still possible to make mistakes in a good learning environment but eventually someone is going to point it out to you and show you a better way to solve the problem.

This was certainly the case for me before I worked at ThoughtWorks whereby I spent a lot of time reading, what were in retrospect, the wrong types of books. I had a subscription to Books24x7 so I had access to the resources to learn but I channeled these in a less than optimal way.

I spent most of my time reading different C# books about essentially the same things without really knowing what the best way to improve myself as a developer was. I improved my knowledge of the APIs but my understanding of how to write maintainable software was no better than it was when I finished university.

Eventually some colleagues introduced me to the concept of writing code in layers to try and separate the various parts of the application I was working on. It improved my approach a bit but I still didn’t really know where to look to find out more information.

In my current environment if someone shows you an idea they will most likely point out some further reading areas for you to investigate and will be happy to answer any questions you have.

To give an example, Phil and I were recently talking about some functional programming concepts that are making their way into more object oriented languages. The examples he was showing me were written in Clojure, but as I am more familiar with these concepts in Ruby or C#, after our discussion he pointed me to a Bill Six article which describes all the functional collection patterns in Ruby.

I wouldn’t have come across that blog post without it being pointed out to me nor would I have become so interested about functional programming concepts in the first place without having had the opportunity to work with Alexandre Martins whose passion for learning about Erlang was what originally captured my interest.

These are just a couple of examples, there are many more.

What if you don’t have the environment?

Obviously there may be times when you don’t have the best environment to allow you to develop yourself.

The most direct way to solve this problem but perhaps also the most difficult is to change your environment so that you have better learning opportunities – there are certainly several people who have cited this as a major reason for them coming to work for ThoughtWorks.

The Obtiva Studio takes the idea of learning to an extreme with their Software Apprenticeship approach but even if you don’t have an optimal learning environment at work that doesn’t mean the learning cannot forge on!

Even if you don’t have the opportunity to work with the best in the industry they are still somewhat accessible through Twitter and most seem happy to answer questions and help people understand their ideas. Following the blogs of these guys and the blogs that they talk about is another way to keep in the loop.

Joining user groups such as Alt.NET is another way to interact with some of the people making things happen in the industry as of course is attending technical conferences where these people speak their words of wisdom.

Of course as Justin Etheredge points you still have to want to improve yourself otherwise it’s never going to work, but I still hold the belief that people generally try to do a good job and often the fact that they can’t do this is a lot to do with the environment that they’re in rather than genuinely not caring.