Don’t you hate those times when you go to a talk or article that says “you should be doing this”, but then doesn’t explain how to do that?
I just wrote one. In “Coding. Standards.” I explained that what software engineers should do is to learn and analyse from all their experiences and interactions. But how do you do that? How does learning work?
The model of learning that I know best is the Kolb learning cycle, which I was taught when I was in management training. Yes – the reason I wear my hair this long is to stop it going pointy. David Kolb published this model in the 1980s, it’s been augmented and adapted since then but is still approximately as written. Having said that, some neuroscientists dispute the validity of this and other models of learning.
Kolb says that there are four distinct processes in learning:
- Concrete Experience: actually doing a thing.
- Reflective Observation: analysing how you (or someone else) did a thing.
- Abstract Conceptualisation: building a model of how things should be done.
- Active Experimentation: just playing with the plasticine and seeing what comes out.
Not everybody goes through all of the items in the cycle, but most people start out somewhere and progress through at least a couple of the points, probably in the order presented (acknowledging that as a cycle it should be, well, cyclic). The four examples he gave corresponded to four “corners” of the cycle:
- Diverging: concentrates on concrete experience and reflective observation. Tries something out, and decides how it could be adapted.
- Assimilating: focuses on observation and conceptualisation. Sees how different examples might fit a common pattern.
- Converging: conceptualisation and experimentation. Try to build a mental model from theory and then put it into practice.
- Accommodating: experimentation and experience. Hands-on trying things out and deciding which ones work.
This gives you a starting point for working out how you learn, and what materials best support your style: there are many blog posts and conference talks based on personal experience, which fit the “reflective observation” category. Technical books tend to be more abstract, and fit conceptual learning. Training courses often bridge conceptualisation and experimentation.
It also gives you a way to understand why some people don’t like your good-faith attempts to help them. “RTFM” works for those people who want to build a conceptual model, but not for everybody else. Similarly, those people saying “please give me the codes” may be people who learn by abstracting from examples. You can’t hate people just for learning in a different way.
