3 ms·

Except that it's far more common for people to believe it and thus ask silly questions that attempt to ascertain the degree to which one has drilled themselves

Except that it's far more common for people to believe it and thus ask silly questions that attempt to ascertain the degree to which one has drilled themselves in said rote memorisation. Like a google interview I had a few years ago where they asked me what the number of blocks in an ext2 filesystem for a specific distribution of Linux was at the time. The irony of being asked this by a company who actually would've featured prominently in my answer (ie, just google it) was not lost on me, and it disabused me of the notion that I'd actually like to work there after all.

jquery 17y ago
Specialization is not equivalent to rote memorization. But rote memorization is a bedrock foundation for almost any specialty, because it is the very language of that specialty. The more fluent you are in a given language, the more easily you can write beautiful prose with it.
- etherael 17y ago
  They often go together, as you illustrate well with your comment, I agree that rote memorisation can be a bedrock foundation for any specialty, however it is not necessarily the only foundation. And the thread of my argument here is that it is not as good a foundation as a complete understanding of many topics in an interwoven fashion. An attempt at an analogy; I assume you're familiar with jQuery as that's your nickname so I'll use that. One could memorise every single API method and syntactical quirk of the framework and be rightfully considered a specialist, but this does not innately suggest that they understand the absolute multitude of concepts that are likely to be bought together in a project making use of this specialty, or how the fabric of a jQuery object might be incorporated into a larger project using a full polyglot of development languages and spanning JRuby, Java, Groovy, Scheme, Scala etc. Knowing the underlying concepts that unite them gives a person the ability to solve problems in any one specific area potentially better than someone who had simply memorised all the API documentation for the jQuery framework. Going through the rote memorisation of all these disparate things you're likely to eventually notice the patterns and ideas that they share, but in my opinion this is a backward way of doing things. Starting with patterns and ideas and fleshing out the specifics with reference documentation on a case by case basis has always been my preferred approach, it's much easier to find a base pattern and go through it's iterations than it is to simply memorise all the potential iterations of a given pattern. How easy is it to memorise a table of results on several thousand experiments demonstrating F=ma compared to simply applying F=ma several thousand times? Even more so with something that moves as fast as development; when the framework changes and your memorised documentation needs to be updated, it is much easier to understand the change from the perspective of cause and effect rather than just "here's how it was including all edge cases and implications, and here's how it is now, including all edge cases and implications."
  - jquery 17y ago
    I completely agree. In fact, this is why physician specialists are required to perform basic clinical duty in many different specialties before diving deeper into their primary specialty (I hope a physician will correct me if I am wrong). The manner of specialization also depends on the field. In programming we have the luxury of time and a search engine, so knowing basic concepts are more important than API details. A surgeon has no such luxury--your heart transplant specialist had better know everything down cold.
    - Retric 17y ago
      Surgeons often lookup how to do a surgery, and even call people for advice before they start. For complex problems they can spend hours or days deciding how to approach a complex problem using 3d images before they start. Now there are a lot of rote skills involved with fixing problems as they show up but normally they have plenty of time to prepare ahead of time and several people to assist them. Granted, when someone shows up in the ER with a gunshot wound they don't have the time, but that's hack and slash medicine where the goal to keep the patent alive for the next few hours so they can get time to deal with any major problems.
- Retric 17y ago
  It would take me a long time to dig up the number of language and dialects I have used, and yet I don't really know half of them. I have several times helped someone solve a problem in a language I did not know by looking at the code and saying ok it's X. And this is not just decedents of C. I have solved a problem someone with 30 years of embedded coding solve a problem he was having in an assembly language I can't even remember the name of. I might not be a true Master, but I can tell learning the inner workings of an API that's only lasts for 10 years is not the way to get there. ASM, C, LISP, and SQL are far more important than Rails. PS: I am all for Memorizing constants but API's are a dime a dozen. One of the few masters I have seen rewrote a system ~90% from scratch in 3 weeks in a language he had never seen that a well respected team was unable to finish in a year. Edit: Focus on the things that let you do a month long task in a a few days not a hour long task in minutes because the little short cuts are easily found when you need them but the big stuff is far harder to stumble upon when you need it.

