Does everything have to be easy? What about hard things?

Today, I overheard someone in our business asking another such person “Does everything have to be easy?” because they thought that sometimes learners should be thrown in over their heads. And sure as heck, I’ve been in over my head, and you have been in over your head, and those two individuals, I’m sure they’ve been in over their heads as well.

When we’re in over our heads, we professionals generally know what to do. We have a huge array of tricks we have come to rely on: we carve off a piece we can resolve, leaving the rest a bit less difficult; we identify the crux of the issue and solve it separately; we know how to search the Web and how to tell a good answer from a weak one. And if we’re lucky, we even have friends who can help us, and we have the courage to admit that we need the help.

But all those secondary skills come down to tricks to make the difficult less difficult. Heck, a Fourier Transform, which I can tell you I never got good at, has its sole purpose making a hard problem easier by switching the way you look at it.

I have gotten as far as I have by learning many different ways to make things easy, and learning those ways wasn’t easy, because I had to discover a lot of them after a long period of hard work and trouble. Sometimes I gave up: there are things I didn’t learn until much later than I might have. For some things, I still have no particular skill.

I still recall my comprehensive examination in front of the committee at the university. It was Anatol Rapoport who asked me a question that I just couldn’t answer. I struggled, fumbled, mumbled, got nowhere. So Anatol asked me an easier question. But I was rattled, so I struggled and mumbled, and again, nothing. So he asked me a still easier question. But I was quite rattled and again, failed. I don’t remember whether he stopped before asking me my name, but I know his questions got pretty simple, but I was getting more stupid faster than he could think of easier questions.

I had “learned” a horrible thing: “Anatol Rapoport asks impossible questions”. I was doomed.

It was not a good time. Fortunately, I have had many good times as well.

My first mentor in computer programming had one great skill: he could suggest a program for me to write, or a procedure to learn, that was just right in size. Difficult enough for me to learn, and easy enough for me to solve, and to learn more than just the solution: how to work out the solution, or find the solution in available reading.

I went for many years after that with no real mentor other than innumerable books, which I was fortunate enough to be able to find, acquire, and read. And fortunate enough to be able to learn things from them, which is not always easy to do.

Then we got our own individual little computers, and magazines about how to make them do things, and those problems and solutions were pitched at various levels, so you could always find something hard enough to be interesting and easy enough to be possible.

Finally, I fell into a community of individuals, some of whom were massively better than I was, and who were kind and generous and gentle in helping me learn, not talking down to me, but lifting me up when I needed it. And most of the others in the community, more or less at my level, all enjoyed sharing what they were doing, and talking about what they were learning, debating and tugging and pulling and pushing at the ideas, teasing out what the elements of programming success really were.

We were learning to make it easy. To do that, we had to be, not in water over our head, but water that was deep enough for us to swim and to learn, but never deep enough to get us coughing and choking and being afraid.

The trick with programming is making most of it easy. The trick to making things easy is that we have to learn easy ways, and matching problems to those easy ways, before we learn the harder stuff. Then, there almost never is any hard stuff. We learn faster and without the pain.

You and I have probably felt pain and fear in our programming lives, and it’s tempting to think it’s necessary. On the contrary: I learned fastest and best in right-size steps, never too big to get me in much trouble, always within my reach.

You and I have probably had some big failures in our programming lives. And we got up and tried again, often at a new company. Are big failures necessary? Do we need to get used to failure, so that we won’t give up? I don’t know that. I am sure that we’ll encounter losses, so perhaps we need experience losing. But if it were up to me, I’d want to teach people a lot of ways of winning, and put them in very few situations where I knew they would lose. Probably zero. Because I will sometimes get it wrong and face them with a problem where they’ll lose even when I didn’t expect it. And sometimes they’ll be confused and lose all on their own.

Losses will arise and I’ll be there to help them recover. Mostly, as managers, we’ll be successful by facing our people with problems that they can solve and solve well, not by throwing them massive problems where they are prone to failure.

Making the hard things easy is the mark of a great programmer and a great programmer has had a lot of experience with successfully making hard things easy. My job when helping someone learn is to find problems that are just hard enough that the learner’s prior experience, applied carefully, will enable them to make the problem easy, and then solve it, learning yet another new way to make things easy.

We need our students to trust us, so that they can hear us. Let’s shape problems that are just the right size to include a juicy bit of learning, and never so big that they panic and fail to learn. There will be time for panic later, and they’ll be better prepared to recover when it happens.

Our job is to show folks how we make things easy, and how we do so with high spirits, confidence, and joy.

Or so it seems to me.