Skip to main content
corrected spelling
Source Link
Meower68
  • 261
  • 1
  • 4

I tend to think that CS education should be done in multiple stages (to be repeated as the students progress in skill):

  1. teach them theory
  2. show them good code
    • as an example
  3. have them write code
    • it's implied that they will need to do SOME debugging to "evolve" their code to a working state
  4. have them debug others' not-so-good code

Start with the theory. Once they start to understand that, show them good examples. Many folks learn well by example; this helps them "solidify" their understanding of the theory and gives them some idea of how it SHOULD look / work. Then, get them writing code; no amount of theory and example can replace this. After all that, startingstart showing them some not-so-good code to debug and clean up.

Remember the famous quote by Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Tackling complex debugging, when they haven't developed enough skill yet, will be overly-challenging. Let them build some proficiency THEN start building the debugging skills.

I would agree that good debugging skills are critical. A quote from Maurice Wilkes:

By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below. [...] It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

I wish I could say that my career was different. The only difference is that much of the code I maintain is written by others. A good part of the remainder of MY life will be spent finding errors in my own programs AND those of others.

Once they've developed good debugging skills on one "level" of programming complexity, repeat the cycle for the next level. Consider debugging skills the "boss challenge" before they've "leveled up" and are ready for the next skill level.

I tend to think that CS education should be done in multiple stages (to be repeated as the students progress in skill):

  1. teach them theory
  2. show them good code
    • as an example
  3. have them write code
    • it's implied that they will need to do SOME debugging to "evolve" their code to a working state
  4. have them debug others' not-so-good code

Start with the theory. Once they start to understand that, show them good examples. Many folks learn well by example; this helps them "solidify" their understanding of the theory and gives them some idea of how it SHOULD look / work. Then, get them writing code; no amount of theory and example can replace this. After all that, starting showing them some not-so-good code to debug and clean up.

Remember the famous quote by Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Tackling complex debugging, when they haven't developed enough skill yet, will be overly-challenging. Let them build some proficiency THEN start building the debugging skills.

I would agree that good debugging skills are critical. A quote from Maurice Wilkes:

By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below. [...] It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

I wish I could say that my career was different. The only difference is that much of the code I maintain is written by others. A good part of the remainder of MY life will be spent finding errors in my own programs AND those of others.

Once they've developed good debugging skills on one "level" of programming complexity, repeat the cycle for the next level. Consider debugging skills the "boss challenge" before they've "leveled up" and are ready for the next skill level.

I tend to think that CS education should be done in multiple stages (to be repeated as the students progress in skill):

  1. teach them theory
  2. show them good code
    • as an example
  3. have them write code
    • it's implied that they will need to do SOME debugging to "evolve" their code to a working state
  4. have them debug others' not-so-good code

Start with the theory. Once they start to understand that, show them good examples. Many folks learn well by example; this helps them "solidify" their understanding of the theory and gives them some idea of how it SHOULD look / work. Then, get them writing code; no amount of theory and example can replace this. After all that, start showing them some not-so-good code to debug and clean up.

Remember the famous quote by Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Tackling complex debugging, when they haven't developed enough skill yet, will be overly-challenging. Let them build some proficiency THEN start building the debugging skills.

I would agree that good debugging skills are critical. A quote from Maurice Wilkes:

By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below. [...] It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

I wish I could say that my career was different. The only difference is that much of the code I maintain is written by others. A good part of the remainder of MY life will be spent finding errors in my own programs AND those of others.

Once they've developed good debugging skills on one "level" of programming complexity, repeat the cycle for the next level. Consider debugging skills the "boss challenge" before they've "leveled up" and are ready for the next skill level.

Source Link
Meower68
  • 261
  • 1
  • 4

I tend to think that CS education should be done in multiple stages (to be repeated as the students progress in skill):

  1. teach them theory
  2. show them good code
    • as an example
  3. have them write code
    • it's implied that they will need to do SOME debugging to "evolve" their code to a working state
  4. have them debug others' not-so-good code

Start with the theory. Once they start to understand that, show them good examples. Many folks learn well by example; this helps them "solidify" their understanding of the theory and gives them some idea of how it SHOULD look / work. Then, get them writing code; no amount of theory and example can replace this. After all that, starting showing them some not-so-good code to debug and clean up.

Remember the famous quote by Brian Kernighan:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Tackling complex debugging, when they haven't developed enough skill yet, will be overly-challenging. Let them build some proficiency THEN start building the debugging skills.

I would agree that good debugging skills are critical. A quote from Maurice Wilkes:

By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below. [...] It was on one of my journeys between the EDSAC room and the punching equipment that "hesitating at the angles of stairs" the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

I wish I could say that my career was different. The only difference is that much of the code I maintain is written by others. A good part of the remainder of MY life will be spent finding errors in my own programs AND those of others.

Once they've developed good debugging skills on one "level" of programming complexity, repeat the cycle for the next level. Consider debugging skills the "boss challenge" before they've "leveled up" and are ready for the next skill level.