Over the years, we have had some very talented, experienced, well-meaning community members advise us that we should consider teaching our students creational, structural, and/or behavioral software design patterns. It was even suggested that we should attempt to teach the SOLID principles meant for scalable, flexible, and maintainable software systems.
Laudable goals.
Against my reservations, I ran the experiment for three straight cohorts. I showed students examples of the most common design patterns that you see in the wild. I explained why professional developers use those patterns, and what their purposes are. I even wrote some tickets for their group projects intended to make them attempt to implement those design patterns.
I also took a stab at explaining the SOLID principles. I showed code examples, provided context, and explained their benefits in a large-scale project.
After running those experiments, here's what I learned.
- There was near-zero understanding of the concepts.
- There was absolutely zero ability to apply or analyze the concepts.
- There was one exception, and I've doubled down on it.
Out of all the patterns and principles, there is one that actually resonates with students. They understand it and can apply it with minimal success. They attempt to adhere to it when they can, and will use it in their discussions in class. They even continue to advocate for it when they enter their professional lives as developers.
Here's the thing. Our course is truly an accelerated learning environment. After 6 months, students still are in the weeds tracking down simple syntax errors, method definitions, and how they are applied for very low-level tasks. In short, they are still putting the pieces of the puzzle together.
There are more foundational patterns that we do focus on, and students truly understand, apply, and evaluate them.
The first one is the DRY principle. One of the core patterns of software development that they must be exposed to early, and often - throughout the entire course - for it to truly stick. I start this conversation on the fourth day of the course and continue to strengthen their understanding for the next six months.
The second foundational principle that also requires constant reinforcement for 6 months is the YAGNI principle. When students take their first tentative steps into building their first moderately complex code, they tend to throw everything they have exposed to up to that point at the problem, with the hope that something will work. We then need to coach them on how to eliminate code that is either more complex than it needs to be, or isn't doing anything to solve the problem.
The final principle that we focus on is the sole SOLID principle that I mentioned above that students can understand and apply in their projects. That is the Single Responsibility Principle.
The elaborative approach of coaching students from the concept of function-level encapsulation to seeing modules as actors in the system that contain all the responsibilities of that actor has been relatively successful. We start with Object.create() in JavaScript, and progress to classes and/or modules when they enter their respective server-side language - whether it is Node JavaScript, Python, Ruby, or C#.
Summary
If you are developer with limited experience, either having gone through a code bootcamp, are self-taught, or got a graduate degree, focusing on increasing your efficiency in following those three principles - DRY, YAGNI, and SRP - will pay huge dividends as your grow your craft and learn to apply more advanced principles when you are ready.
One of the core concepts that I've learned as a coach is that all real learning happens through experience. I can talk for hours, or days, about design patterns that are used in long-lived, large scale projects, but until you experience the need and application of them, nothing is learned.
At best, I can hope for is simple knowledge where a student can recite the definition.