Programming: What they don't teach in school

Much has already been written about how much High School computer science teaching sucks ( High school computer science education ). As a student who has just left high school I just wanted to present my 2 cents on how bad the seperation between RealWorld programming and ClassRoom programming is. A common rebuttal is that there isn't enough time. I agree there isn't, but half-baked knowledge is dangerous. If you teach something, teach it qualitatively, not quantitatively.

The Problems

Tool Power

A programmer is only as good as his tools, and how well he can use them. But schools generally lock down students to a specific ( often crappy ) tool. For example, we've Turbo C++ 3.0 ( 1992 ) on all computers. That is a 16 year old environment, supporting 16 year old standards. That's bad! In the days of Linux and Wikipedia do you really want kids raised on old proprietary standards. The ICSE board is very good atleast in their terms. They say that any Operating System ( why are we still on Windows ) with a latest C++ compiler should be used. It seems our school isn't listening.

If you are on Java, you probably have BlueJ. Now I've nothing against the BlueJ folks, but hiding all the compilation details from the student is denying knowledge. Students ( especially the ones who got into CS just for fun ) are of course happy that they don't muck around with "hard" stuff. But thats not how things work in the RealWorld. You should know how to use the command line, invoke javac and java. And, fricking, you should know that Java files have a .java extension and .class is the compiled byte code.

Another issue is shortcuts, quick search and replace, commenting. Kids don't know any of these things. It's type, click, type. Click Save. Click Compile. And to change something there is always manual replace.

File Management

Typical high school level programs, if well written, are never longer than 2 pages. They are often crappy, in the fact that the logic is repetitive, their is no purpose to the program and that students still don't get it!

So when it's project time, what the instructor gets is a dump of humongous shit, often with all the code in main, bad indentation and no comments. That's because the instructor hasn't taught the kids anything about decoupling programs, and seperating classes in files, and using header files. Often the instructor himself has no idea about build systems.

Bad Core Concepts

One really bad thing I see among my fellow students, is the complete inability to realise that each statement is an individual component. It evaluates to something, and other statements can use that value to do their job. This causes repetitive coding. To illustrate see this code sample.

function isSpam(email) {
 if(email.contains('$$$'))
     return true;
 else
     return false;
}

Students aren't taught that email.contains is returning true or false, and all we care about is true and false. They are never taught to see function documentation, just use it the way the instructor tells them too. This code can be simplified to the following, because email.contains is already doing what we want it to do, why decorate it?

Beautiful Code: Of Readability

Bad indenting. Student code is full of bad indenting. Instructor code is full of bad indenting.

Learn to appreciate code people. It's just as much art as painting or poetry. Encourage right indentation, make liberal use of whitespace, clean up your logic, don't nest too much. You should be able to go back to it after a few months and not have to spend time just cleaning it up.

Follow standard conventions for variable names, make sure your method names and parameter names make sense. Use camelCase or _underscores_. Make booleans start with 'is' or simply the condition you're representing. If any variable has more purpose than a loop counter or a position marker, it should have a meaningful name.

Name your files meaningfully, keep it lowercase, and keep all your fake 31337 ness to yourself.

Type for today, Think for tomorrow

It's a matter of thinking for 3 hours, writing 3 minutes worth of elegant code, versus thinking for 3 minutes, spending 3 hours typing up code.

-- Compsci.ca

The post above also mentions some of the crap I've mentioned here, like the 4600 line Sudoku.
Student code is littered with conditionals highly specific. The very reason you're using a high level language is to avoid this. I've seen quiz programs where each question and its answer is in an if clause, embedded in the program! Cardinal sin. Use a file and parse the file, if you can't do that, atleast put all the questions and answers in two arrays ( don't tell me about maps ). Then you can just use a loop to pick out the question and its right answer.

Make your code extensible. Just because this is some dumb program which you're writing in school, doesn't mean it should be a waste of muscle energy, disk space and time.

