The main idea is that studying a bunch of design patterns or general design ideas in bulk is useless, because your brain has to dissect those abstract things and learn to detect them as "symptoms" on concrete problems when you are doing real tasks on real code.
If you want your brain to naturally come up with a certain design pattern as a solution, it has to try use it in repeat, through iterations. Just like how you learn new vocabulary in a language: you review words a few times until they become second nature and you can naturally use them when you speak.
I have been trying this method on myself and programmers I was mentoring in real-world production environments. And it's proven to be working. It's really simple and fundamental in principle.
Here's the method:
1) Acquire the knowledge of the existence of a single design idea.
2) Write a piece of code the way you normally do.
3) Review your own code and try to detect bad things about it.
4) Refactor your code. Think of all the design ideas you can come up with for that specific piece of dirty code.
5) goto 1 (enough times).
"Enough times" is totally relative. Relative for each design pattern, and relative with one's fundamental knowledge of software design.
Maybe after all, this is simple, but it takes some time. The truth is becoming genuinely and fundamentally good at programming needs time and mindfulness. I am also far away from ideal and do practice this on a daily basis. It's a fun part of the process.
Also you can easily find the failed examples of "learning in bulk" within the college students who study a bunch of design patterns for exams but forget all of them a week after. Moreover, they aren't also taught to use the abstract ideas in real world and concrete problems.
I hope this will be helpful to someone out there.
Top comments (0)