6 ms·

> 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

by mod 10y ago

> 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.

vonmoltke 10y ago
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.
collyw 10y ago
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.
- 1propionyl 10y ago
  I wish it was considered acceptable to provide bar charts of relative self assessed competency with a set of tools. With error bars of courses.
  - crispyambulance 10y ago
    It is not acceptable because it is utterly meaningless. There's no way that a scale can represent something that is intrinsically subjective.
    - atoko 10y ago
      It might be subjective but it's a good indicator to how much guidance the person needs initially. I think it would be useful.
    - SubiculumCode 10y ago
      Subjective ratings often predict reality quite well.
    - cema 10y ago
      And yet, people are often asked to estimate their level of specific knowledge "on the scale of 1 to 10".
  - gr3yh47 10y ago
    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
  - abraae 10y ago
    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.
CoolGuySteve 10y ago
A dungeons and dragons player would recognize this as the semantic difference between the "intelligence" and "wisdom" stats.
- gaius 10y ago
  Or in The Wrath Of Khan where Kirk and Spock realize Khan's intelligence but inexperience are his weakness in the Mutara Nebula.
TheOtherHobbes 10y ago
No, it's not about stuff you know. This was posted recently, but it was so good it's worth repeating: http://blog.robertelder.org/50-interviews-with-facebook-twitter-amazon-others/ http://blog.robertelder.org/50-interviews-with-facebook-twit... 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.
- encoderer 10y ago
  > 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.)
- mod 10y ago
  That's just skill and superior skill. Both require you to know stuff. And in programming, skill is just knowing more stuff (knowing how to apply things). In other trades, skills might be swinging a hammer well or being able to chop potatoes really quickly.
  - rabidrat 10y ago
    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".
deleted 10y ago
[deleted]
adekok 10y ago
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.
- rimantas 10y ago
  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.
- Digit-Al 10y ago
  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.

by mod 10y ago

vonmoltke 10y ago

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.

collyw 10y ago

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.

1propionyl 10y ago
I wish it was considered acceptable to provide bar charts of relative self assessed competency with a set of tools. With error bars of courses.
- crispyambulance 10y ago
  It is not acceptable because it is utterly meaningless. There's no way that a scale can represent something that is intrinsically subjective.
  - atoko 10y ago
    It might be subjective but it's a good indicator to how much guidance the person needs initially. I think it would be useful.
  - SubiculumCode 10y ago
    Subjective ratings often predict reality quite well.
  - cema 10y ago
    And yet, people are often asked to estimate their level of specific knowledge "on the scale of 1 to 10".
- gr3yh47 10y ago
  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
- abraae 10y ago
  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.

CoolGuySteve 10y ago

A dungeons and dragons player would recognize this as the semantic difference between the "intelligence" and "wisdom" stats.

gaius 10y ago
Or in The Wrath Of Khan where Kirk and Spock realize Khan's intelligence but inexperience are his weakness in the Mutara Nebula.

TheOtherHobbes 10y ago

No, it's not about stuff you know. This was posted recently, but it was so good it's worth repeating: http://blog.robertelder.org/50-interviews-with-facebook-twitter-amazon-others/ http://blog.robertelder.org/50-interviews-with-facebook-twit... 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.

encoderer 10y ago
> 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.)
mod 10y ago
That's just skill and superior skill. Both require you to know stuff. And in programming, skill is just knowing more stuff (knowing how to apply things). In other trades, skills might be swinging a hammer well or being able to chop potatoes really quickly.
- rabidrat 10y ago
  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".

deleted 10y ago

[deleted]

adekok 10y ago

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.

rimantas 10y ago
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.
Digit-Al 10y ago
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.