As others have mentioned, its less about the syntax of a language and more about the plethora of libraries that is the real boon when it comes to using a programming language. It has been said that the majority of a tough problem is worked out unconsciously. If we eschew memorization for "just in time" methods, we are essentially putting a hard limit on the type and difficulty of problems we're capable of solving.
I personally think the amount of library functions memorized is the biggest difference between average programmers and the so-called 10x programmers. An extremely high level of fluency with a programming language environment is invaluable when it comes to efficiency and code quality. It is analogous to conversing in a language where one has to look up every other word compared to a native speaker who has a deep fluency. It's not just a matter of speed; the depth and quality of thought is orders of magnitude greater in the fluent speaker. The more of the heavy lifting you can do unconsciously, a vastly higher level of output one is able to produce for the same amount of mental effort. We accept this in just about every profession, yet we resist when it comes to programming. Personally, I'm glad my doctor memorizes a large amount of the facts he uses in his day-to-day work.
It is unfortunate that just about every new language brings with it a new set of standard libraries that we must learn to use effectively. We give up so much expertise and efficiency when we don't allow ourselves to build up a high level of familiarity with them. I can imagine a future where there is a standard library of methods that every programmer attempts to memorize and that every new programming language is programmed specifically for this standard library. We are already seeing this with language frameworks like the JVM and .NET, but we need to go even further. Hopefully libraries themselves will be created specifically to be easy to memorize.
The problem is that languages and especially libraries change too frequently. A doctor can learn the name of every bone in the body and that knowledge will for the rest of his life. In programming, there are very few things that will still be the same in 20+ years and we have no idea what those things are. It depends on the field but things can change so much within 2 or 3 years that its just not worth memorizing everything.
The timespan of change doesn't matter; the question, as always, is whether the benefits outweigh the cost.
Now, the cost is approximately <5 minutes per flashcard to give you roughly 95% recall (more details: http://www.gwern.net/Spaced%20repetition#what-to-add ); so the question is, does not knowing something you could've put into a flashcard - the consequences of not knowing it, the time it takes to look it up, whether you will even know to look it up, etc - outweighs the cost of a few minutes' review over that time period.
I think for a lot of stuff this can be true: shell scripting is not going away in 20 years, for example. If you're programming in it routinely, a language you will use for only 10 years can be worth memorizing for a while. If you're using a tool every day for the next year, there's going to be a lot worth memorizing there too.
> In programming, there are very few things that will still
> be the same in 20+ years and we have no idea what those
> things are.
For the most part we are walking toward local optima in programming languages with larger jumps rarely succeeding.
SRS is well designed for gradually changing bodies of knowledge. New cards are added and come up more often, older cards can be retired but they rarely come up anyway.
Interesting point. I think an analogy that many people can appreciate is that one's knowledge of a language and libraries plays the same role in programming that one's knowledge of mathematics plays when learning physics in school. If you're struggling with the math, you aren't able to devote much thought to the physics you're supposed to be learning. I understood the principle very well in school and always made sure to refresh my knowledge of the required math skills before tackling my physics work, but I haven't applied it to programming as well as I should. Food for thought.
"I personally think the amount of library functions memorized is the biggest difference between average programmers and the so-called 10x programmers."
I don't know, what about the ability to think outside the box, a solid grasp of the fundamentals, or the capability to understand and create high level abstractions?
Seems like you're saying the ability to glue together a bunch of library functions is what classifies a great programmer. If that's the case, it should make programming interview tests rather trivial.
These were my thoughts too - while I agree with the general sentiment of using Spaced Repetition; it also depends on the language you are using. If I find I'm beginning to recognize an abstraction I immediately begin to search for something someone else has already done.
The author of the post used PHP as an example and I think it's a terrible example because PHP's standard library and 3rd party libraries were all over the place in terms of naming conventions, structure, duplicated but not quite abstractions, &c...
I've found learning languages like Haskell to be very different - where learning the axioms and postulates is what leads me to implementation specifics. A good example: I was building accumulating recursive functions for a little project and was looking at the code and said this to myself, "This doesn't feel right, this looks like Scheme or Erlang code - not Haskell."
I set out to find any abstractions built into Haskell or 3rd party libraries that handled accumulators - low and behold folds! I've done that numerous times with this language proceeding from fundamentals and the process of abstraction to find first if the abstraction has already been done!
[EDIT]
I use Spaced Repetition for learning Haskell - but it isn't names of functions; it is the Monad laws, or Functor laws, &c... that I want to memorize.
The point is that the more of the details you have committed to memory, the better your able to "think outside of the box" because your limited cognitive capacity is not bogged down by the minutia. The analogy of fluency in natural language I think is very relevant. The difference in complexity of thought between someone fluent in a language vs someone just learning isn't a matter of intelligence, its a matter of having the building blocks of thought committed to memory. The more of the details that are second nature, the higher level of thought that results. I don't see why this is any different when it comes to programming.
I agree with you and I like your last point. It is indeed a problem that we have many languages and many libraries when many of them do the same thing. One big library to rule them all. Some day we will have that. There will be many algorithms in there, containers, network stack, everything you want and need. And cross platform of course.
What you mention is one more thing to remember when starting on a specific project/team: Which of the possible library functions should you use for a given Task?
> The more of the heavy lifting you can do unconsciously, a vastly higher level of output one is able to produce for the same amount of mental effort.
I agree, but working from the standard library has it backwards. One should subconsciously know what is in principle possible and then look up/remember how it's called in the language you are currently working in, and if it is not there implement it yourself.
But the act of searching and evaluating the results limits your cognitive capacity for building even greater abstractions. If you already have some standard set of implementations memorized that frees up your mind to use those pieces as building blocks for new, grander structures. As you fill your working memory with minutia, the larger abstractions are bumped out which makes it harder or impossible to create new abstractions using the higher level building blocks.
I get the resistance to memorization--I am the laziest SOB I know (and being in the company of programmers, that's no small feat). I got through college almost never taking notes and by just understanding concepts. It worked great for some subjects, namely math, CS, physics, etc. But one thing a math professor said one time in a higher level course for math majors that stuck with me: "If you don't memorize what came before, you will never be able to make new discoveries". In hard math it is expected to memorize the results that came before as this is the only way to discover patterns between them and create new associations.
I think the same applies to programming. Your mind can only hold and manipulate so many units of information at a time. The more abstract those units are, the greater the resulting mental structures will be. We artificially limit ourselves in our resistance to memorization.
Comments
As others have mentioned, its less about the syntax of a language and more about the plethora of libraries that is the real boon when it comes to using a programming language. It has been said that the majority of a tough problem is worked out unconsciously. If we eschew memorization for "just in time" methods, we are essentially putting a hard limit on the type and difficulty of problems we're capable of solving.
I personally think the amount of library functions memorized is the biggest difference between average programmers and the so-called 10x programmers. An extremely high level of fluency with a programming language environment is invaluable when it comes to efficiency and code quality. It is analogous to conversing in a language where one has to look up every other word compared to a native speaker who has a deep fluency. It's not just a matter of speed; the depth and quality of thought is orders of magnitude greater in the fluent speaker. The more of the heavy lifting you can do unconsciously, a vastly higher level of output one is able to produce for the same amount of mental effort. We accept this in just about every profession, yet we resist when it comes to programming. Personally, I'm glad my doctor memorizes a large amount of the facts he uses in his day-to-day work.
It is unfortunate that just about every new language brings with it a new set of standard libraries that we must learn to use effectively. We give up so much expertise and efficiency when we don't allow ourselves to build up a high level of familiarity with them. I can imagine a future where there is a standard library of methods that every programmer attempts to memorize and that every new programming language is programmed specifically for this standard library. We are already seeing this with language frameworks like the JVM and .NET, but we need to go even further. Hopefully libraries themselves will be created specifically to be easy to memorize.
The problem is that languages and especially libraries change too frequently. A doctor can learn the name of every bone in the body and that knowledge will for the rest of his life. In programming, there are very few things that will still be the same in 20+ years and we have no idea what those things are. It depends on the field but things can change so much within 2 or 3 years that its just not worth memorizing everything.
The timespan of change doesn't matter; the question, as always, is whether the benefits outweigh the cost.
Now, the cost is approximately <5 minutes per flashcard to give you roughly 95% recall (more details: http://www.gwern.net/Spaced%20repetition#what-to-add ); so the question is, does not knowing something you could've put into a flashcard - the consequences of not knowing it, the time it takes to look it up, whether you will even know to look it up, etc - outweighs the cost of a few minutes' review over that time period.
I think for a lot of stuff this can be true: shell scripting is not going away in 20 years, for example. If you're programming in it routinely, a language you will use for only 10 years can be worth memorizing for a while. If you're using a tool every day for the next year, there's going to be a lot worth memorizing there too.
SRS is well designed for gradually changing bodies of knowledge. New cards are added and come up more often, older cards can be retired but they rarely come up anyway.
Interesting point. I think an analogy that many people can appreciate is that one's knowledge of a language and libraries plays the same role in programming that one's knowledge of mathematics plays when learning physics in school. If you're struggling with the math, you aren't able to devote much thought to the physics you're supposed to be learning. I understood the principle very well in school and always made sure to refresh my knowledge of the required math skills before tackling my physics work, but I haven't applied it to programming as well as I should. Food for thought.
"I personally think the amount of library functions memorized is the biggest difference between average programmers and the so-called 10x programmers."
I don't know, what about the ability to think outside the box, a solid grasp of the fundamentals, or the capability to understand and create high level abstractions?
Seems like you're saying the ability to glue together a bunch of library functions is what classifies a great programmer. If that's the case, it should make programming interview tests rather trivial.
These were my thoughts too - while I agree with the general sentiment of using Spaced Repetition; it also depends on the language you are using. If I find I'm beginning to recognize an abstraction I immediately begin to search for something someone else has already done.
The author of the post used PHP as an example and I think it's a terrible example because PHP's standard library and 3rd party libraries were all over the place in terms of naming conventions, structure, duplicated but not quite abstractions, &c...
I've found learning languages like Haskell to be very different - where learning the axioms and postulates is what leads me to implementation specifics. A good example: I was building accumulating recursive functions for a little project and was looking at the code and said this to myself, "This doesn't feel right, this looks like Scheme or Erlang code - not Haskell."
I set out to find any abstractions built into Haskell or 3rd party libraries that handled accumulators - low and behold folds! I've done that numerous times with this language proceeding from fundamentals and the process of abstraction to find first if the abstraction has already been done!
[EDIT]
I use Spaced Repetition for learning Haskell - but it isn't names of functions; it is the Monad laws, or Functor laws, &c... that I want to memorize.
The point is that the more of the details you have committed to memory, the better your able to "think outside of the box" because your limited cognitive capacity is not bogged down by the minutia. The analogy of fluency in natural language I think is very relevant. The difference in complexity of thought between someone fluent in a language vs someone just learning isn't a matter of intelligence, its a matter of having the building blocks of thought committed to memory. The more of the details that are second nature, the higher level of thought that results. I don't see why this is any different when it comes to programming.
I agree with you and I like your last point. It is indeed a problem that we have many languages and many libraries when many of them do the same thing. One big library to rule them all. Some day we will have that. There will be many algorithms in there, containers, network stack, everything you want and need. And cross platform of course.
What you mention is one more thing to remember when starting on a specific project/team: Which of the possible library functions should you use for a given Task?
> The more of the heavy lifting you can do unconsciously, a vastly higher level of output one is able to produce for the same amount of mental effort.
I agree, but working from the standard library has it backwards. One should subconsciously know what is in principle possible and then look up/remember how it's called in the language you are currently working in, and if it is not there implement it yourself.
But the act of searching and evaluating the results limits your cognitive capacity for building even greater abstractions. If you already have some standard set of implementations memorized that frees up your mind to use those pieces as building blocks for new, grander structures. As you fill your working memory with minutia, the larger abstractions are bumped out which makes it harder or impossible to create new abstractions using the higher level building blocks.
I get the resistance to memorization--I am the laziest SOB I know (and being in the company of programmers, that's no small feat). I got through college almost never taking notes and by just understanding concepts. It worked great for some subjects, namely math, CS, physics, etc. But one thing a math professor said one time in a higher level course for math majors that stuck with me: "If you don't memorize what came before, you will never be able to make new discoveries". In hard math it is expected to memorize the results that came before as this is the only way to discover patterns between them and create new associations.
I think the same applies to programming. Your mind can only hold and manipulate so many units of information at a time. The more abstract those units are, the greater the resulting mental structures will be. We artificially limit ourselves in our resistance to memorization.
The phenomenon you describe is called "chunking".
[1] http://en.wikipedia.org/wiki/Chunking_(psychology)