6 ms·
What the article describes as "competence" sounds like total incompetence to me. If you learn a pattern from a book or a class or a blog post, and then you app
by hasenj 10y ago
What the article describes as "competence" sounds like total incompetence to me.
If you learn a pattern from a book or a class or a blog post, and then you apply it in a project just because "the book said so" you are not a competent programmer.
This might be an artifact of English not being my first language, but I would reverse the definitions.
Proficiency means knowing how to use something.
Competence is knowing how to do something properly, which implies having a deep _understanding_ about what is going on.
That seems to be how people use these terms anyway (regardless of the dictionary definition).
Proficient in jQuery: knows the ins and outs of most jQuery functions and plugins.
Competent in jQuery: non-sensical statement.
Proficient in git: knows most useful commands and arguments.
Competent in git: almost a non-sensical statement.
On the other hand:
Competent front end developer: understands how to develop a web based application UI from scratch without being tied to a specific product domain.
At least that's how I understand these terms.
- practicingdev 10y agoTo me the terms are roughly interchangeable if taken in their general meaning, or at least easy to confuse with one another. But when I wrote this article, I hinged it off of specific definitions assigned to the terms in the Dreyfus Model, which although not exactly commonplace, is an established bit of literature (for example, Pragmatic Press uses Dreyfus Model to indicate expected skill level for readers of their books) So I stuck with their definitions and attempted to restate those definitions (informally) in the article. But I'd be fine with you calling these Thing 1 and Thing 2, as long as they mapped to the definitions provided. What the article refers to as competence (Thing 1) is something programmers generally recognize as valuable, because it is valuable! Essential, in fact. What the article refers to as proficiency (Thing 2) is something programmers probably also recognize as valuable, however... many do fall into the trap of thinking this: Thing 2 is what you get from being really good at Thing 1 in many areas. In truth, Thing 2 is what you get from being halfway decent at Thing 1 in many areas, and then with a view of the bigger picture, getting really good at specific aspects of Thing 1... in the context of your actual work, goals, etc. In other words, Thing 2 = Thing 1 X TheBiggerPicture. Now if I were to use my own way of thinking about this... I actually thing of Thing 1 (competence) as tactics, and Thing 2 (proficiency) as strategy. But I think that could end up leading to an even more confusingly overloaded set of terms.
- nimblegorilla 10y agoI agree that better terminology would be something like competent and master.
- practicingdev 10y agoThis is roughly the full Dreyfus model: (1) Novice... does not understand anything but basic knowledge in the abstract sense (2) Competent... knows how to apply knowledge to solve concrete problems (3) Proficient... sees how particular solutions fit into the context of different problems (i.e. what tools to use, when, and why) (4) Expert... picks the right tool for the job without having to do careful analysis... works from intuition by pattern matching against fundamental concepts combined with past experiences. (5) Master... picks the right tool for the job without even being consciously aware of the fact that they're "doing work" at all. It's important to remember that all of these levels apply within specific contexts... you can be master one thing while being a novice at many other things. But each step along the path is a gate of sorts: in that you can't really understand what it's like to be an expert in anything until you're an expert in at least one thing, and building expertise is easier when you have done it at least once. But a big problem (which we're mentally hard wired to be biased about) is evaluating our own skills, as well as the scope of experience of others. This is why someone with local expertise often thinks they can speak on topics outside of their actual expertise, and why people tend to believe them when they do. "Thinking, Fast and Slow" by Daniel Kahneman is the best book I know on that topic. Totally worth reading.