Exercise may be a bad analogy because you get immediate feedback from your body. If you’re doing something wrong, it hurts, and in a bad way. If you’re doing something right, it hurts, but generally you can tell that it’s hurting in a good way.
With programming, how do you know that it hurts? How do you know if it’s a good kind of hurt or a bad kind?
A few quotes that I thought were insightful:
cc - Though, having so many principles to follow has some draw back. Some people just don’t try to understand them well before using them.
wedge - It’s not nearly so worthwhile as an actual apprenticeship (referencing StackOverflow.com)
Steve W - As I understand it, the original complaint about the SOLID principles was that they were written by someone who had no real-world experience. That getting things done in the real world was more important than code quality.
Jeff Atwood Remind me again – who, exactly, are we writing these principles, rules, guidelines, and methodologies for?
I would like to answer that question, but first a short story:
I feel like my first 12 years of my career was wasted.
I was a talented programmer. I could solve every single problem thrown at me in a fairly efficient and intelligent manner. The code that I wrote worked. I had read nearly every book I could get my grubby little hands on, yet still I was missing something.
Finally, 12 years into my software development career, I met someone capable of mentoring me.
Looking back I can truthfully say that most of the code I had written before that sucked, even though my managers and co-workers thought I was a programming demi-god.
Before and after my apprenticeship I can tell a difference. My mentor can tell the difference. There is a hugely astounding difference.
Now, re-reading many of the books that I had read prior to my apprenticeship I can fully understand them and apply them… but that’s because I’ve already experienced the problems these books are trying to solve and I had someone to help show me the correct principle, design pattern, etc to apply for any given problem.
A knowledgeable person reading correct principals and guidelines can recognize them as correct and apply them correctly.
A less experienced person will generally reject them as written by someone who had no real-world experience if he even understands what the author was trying to say in the first place.
To answer Jeff’s question: We’re writing these principals as a way of verbalizing and fine-tuning that which the masters and mentors already understand. They’re not in and of themselves capable of teaching anything. They’re to be used as a bible, dictionary, glossary and reference manual, not as a teaching textbook.
For those that have not yet mastered their trade, the best we can do is to mentor them. Let them make their mistakes and then kindly, gently, show them the better way of doing things.
I’ve been on the giving and the receiving side of such a relationship and I have to say there is no other way. There is no golden solution… or at least none that I’ve found so far.
Nice article!
