This is the first post in the teaching and learning series. The teaching and learning series includes the following posts:

1. All Developers Should Know How They Learn Best (this post)

2. The Secret Of Being A Great Mentor

3. The Secret Of Being A Great Apprentice

4. Become A Better Developer By Indexing Your Brain

5. Learn More – Faster By Using The World-Wide Community

6. What Playing Cards Can Teach Us About Ramping-Up And Transferring Knowledge

Software development is one of those industries where you can’t really help it but be constantly learning. No matter how knowledgeable you are with the technologies you currently work with you still daily discover new, better, more efficient ways of doing what you do. It is even more hectic when you move to a new environment or end up on a new project where the technologies may not be as familiar, (or you could be a downright newbie) the domain is completely different and you have to work extra hard to get across everything in order to become effective as fast as possible.

But how do you make sure that you’re getting across all this new stuff as quickly as you can be? You probably have some personal strategies that you have developed over time that work well for you. Maybe you start doing a lot of relevant reading or maybe you browse the source code/unit tests in your free time or maybe you just ask a bunch of questions over beers after work (and some just simply wait and wait until they begin to grok what’s going on). We normally don’t know why a particular strategy works for us, we just know that we learn faster and better when we employ it. But it is actually not that hard to figure out why certain things work for you and why others don’t and if we knew this we could probably streamline our learning even more (and not just the on-the-job learning that we do, but out personal learning endeavors as well).

There are a number of theories about what makes people learn best and what personality traits effect learning. Some are better, some are worse, some have been criticized while others have been praised. I am a believer in balance in all things, so rather than subscribing to one particular learning theory, I prefer to examine myself with regard to several which in the end, gives me a broader understanding of what it is about me that effects how I learn and what strategies I would need to employ to make sure I am getting the most bang for my buck (so to speak). I would recommend all developers go through a similar exercise if only to be more aware of what makes you tick and why your favorite strategies are infact best. To that end, here is an outline of some of my favorite learning theories.

Your Personality

Personality can have a major affect on how a person learns, this just makes sense and so some of the earliest and most well known theories are centered around this. Some of the oldies (but still goodies) that most people have probably heard of are Myers-Briggs Type Indicator and the Keirsey Temperament Sorter. Both of these are based around 4 personality dimensions each of which can have one of two values:

1. Energizing – how a person is energized or motivated
   • Extroverted – draw energy from people and like to discuss their thoughts and ideas with others when learning
   • Introverted – expend energy while with people, like to think through new ideas by themselves
2. Attending – what makes a person pay attention
   • Sensing – focus on what their senses tell them, notice the details
   • Intuiting – focus on the possibilities and the ‘big picture’
3. Deciding – how someone makes decisions
   • Thinking – use logic and structure to make decisions
   • Feeling – tend to use value-judgments to make decisions, i.e. ethical or moral concerns
4. Living – a person’s lifestyle
   • Judging – have a structured and organized approach to living and decision making
   • Perceiving – are a lot more flexible, tend to explore possibilities before committing to a course of action

You pick your leanings in each of the four categories which gives you your personality classification (e.g. if you’re extroverted, sensing, feeling, judging you would be a ESFJ). Based on the descriptions of the various traits you can combine them to figure out what kind of approach to learning can work for you. For example, you may need to walk through the big picture in a logical and structured fashion, all the while discussing your thoughts with others. Or you may need to sit down by yourself and explore the various possibilities and the details of what effect they would have. There is no right or wrong way, but knowing what kind of personality profile you have can help you focus on the most effective way for you to absorb and retain new information.

Are You A Left-Brainer Or A Right-Brainer?

These days everyone is aware that our brain has two hemispheres. This was originally proposed by Dr. Roger Sperry who in 1981 won the Nobel Prize in Medicine for his work. For most people one side of the brain tends to dominate even though everyone uses both in their day to day life. Despite what some would have you believe you don’t need to be either a left-brainer or right-brainer to be a good developer. You’ve probably met developers in your work who like to dive into code and explore and who tend to almost intuitively find solutions to problems (these were probably right-brain dominant). You’ve also probably met developers who like to work through the details and approach their problem solving in a logical and systematic fashion (these were the left-brain dominant).

Left-Brain Dominant

