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.
Ignoring warnings
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?
7 comments:
Speaking as a professional programmer (among other things), we use code we don't understand all the time. In fact, if you use an application framework such as Cocoa, you never know for sure what is going on inside the code because they don't tell you. Same with libraries.
I often copy code from elsewhere and use it. Many times, I don't even want to know how it works, as long as it gets the job done.
There is a big difference between calling an API or using a method from a library and cutting code from inside one. Such code is intended to be used as a black box but even them a solid understanding of the inputs and outputs is critical.
I don't cut and paste code without really understanding how it works. Too risky for me. But then I have only been programming professionally for 40 years so maybe when I have some experience I'll feel differently.
Gordon: There is a slight difference when you talk about the use of libraries. With a library you can and should be evaluating its stability, health, and community. You certainly have a point if you're using some random library on github, but there are people (perhaps not yourself) looking at the quality and function of Cocoa and other heavily used libraries & frameworks. Copying code you don't understand directly into your source however is very concerning, because you are assuming responsibility for function and maintenance.
Alfred: But starting from scratch is so much fun! Who hasn't wanted to make a better wheel (Shark Wheel's square-shaped skateboard wheels for example).
I think the original statements were good, especially for students. There are a lot of pitfalls in programming. For example, an "if" followed by another "if", then an "else" which was un-indented and intended to go with the first "if", but, of course, doesn't. C++ ctors and dtors have a lot of "gotchas" when you try calling methods which are overrides.
Warnings are good, but some warnings are stupid. I took Apple, Inc to task for "&&" within "||". I said, what next? "*" within "+"? If someone doesn't know "and" has precedence over "or", they shouldn't be programming.
Gordon: We are also just trying to get the fundamental concepts down to our students as the learn how to code. Certainly after they "get it", using existing code is fine in some cases. I know as a teacher, I tell the kids (at the intro level), you can only copy/paste something you've written yourself.
Strategies for teaching kids not to do these or “this is how I kinda, sorta try to get the kids to not do what I do all the time”.
1. Copy-paste – require comments in the code. If they cannot comment it then they cannot understand it. The drawback is comments can get a bit excessive which is OK by me. It makes it so much easier to grade and troubleshoot the kids programs if there are lots of comments. I live by copy and paste but I spend the time to figure out the code because I am trying to learn as I code. I try to give the kids the same incentive but they are kids and are quite not into learning for learning sake as us geek programming teachers.
2. I actually like the kids to start from scratch each time simply for the practice of starting from scratch. The old drill and practice sort of thing. But I teach them how to avoid this time consuming approach. I teach some very simple skills to help.
a. Save all your old stuff and keep it organized.
b. Have a good name for your program so you can remember what it does.
c. Save versions. They hate doing this for some reason.
d. Use functions, modules, subroutines, subprocedures, methods or whatever you want to call them. Then all they have to do is remember they built them.
3. Google is your friend but think first and avoid error #1. It is not necessary to reinvent the wheel but you better know how that wheel works. And besides, whoever posted that wheel on the internet might be on training wheels themselves.
4. I do not have this problem. None of the languages I teach with gives gentle warnings. The program just dies in an ugly manner.
5. This is the hardest one to teach around for me. This why I try to grade on progress and method, not results. I could really care less if a kids code works if he has spent time designing and researching. A kid that has tried several difference strategies to his program to get something refined is going to get a better grade from me than a kid that has hacked something together that works. But this involves watching the kids code in a classroom.
The most important teaching strategy to avoid these errors, and about a dozen others, is to program away from the computer and type code at the computer. I am terrible at doing this and teaching this. I love to program at the computer on the fly. It is a challenge to my masculinity. Then again, maybe not. It is just fun that way. The kids want to try things on the computer instead of thinking and planning. Someday I will figure out how to teach the kids to plan without being at the computer in a way they will actually do it. I will then publish a book, shake the President's hand and retire happy.
I'm not a teacher, just a PhD Electrical Engineer (Purdue) after a career at Bell Labs and TRW. I lurk in these forums because I have spent years developing a presentation system for instructors to use in the classroom and simultaneously capture for the web. I got sick of watching presentations, by so called media experts, which were so graphically poor and painful to watch that I was convinced I could do much better.
iQPresenter (available RSN) integrates sophisticated graphics, text, movies, etc. with annotations, attention directors, chalkboards, and multiple live video inputs, even from wireless iOS devices. It's feature rich with everything contained in a database, including a components library.
I have thought about teaching at a local college, maybe, C, C++, Objective C, Cocoa, math classes, etc. I didn't mean this to sound like a commercial, but to explain my interest.
Post a Comment