> But the place where the intermediate programmer tends to get stuck ... is thinking that the difference between a beginner and an expert can be measured in how much stuff you know.
> And at its essence, proficiency is about "why you do things a certain way"—It's the difference between understanding each of the parts of a problem individually, and understanding how the parts fit into the whole.
So I guess it is about stuff you know.
The article then goes into further specifics about how you have to know when to apply what you know.
I'm sure everyone has worked with someone who has memorized a lot, but doesn't know how to do much. Their productivity is limited.
There are also people with innate "know how", who can get things done without much background knowledge. They just know how things work.
My $0.02 is that experts have both of the above skills. They know a lot more than average people, and have better techniques for doing things.
My experience has been that once you reach a certain level of expertise, it's better to "know how", than to know things. For the software I've written, I just forget about the minor details, and have to look them up again. The details aren't important, and just aren't worth remembering.
In contrast, remembering the problems and solutions is much more important. The solutions can be applied to multiple problems in a way that simple "memorization of facts" cannot.
Yeah. I used to work with a guy who mainly knew databases, but also had to do some C# as part of his job. He did loads of MS certifications, just to have them on his CV, but was clueless and usually had to ask me how to do anything more than the most simple programming tasks.
Being expert means having ability to recognise certain patterns and having skills to apply then. So yes details don't matter much if pattern recognition works fine (and it's ability to work is in some degree dependant on ignoring non-essential details). Which details don't matter is aldo learned through experience.
There is a danger of miscategorizing if one gets too confindent and sloppy.
The interesting point is the distinction between skill and talent.
Skill is close to competence. You can solve well-defined problems using standard tools and practices.
Talent is close to proficiency. You can not only improvise good solutions for novel problems, but you can also prioritise problems intelligently to achieve strategic goals, because you have a clear view of how the codebase fits into your business or project.
Without talent you can waste a lot of time by picking the wrong tools, or using tools in the wrong ways. Even though your code may be perfectly correct, the solution built with the code can still be completely wrong or useless.
In fact talent is somewhat orthogonal to skill. You can have an untrained version of that overview talent, but it's not so useful if it isn't grounded in skill.
When you have both, you have real proficiency - good code doing the right things to solve the right problems.
I think you're splitting hairs. The parent and OP are saying there is a qualitative difference, and by saying "just X and better X" you're trying to say that the difference is merely quantitative. In my experience, when someone makes a claim of qualitative difference, and someone else insists that the difference is merely quantitative, it's because the latter person has not themselves seen the quality of the difference. This applies in many fields.
And that's compatible with my personal understanding here as well. As someone who has been programming for 30+ years and is generally considered proficient, I agree with the parent that the difference is qualitative. This explains a lot of the times when I look at what senior developers are doing and think "yes, that tool is generally useful, but not this time". And it gets frustrating then when they start arguing about "best practices" but I'm trying to make a larger point about "this project".
You make a good analysis, and I don't disagree with you. The crux of my argument is more like this:
Programming is a knowledge field, so any proficiency is just deeper know-how. "Stuff you know." Is that quantitative? Not exactly. I certainly don't think someone who knows 50 languages is a better programmer than someone who knows 2 languages, by virtue of the quantity.
Some things are memorization: how to write a class, for instance. And some things are not: how to model a situation into an appropriately-designed class.
One requires application of knowledge, I guess you could say. Qualitative.
But you can't apply your knowledge of different class designs without knowing why they're appropriate. That's not purely qualitative.
Am I splitting hairs? At this point, probably. I just think the arguments I responded to are poorly worded. Yours is not, and I can't disagree with it.
> Talent is close to proficiency. You can not only improvise good solutions for novel problems, but you can also prioritise problems intelligently to achieve strategic goals, because you have a clear view of how the codebase fits into your business or project.
Calling that aspect talent and not just another skill is somewhat elitist I think. It can be learned. It's just another skill. (Haven't read the link.)
I interpret "stuff you know" as easily-recallable facts. Obviously at the highest level view knowledge is what separates a beginner from an expert. Knowledge is much more than "stuff you know", though. It is about understanding why, knowing how to handle non-textbook situations, and knowing where to find the facts you need when you need them.
I think he is arguing for having depth as well as breadth of knowledge.
Certainly when I am looking at CVs and see every framework under the sun listed when we are looking for a Django dev, I assume they have done the Django tutorial, maybe a little more then moved onto the next framework.
on my resume I list specific skills (i.e. AWS, Node.js) under several categories (i.e. ops, programming) and for each skill listed i format them bold, italic, plaintext with a legend showing that those map to adept, proficient, and working knowledge
SuccessFactors HR product used to do this (may still do).
You had to drag and drop your skills within a kind of bell curve. It forced you to prioritise only one or two as your super skills, then a larger number that were your next top skills, and finally a whole bunch of stuff at the lower level.
It worked well, though it was in no way the final word on this kind of very challenging problem.
> And at its essence, proficiency is about "why you do things a certain way"—It's the difference between understanding each of the parts of a problem individually, and understanding how the parts fit into the whole.
So I guess it is about stuff you know.
The article then goes into further specifics about how you have to know when to apply what you know.