Tuesday, June 05, 2018

Programming Projects–The good, the bad, and the ugly

End of the semester project time for me. All of my programming students have been finishing up[ their self-selected projects and I have been grading. It’s always an interesting ex3ercise. None of the students have much experience designing and writing programs. One thing that is clear is that they don’t always spend enough time planning before they start.

Students often seem to think in small steps without thinking about what steps will follow. Sometimes this results in user interfaces that look great and are fairly sophisticated. Unfortunately, they often haven’t thought about how to implement more of the code behind the user interface. Other times they do think further but not far enough. In either case they run into road blocks because the initial design is just not complete. As ugly as these designs can get it is interesting and challenging to try to develop workaround for them. I’ve learned a few tricks over the years. I only wish we had time to restart from scratch and redesign the programs.

Some of the mort popular projects are easy enough to design and code but can be tedious with the limited background in programming the students have. These designs require a lot of code. That takes time to write and to debug but is usually manageable. What concerns me this year is the number of my advanced students who don’t use language or features that they have taught and should know to use that they don’t use.

No matter how many times I tell students that a list of variables that are differentiated only by a number should probably be an array some students take what they think is a short cut. They are almost always wrong about that. I’ve got  to work on that next year.

On the plus side, some of my students take it upon themselves to learn features, methods, and functions that we don’t have time to cover in class. this year students found a couple I didn’t know about. Modern programming libraries have far too many features for anyone to know all of them. Some of these features will get covered next year as they are more efficient than what I have been using. Others I have to think about how or if I cover them. Sometimes features make things easier for programming but harder for a teacher to instill an understanding of concepts.

Students seems to learn a lot from this end of semester projects. That is great. It’s a real plus when I can learn things from them as well.

1 comment:

Garth said...

One of my very first "Good Ideas" for a programming project for one of my classes was a Battleship game program. You know, the old graph paper grid game. Easy game concept-wise. Not so easy implementation-wise. This is one of the many times that reinforced the idea that the Good Idea Fairy in not a nice entity. Concept to implementation takes so much more than just a half-way decent idea of coding syntax. Having the kids plan and design before they sit in from of a computer is very difficult. It would be nice to be able to have the time so they could learn from their mistakes. Kids (and teachers) want to code and get something to happen on the computer. They do not want to sit and think about how what ever they are building is going to work. Nuts on that, let's just wing it and try trial and error for a few days. One of my favorite phrases is "Two hours of coding will save 15 minutes of planning."