jquery 17y ago

Specialization is not equivalent to rote memorization. But rote memorization is a bedrock foundation for almost any specialty, because it is the very language of that specialty. The more fluent you are in a given language, the more easily you can write beautiful prose with it.

etherael 17y ago
They often go together, as you illustrate well with your comment, I agree that rote memorisation can be a bedrock foundation for any specialty, however it is not necessarily the only foundation. And the thread of my argument here is that it is not as good a foundation as a complete understanding of many topics in an interwoven fashion. An attempt at an analogy; I assume you're familiar with jQuery as that's your nickname so I'll use that. One could memorise every single API method and syntactical quirk of the framework and be rightfully considered a specialist, but this does not innately suggest that they understand the absolute multitude of concepts that are likely to be bought together in a project making use of this specialty, or how the fabric of a jQuery object might be incorporated into a larger project using a full polyglot of development languages and spanning JRuby, Java, Groovy, Scheme, Scala etc. Knowing the underlying concepts that unite them gives a person the ability to solve problems in any one specific area potentially better than someone who had simply memorised all the API documentation for the jQuery framework. Going through the rote memorisation of all these disparate things you're likely to eventually notice the patterns and ideas that they share, but in my opinion this is a backward way of doing things. Starting with patterns and ideas and fleshing out the specifics with reference documentation on a case by case basis has always been my preferred approach, it's much easier to find a base pattern and go through it's iterations than it is to simply memorise all the potential iterations of a given pattern. How easy is it to memorise a table of results on several thousand experiments demonstrating F=ma compared to simply applying F=ma several thousand times? Even more so with something that moves as fast as development; when the framework changes and your memorised documentation needs to be updated, it is much easier to understand the change from the perspective of cause and effect rather than just "here's how it was including all edge cases and implications, and here's how it is now, including all edge cases and implications."
- jquery 17y ago
  I completely agree. In fact, this is why physician specialists are required to perform basic clinical duty in many different specialties before diving deeper into their primary specialty (I hope a physician will correct me if I am wrong). The manner of specialization also depends on the field. In programming we have the luxury of time and a search engine, so knowing basic concepts are more important than API details. A surgeon has no such luxury--your heart transplant specialist had better know everything down cold.
  - Retric 17y ago
    Surgeons often lookup how to do a surgery, and even call people for advice before they start. For complex problems they can spend hours or days deciding how to approach a complex problem using 3d images before they start. Now there are a lot of rote skills involved with fixing problems as they show up but normally they have plenty of time to prepare ahead of time and several people to assist them. Granted, when someone shows up in the ER with a gunshot wound they don't have the time, but that's hack and slash medicine where the goal to keep the patent alive for the next few hours so they can get time to deal with any major problems.
Retric 17y ago
It would take me a long time to dig up the number of language and dialects I have used, and yet I don't really know half of them. I have several times helped someone solve a problem in a language I did not know by looking at the code and saying ok it's X. And this is not just decedents of C. I have solved a problem someone with 30 years of embedded coding solve a problem he was having in an assembly language I can't even remember the name of. I might not be a true Master, but I can tell learning the inner workings of an API that's only lasts for 10 years is not the way to get there. ASM, C, LISP, and SQL are far more important than Rails. PS: I am all for Memorizing constants but API's are a dime a dozen. One of the few masters I have seen rewrote a system ~90% from scratch in 3 weeks in a language he had never seen that a well respected team was unable to finish in a year. Edit: Focus on the things that let you do a month long task in a a few days not a hour long task in minutes because the little short cuts are easily found when you need them but the big stuff is far harder to stumble upon when you need it.