•December 19, 2022
Feedback is crucial for success when you are learning a new skill. One of the ways we give feedback at the Craftsmanship Academy is “just-in-time learning.” We don’t critique the work they haven’t done yet, but we ask questions in the moment. “How did you approach that?” “Is your method attainable?” “Is that the smartest way to accomplish that?”
We practice pair programming and test-driven development because they give you immediate feedback. In the academy, we have code sacrifices. In a code sacrifice, someone volunteers to show us their code, and we all talk about it. “I see you did this. What about doing this?” When you are done discussing their code, you move on to the next person. Do they have something different? Often, feedback applies to more than one person. Code sacrifices let them get feedback from an expert.
Code sacrifices are a more direct form of feedback than industry-accepted pull requests. In a pull request, I submit the code to whoever is in charge, and they look at it whenever they can get to it. It’s an asynchronous review. I write the code, then later, they find some time in the day to look at it, maybe a cursory glance. They write their feedback; you may want to think about this or that. There’s no dialogue. But with the code sacrifice, you can give and receive feedback in real-time. “What made you choose this method?” “What about doing this instead?” “Here are some techniques I use.”
A few years ago, I was exposed to the Dreyfus Model of Skill Acquisition, which helped me understand the variety of expertise in individuals with the same amount of industry experience I’d observed over many years. The experts best understood why “best practices” were best practices. They understand that context matters. They seek feedback. Not only should what they create “work,” but it should not introduce more complexity than is inherent in the challenge being addressed. “Expert beginners,” on the other hand, just worked by themselves until they got something to work.
At the academy, apprentices always learn entire systems, not just portions of them. Many programs, such as boot camps or computer science degrees, use a fill-in-the-blank approach or have their apprentices be able to select an approach to use.
There is no way to get around the need to gain understanding. There is a problem that needs to be solved, and we are not going to solve it for the learner. We present the problem, give a concept needed to take the next steps, and leave the learner to take those steps on their own. They can’t give up. If they are stuck because they don’t fully understand the concept (or sometimes previous concepts that they need to build on), they’ll have a chance to get help from the expert in a little while (usually an hour or two). But then it is back to working through the solution themselves.
If the learner “gets it working” but does it by introducing unnecessary complexity, they get the feedback they need. When we give them examples of code to show an approach to solve a problem, we just show them once and then take it away… they have to reproduce it themselves and take it all the way through to a solution.
We don’t fool ourselves and don’t let them fool themselves into thinking they are experts. But they get more feedback in a few weeks than many get in years, and they have developed the habit of seeking that feedback to constantly improve.
RoleModel has a culture of experimentation, but the academy can’t experiment until they finish the immersion phase and have a solid foundation of the basics. We introduce methods of experimentation slowly, in a couple of different ways.
First, we introduce new constraints, such as writing code that solves this problem in seven lines or less. Now, you can only use this method, etc. We give them constraints, not necessarily upfront, just a little bit at a time. We do this to help teach best practices and to help them understand how to do things in the real world. For example, writing a solution in seven lines of code or less helps them think about how to do things simpler and how to isolate a section of code. It makes you think beyond “does this code work?”
Every quarter, RoleModel holds Character-building, Collaborative, Craftsmanship (CCC) days, where we put aside our day-to-day work and work on experiments to advance our craft together. The academy participates in those experiments alongside developers further along in their careers. So, not only is there experimentation for the academy participants to participate in, but they see how experts experiment. Later, when they start their own experiments, they’ll be doing so with some extra wisdom gained in how to approach an experiment.
After they’ve gotten through our immersion and internship phases, they are assigned to read “Software Apprenticeship: Guidance for the Aspiring Software Craftsman.” Inevitably, they choose to follow its advice in doing some of their own experimentation. But having lived in the environment for ultralearning, their experiments benefit from the wisdom they’ve gained through being guided by mentors that are already what they want to become.
“Just-in-time” learning allows Academy participants to receive feedback in the moment. They participate in code sacrifices where they can get feedback from an expert and listen to the feedback their peers get, which often applies to more than one person.
We learn by using concrete examples of real-world software, and we look at entire systems. This helps develop their sense of intuition by cementing the concepts in the contexts they face in their careers. We also give them constraints when they’re learning to write code that help them reduce unnecessary complexity. They’re not experts yet, but they’ll get more feedback in a few weeks than others get in years.
Scott Young found Ultralearning to be effective across a variety of disciplines. Meanwhile, we developed a similar approach with the Craftsmanship Academy long before we heard about Scott or the work he’s doing with Ultralearning. When we first learned about Ultralearning, it gave us a vocabulary for everything we saw working at the Academy.
This begs the question, why aren’t more people adopting the principles of Ultralearning? We have examples of the concepts working across multiple fields documented in Young’s book, Polyface’s farming, our Craftsmanship Academy, and certainly others yet to be documented. The principles are clear. Academia’s model falls short.
If you want to learn a skill, using the concepts of Ultralearning will get you where you want to be. Creating spaces like the Craftsmanship Academy helps the next generation more effectively learn their craft by designing an Ultralearning environment. The path to mastery will be clarified through environments that provide both directness and feedback.
In case you missed them, here are Part One: Why Our Software Craftsmanship Academy Overcomes Academia's Biggest Problem, Part Two: A Successful Environment for Ultralearning Software Development, and Part Three: How Directness Reduces the Need for Drilling