If you have to choose day's of the week, put them in an array. You want to find out the number of days in a month, use a 12 element array. Or better yet, use your brain a bit more and write this:

It might seem like more code, but you can write this code once and use it anywhere. And you are using your brain.

Solutions

Use better languages

Far too many schools have jumped on the Java bandwagon. If you are teaching kids who don't have much programming experience start with a higher level, small language. Use Python. You should be able to finish explaining most of the language within a week. Besides the interactive interpreter is great for messing around to know exactly how something works, how to make it go wrong and where it can fail. You will also spare them from the compile cycle ( I know, it kind of contradicts my first problem :p ), allowing them instant gratification. Spare them the brackets and let them develop the logic. Logic is far more important than syntax. Syntax changes, but logic is immortal.

Real World Knowledge

Once in a while just stop the programming, and discuss technology related issues, latest news, ethical considerations. Anything which expands their minds and gets them more interested in computers. There are more than enough anecdotes and quotes about programming, use them. Instructors should stay on top of news stories. You don't have to know what monads are, but at least know what Linux is. One of my instructors had never heard of Opera and Mozilla ?!? Whatever language you are teaching, make sure you know it well. The same instructor above didn't know that the Java GUI framework is called Swing. Make sure you are aware of atleast major upgrades and integrate them.

The Open Source ecosystem is set to flourish. Make sure your students are aware of what it is. Encourage them to try out FLOSS. If you can't convert to Linux, atleast use open source compilers, tools and languages on your Windows machines. Set aside a computer where you can mess with distros.

Encourage frequent group projects. Let the kids make plans. Tell them how to go about design. Make sure its extensible and adaptable. If the project will need something more than what is taught, tell them to read about it, while you do too.

Good Reading

I don't know about the rest of the world, but in India, Computer Science textbooks for high school are crap. They are full of errors, bad practices, incorrect language, and often old software. There are hundreds of better quality books available online, often royalty free. There is Wikipedia and Wikibooks. While using them, remember to tell your students how cool the Internet is, and teach them about sharing.

Mark for the big picture

There is this huge emphasis on theory at the high school level, mostly due to lack of time for practical assessment. Which means students have to often write programs and submit them without testing. In such situations, don't cut marks for syntax errors, unless they mess up the logic ( missing braces ). The compiler/interpreter is going to catch them anyway. As long as the program works correctly logically, missing semicolons are OK.

Rank readability above extensibility, extensibility above just-getting-it-done. If a student has used some cool logic, or exploited the specifications, give him some appreciation. After all programming is all about getting the best out of constraints, and pushing the limits. If he/she has looked to optimize, that's good too.

Don't hand hold

Far too many instructors help students fix their errors. Don't help them fix the errors, help them understand what the error is. Any decent language is quite verbose at error reporting, and in case of languages which support exceptions, the class name is often a very good indicator. Any decent compiler also reports line numbers. Let them fix the problem for themselves. Time well used now, is time saved later. Tell them it's called debugging.

Create some passion

Kate Masukomi sums it up nicely. Most programmers today are doing it to pay the bills. Don't let your students be one of them. If someone just doesn't seem to have any aptitude, maybe he should look into some other field. Encourage the good ones to expand out of the syllabus, mess with different languages and read sites like Proggit. Tell them to blog and learn HTML/CSS and create their own site. Don't create hundreds of typists, the world would prefer fifty real programmers ( thanks to lankythoughts for the link! ).

Conclusion

If something isn't done quickly, the IT world will be in a mess. Already the lack of real talent is leading to a shortage of employees. According to me, the only real coders are the people who are up breast with new developments and technologies. They don't have to know how everything works, but they should know that it exists. That's passion. They are the ones who read blogs, write them, comment on articles, are always hacking on side projects and have commits on some open source project. Make your students a part of that group.

P.S. Forgive my immodesty in certain areas :)