•November 22, 2022
Recently, I have been listening to “Ultralearning” by Scott H. Young. By the time I hit “Chapter VI: Principle 3 - Directness: Go Straight Ahead,” I felt like I was listening to the perfect justification for something I’ve been believing and practicing for years.
It pointed out that Academia’s dirty secret was their struggle to obtain “the holy grail of education… transfer”, defined as the “ability to extend what has been learned in one context to new contexts. Educators hope that students will transfer learning from one problem to another within a course, from one year in school to another, between school and home, and from school to workplace.” (excerpt from “How People Learn: Brain, Mind, Experience, and School: Expanded Edition 2000”, National Academies Press). The reality is that formal classroom education doesn’t transfer to the exact situation in which you want to use the skill that you theoretically learned. According to Robert Haskell, “research findings over the last 9 decades clearly show that individuals and academia have failed to achieve transfer of learning on any significant level… without exaggeration (there is) an education scandal.”
This particular chapter in Ultralearning then goes on to point out that to learn a topic, you should not ignore directness. Transfer is harder when knowledge is limited. Scott Young points out that you can overcome the challenge of transfer by directness. Concepts learned in direct application are learned more deeply and, therefore, can more easily transfer to other applications of that knowledge.
A better approach might be to tackle a project with some “just in time” guidance from experts in a field. This is consistent with my experience in my software development and consulting career. My experience in other areas I’ve learned at some level of depth quickly (e.g., video production, woodworking, house building) also confirms this approach.
This approach is how I’ve been helping others learn software craftsmanship for around 30 years. (I was mostly focused on learning it myself in the first 10 years of my software development journey, which included a B.S. degree in Computer Science).
Helping others become “Ultralearners” all started when Ivar Jacobson sent his daughter, Agneta, to immerse herself in learning what she could of the USA and software development at my former employer. After completing her college degree, she was given a list of sub-projects with the goal—to figure out how to build the software tool he had imagined. She “lived” at our office and in the home of one of our developers while working on these projects and received “just in time” guidance, exposure, and help over the hurdles. After seeing the incredible growth in her over those short months versus the people we had given “classroom training,” we were inspired to do something that would be similar.
We created an immersion program called the Smalltalk Apprenticeship Program, where we teamed an expert with 2-3 relatively novice developers from our client companies to work on a project. They came to our place for 1-2 week stints over several months and received guided direction in building their project with “just-in-time” learning whenever they didn’t know what they needed to take the next steps.
These “apprentices” were typically in their 20s or 30s and already employed by someone else in business. I was being paid to train them. However, I often wondered what the prerequisites were for success. I kept observing that success in learning had very little to do with the previous formal education of the “apprentices.” Their desire to dive into the challenge of building a significant application with technology they knew almost nothing about, as well as general problem-solving skills, seemed to be more relevant.
Over the next few years, I worked with people with degrees in Computer Science, Human Factors, History, Music, and others. If there was any correlation between their previous academic education, it might have been that the Computer Science majors typically had more stumbling blocks. (E.g., they might try to optimize the performance of the code before they built an effective model to serve the domain of the application).
The experiment was far from perfect. But the biggest problem I faced was not the half-baked curriculum. These students were both headed to college without the thought that being a software developer was in their future. They weren’t motivated to learn outside a classroom, and they didn’t see the reward of struggling through to complete the project. They’d get stuck and neither work through it nor contact me to help them over the hurdle. Instead, they would just show up for our next group session expecting me to show them how to take the next step. They had been successful inside a classroom and saw more success inside the classroom as their next steps in life. They looked at our meetings as “the next class” rather than an opportunity to get over hurdles.
We aborted the experiment before the summer was over and had a debrief. They admitted they lacked motivation and were comfortable with being spoon-fed facts and solutions when given a challenge to overcome, rather than some basic instructions and assurance they were pointed in the right direction.
I was familiar with some homeschooled youth that I had met and wondered if they were any different. It seemed that, by the time they were in high school, many of them were teaching themselves in many subjects and doing “real things” outside of academic learning at a level I hadn’t seen in most teenagers whose idea of learning was mostly restricted to a classroom setting. (NOTE: This was 1997, when homeschoolers were harder to come by and had very dedicated parents who were pioneers of sorts). Through providence, I found a homeschooled young man - Nathaniel Talbott - who was self-taught in the mechanics of programming and had worked with people in multiple contexts outside a classroom. He recognized he was far from an accomplished software developer and wanted to “apprentice” under an experienced developer. He was much less expensive than a college graduate, so the risk/reward seemed to be in line for the next experiment.
My goal was to both get help in my business and to have him be better off in 4 years than he would have been had he gone to college. I tried a modified version of the previous experiment… give him a project, give him a little instruction on what I thought he might need to know, and have him ask when he got stuck. It worked wonderfully. Within a few months, I brought him onto a client project with me.
I was pointed to a book about Situated Learning: Legitimate Peripheral Participation. This was an academic summary of “learning by observing and repeating what the experts do.” Their examples were not in the computer world we live in today, but they gave me a few insights and things to reflect upon from my own experience.
Eventually, in 2011, after reflecting on how I guided each of our apprentices and what they had to learn before safely putting them on client projects, and what they could only really learn on real client projects, I created the Software Craftsmanship Academy. Since then, every 18-24 months, we’ve taken on 2-5 aspiring software developers at a time.
We’ve recently just wrapped up the 3rd “immersion” section of our 8th cohort - 9th if you count our modified version that took place over two summers with high schoolers. It has been a significant investment over the years, and we are convinced that the payback is worth it. A few years ago, I wrote an article titled “Ready to Farm for Software Talent?” that summarized the benefits we have seen from growing our own talent. We have found that we can nurture those that understand the basics of programming and have the desire to learn into solid developers in 12-24 months.
I am convinced that people who are experts in their fields and want to continue to have an evergreen business should consider building their own environment for Ultralearning rather than relying on academia.
Scott Young developed the concept of Ultralearning over years of observation and trial and error. The Craftsmanship Academy developed similarly, observation and experimentation with students who wanted to learn to develop software until we found a system that worked. I’ve been pleased to recognize that we have applied many of the principles outlined and the results espoused in Ultralearning. Scott Young gave us a vocabulary to describe the principles that we have seen in action over the years. We’re continuing to reflect further on how we can continue to improve based on thoughts generated by the book.
We are not the only ones who have discovered that this type of apprenticeship works, Polyface Farms has a similar program to train farmers. They have a 5-month intensive and take on some candidates after that to stay for a year. Programs like theirs, or the Craftsmanship Academy, are few and far between, but the experts who have developed an Ultralearning environment, often by trial and error, find success in the subject they teach. Whether it is a high-tech field or a career as old as civilization, look for those types of programs, whatever you are trying to learn.
Academia struggles with achieving transfer of their material. Transfer is the ability to apply what you’ve learned to new contexts, which is difficult when your knowledge about a subject is limited—like when you are learning something new. A better approach is just-in-time learning from experts—giving students the information they need in the moment they need it.
At RoleModel Software, we developed a program called the Craftsmanship Academy for aspiring software developers. After reading Scott Young’s book Ultralearning, I realized he gave us a vocabulary for the ideas that have been succeeding for many years in the Craftsmanship Academy. Through a process of trial and error, we created an environment for Ultralearning software development.
In part two of this series, we’ll begin to discuss how we’ve created a successful environment for Ultralearning software development in the Craftsmanship Academy.
Check out Part Three: How Directness Reduces the Need for Drilling and Increases Retrieval and Retention, and Part Four: Feedback in the Context of Directness.
