… the point here is not simply that somebody who has skill in something learns by doing more of the same, they actually learn in a fundamentally different way.
Now one of the most interesting things that we get out of this is the fact that guidance or advice for the novice and the advanced beginner tends to be phrased in absolutes; it tends to be context-free — oh, you should always do this; oh, never do that — but as you ascend through this [levels of skill], what you find is that your experience tells you, there are these interesting little edge cases — these edge cases that don't seem to follow the rule, they are exceptions to the rule.
As you reach the expert end of the scale what you realize is that these are not exceptions to the rule, they are their own rules.
They are rules with well understood context which is one of the reasons that people with a lot of experience tend to come back at you with — you know you ask some question and they come back at you it depends.
They're not just being awkward — they might be that as well but they're not just being awkward — what they're doing: given, based on what you've told me, there's three possible solutions; there's three possible ways of doing this — I need more information because it depends.
There are few absolutes — in other words it's highly contextual.
So where do the SOLID principles live? I do use the phraseology sometimes as "the SOLID principles" — with only a couple of exceptions they live at this end [Novice, Advanced Beginner].
If you're still following the SOLID principles and you regard yourself as a competent developer you need to start giving them up …
So it needs to be stated that simply itemizing "Clean Code Guidelines" — without any context - can really only serve novice and advanced beginner developers. To truly advance, one needs to understand the prevailing assumptions and circumstances that tend to arise that give credibility to these guidelines so that it becomes possible to disregard the guidelines outside of their implied, applicable context.
To be clear, a competent developer doesn't just simply disregard the guidelines but needs to be capable of formulating a valid argument of why the guidelines do not apply in a particular context.
That said, I find to this day that he has failed to reconcile his growing admiration of Clojure (at least since 2010) with his continued evangelism for the class-based object-oriented development methodology. I'm inclined to believe this is entirely motivated by "professional reasons".
Love it! The Dreyfus model of skill acquisition is one of my favorites. The whole original research paper is well worth the read: apps.dtic.mil/sti/pdfs/ADA084551.pdf
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
as annoying and incoherent it can seem for a novice seeing experts that do not strictly follow the rules all the times, in the end it is really just that. Context and experience enable you to understand if the rule makes sense in that specific context or not.
rules are easy and necessary, and fundamental at the beginning, the more you grow and the more you understand, the more flexible you can become.
it kinda reminded me of the quote from Pablo Picasso:
Learn the rules like a pro, so you can break them like an artist.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Perhaps that article's author simply needed a more appropriate title:
Kevlin Henny stated it this way in reference to the Dreyfus model of skill acquisition:
So it needs to be stated that simply itemizing "Clean Code Guidelines" — without any context - can really only serve novice and advanced beginner developers. To truly advance, one needs to understand the prevailing assumptions and circumstances that tend to arise that give credibility to these guidelines so that it becomes possible to disregard the guidelines outside of their implied, applicable context.
To be clear, a competent developer doesn't just simply disregard the guidelines but needs to be capable of formulating a valid argument of why the guidelines do not apply in a particular context.
At the time I found Designing Object-Oriented C++ Applications Using the Booch Method (1995) and Agile Software Development, Principles, Patterns, and Practices (2002) quite useful, as well as his blog (as long as you keep your critical thinking firmly engaged — don't take anything at face value).
That said, I find to this day that he has failed to reconcile his growing admiration of Clojure (at least since 2010) with his continued evangelism for the class-based object-oriented development methodology. I'm inclined to believe this is entirely motivated by "professional reasons".
Love it! The Dreyfus model of skill acquisition is one of my favorites. The whole original research paper is well worth the read: apps.dtic.mil/sti/pdfs/ADA084551.pdf
Keeping in mind:
Perhaps you'll enjoy Dan North's Dreyfus Squared pattern/hypothesis.
Very good read!
absolutely love this comment!
as annoying and incoherent it can seem for a novice seeing experts that do not strictly follow the rules all the times, in the end it is really just that. Context and experience enable you to understand if the rule makes sense in that specific context or not.
rules are easy and necessary, and fundamental at the beginning, the more you grow and the more you understand, the more flexible you can become.
it kinda reminded me of the quote from Pablo Picasso: