I carried that assumption for quite a while and only realised relatively recently how harmful it can be.

The most observable outcome I noticed is that I either didn’t give my opinion in group situations or just didn’t take part in them because I assumed that what I wanted to say would eventually be contributed by someone else anyway.

The danger of doing that is that sometimes people didn’t come up with a solution I’d seen work before and I’d be extremely frustrated because it seemed like the others were making what I considered bad decisions deliberately.

I think this belief evolved from the fact that for several years I was nearly always the least experienced person on the teams that I worked on and it was often true that my colleagues knew way more about almost everything than I did.

As time has gone on I’ve seen more situations and gained some ideas on approaches which work and I haven’t been the least experienced in the teams I’ve been working on so the belief doesn’t necessarily hold anymore.

I’m not sure if this is a common stage to go through on the software journey so it’d be interesting to hear about your experience.

I’m now moving more towards an approach where I give my opinions in situations where I have some knowledge while also accepting the fact that there will be other situations where others know much more than me.

In those situations I can legitimately keep quiet and learn from my colleagues experiences.

The Learning Models

The VAK learning style model describes a simple model covering the different learning styles that people have:

• Visual – seeing and reading.
  • Involves the use of seen or observed things, including pictures, diagrams, demonstrations.
• Auditory – listening and speaking.
  • Involves the transfer of information through listening: to the spoken word, of self or others.
• Kinesthetic – touching and doing.
  • Involves physical experience – touching, feeling, holding, doing, practical hands-on experiences.

My own learning style is predominantly visual so I tend to find that a well drawn diagram will help me understand something far more quickly than a colleague spending 10 minutes explaining something using only words.

If the latter happens then I either find myself totally zoning out or mentally trying to sketch out what the speaker is saying.

In a team environment this would translate into ensuring that we use the whiteboard when trying to explain problems.

Sometimes just going to the whiteboard isn’t enough and we need to cater to the kinesthetic learning model which in software development terms would involve walking through the code.

I’ve never been involved in a team session where we went through a part of the code base together but I’ve heard from colleagues that it can be very helpful in some situations.

I think it’s important that we know what our favoured learning style is so that we can guide any discussion in such a way that it plays to our strengths.

In terms of software development

Although people tend to have different learning models my general observation is that we can move through the models from auditory to visual and finally kinesthetic depending on the complexity of what’s being explained.

I think it also partly depends on the experience of team members. For example, I’m now able to understand many more discussions which are purely verbal where previously I’d have needed a diagram or someone to show me what they meant in the code.

I think it’s important to look at the implicit feedback we’re getting from colleagues when explaining something to see whether or not the model we’ve used has been effective.

If it hasn’t then at least we know we have some other approaches to try which might be more successful.

In a way he is right and I didn’t write anything at all about C# or Java when I was first learning how to write code in those languages because I didn’t have the confidence to write about something that I knew nothing about.

However, what I found when I was initially learning F# was that even writing about very basic things was quite useful to me and once I’d written about something my understanding of it tended to increase.

For example about a year and a half ago I wrote a post about some common things that I’d been getting confused with and I was quite surprised to notice that I never confused them again once I’d written that post.

I’m not sure of the science which explains why that happens but I’ve noticed a similar thing happening with Ruby.

I wrote about the advantages of learning through teaching last year which is along similar lines and I think the points I made there are applicable even if the subject matter would be trivial for others.

The other useful side effect which sometimes happens is that someone much better than me will point out a better way of doing something than what I described and I can then use their approach in code I write in the future.

In a somewhat related article titled ‘Blogging, empowerment, and the “adjacent possible”‘ Scott Rosenberg recently described in more depth how writing about things can actually change the way we think about them.

The cycles I described were as follows:

1. Don’t know what is good and what’s bad
2. Learn what’s good and what’s bad but don’t know how to fix something that’s bad
3. Learn how to make something that’s bad good

I think I’ve followed similar cycles with respect to how an overall project is run.

To start with I didn’t really know what it was that made a project run with an agile mindset different to anything I’d seen previously so I spent a lot of time observing the approaches my colleagues used, the processes they tried to drive and generally trying to understand what made a project tick.

Having worked on quite a few projects and seen similar underlying concepts working despite differing contexts I started to notice that the situations coming up were often the same or very similar to ones that I’d seen before.

At this stage I was more convinced that some of the approaches I’d already learnt could be useful but often deferred to more experienced colleagues or suggested improvements and relied on them to help drive them.

When I worked with Dermot he pointed out that the next step was to now be the one who can drive the changes that I want to see rather than relying on someone else to do it.