If you’re left brain dominant you probably like to walk through your learning step by step. You like resources that break down the information into a series of tasks and guide you through those tasks in a sensible fashion. You will also tend to work and learn well with other people who think the same way as you (other left brainers).

Right-Brain Dominant

If you’re right brain dominant you will prefer to know the big picture as well as see examples and case studies of best practice. You learn well from observing and discussing and are happy to start work when only a broad goal or outline exists, filling in the details as you go.

Neither of these is inherently better but it does pay to know what works best for you. On any team you work either one or the other style will tend to dominate, if it is not your style it is up to you to make sure that your style is also represented in some fashion. Maybe you may need to fill in a little more detail and come up with a little more structure to help the left-brainers on the team when you have a goal you need to achieve. Or maybe you need to zoom everyone out a little to make sure the right brainers are represented when everyone seems to be too focused on the detail.

Who The VARK Are You?

VARK is one of the most common categorizations of learning styles. VARK was created by Neil Fleming and is based on the Neuro-linguistic programming (VAK) learning model. VARK is an acronym where each letter stand for a particular type of learning style.

• Visual Learners – prefer visual representation of information and tend to remember things better if they are organized visually (i.e. charts)
• Auditory Learners – learn better when they hear information (i.e. learn well through talking and discussion)
• Reading/Writing-preference Learners – this one is pretty self-explanatory, these types of people need to read and/or write to learn and remember something
• Kinesthetic Learners – require action and movement to learn things, they need to try things out to learn and remember them

You’re probably noticing by now that there is some cross-over with the previous models that we discussed. For example auditory learners may tend to be more extroverted while reading/writing preference learners will tend to be more left-brain and thinking (as opposed to right-brain and feeling). The categories with this one are very broad and you may once again not fall neatly into just one, but as always it is best to be aware which style works for you and make sure that you give yourself the best opportunities to learn and retain new information. So, if your current environment does not provide the kind of information that works best for you (i.e. there is not enough charts or not enough discussion is going on), it is up to you to remedy that.

You’re Suffering From Multiple Intelligences

The theory of multiple intelligences was proposed by Howard Gardner. Basically the theory states that there are 7 different aspects to our intelligence that can be measured separately. We use all these intelligences in our day-to-day life but we have an affinity for one or several and therefore find them easier to use. This means that particular learning styles will work better for us. The 7 intelligences are:

1. Logical/Mathematical – like information to be presented logically and systematically, they like to problem solve and make connections between concepts
2. Verbal/Linguistic – learn best through reading, writing and discussion. This intelligence incorporates abstract thought and reasoning
3. Musical – for this intelligence learning is enhanced when new material is associated with sound and music (this should certainly be familiar to many people who like to study with music)
4. Visual/Spatial – here learning involves creating visual representations of content, such as graphs and charts as well as mind-mapping and content-mapping techniques
5. Interpersonal – people who are dominant in this intelligence like to learn in groups, talking and interacting with others
6. Intrapersonal – people who dominate with this one like to learn by themselves, they concentrate and process information better when they are alone
7. Bodily/Kinesthetic – here people like to learn by doing, movement and action, they need to try things to retain and absorb information

Once again there is a significant amount of cross-over with the other theories but hopefully having several presented at once helps to clarify in your own mind what kind of person you are. What it also teaches us is the fact that there is no one best way to work in a team (whether it’s a software team or any other). Some people learn better in groups while others learn best by themselves, so you need to provide time for group work as well as personal work. So for example, if you always work by yourself (in your workplace) and group time is not provided (and you’re and Interpersonal learner) you need to make the group time yourself. The same could be said about all the other intelligences. If music works best for you then make sure you bring your iPod with you. If you’re visual then push for creating more charts and doing more mind-mapping exercises. If you’re kinesthetic, then maybe you need to introduce role playing exercises to the team etc.

There are many other intelligence and learning theories out there (such as the 4-MAT system, Experiential Learning etc.), some are a lot more complex than the four above. The reason the above 4 are good, aside from the fact that they are the most well known ones, is the fact that we can easily classify ourselves according to all 4 which can give us a reasonable understanding of the kind of personality we have and therefore what kind of activities can help us learn better. We can possibly do more with the more complex systems, but in my opinion the law of diminishing returns kicks in, we expend a little effort to know enough rather than expending a whole lot to learn just a little more.

