6 ms·

When learning code out of a book for a new language, one trick I found that worked really well was to read the code, then close the book and try to type as much

When learning code out of a book for a new language, one trick I found that worked really well was to read the code, then close the book and try to type as much of it from memory as I could. I would futz with it for several minutes exploring various ways of making it break, seeing if I could 1) predict how I was breaking it, and 2) use the error messages to fix my mistakes. Then I would open up the book again and compare it to what I had typed, examine the differences between them, and see if/how they explained the errors I was getting.

eru 14y ago
Interesting concept. Especially if you consider that better memory for plausible situations is one of the differentiators between experts and beginners. Be it in programming or chess. Because experts have developed mental shorthands for common situations.
spfoos 14y ago
This is how I learned/am learning Erlang.
- jerf 14y ago
  Reimplementing standard library functions is great for Haskell too. The biggest of the "big breakthrough" experiences I had was from trying to reimplement the standard monadic State datatype.
  - ufo 14y ago
    And then it stackoverflows and you learn that there are actually two standard monadic state datatypes :)
teach 14y ago
I'm a high school computer science teacher, and this is a WONDERFUL idea. I'm totally going to steal it and create a few assignments based on the concept.
- keithpeter 14y ago
  I teach Maths (in the UK), so pinch of salt needed with my suggestion below... Suggestion: code fragment on your interactive whiteboard. Ask students what each line does, how the loop works &c. Then blank the screen and get them to replicate....
  - teach 14y ago
    Good idea but wouldn't work for me since I don't lecture anymore.
- robomartin 14y ago
  Please do teach them the value of data representation. I don't think this is obvious but it can make the difference between having to write a mountain of code or finding a simple solution. Super-simple silly example: You have to write a program to work with four colors: Red, Green, Blue, Black. Naive representation will use strings: "red", "green", "blue", "black". A little smarter would be an enum type where red=0, green=1, blue=2, black=4. And, depending on context, it might even make sense to use individual bits to identify each color: red=01h, green=02h, blue=04h, black=08h. And, if the goal is to extend to other colors, it might make sense to represent them as RGB vectors. You get the idea. I find that a lot of newbie programmers are too focused on the mechanics of writing code. They forget (or don't know) that investing some time in optimizing the representation of the data or problem they are trying to solve could make a world of difference.
  - KPLauritzen 14y ago
    COuld you elaborate a bit on what the benefit of the other representations in your example. I don't get it.
    - robomartin 14y ago
      OK, I pulled colors as an example out of thin air but I'll see if I can make it work. Let's say you have to write a routine that does something based on a color as the input. You have a few choices in terms of how to represent the colors: - The name of the color in a string - A typdef enum for your colors (integers) - A color-per-bit scheme (U8, U16, U32) - Channel-per-bit scheme (U8) - 4 or 6 bit packed RGB values (U16 or U32) - 8 bit packed RGB values (U32) - 8 bit unpacked RGB values (struct of three U8) - 16 or 32 bit unpacked RGB values (struct of three U16 or U32) - Unpacked RGB floats (struct of three floats) - and more... I won't go into the implications of each of the above. Some of it is highly dependent on both the system and the objectives of the work being done. Say, for example, that you choose to use the names of colors stored in strings as your color representation. Now you have to compare strings in order to identify the colors: if(strcmp(input_color, "red") == 0) { // Do something with red } else if (strcmp(input_color, "green") == 0) { // Do something with green } else if (strcmp(input_color, "blue") == 0) { // Do something with blue } ... etc Regardless of language the strings need to be compared character by character. Even if a language or OO framework allows you to say something like if(string1 == string2) you have to keep in mind that what is going on behind the scenes is pretty much exactly what strcmp() has to do. Which means that the above is, at the very least, slow. And, of course, it isn't very portable. What happens if the input has to be in German or Japanese? The typdef enum representation gives you the ability to use a far more efficient construct to identify your colors: switch(color) { case COLOR_RED: // Do something with red break; case COLOR_GREEN: // Do something with green break; case COLOR_BLUE: // Do something with blue break; ... etc This is much, much faster. It is, at the core, an if/else-if structure that is only comparing integers, which is a single machine language instruction. Fast and clean and language-portable by means of the proper text-to-integer function somewhere to deal with different languages. If you are on an embedded system that can do bit testing in machine language it might make sense to encode one color per bit or one color channel per bit. for example, in some embedded C dialects you might be able to do something like this: if(color.0) // Select and test bit 0 { // This is red } else if(color.1) // Select and test bit 1 { // This is green } ... etc At this level the advantages of doing this are tightly linked to the platform and the goals of the application. If, for example, one needs to be able to expand the available range of color inputs beyond what can be described with simple words a discrete RGB representation might be the best choice. This is also the case if you wanted to future-proof the program and be ready for when more colors arrive. Here you have several choices, two of which are to represent each channel with an 8 bit value or choose floats instead. The 8 bit values can be packed nicely into a U32, making it very efficient. You could also create a struct to facilitate access to the components and let the compiler optimize for you. The float example is interesting because the conversion from float to whatever (if necessary) can be of any bit width. So, for example, if the color needs to ultimately be mapped to an 8-bit-per-channel display device you can translate from float to 8 bits on output. All of your intermediate math and color manipulation would be done in full-resolution floats which means that you are not going to accumulate errors. This, for example, is important if you are applying FIR filters to calculate missing color sample data from certain video data formats. Packing has its issues as well. If you are dealing with little-endian vs. big-endian systems there might be overhead associated with unpacking and possibly rearranging a packed RGB value. If you are dealing with processing colors at a massive scale this can have performance and even power consumption implications. I may have been lucky in that my very first CS professor was hell-bent to teach the importance of thinking deeply about data representation BEFORE thinking about code. He'd repeat this mantra 'till you were sick from hearing it. Years later I'd learn to appreciate this bit of wisdom in more ways than one.
sharkweek 14y ago
One thing that has really sped up my my learning over the past few months on Code Academy -- complete a lesson, then in another tab open their scratch pad feature and try to retype the code not only from memory, but also while thinking through the logic. Has really been effective for me as I feel like I now have a pretty good (beginner) grasp on JS and Python
- muratmutlu 14y ago
  I have to try this. Could you code in other languages before doing this?
  - sharkweek 14y ago
    Not really, no -- it's been pleasantly surprising how quickly I've picked it up using the above method though. I highly recommend giving it a shot.
hsitz 14y ago
Another +1. When I've used this method I've noticed that the tendency at first is to try to just remember the code and copy it out of your memory. There comes a point, though, when you don't remember it well enough to "copy from memory" and this naturally segues into a focus on the logic and syntax of the code so you end up reconstructing working code without fully remembering the original.
RegEx 14y ago
This is exactly how I handle learning languages/frameworks. I wrote a little something on it as well [0]. I value thorough comprehension over "how fast can I finish this book?". I try to get my hands as dirty as possible. I want to see the warts of this thing I plan on using to build projects. Trying to rebuild book examples from memory forces you to consider the requirements and the end goal. This was particularly useful when I first learned about linked lists and queues in C. [0]: http://vertstudios.com/blog/how-to-read-programming-tutorial/ http://vertstudios.com/blog/how-to-read-programming-tutorial...
- ashutosh2000 14y ago
  This is really a nice trick!! Thank you for sharing!

eru 14y ago

Interesting concept. Especially if you consider that better memory for plausible situations is one of the differentiators between experts and beginners. Be it in programming or chess. Because experts have developed mental shorthands for common situations.

spfoos 14y ago

This is how I learned/am learning Erlang.

jerf 14y ago
Reimplementing standard library functions is great for Haskell too. The biggest of the "big breakthrough" experiences I had was from trying to reimplement the standard monadic State datatype.
- ufo 14y ago
  And then it stackoverflows and you learn that there are actually two standard monadic state datatypes :)

