How do you know you know a new technology? | Hacker News Reader

How do you know you know a new technology?

4 pointsamp1088 comments

Suppose you want to learn a new language, framework, or technology. Using primarily online resources, how do you measure your progress? How do you know you've learned enough to call yourself proficient? (That's probably my biggest problem: not knowing what I don't know, that someone who competently uses a technology should.)

Here are a few things that don't work for me, that are popular recommendations:

"Read the API/language spec." Some autodidactic genius could do this, but not me.

"Just write a project that scratches an itch." My itches never cover more than about 12% of any given language, library, or framework.

"Read code." That's a great way to see what idioms work in a language that you can already read, but a lousy way to learn it. Also, I have no way of knowing what isn't represented by the code I read.

"Do a tutorial/read a book." Most tutorials are crap, and if I don't know anything about a topic, I can't separate the wheat from the chaff. Likewise with books, which also carry with them a 30-50 dollar investment if I can't find them elsewhere.

What other strategies are out there? Am I doing the above ones wrong? (And if so, what's the right way?)

>I can't separate the wheat from the chaff

I know this might not be the answer you're looking for but what isn't coming across in your question is a lot of passion for what you're doing so I have to ask, are you sure this is what you want to be doing?

You seem to be looking for the quick fix when learning a new programming language should be akin to finding out all the uses of a new tool in a woodworking workshop, if you're finding this a slog, is it really what you'd rather be doing?

I don't think any of the few things you listed are measures of how you measure your progress or prowess. They're strategies to make progress.

When you can accomplish what needs accomplished, you're proficient. When you can do it in the most efficient way, quickly, you're an expert.

I do the first way ("read the API/language spec"), and it seem the good way, to me. However, sometimes doing more than one thing may help if needed.

But you could also try writing stuff to see what it is, and then you can learn by that way, maybe; that would be in addition to reading the document, so that you can know what it is, and see if it is helpful.

I don't know how to call myself proficient, so I just guess. If I made something with it, then I might say I am proficient to write that particular program with it.

> Likewise with books, which also carry with them a 30-50 dollar investment if I can't find them elsewhere.

Not sure if you're aware, but a yearly membership to acm.org (Association of Computing Machinery) includes a subscription to O'Reilly's library of programming books. It doesn't have EVERY programming book written, but it contains quite a bit.

I didn't know this, it sounds very interesting; do you know if this also includes the various training videos and live training seminars offered on the O'Reilly learning portal, or the books only?

It sure does. You get it all. The ACM has a library of learning materials as well but I haven't looked at those yet. The O'Reilly stuff keeps me busy!

You don't have to be good at it. It's like languages - nobody knows English 100% unless they edit dictionaries for a living. You probably know about 40% of your native language vocabulary and that's good enough to be more than proficient.

With code, I think if you can read/write something fluently, that's proficient.

I know I'm good at something when:

The intro tutorials are boring and no longer cover anything new.

It gets harder to find more advanced tutorials and challenges.

I can quickly compose questions to find the fixes for the problems I have.

I run into intermediate tutorials and quickly notice things they're doing wrong.

Reply on news.ycombinator.com