Of course just like with everything we will never be able to neatly pigeonhole ourselves, we are often both thinking and feeling, or visual and auditory in equal measure. But knowing this also tells you much, such as the fact that both a visual and an auditory learning style can work for you (i.e. explanation and diagrams) so maybe next time in addition to drawing a diagram you can look really weird and talk yourself through it while doing it, you’d be surprised at the difference it can make.

I hope this has helped you become more aware of how you learn and retain information and why certain strategies work best for you. If you’d like to share your experiences with learning or if you know of other theories that are easy and work really well (perhaps you have one of your own) feel free to share them in the comments. Otherwise, stay tuned for the next post in the teaching and learning series title – The Secret Of Being A Great Mentor.

Images by country_boy_shane, Arenamontanus and George

I just can’t resist making up words when there is even a remote chance of rhyming potential :). Anyways, I’ve been on one of my periodic binge-learning sprees lately and since I’ve been trying to be more aware of how, when and why I do things, it got me thinking about how people learn (especially developers), mentoring, apprenticeships, knowledge transfer on software projects and a few other things. I’ve touched on some of this stuff briefly in several of my recent posts such as:

• Building Software Development Expertise – Using The Dreyfus Model
• Are You The Best Developer In The World?
• Do You Morph Into A Different Programmer?

But I haven’t yet specifically covered learning and how to do it more effectively especially when it comes to software development. So, rather than just writing a bunch of posts in an ad-hoc fashion (whenever the fancy strikes me) I’ve decided to plan and write a series of posts on the topics of learning, teaching and knowledge transfer (as it relates to development and developers of course). Hopefully by having an overarching theme (a story arc or an epic if you like) the posts will be more interesting and it will hopefully force me to finish all of them within a reasonable stretch of time (rather then jumping to the next fascinating idea that I’ve been mulling over). As it stands I am planning to write six posts:

1. All Developers Should Know How They Learn Best
2. The Secret Of Being A Great Mentor
3. The Secret Of Being A Great Apprentice
4. Become A Better Developer By Indexing Your Brain
5. Why Aren’t You Awesome Yet? (Learning Via The World-Wide Community)
6. What Playing Cards Can Teach Us About How We Learn – And How Fast We Do It

Hopefully I can finish them within the next 2-3 weeks, but we’ll see how we go considering I haven’t tried writing a series of posts before. These aren’t set in stone, so if anyone has any other ideas about what I should cover, feel free to leave a comment and let me know, otherwise I hope you enjoy reading the posts.

I believe respect is one of the corner stones of agile teams. In my mind agile software development was always first and foremost about people – the practices and processes we use now are secondary and less important. It is all about how you deal with people, how you treat them, how well you are able to collaborate etc. Even technology must take a back seat considering that any non-trivial piece of software these days will be built by a team of people (rather than just one individual) and even the coolest technology in the world will not be able to make up the deficit when the people in the team are unable to work together. It therefore should come as no surprise that 2 out of the 4 points in the Agile Manifesto are centered around people:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation

There has been a tremendous amount of literature written about how to get people to work well in teams. When a company/projects can get it right – astonishing results have been achieved, but despite all the studies and guidelines on the subject, to this day the elusive factor that makes a team click is more often than not pure chance (with elements of premeditation, but chance nevertheless). Which leads me back to where I started – respect.

I am not saying that respect is the single factor that will make people succeed when they work together, but it is certainly a major component.

Respecting Those You Work With

Can you respect absolutely everyone you work with? It is a tough question and if we’re honest with ourselves, the answer will have to be no. We respect certain qualities and attributes, these are the qualities that are important to us. When others exhibit those qualities, we are likely to esteem them more highly than the people who lack the attributes that we admire. But, just because a person may not be someone we can innately respect, that does not mean that they should be treated disrespectfully or dismissively or that their opinions are less valid. You potentially interact with all sorts of people on a day to day basis:

• team mates
• members of other teams you deal with
• business people (customers, stakeholders)
• marketing
• users
• etc.

Not all of these will have the same background or level of knowledge/skill – infact they may be completely unlike you in every way. But aside from the fact that they may be highly respected in their field of expertise, your interaction with them forms part of the dynamic of your whole workplace which contributes to the energy it will exude.

