Ten Principles of Adult Learning Applied to Software Development

Late last year, I started taking certification in teaching. How I embarked on that path, and why, is a story best left for another day.

As part of my research, I've been reading up on Garry Mitchell's Ten Principles of Adult Learning as outlined in the The Trainer's Handbook: The AMA Guide to Effective Training. And uncannily enough, these concepts seem way easier to understand when applied to software development. In fact, some of these principles mirror the observations I've made regarding software development over the course of my career.

1. People learn only what they are ready to learn.

This usually means that people tend to be more receptive if they perceive that what they are about to learn, is useful to them in some way. If it's important to know that stuff. Simply put, not many people learn something for the sake of learning something. It's a means to an end. They have to justify the time and effort invested in learning.

This happens a lot in software development. The domain being so wide and varied, there's always something to learn and many software developers are constantly adding to their arsenal of knowledge. Not just because they love it (though generally, they certainly do) but because in the software development industry, conventional wisdom states that they should.

Learning to configure a router.

Even then, software developers tend to choose topics they think are more pertinent. A console programmer would generally pick learning network security over web typography. A web developer would place more importance on improving his CSS than learning how to configure a router. I don't claim that this is the right approach - the fact that I'm undergoing a teaching course suggests I'm a fan of cross-disciplinary training - but that's how things are. People learn what they perceive to be of (preferably immediate) value to them.

2. People learn best what they actually perform.

Confucius had this to say regarding "performing".

"I hear and I forget. I see and I remember. I do and I understand."

Get your hands dirty, sunshine.

It's not a deliberate thing. Lessons are more readily absorbed with hands-on experience. And you will see this in spades, in programming. Reading code, knowing the right terms to use, understanding algorithms - that's all well and good. But actually diving in and getting your hands dirty, watching your code come to life as you type in those commands - that brings your absorption rate up to a whole new level.

Sure, a guy could learn the basics of Database Normalization, all the way to BCNF. But until he actually gets to work with a database schema and preferably build one up from scratch, all of it remains theoretical.

3. People learn from their mistakes.

The nice thing about getting things right, is that you learn one correct way to do it. The nice thing about getting things wrong is that you learn one incorrect way to do it. And if you make many mistakes, then you learn many ways not to do it. And if you learn fast enough from your mistakes, you never commit them again, ever.

Don't be afraid of screwing up. "Screwing up" is just another term for "experience".

Mistakes happen.
Learn from them.

In software development, the program rarely runs properly the first time. No, the more moving parts a piece of software has, the higher the chances of something going wrong. But solving bugs is one of the many ways a developer learns, and it's arguably one of the most vital skills in the industry. The more mistakes you make in the course of writing a program, the more experience you get. Subsequently, you either introduce less bugs into your code, or you learn to find them fast. Either way, it's growth. It's good.

4. People learn easiest what is familiar to them.

When something in front of you looks similar to something you've experienced before, that enables you to pick it up faster. After all, you already know part of it, right? Being able to relate a new piece of information to what is already known, helps people to absorb and retain that knowledge. If you've learned to ride a bicycle as a kid, learning how to ride a motorbike arguably requires you to mount a learning curve less steep.

Learning to ride.

Take these three code samples, for example.

PHP

echo "Hello World!";

Java

System.out.print "Hello World!";

Ruby

print "Hello World!"

What do they have in common? They all write a sentence Hello World! on screen. They may be in different programming languages, but boy, do they look similar. When a developer gains enough proficiency in one programming language, that enables him to pick up other languages faster. Because the languages do largely the same thing at basic levels of use, and if you've already mastered those basic levels, learning how to do them in a new programming language isn't much of an issue.

For a more meta example, look at what I'm doing with this listicle. I'm deepening my understanding of Gary Mitchell's Ten Principles of Adult Learning by applying them to a domain I'm more familiar with - software development!

5. People favor different senses for learning.

We've generally got five senses. Some have less. Some of us claim to have six! The point is, the eyes are not the only channel via which one absorbs information. People can do the same by listening to lectures, songs and readings. Chefs may learn the exact amount of salt to put in the soup, via smell and taste. You get the idea!

Learning in the kitchen.

Sensory input is converted into data, which is then processed by the brain and stored as information. Any sensory input, not just visual.

Ever watched a programmer use an IDE, and wonder how he manages to get all that weird code typed without even touching his mouse? Shortcut keys. The programmer gets attuned to where to place his hands on the keyboard and how far to stretch his fingers. Admittedly, I haven't gotten to that point yet. Perhaps one day...

6. People learn methodically and, in our culture, systematically.

People just don't absorb all that knowledge in one go. They learn it in small bites, incrementally. It's like eating a pizza. You don't stuff the whole goddamn thing in your mouth at one go, do you? For starters, your mouth just isn't large enough (though if it is, congratulations I guess). No, you eat the pizza slice by slice, bite by bite. You chew, swallow, reflect on the taste, then line up the slice in your hand for another bite.

Slice by slice, bite by bite.

And that's how it is with learning. You can't rush it. Stuff has to be learned in a logical sequence for it to stick.

In software development, we see this when fledgling programmers start writing code. They first learn primitive data types, and simple operations. Then they may learn conditionals and iterations before progressing on to hashes and arrays. But they certainly won't learn jackshit if you throw data structures, iterations and bitwise operations at them all in the space of fifteen minutes!

