All these ideas, and a lot more, came out of a bit of lunchtime reading over the past few days. I’d say that every one of them is worth learning about, and many of them will make our program better. A few probably can’t coexist: we can’t use both Mediator and Adapter in the TextBox-TextModel interaction. We can’t both write our own XML tree and use the .NET XML support like XMLTextReader. To find out which of these ideas is best, we need to try them both. And, of course, we do want to learn as much as we can, as fast as we can.
On the other hand, we have this customer to keep happy. If we go into a cave to learn everything we might need to know about XML and patterns, the customer isn’t going to get any features. And then the customer isn’t going to be happy. And then the customer will cancel our project. So what’s the best way to handle learning? Well, I don’t know, but here are a few ways that learning can happen:
Having the customer schedule learning stories is the best possible situation, perhaps with the exception of writing a book that shows how ignorant you are and how you dig your way out of it. The customer allocates a certain amount of the team’s time to learning. Sometimes the customer might pick the things that you learn, based on what you tell them might be beneficial. The customer might be more interested in the .NET XML support, which relates to their problem, than they are in Mediator and Adapter. Or the customer might just allow you so much time per week to study and experiment with things that you feel you need to learn. This would be really good. Get paid to learn. It’s hard to get this situation, however, because the customer has other things on her mind, like getting her application done.
Another good deal for the learner is for the team’s manager to make a certain amount of time available for learning, holding it back from customer-driven programming time. Maybe the customer gets to schedule four days a week, or four and a half, and the other half day belongs to the team. This can be good for the team and for the manager, of course, because the team becomes more powerful. With a bit of judgment on what to learn, the things we learn this week can help us next week. This situation, too, can be hard to set up. Even the best manager can feel the pressure to make the programmers work more and more, “just this little while,” to respond to some urgent need or other.
This is, of course, a shortsighted view. Overworked programmers won’t learn, they’ll get tired, they’ll make mistakes, and quite often the project or the team will falter. But it happens every day. Extreme Programming allocates one of its dozen practices to this issue, with the practice “Sustainable Pace.” This practice dictates that the team will work at a pace that can be sustained indefinitely. Sure, you’ll sprint once in a while, but by and large, software development is an activity that takes place over months and years, and the team needs to work at a pace that keeps them strong and growing stronger, over the entire term.
Wise team managers provide space, time, and resources for programmers to learn. But often it doesn’t happen. What then?
Folks, this is our profession. We cannot afford not to learn, not to improve our skills. If time isn’t available on the job, we still need to do it. It’s hard, ain’t it hard, ain’t it hard (oh yes), to work on programming in our free time, after slaving over a hot terminal all day long, all week long. Yet we have to find a way to do it, or we’ll be left behind.
There are lots of important things in life: our families, our friends, our communities. We have to find room for all of them. Each of us has to find the balance that works for us for learning about our profession, in the context of our lives. I’ve made mistakes in both directions, but usually my mistake has been to focus too much on work and not enough on the things that were important to me, including learning and family and friends. I’ll try hard not to make that mistake again. You—well, you have to find your own balance.