Designing Learning

by Andy Hunt and Dave Thomas

---

In our last column on StickyMinds,, we boldly stated that the two most fundamental activities in developing software are communication and learning. In this week's column, we'll focus on learning. As software development professionals, we're always learning--not just new technology, but the problem domain, the quirks of the users/clients, even the characteristics of the evolving system itself. That's a lot of learning--from many sources. But for such an important aspect of our profession, we tend to ignore it completely. Even for the traditional things we need to learn, such as new technology, we tend to learn accidentally and at the last minute (sometimes even later). Exercise your brain; take learning into your own hands. Doing so will benefit your skills and your career.

In order to be successful, we need to improve and take a more active role in our own learning whether we are working as developers, testers, or managers.

As we mentioned in the last column, people at different skill levels have different needs when it comes to learning. Beginners need unambiguous, context-free rules, with no confusing reference to the larger picture. More advanced practitioners cannot work to rule, and must see the larger context and a holistic view.

In addition, people have different learning styles--some prefer to read, others to hear a lecture, others to just wade in and play (also known as "experiential learning"). Oh, and before we even start learning, there's the small matter of trying to determine what you need to learn in the first place.

Create a plan

In order to focus deliberately on your own learning, start with these three innocuous questions:

• What do you need to learn?
• How are you going to learn it?
• How will you know you're done?

Let's take a closer look at each of these.

What do you need to learn?

This is a much harder question than it first appears. If you are on a project moving to a new language or environment, then the answer might be pretty simple. But many times, what you really need to learn isn't so obvious.

What's broken? What's lame? What are you guessing at that you really ought to know? What's missing in your knowledge portfolio, either for your current project or for your career in general? Besides obvious things such as a technology or a technique, think about less obvious things like, "What are the characteristics of the system when placed under load?" Make a list. Go on, grab a piece of paper or a keyboard and make a list. We'll wait right here.

How are you going to learn it?

Okay, now you've got a list. For each topic that you've identified as relevant, you need to figure out how you're going to learn it. Unless you've picked all new topics and you're a complete beginner, you will have some experience with each one. Depending on how much experience you have in each topic, you'll have to approach each one differently.

One size does not fit all, even for you! For topics in which you are a novice, you need to find very basic, rule-based, "cookbook"-style instruction, possibly cutting across different technologies. For instance, Greg Wilson's new book Data Crunching gives a beginner's overview--and concrete recipes--using XML, SQL, plain text, and binary file handling.

If you have more experience, you need to find something with more of a big-picture overview. For instance, if you're fluent in several programming languages, a simple overview of a new language's syntax and key features is probably enough to get you going.

How do you learn best? If it's by reading, then go buy some books. If you need to hear it or attend a class, then start scouting the web for an appropriate conference, workshop, or other learning opportunity.

How will you know you're done?

Finally, how do you know when you're done? In all things pragmatic, we need feedback to know when we're done. In this case, just setting a goal of "learning xyz" isn't sufficient. For instance, instead of saying you want to learn Ruby, set a concrete goal like you want to "be able to write a web-based application that manages your to-do list in Ruby." Give yourself a timeline. For instance, write "hello world" on the first day, a small program with unit tests during the first week, and the big web-application at the end of the month.

After achieving this milestone, re-evaluate and reiterate what else you need to learn. Learning is an open-ended activity, of course, so you're never really "done." But if you can set some concrete, achievable milestones and meet them, you'll be in a good position to create the next set, and so on.

You'll be learning a lot--deliberately, not by accident--and your skills and your career will be in much better shape.

About the Authors

---

Andy Hunt and Dave Thomas are partners in The Pragmatic Programmers, LLC, specializing in helping people find better ways to develop software. They helped author the now-famous Agile Manifesto, and speak internationally on new ways of producing software. From their best-selling book, The Pragmatic Programmer, to the new titles from their Pragmatic Bookshelf publishing company, Dave and Andy are there to help programmers stay on top of their game. Contact them via www.pragmaticprogrammer.com.