teach 14y ago

I'm a high school computer science teacher, and this is a WONDERFUL idea. I'm totally going to steal it and create a few assignments based on the concept.

keithpeter 14y ago
I teach Maths (in the UK), so pinch of salt needed with my suggestion below... Suggestion: code fragment on your interactive whiteboard. Ask students what each line does, how the loop works &c. Then blank the screen and get them to replicate....
- teach 14y ago
  Good idea but wouldn't work for me since I don't lecture anymore.
robomartin 14y ago
Please do teach them the value of data representation. I don't think this is obvious but it can make the difference between having to write a mountain of code or finding a simple solution. Super-simple silly example: You have to write a program to work with four colors: Red, Green, Blue, Black. Naive representation will use strings: "red", "green", "blue", "black". A little smarter would be an enum type where red=0, green=1, blue=2, black=4. And, depending on context, it might even make sense to use individual bits to identify each color: red=01h, green=02h, blue=04h, black=08h. And, if the goal is to extend to other colors, it might make sense to represent them as RGB vectors. You get the idea. I find that a lot of newbie programmers are too focused on the mechanics of writing code. They forget (or don't know) that investing some time in optimizing the representation of the data or problem they are trying to solve could make a world of difference.
- KPLauritzen 14y ago
  COuld you elaborate a bit on what the benefit of the other representations in your example. I don't get it.
  - robomartin 14y ago
    OK, I pulled colors as an example out of thin air but I'll see if I can make it work. Let's say you have to write a routine that does something based on a color as the input. You have a few choices in terms of how to represent the colors: - The name of the color in a string - A typdef enum for your colors (integers) - A color-per-bit scheme (U8, U16, U32) - Channel-per-bit scheme (U8) - 4 or 6 bit packed RGB values (U16 or U32) - 8 bit packed RGB values (U32) - 8 bit unpacked RGB values (struct of three U8) - 16 or 32 bit unpacked RGB values (struct of three U16 or U32) - Unpacked RGB floats (struct of three floats) - and more... I won't go into the implications of each of the above. Some of it is highly dependent on both the system and the objectives of the work being done. Say, for example, that you choose to use the names of colors stored in strings as your color representation. Now you have to compare strings in order to identify the colors: if(strcmp(input_color, "red") == 0) { // Do something with red } else if (strcmp(input_color, "green") == 0) { // Do something with green } else if (strcmp(input_color, "blue") == 0) { // Do something with blue } ... etc Regardless of language the strings need to be compared character by character. Even if a language or OO framework allows you to say something like if(string1 == string2) you have to keep in mind that what is going on behind the scenes is pretty much exactly what strcmp() has to do. Which means that the above is, at the very least, slow. And, of course, it isn't very portable. What happens if the input has to be in German or Japanese? The typdef enum representation gives you the ability to use a far more efficient construct to identify your colors: switch(color) { case COLOR_RED: // Do something with red break; case COLOR_GREEN: // Do something with green break; case COLOR_BLUE: // Do something with blue break; ... etc This is much, much faster. It is, at the core, an if/else-if structure that is only comparing integers, which is a single machine language instruction. Fast and clean and language-portable by means of the proper text-to-integer function somewhere to deal with different languages. If you are on an embedded system that can do bit testing in machine language it might make sense to encode one color per bit or one color channel per bit. for example, in some embedded C dialects you might be able to do something like this: if(color.0) // Select and test bit 0 { // This is red } else if(color.1) // Select and test bit 1 { // This is green } ... etc At this level the advantages of doing this are tightly linked to the platform and the goals of the application. If, for example, one needs to be able to expand the available range of color inputs beyond what can be described with simple words a discrete RGB representation might be the best choice. This is also the case if you wanted to future-proof the program and be ready for when more colors arrive. Here you have several choices, two of which are to represent each channel with an 8 bit value or choose floats instead. The 8 bit values can be packed nicely into a U32, making it very efficient. You could also create a struct to facilitate access to the components and let the compiler optimize for you. The float example is interesting because the conversion from float to whatever (if necessary) can be of any bit width. So, for example, if the color needs to ultimately be mapped to an 8-bit-per-channel display device you can translate from float to 8 bits on output. All of your intermediate math and color manipulation would be done in full-resolution floats which means that you are not going to accumulate errors. This, for example, is important if you are applying FIR filters to calculate missing color sample data from certain video data formats. Packing has its issues as well. If you are dealing with little-endian vs. big-endian systems there might be overhead associated with unpacking and possibly rearranging a packed RGB value. If you are dealing with processing colors at a massive scale this can have performance and even power consumption implications. I may have been lucky in that my very first CS professor was hell-bent to teach the importance of thinking deeply about data representation BEFORE thinking about code. He'd repeat this mantra 'till you were sick from hearing it. Years later I'd learn to appreciate this bit of wisdom in more ways than one.

sharkweek 14y ago

One thing that has really sped up my my learning over the past few months on Code Academy -- complete a lesson, then in another tab open their scratch pad feature and try to retype the code not only from memory, but also while thinking through the logic. Has really been effective for me as I feel like I now have a pretty good (beginner) grasp on JS and Python

muratmutlu 14y ago
I have to try this. Could you code in other languages before doing this?
- sharkweek 14y ago
  Not really, no -- it's been pleasantly surprising how quickly I've picked it up using the above method though. I highly recommend giving it a shot.

hsitz 14y ago

Another +1. When I've used this method I've noticed that the tendency at first is to try to just remember the code and copy it out of your memory. There comes a point, though, when you don't remember it well enough to "copy from memory" and this naturally segues into a focus on the logic and syntax of the code so you end up reconstructing working code without fully remembering the original.

RegEx 14y ago

This is exactly how I handle learning languages/frameworks. I wrote a little something on it as well [0]. I value thorough comprehension over "how fast can I finish this book?". I try to get my hands as dirty as possible. I want to see the warts of this thing I plan on using to build projects. Trying to rebuild book examples from memory forces you to consider the requirements and the end goal. This was particularly useful when I first learned about linked lists and queues in C. [0]: http://vertstudios.com/blog/how-to-read-programming-tutorial/ http://vertstudios.com/blog/how-to-read-programming-tutorial...

ashutosh2000 14y ago
This is really a nice trick!! Thank you for sharing!