Hacker News Reader

Comment by mod | Hacker News Reader

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

View on HN

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.

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

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.

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

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

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

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.

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.

It is not acceptable because it is utterly meaningless. There's no way that a scale can represent something that is intrinsically subjective.

It might be subjective but it's a good indicator to how much guidance the person needs initially. I think it would be useful.

And yet, people are often asked to estimate their level of specific knowledge "on the scale of 1 to 10".

Subjective ratings often predict reality quite well.

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.

Reply on news.ycombinator.com