by Andy Hunt, March 15, 2023

The Journey

Why Training Doesn’t Help

The mind is not a vessel to be filled, but a fire to be kindled. —Mestrius Plutarchos (Plutarch), 45-125 A.D.

Software development happens in your head. Not in an IDE. Not in Large Language Model Chatbot. Your ability to learn may be your most important element of success. It’s what separates getting ahead from just getting by; from surviving to thriving.

Many HR departments still haven’t figured this out, but in reality, it’s less important to know Java, Ruby, Rust, or the iOS SDK. There’s always going to be a new technology or a new version of an existing technology to be learned. The technology itself isn’t as important; it’s the constant learning that counts.

We have a lot to learn, and we have to keep learning as we go. There’s just no way around that. And it’s up to us—each one of us, individually. Your company or your teammates or friends can’t learn for you. It’s up to you to plan and execute.

But the very word learning may have some unpleasant baggage, conjuring up images of youthful chalk dust torture, the mind-numbing tedium of corporate-mandated “copy machine training,” or similarly ersatz educational events. That’s not what it’s all about. We misunderstand the very meaning of the word “education”

Education comes from the Latin word educare, which literally means “led out,” in the sense of being drawn forth. We don’t generally think of education in that sense—of drawing forth something from the learner. Instead, we think that education is something that’s done to the learner—as something that’s poured in, not drawn out. This model is especially popular in corporate training, with a technique that’s known as sheep dip training. You line up unsuspecting employees, dunk them in an intensive, three-to-five-day event in an alien environment, devoid of any connection to their day-to-day world, and then proclaim them to be Java developers, .NET developers, or what have you. It wears off, of course, so next year you need to have a “refresher” course—another dip.

Companies love standardized “sheep dip” training. It’s easy to purchase, it’s easy to schedule, and everyone fits in a nice little box afterward: you now have a nine-piece box of Python developers. It’s just like fast-food chicken nuggets. There’s only one drawback. This naive approach doesn’t work.

Cognitive Load

Simply mastering a syllabus of knowledge doesn’t increase professional effectiveness. (Klemp, G. O. “Three Factors of Success”). That casts serious doubt on most, if not all, technology certification programs. The “body of knowledge” is demonstrably not the important part. The model you build in your mind, the questions you ask to build that model, and your experiences and practices built up along the way and that you use daily are far more relevant to your performance. They’re the things that develop competence and expertise. Mastery of the knowledge alone is necessary, but it isn’t sufficient. Here’s how that fits in.

In 1988, John Sweller formulated what he called Cognitive Load Theory (CLT). In this model, cognitive capacity is filled with some combination of the following types:

  1. Intrinsic cognition. This is your body of knowledge, the things you already know and can readily access.

  2. Extraneous cognition. These are the external elements you need to find, understand, or manage. This area is the home of accidental complexity: dealing with library version mismatches, obscure build pipeline error messages, OS upgrades that break a critical API, etc.

  3. Germane cognition. This type is where learning and problem solving happen. This is the good stuff—the kind of thinking and learning that separates us from dumb, rote machines and processes. This is also where short-term memories get transferred to long-term memory.

The Journey By Tom Geraghty used with permission1

Now here’s the problem: cognitive capacity has a finite limit in which all three types have to fit. If you’re struggling to recall something Intrinsic you thought you knew, that’s going to hog resources. If you’re swamped with Extraneous cognition, that’s going to take all the room that’s left. Now there’s no room left for Germane cognition at all.

In order to maximize space for Germane cognition, you need to do two things:

Keep your body of knowledge up to date and at your fingertips

If you find yourself having to look up something common over and over again, take a few extra minutes and memorize it this time (I still remember the command flags for cpio -itcduvmB and it’s been decades since I needed to know that).

Minimize Extraneous cognition needs

This one hits us hard. Modern software developers are practically being eaten alive by accidental complexity. From React to Kubernates to the npm and other package manager cesspools, it’s becoming harder and harder to concentrate on the essential complexity of our applications.

There’s a strong case to be made for a mostly boring technology stack. I don’t mean boring as in tedious, or insufficient for the project. But boring as in “unsurprising.” No gotchas. Things work as expected. We call it the “Principle of Least Surprise.” Some programming languages are better at this than others. C++ can be notably surprising and unintuitive. Ruby is notably unsurprising; you can guess how something might work and usually be correct.

Choose a tech stack that will minimize accidental complexity.

My Job Was Stolen by A.I.

When I was first interested in programming, I was dismayed to see an ad for a database tech that promised “to make programmers obsolete.” I was just getting started in the field and already they’ve got something to replace me? The ad touted a database that could be programmed in “plain and simple English.” The year was 1976, and let’s just say I’m still waiting.

Large Language Models such as ChatGPT are the latest round in the “hey we can replace programmers with tech” sweepstakes. I have no doubt that these massive article-sized auto completes will be useful and better integrated in the software development workflow. But replace developers? Not likely. Here’s why.

The University of British Columbia maintains an on-going “Catalog of Catastrophe.” These are large, public, often IT-based projects that have failed so spectacularly as to make the mainstream news. And it’s expensive; we’re talking anywhere from tens to hundreds of millions of dollars, up in smoke. Poof.

From these massive debacles, UBC have extracted the top ten root causes of failure (see http://calleam.com):

  1. The underestimation of complexity, cost and/or schedule
  2. Failure to establish appropriate control over requirements and/or scope
  3. Lack of communications
  4. Failure to engage stakeholders
  5. Failure to address culture change issues
  6. Lack of oversight / poor project management
  7. Poor quality workmanship
  8. Lack of risk management
  9. Failure to understand or address system performance requirements
  10. Poorly planned / managed transitions

Now have a good look at this list and ask yourself how ChatGPT can help address any of these issues. Any of them. One? Anything at all?

For that matter, now that we’re looking at the real root causes of epic fails, ask yourself how your software development process is addressing these issues. A lightweight project management framework such as Scrum might help with a couple of these issues, if used properly. But it offers nothing for all of these other deadly traps.

And in fact, no single software methodology does. These root causes aren’t necessarily anything you can train for. Instead, these are based around faults in our thinking and learning skills.

The ideas behind The GROWS Method® can help. Constant learning, constant critical thinking results in constant growth. You grow and refactor your software. You grow and refactor your wetware—the biological computer between your ears. We offer a workshop that helps you do exactly that..

We still have a lot to learn.

/\ndy

1See Cognitive Load and Psychological Safety to learn how cognitive load and psychology safety intertwine.

— Andy Hunt


Back to All Articles...

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.