I like posts like 5 Programming Mistakes You Should Stop Making by Rahul Singh because they help me focus my thoughts. Through the summer I am working on planning out my teaching for the new school year and this post reminds me of many of the beginner mistakes that students tend towards. I recommend the whole put but I’m also going to give my take on these “5 mistakes” in the particular case of student developers.
Copy-pasting code without understanding it
Reusing code is a great thing but it is risky business if one doesn’t really understand what the code is doing and why. Side effects are only one risk but it gets a lot of people. More often than not though the code doesn’t do exactly what a student expects. It may be close. In other cases the inputs are not what a student has/needs/wants. Borrowing code without understanding it often leads to more work rather than less. And then when the teacher/grader asks a student to explain it it all starts to look a bit too much like cheating.
Starting from scratch every time
This one bites a lot of students on the APCS exam. Students are asked to write a method in one part of a question and then use it in the second or later part of the question. Too often students rewrite the method rather than just calling it. Errors are bound to creep in this way. During the school year I see the same thing where a bit of code from a previous project could easily be used but a student writes it all from scratch. This seldom ends well. Properly written, tested (and in school graded with suggestions for improvement) code can save a student a lot of time and heartache.
Searching Google/Bing without trying yourself
Students often think of search engines as a quick way to get an answer without thinking much. This causes them to completely miss the opportunity to learn from the lectures and demonstrations they have had in class. The process of taking what one already knows (or has heard in class) and building on that to discover knowledge though their own work is a real missed opportunity.
I know experienced programmers who occasionally ignore warnings. Often times this is because they know from previous experience that in that particular case they can get away with it. Even then it is not really a good idea. For students it is never a good idea to ignore warnings. A warning means that something is not quite right. It may not signal a hard coding error but it is very likely to signal a logic error. Warnings are a clue and they should be looked at very carefully. It is easy to ignore a warning if things seem to be ok but down the road there is likely to be a case where serious trouble will result.
Making Quick fixes instead of Permanent ones
Oh boy have I seen this one. Especially from boys in a hurry. Throw in a semi colon somewhere/anywhere and see the code compile. That is the ultimate quick fix but it never lasts. Add in some hard coded numbers – just for now – and never get back to replace them with constants. Students do a lot of things to just get it working for now without giving thought to long term concepts like maintainability and enhancability. It’s easy to write that off with “its just a school project and I’ll never touch it again.” The risk there is that this builds bad habits that are hard to break later on.
I’ll be talking about these things with my students this year. Weaving them into the conversation (again and again) if hope of building good habits and critical thinking. How about you?