I’ve been trying to do that more recently and it’s not all that different to the way that I already try and influence the way that code is designed except it covers a wider spectrum of situations.

Books like ‘Fearless Change’ and ‘Agile Coaching‘ certainly have good tips for how to influence change but I find that more often than not I only really understand how to do something after I’ve made a complete mess of it the first time around.

I guess the downside of trying to influence situations more is that you put yourself in a position to be shot down so perseverance and knowing when to push and when to back off seem to be skills that will be particularly useful.

The author starts out by making some interesting observations about spacing out our learning:

An hour of study tonight, an hour on the weekend, another session a week from now: such so-called spacing improves later recall, without requiring students to put in more overall study effort or pay more attention, dozens of studies have found.

No one knows for sure why. It may be that the brain, when it revisits material at a later time, has to relearn some of what it has absorbed before adding new stuff — and that that process is itself self-reinforcing.

I’ve written previously about re-reading books and how we seem to notice different things when we process information the second time around.

I’ve also found that when I don’t understand something immediately that if I leave it for a while and come back to it later on it often makes more sense even though I haven’t deliberately tried to make sense of it.

For example I was playing with Clojure in November and December last year but then didn’t look at it again until quite recently.

Looking at it the second time the syntax and style of programming felt more natural to me which I think is because I’d played around with J a bit which is slightly similar.

This time I’m also using emacs and Swank instead of La Clojure and that combination of tools also feels more natural than it did when I tried last year. I don’t have any explanation for why that is!

I found the following section related to the type of material studied quite interesting:

Varying the type of material studied in a single sitting — alternating, for example, among vocabulary, reading and speaking in a new language — seems to leave a deeper impression on the brain than does concentrating on just one skill at a time.

I don’t do this intentionally but I find that my interest in something rarely lasts more than a couple of hours so I tend to switch between coding, blogging and reading when I’m doing anything software related in my own time.

The article also goes on to talk about the value of testing ourself on material, suggesting that the harder it is to remember something the harder it is to later forget.

The only correlation I can think of with respect to my own learning style is that I find it easier to remember information if I write about it or explain it to someone else.

It’s a very interesting article and well worth reading.

The questions being asked, discussions being had and situations that were coming up were pretty much the same as I’ve seen on any software project that I’ve worked on.

One particularly interesting thing which came up a few times was that there was a ‘them vs us’ feeling between the analysts and developers.

This is certainly an example of a situation which didn’t come up on the project when I participated in ThoughtWorks University 4 years ago where we only had a one week simulation.

It is however a situation that does come up and on the projects I’ve worked on it certainly can feel like you’re fighting the analysts. They’re trying to balance the wishes of the client as well as those of the developers and to developers it can often seem that the analyst is just being difficult for the sake of it.

The cool thing was that the grads then came up with different potential solutions to this problem and they were pretty much the same solutions that we’ve used on projects I’ve worked on.

While discussing a different topic with Dave Cameron he pointed me to the Wikipedia entry for ‘situated cognition‘ which “posits that knowing is inseparable from doing by arguing that all knowledge is situated in activity bound to social, cultural and physical contexts“.

The following quotes seem to explain why, in my experience at least, I learn way more effectively when working with colleagues on projects than I could ever do on an out of context training course:

Knowing emerges as individuals develop intentions through goal-directed activities within cultural contexts which may in turn have larger goals and claims of truth.

Knowing is expressed in the agent’s ability to act as an increasingly competent participant in a community of practice.

Learning must involve more than the transmission of knowledge but must instead encourage the expression of effectivities and the development of attention and intention that reflect real life learning processes

I think this new style TWU gives grads an even better start to their ThoughtWorks lives and I hope to take part as a trainer for one of the terms later in the year.

I’ve been working through the refactoring/code smells courses myself and while I’ve been finding it really useful, I think this was partly because I’ve been able to link the material to situations that I’ve seen in code bases that I’ve worked on over the past few years.

It would have been interesting to see if I’d have got as much value from going through the material 4 years ago before I started working at ThoughtWorks and didn’t have a range of code bases to relate the patterns to.

My thinking is that I would have found it more difficult to see the value of the material and that the approaches described would just have seemed ‘obvious’ despite the fact that I’ve made pretty much all of the mistakes that the training looks to address!

About a year ago I wrote a blog post where I described the value of re-reading books and one point which I’d forgotten is that even though it may be hard to relate to some ideas the first time you come across them it’s still valuable to read about them anyway.