Have you ever walked into an office and just felt really good about the place? Everyone seems to be really happy and the whole area just feels a little brighter than it should. Well, more likely than not, people treat each other with respect and courtesy there. On the other hand, I am sure you’ve at least visited an environment where as soon as you walked in you thought to yourself, “I’d rather shoot myself than work here and if I did work here I probably would“. Guess how people treat each other there.

Of course all of this seems really fluffy and touchy-feely (flowers and peace man – groovy :)) and I am well aware of that. If you’re a hardcore analytical developer who only respects cold logic and wicked Unix skillz think of it this way, there is always a developer out there who is much more hardcore and analytical than you and whose Unix skillz are way more wicked. If you ever met that person would you like to be dismissed and marginalized by them or do you want to be treated with courtesy and respect? And now tell me, does that ‘clueless customer’ or ‘stupid marketing guy’ really deserve your disdain? You can make all the jokes you want at this point, but just remember one thing. Do you know who else works in that crappy workplace where everyone is an arrogant bastard and people treat each other with contempt and scorn – you do! Joke about that.

Respect In Teaching And Learning

Enough of the fluffy stuff here is something concrete. Most developers would agree that one of the things you want to get from your job is to be able to learn from the people you work with. Of course, in order for someone to learn, someone else will have to teach – that’s just common sense. But, nobody really has a duty teach anyone anything. They will either do it because they are extremely altruistic and enjoy teaching others or something will prompt them to share their skills and knowledge. Do you know what that something is? You guessed it – respect.

Let me share with you a little piece of wisdom that my dad shared with me a little while ago. My dad has been a tradesman ever since he got out of the army – around 30 years or so. He is very good at what he does. The way knowledge is passed on in the trades is through apprenticeships. The relationship between master and apprentice is interesting, the master can either tell the apprentice what to do or he can also explain why certain things are necessary. In the first case the apprentice learns the moves and may become a decent worker, in the second case the apprentice can set himself firmly on the road to becoming a master himself. But, the thing is, it is much easier for the master just to give directions, it takes extra effort to sit down and explain (and sometimes show) why things are necessary. So what would make the master want to take the time to order their own thoughts and to actually sit down and teach rather than just supervising? It is several things:

• when the master can see that he has the apprentice’s undivided attention – the apprentice is not distracted by other concerns when the master is sharing knowledge
• when the master can see that the apprentice is willing to follow direction – the apprentice doesn’t argue unnecessarily
• when the apprentice is willing to do something extra without being told – for example, the apprentice takes the initiative to clean up after a job is finished without being told

It has taken the master many years and/or decades of effort to gain the knowledge that they have, all they want to see is that the apprentice appreciates being taught what the master knows. The thing that the three points above have in common is that they are all signs of respect:

• showing appreciation for being taught by giving your full attention
• not being too argumentative (although asking questions and arguing to some extent can be ok)
• saving the master from doing something routine/boring

Just three little signs of respect, but they make all the difference between a person who is happy to teach you something and take the time to explain and someone who won’t really bother and just do it themselves (probably better and faster to boot).

I’ll be the first to admit that the dynamic in software is completely different than it is in the trades. There is no formal apprenticeship relationships and the line between master and apprentice can be extremely blurry, it is more often several people sharing knowledge with each other rather than one person teaching. But the basic principle of respecting the person who is willing to share the knowledge translates very well. If you don’t give your attention, if you don’t show some appreciation if you’re not willing to follow the directions at least for a little while, next time the person may not even bother sharing what they know and everyone is worse-of if that happens.

Fostering An Atmosphere Of Respect

If you were asked to give up any agile practice or ideal which one would you choose? It is tough to answer that one, but I do know one thing, I would give up all of them before I would give up the idea of respect within the team and in the workplace, because without respect all the other practices aren’t worth a whole lot.

One of the best things you can do for any software team is to foster an atmosphere of respect, not just towards other team members but towards anyone who has to deal with the team. Not only will this create an atmosphere where people will be happier, but it will also foster an environment where everyone is willing to share what they know, people are happy to collaborate, noone is afraid to bring up issues if they notice them. Everybody knows that no matter what, they will be treated with respect and courtesy. How to foster such an atmosphere is a whole other matter and I would like to come back and look at it at some point. In the meantime, I would love to hear what you think. Do you believe respect is as important for truly agile teams as I think it is, or do you think something else is more so?

Image by kkimpel