To become a 'professional software engineer', one must learn to be a team-player within a group of persons tasked in building and maintaining a piece of software that will stand the test of time. Which requires a very different skill set. One can be a good SE and still be relying on auto-completion and inline help in one's favorite text editor.
Remembering the API of your languages definitely helps, but actually building softwares that will be used by real users, for years, that's what makes you a 'professional software engineer'.
Usually, a programming language (or an API or whatever) has some core part which you use daily. So, no need to memorize anything actively. Yes, sometimes you write something and wonder "Is there an easier or more idiomatic way to do that?", then you will search in the manuals or on stackexchange and you see how it's done. If you are curious (which I hope), you will maybe also check WHY it is the easiest resp. most idiomatic way. Again, no need for active memorization. Then there is the part of the language or API that you rarely need and that you don't have to memorize anyway.
To be honest, I am completely speechless. Flashcards? To memorize programming manuals? I know people who use flashcards when following crash courses to qualify as Cisco engineers or whatever. But for programming???
Part of how I got the job I got (an amazing dream job) is because the interviewers were flabbergasted seeing me live-code flawless idiomatic code like it was the back of my hand. Difficult to achieve that without SOME sort of systematic study. Most master pianists don't get there by just doing lots of casual play.
I should also mention, one of my main language is kdb+/q. Try mastering THAT without flashcards ;)
Could you explain in some detail how this works out in practice ? For example with someone learning JavaScript or Python ?
I created cards by going through this excellent free online book (I skipped chapters I wasn't interested in): http://exploringjs.com/es6/index.html
The process of creating cards: (A) read a paragraph. (B) make flashcards for everything new introduced in that paragraph. (C) goto A.
As for B, I would take great pains to make the cards as terse as possible while still drilling the concepts. Over-verbose examples should be rewritten more tersely (and tested in the browser to make sure you didn't screw up).
For example, from the first paragraph of Section 4.1 I might make this card, among others:
(Front) Evaluate:
var x = 0;
function f(){ if(false) {var x;} return x; }
f()
(Back of card) undefined
(Notice how I distilled the much-more-verbose examples from that paragraph down to a core that illustrates the key point.)
If you're serious about this, it'll take a lot of time. I used it to crash-learn basic kdb in about 1 month, but that required spending ~4 hours/day that whole time. Making cards is a skill in itself, you'll get better at it over time (a lot of my early cards are way too verbose and sometimes I'll rewrite them now that I've gotten better at making terse cards)
I cannot believe that you are following such a strange approach to learning programming. In fact, I believe that you are using Anki for something completely different than what you are claiming here. You are not making flashcards and you are not memorizing the answers. You are making quizzes and you are using Anki to check whether you are able to solve them. At least, that's what I hope.
But in your own post you point out that flashcards can be used for quizzes as well?
I think you have this weird idea that flash cards are only good for memorizing the things written on them.
That's a really limiting, and false, idea.
A flash card is just a pairing of a specific question with a specific answer. How you use that simple framework is up to you.
I used them for trig identities. That was straight memorization.
I also used them for proofs. As in 'Prove every edge in G^k is a walk of length k in G'. Then I'd work through the proof, and check my answer against the one on the other side. That's not memorization.
It's still flashcards though.
One trick is I found it's best to design the cards so you can say the answer fast. You don't want to waste time verbalizing long asnwers. So my cards end up looking like this:
(Front of card) Evaluate: {'foo': 'bar'}.get('baz', 0)
(Back of card) 0
Or like this:
(Front of card) How to get [1, 2, 3, 4, 5] in lodash? _.___(1, 6)
(Back of card) _.range(1, 6)
That latter is an example of what's called a "cloze", where you show the full answer on the front of the card, except with one part blocked out. You can block out different parts of the answer to create multiple cards for the same question e.g.
(Front of card) How to get [1, 2, 3, 4, 5] in lodash? _.range(___)
(Back of card) _.range(1, 6)
What nonsense. You must have hung around insufferable people.
I only semi agree because this seems to be a phenomenon of an older generation. Newly minted PhDs are often much more proficient in programming, since they usually have received a much stronger education in that regard.
That's usually the easiest way to learn a new language.
Also, it's easy to get the bird's eye view of a language (say, React, for example), but when you're down in the trenches, you need to KNOW about the pedantic little details (like "class" vs. "className", "for" vs. "htmlFor", minutiae of React lifecycle, etc.)