It helps to prepare your mind for when you eventually come across some code where the idea can be applied and Krishnan pointed out that this was actually part of the feedback received from the current TWU participants.

I think this is probably a good example of a variation of confirmation bias at work in that since we’ve been prepared to see certain patterns/potential to use different refactorings in code when we do come across those situations in code we’re much more likely to see those situations.

Krishnan pointed out that it would still be very useful for the TWU trainers to refer back to the Industrial Logic material when we come across those patterns in the project simulation that we run as part of TWU.

I think this is the most important part of the process as it will help to reinforce the learning.

I’m still curious whether there ever is a time when it makes sense to delay learning about something until we have more context.

I find that when I’m learning about something which goes way over my head I’ll often stop doing that and pick something else to look at which I can relate to a bit better.

I try to go back to the original material again later on but what I find often happens is that I’ll come across it in the future more by coincidence than design and this time it will make more sense.

Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow.

Be the Worst was the seminal pattern of this pattern language. It was lifted from some advice that Pat Metheny offered to young musicians: “Be the worst guy in every band you’re in.” Pat’s advice struck a chord with Dave, and was one of the reasons he started writing this book.

Since I started working at ThoughtWorks it hasn’t been that difficult to follow this pattern and I’ve been the least experienced developer on the majority of teams that I’ve worked on.

I always thought this was a pretty good thing as since I’m always surrounded by people who know much more than I do about various aspects of software development the opportunity to learn is very high.

Recently conversations with several different colleagues leave me questioning whether at some stage we need to move away from this pattern, perhaps temporarily to improve skills in other areas.

The authors do cover this a bit in the book:

Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think. It’s only when you work on your own that you will see how much your team increases your productivity and realize how much you have learned.

Making technical decisions

One area in which I’ve noticed that this is true is when it comes to making technical decisions on a project. Quite often I find that even though I have an idea of what the solution to a problem should be I end up deferring the decision to someone more senior in the team.

I don’t think there’s a problem with discussing solutions with others in the team but it certainly seems that it would be a better learning experience to be in a situation where I was forced to make the call and then see how things went as a result of that decision.

It’s certainly possible to engineer a situation where you have to make that type of decision by working on open source projects but it’s still useful to get experience on real projects as well.

I guess the easiest way is to be on a team where you aren’t the worst so that by default you’ll end up in a position where you have to make those calls.

An alternative is for more senior people to encourage others to make decisions with the knowledge that at least they will be there to help recover the situation if it goes wrong. I’ve seen some of my colleagues use this approach and it seems to work reasonably well.

It’s still not a perfect approach though because often someone more experienced may know intuitively that an approach isn’t going to work but will struggle to explain why they know that.

Solving problems

The other situation where ‘be the worst’ is perhaps limiting is when it comes to solving problems on a team.

At the first sign of being ‘stuck’ there is a real temptation to ask someone for help even though you might be able to solve the problem alone given enough time.

A colleague in my first job suggested that whenever I got stuck it was worth struggling with it for an hour before asking for help. I don’t know if that’s too prescriptive but there certainly seems to be some merit in the idea.

I’d be interested in hearing others’ thoughts on this and whether there is in fact a point at which you can grow more by focusing less on learning all the time from others and more on stretching yourself to find situations in which to take the responsibility for making decisions based on that knowledge.

I think one thing that’s really important is not to be afraid of your ignorance. If you don’t understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn’t help anybody. Not knowing something doesn’t mean you’re dumb – it just means you don’t know it yet.

A variation of this which I’ve noticed myself doing is internally telling myself that I ‘should’ know how to do certain things much better than I can.

This is most typically the case when I’m struggling with something on a new project that I’m working on and while it is indirectly useful for helping to identify areas that we can work I think the voice in itself is not that helpful to our learning.

When this happens I’ve started writing down whatever it is that I think I should know better and then taking some time to read more in that area.

Wherever possible I also try to speak to people who already have that skill and find out how they went about learning it.

For example, as I mentioned in my post about reading the Unity source code, reading code is something I want to get better at and when I’ve worked with Dave Cameron he’s able to understand how things fit together much more quickly than I am.

When we discussed this he pointed out that he’d spent a lot of time debugging through a lot of different code bases just for fun and working out how they fitted together by following the control flow.

It’s pretty much always the case that others have spent quite a bit of time working on these skills so it’s certainly something to keep in mind next time I come across something I ‘should’ know!

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 fire hose learning stage.

Continuously question what you’re doing

This is 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 learning a new language, taking part in coding dojos or participating in a 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.