Also, in the domain of Human-Computer Interaction, we usually apply Miller's Law, also known as The Magical Number Seven, Plus or Minus Two, where the number of objects an average human can hold in working memory is about 7. This means that when designing a user interface, it's considered good form not to overload the user with too many buttons and icons at once.

7. People cannot learn what they cannot understand.

People can memorize stuff - it's just not a terribly effective way to retain knowledge. A better way to learn something is to understand it. And a better way to help people understand something is to keep things simple. Don't complicate stuff unnecessarily.

Er, what?

Martin Fowler is the creator of this classic software quote...

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

Here's some JavaScript code. It represents how I top up my Ez-link card over the course of 10 days. If the remaining balance is less than 5 SGD, I top it up by 20 SGD. If it's between 5 to 10 SGD, I top it up by 10 SGD. If it's more than 10 SGD, I leave it alone. Every day, I use 2.50 SGD from the card. I start out with a balance of 20 SGD in the card.

This code is readable to most experienced programmers. But probably not so much to the beginning programmer.

var bal = 20;

for (var i = 0; i <10; i++)
{
    bal -= 2.50;
    bal += (bal < 10 ? (bal < 5 ? 20 : 10) : 0);}

Now look at this JavaScript code. This is long and unwieldy, but it serves an important purpose: it details the sequence carefully. You don't have to be a genius to read this.

var bal = 20;

for (var i = 0; i <10; i++)
{
    bal -= 2.50;

    if (bal < 10)
    {
        var topup = 20;
        if (bal > 5) topup = 10;
        bal += topup;
    }
}

Which one's easier to understand? The second sample has more lines (and therefore more code), but each line only took up a fraction of your mental stack. In the first sample, the entire line was long, convoluted and definitely took you longer to read and understand.

8. People learn through practice.

Repetition, repetition... and more repetition. If you see and hear something enough times, with each repetition it gets absorbed into your subconscious. If you do something over and over, it develops muscle memory.

Have I mentioned repetition yet?

One kick... 10,000 times.

Consider this quote by Bruce Lee.

"I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."

If this line of badassery mouthed by the long-deceased badass himself doesn't convince you, nothing will.

The phrase "practice makes perfect" does not hold true in software development because in software development, perfect does not exist. If the tech world were to arrive at perfection, all progress would come to an abrupt halt. However, practice does make better. And the more times you write code, the easier it is to write it next time round. Write that code. Make variations on it. Write it till you could do it backwards and sideways in your goddamn sleep. (I was just being dramatic there. Please don't write any code in your sleep!)

The point, of course, is that programmers, like most other people, get better with practice.

But for a more meta example, consider this listicle. I'm repeating Gary Mitchell's Ten Principles of Adult Learning, on a blogpost, in my own words. This forces me to reexamine the words in his book, and in turn, this helps me retain that knowledge.

9. People learn better when they can see their own progress.

What this means is that it helps a lot if people know they are generally on the right track. A certain amount of self-doubt is healthy; it keeps you questioning. And when you're learning, you don't ever want to stop questioning. But there comes a point where doubt slows you down and hinders progress. Or worse - the learner experiences no doubt at all even though his direction is wrong, and goes off half-cocked at full speed in the opposite direction. I know one of the earlier principles mentioned is People learn from their mistakes, but that helps only when they're generally still on the right track.

Track your progress!

So when people get to review their own progress and ensure that they are learning exactly what they intend to be learning, it does not matter how fast or slow they learn - they are traveling in the right direction and they know they will eventually arrive at their destination. And when they can be certain that what they've learned so far is correct, this helps motivate them to commit the lesson to memory.

In software development, this usually manifests itself in the form of specification reviews. If you leave developers alone for too long, they may end up with a finished product that is far from what was originally specified. Therefore, weekly or even daily reviews are required to ensure that everyone in the team is on board and sticking to the program, to address deviations and take corrective courses of action. When developers are secure that they are traveling in the right direction, they'll be more motivated to put their backs into it, so to speak.

10. People respond best when what they are to learn is presented uniquely for them. Each of us is different.

Being unique individuals, people will respond differently according to method of information delivery. Public speakers may prefer to in turn listen to speeches, talks and lectures. A
chemist may respond better to information that is presented in a formula, such as empirical equations. Someone with an interest in food will naturally learn faster if the information is related to food in some way. Ever watched Kung Fu Panda? That's a perfect example.

Different people digest information
differently.

Likewise, people in the software development industry can be a diverse bunch. Data analysts may prefer their information presented in charts. A database engineer may find information easier to absorb if it comes in table form.

Personally, I like reading - books, blogs and articles. I like to observe how different people relate the same kind of information. Different authors writing on, say, web security, may present the same information in their own way, and digesting all the various works reinforces my own understanding of the material.

Whew, that's it!

That was a lot to think about. Suffice to say, it's been an interesting ride so far. For some reason, this shit is endlessly fascinating. It's been a while since I got this excited about learning something that wasn't tech-related.

Oh wait... I guess it is tech-related now. After all, I just related it, didn't I?

Keep calm and Garry on, dudes!
T___T