Recently Mark Guzdial had a post called High school CS teachers need to read and trace code, not develop software that got me thinking along some new lines. Working with students on their final projects and some other online reading lately has me thinking even more about what is involved in becoming a real developer of software. Some claim that once you write your first code you are a software developer. Seems a stretch to me. I’ve replaced a few pipes and made minor plumbing repairs but that doesn’t make me a plumber by any means.
As a teacher with limited time for teaching I can teach only so much. I teach some important concepts that software developers need to know for sure. Loops, decisions, variables, and the general basics. Students can write simple programs with what we cover even in a short part of a semester that we dedicate to that in our first course. That doesn’t make them developers though. Not in a real sense that means someone should hire them to write code.
Developing software is more than just writing code. It means writing code well. Let me jump back to plumbing for a minute.
I replaced an l joint under my bathroom sink. It sort of worked by which I mean it only leaked a little. I knew the basics but my implementation left something to be desired. I hired a real plumber to fix that and some other work that, thankfully I knew were beyond my skill, and there was quite a difference. No leaks for one thing. For an other thing it all looks nice and neat and clean. My depth of knowledge was not enough to do a professional job.
This is also true with programming. I printed out a student program to play a game called lights out (instructions at the bottom of this post). It went on for about 20+ pages. The version I wrote too barely 2 pages. Why the difference? Experience mostly. There was nothing in my code syntactically that the student hadn’t learned. But the experience to look at a problem and see that there are different ways of doing things was not there for the student. Students took days and days to complete their Lights Out games. It took me a bit over an hour. That’s not a brag. It’s what happens when you have decades of experience.
When I looked at that program it screamed two dimensional array with “buffer” items around the edge to simplify operations. I’ve seen that sort of thing many times over the years. I see a group of items while a beginner generally sees 25 individual items that have to be handled individually. Could I have taught what I did to students? Of course. Should I have? Probably not with the time I had and the priorities for what needed to be taught in the time available.
In fact for each of the projects my students selected for their end of year projects (there were quite a variety of them) there is probably a technique that would have helped them create a more efficient and better running program. They could probably have saved time as well. But I didn’t have the weeks it would have taken to cover all those techniques.
What do we want to cover in a first programming course? The basic concepts of course. We want students to understand loops, decision structures, data storage, and the logical thinking behind all of this. That is computer science – at least a small subset of computer science. We’re not making them software developers though. Not by a long shot.
3. Lights Out – The game starts with 25 red buttons arranged in 5x5 grid. Each button pressed toggles itself and the four buttons around it (above, below, to the right, and to the left) between green and red. The object of the game is to get all 25 buttons green.