•December 13, 2022
Academy participants are not solving any “academic” problems. One of the definitions of “academic” is “theoretical or hypothetical; not practical, realistic, or directly useful.” They are taught how to use the same tools and practices our developers are using when they tackle their initial “toy” projects we give them at the beginning of the academy. But these are not academic. They are practical “low stakes” applications (e.g., an interactive game of “Go Fish”) that can be used by anyone… and they are assigned to get feedback from potential users of these applications, which they can find among their family and friends… or random strangers.
They are either looking over their shoulders as they work, contributing to the discussion as to how to address the real-world challenges they are facing that day, and sometimes even taking a shot at solving those challenges themselves. They don’t have to overcome the use of the tools, so they have less trouble jumping that gap of knowledge they have not yet attained because the impediment of the tools is no longer there.
By the time they are in the apprenticeship phase, they have the best practices; when they shadow an expert in the field, they begin to apply them to problems they haven’t seen yet. We’ll give them tasks that they are prepared to handle in a real-world project where you can see how it applies. This is where they apply the skill of transfer.
They are learning what they need to accomplish an actual goal. They’ve been through the immersion stage; they have the tools. Now it is time to see how they apply in project-based learning. Sometimes, they are given stricter rules than they will have in the real world for the purpose of learning. We tell them any method you write that’s longer than seven lines of code; you throw it out. In the real world, you may need more. But for the purpose of this project, stricter rules guide better solutions.
They learn from the source. If you want to learn to be a software developer, you have to learn to develop software. When they fail miserably, we talk about how they can do better. We ask them questions that will hopefully guide them to a better solution. By answering them, you should end up with better code.
Within months, they are spending most of their time working on project teams, and the rest continuing to bolster their understanding of more advanced topics so they can contribute more to their project teams (and others). Their mentors are not burdened with teaching them everything they need to know about software development; just how to apply the concepts they’ve already learned to the problem at hand and fill in some conceptual gaps… the last 20 percent that takes a lifetime.
Many developers don’t recognize that they should not just get something to work but get it to work well. The concepts we teach early on guide them to create clear, concise code. Without it, they will be building a big ball of mud. One way we get them to do this is to have them work on the same domain on several different projects with guided rules they must follow and instructions to delete any code that doesn’t conform to the rules. They get it.
And, by building projects with different technologies in the same domain, they see opportunities to do something different/better each time they build a similar application. The knowledge they pick up transfers to the next application, and the gaps get smaller. As their knowledge continues to grow, it is ready to transfer to a different domain.
We drill new best practices in the same domain to ease the cognitive load, pushing but not breaking it. This way, they can apply the best practices in a domain they already know. When they get stuck, we can get them past their freezing point by giving them a boost or just enough of the answer to get unstuck, allowing them to focus on the new skill.
Sometimes we write the first test for them. Giving them an example, or two, or three. Once they’ve seen an expert do it, they can try it on their own. Giving them directions or examples before they try reduces the cognitive load.
We design the drills and practices for them. All they have to focus on is the new best practices or skills that they are learning and understand how to apply them to the project. Some skills, like intention revealing names and test-driven development, get introduced on day one and continue all the way through their training. You need to get those things, even if you get nothing else.
We have a mantra that we teach the academy apprentices: make it run, make it right, make it fast. We focus on repeating key things often until they become second nature. Some of the principles they learn in the first week they get every week after. If you do something every day, it becomes normal.
As you practice a skill, it causes retrieval. When I jump back into programming after I haven’t done it for a while, I look at a problem and think, “I know there’s a solution for that,” but I have to go look it up. After programming for a few days though, my fingers remember shortcuts that I didn’t even remember I ever knew. Working on best practices every day helps condition your brain to retrieve information and even helps improve background memory—like those shortcuts I didn’t consciously remember. When you are working on projects, solidifying best practices for 8-10 hours a day, retrieval happens.
From the beginning of the academy, participants are learning to use the tools developers use in low-stakes applications where they can make mistakes. Within the first month, they start working with experienced developers and see how the tools they are learning to use work in advanced applications. When they get to the apprenticeship phase, they understand best practices and can apply them to problems when shadowing an expert.
They are learning with a goal in mind. When we give them projects to practice on, they are working with different technologies in the same domain, and the knowledge they gain on each project transfers to the next application, and their understanding grows. By working on key concepts every day, best practices and key concepts become second nature.
In part four, we’ll discuss the critical need for feedback and how it nurtures intuition, which builds a foundation ready for experimentation.
In case you missed them, here are Part One: Why Our Software Craftsmanship Academy Overcomes Academia's Biggest Problem and Part Two: A Successful Environment for Ultralearning Software Development
