Learning for the Whole Audience
What do you hear with the terms “scaling learning?”
The most common reaction focuses on the logistics. This results in many less-than-adequate web-based training programs.
The idea of scaling learning also suggests that a LOT OF PEOPLE need to consume the learning. Developers may not like legacy code, much like instructional designers do not like wide audience delivery. Put together a nice little niche piece of learning? Fun! Make learning work for 100% consumption over a large audience? Hiding.
Because you have to address a wide variety of competencies. You can’t bore the audience that is already highly proficient and you can’t lose the audience that is becoming proficient.
And this is partially why so many organizations provide piecemeal training programs for their developers. It is also why companies hire coaching and mentors, to identify and address the gaps … one team at a time.
But what if you want your entire organization to get on the same page with a skill set? Go ahead and envision all the instructional designers sneaking out of the room right now…
However, Deep Roots’ training has made scaling not only possible, but very realistic and cheap.
Yes, we do the basic learning design of chunking topics out and breaking those down even further with tiny habit shifts at a time. We perform the common sense coaching points. We verify our work through measurable results. But how do you take something as insane as “fixing God classes” and make the content consumable for all levels?
We use the proficiency taxonomy to guide our content.
Let’s look at the “start to fix God classes” example.
Imagine two incredible experts having a conversation on how to fix a God class. Me, as the learning designer, asked Arlo, the technical brain of this company, to write what he would tell Llewellyn Falco or Jay Bazuzi, other exhaustingly brilliant technical brains. This is what I got.
God classes are easy to kill - except that they protect themselves with procedural code. So just create Whole Values and wait.
I blinked at him. So he kindly expounded that there were two implied concepts that he wouldn’t have to bother saying. The first implication was that when he said “they protect themselves with procedural code,” there was the implied concept of “Because time + Data Gravity = Primitive Obsession, in the obvious manner.” The second implication is “Whole Values naturally become concepts and accrete behaviors and responsibilities. Once you have some next to a God Class, normal feature development will tend to move responsibilities off the God Class, causing it to shrink. Problem solves itself over the next year.”
I may have responded with a sarcastic “well, duh”. The point being, Arlo’s two-sentence answer will not scale.
Now let’s imagine Arlo speaking at a conference, with a talk focused on proficient developers who have been practicing in the field for … a long time.
Although every God Class creates an obvious coupling problem, it creates an even larger and less obvious problem: it protects itself with pawns. Code that touches the god class has to read or write data on the God Class. Thus each concept ends up half in the God class. The remaining halves are not worth making explicit, so they end up as a set of unrelated procedures filled with Primitive Obsession: pawns. These pawns then protect the God Class from any attempt to kill it.
Yeah, I think I’ll take a miss on that talk. I’m sure it’s valuable, for perhaps the 20% of the overall development audience with some legacy code experience. This was after he did a lot of hand waving about visuals and I suggested a metaphor to help.
Now keep in mind, this may be perfect for his niche audience. But we have to break this down for all developers. After all, over 50% of have been in the field for less than 5 years and many more have only worked on new products.
Now, here is where over 50% of our developers currently sit. Rapid industry growth more than doubles the number of employed developers every 5 years. Thus, we are guaranteed that over 50% of all employed developers have less than 5 years of experience.
So, how do we fix god classes for 100% of the developer audience versus 20% or .00001%? We start out by introducing a metaphor.
Although every God Class creates an obvious coupling problem, it creates an even larger and less obvious problem: it protects itself with pawns. So how we are accidentally building these pawns?
Arlo Belshee & Marian Willeke
Now we break down the logic.
- We had a new feature to write that was related to the God Class.
- Because it was related, the code reads and modifies data that is already on the God Class.
- This forces us to add or edit methods on the God Class related to the new feature. However, this gives the new concept to the God Class as well.
- The remaining half of the concept is written outside the God Class, but is just not worth making explicit. So it ends up becoming a procedure with lots of Primitive Obsession.
- You have created a new pawn.
- Since the new procedure has no clear concept, it gets tossed in with all the other unrelated procedures and into some class whose name ends with -Manager or -Utils.
- Your pawn now defends the God Class.
- Any attempt to eliminate the God Class first requires fighting through an army of procedures. It never seems to get anywhere.
Arlo Belshee & Marian Willeke
We then close with the opportunity to start fixing god classes with a summary and resources.
Check out our developing Legacy Cookbook to access the recipe that shows you how to steal your opponent’s pawns, converting them to your side. You will quickly surround the God Class with dozens of pawns, each ready to take off a piece. After that, the God Class is doomed.
Making Content for Large Audiences
The secret for making content effective for the broad audience requires a few things.
Most of the habits offered by Deep Roots involve a metaphor. These mental constructs pull on the knowledge that the audience already knows. Once that’s tapped from the long term memory, we can then use that association as a scaffold for new knowledge. What took pages of instruction can now be processed with a simple metaphor in one paragraph.
All of the habits offered by Deep Roots are chunked into tiny one-item shifts within a habit. Our brains decision-fatigue easily, so anything that requires more than one concept must be individually processed for real change. Discovering this deconstruction is where instructional designers provide a real gift for the subject matter experts. If you don’t have one available to you, then find somebody who isn’t in your field.
It is simple to create complexity. It is complex to create simplicity. Doing a brain dump of what feels so right … is easy. It’s fun. It’s rewarding. However, breaking down a learning design for anybody to be able to pick up at least the concept is hard. Is not fun. Makes you feel inadequate.
I am not a coder. So if Arlo can explain to me the process well enough that I can get the concept, or intent, then we know anybody in the targeted audience will get it. And that needs to be our goal when targeting broad-based audiences.
If you can’t explain it to a six year old, you don’t understand it yourself.
While this does not help our ego, addressing this head-on will allow our ability to enact real change in others.
How this helps you…
This is the premise of our training approach. Yes, we also can scale our results logistically to 10 teams at a time, or, with 10 trainers, 100 teams at a time. But that would be a complete waste of their time and your money if the content was not consumable by each developer.
And for free, we offer a monthly legacy code newsletter that breaks down a tough problem and provides a recipe for solving it. Sign up for it or forward to your development teams! Meanwhile, don’t hesitate to start your dev teams on the road for technical excellence.
Written by Dr. Marian Willeke, Director of Learning at Deep Roots