Writing Software is Writing

I realize that this probably seems more self-evident than revelatory. However, as I reflect back on this last (first for me) semester of teaching software development, I don’t think I treated it this way at all.

Our daily structure when we started this subject looked something like this:
Me: Introduce / Review some concepts
They: Use those concepts in some kind of (small) coding exercise

We would then periodically chain these concepts together into something somewhat more complex.

So far, so good. This seemed to work as far as understanding the concepts and syntax went and aligned well with my goal of getting students doing actual coding as soon as possible. The problem showed up when we tried to take the next jump forward and work on individual projects.

We started strong. Each student chose a fairly simple (at least superficially) game that they were already familiar with and created some wireframe sketches of the interface they would need. This went very well. When we moved on to the more abstract work of creating class diagrams, however, the cracks started to show.

Most were able to come up with one or two classes they would need, but it was obvious that they didn’t have a clear picture in their mind of what they were going to need to create. This would have been a good place to hit the pause button for a few days. Instead we moved on to creating the actual code and this is where things pretty much stalled out for a time.

At first I wasn’t too concerned. There is a natural amount of not-knowing how to do things and associated frustration that you just have to learn to roll with in this field. After offering only slight assistance for a few days, I realized that students were clumping into four main groups:

1. The few (10-15%) who knew where they were going.

2. A similar number who had dramatically scaled back their project plan (ie. a minimal console interface instead of a graphical interface, single player instead of multi-player, etc.)

3. 40-50% who had found (or more frequently had ChatGPT create) the basic framework for their code. This was not against our rules. I was very curious to see if what they found would be accurate enough and if they would have the skills to extrapolate that code into their projects. More on that in a minute.

4. About 20% who had quietly given up. They were giving the appearance of working for the most part, but were basically just idling.

The first two groups I wasn’t overly concerned about. While encouraging those in the second group to stay open to new things they could implement as they had time, scaling back is a reasonable strategy. Those in the fourth group were stuck because they didn’t even know where to start, so working one on one with them was enough to get them moving. The third, and largest group was a little more complicated.

My hope in allowing students to generate project code with ChatGPT was that it would be insufficient for the task, forcing them to dig through the code and find and fix things. In my experience this is often more difficult than just writing something from scratch. What I found was that even ChatGPT 3.5 was good enough that most of the more difficult functions (ie. checking for a win in tic-tac-toe) did not need to be fixed. Ultimately about a third of these students ended up understanding how the code worked and made significant modifications. The remaining two thirds focused on minor tweaks such as changing graphics and sound.

In the end almost every student ended up with a project that they were proud of and we had a fun time putting on an exhibition where other classes could play their games. Even though the final results were pretty solid, I think there is substantial room for improvement in how I approach this in the future. As I met with each student to review and grade their final project, they were able to give me great insight on how to achieve that.

One topic we discussed frequently was what they felt the role of generative AI should be in a project like this. Most suggested that in the future I limit this to asking for explanations, or possibly only allowing generated code for very specific areas they were having problems with. I was impressed with their honest assessment of where it caused more harm than help.

By far though, the most common theme was that students felt unprepared for how to get started. It wasn’t about not understanding the planning and requirements documents, or the programming concepts, they just had not seen enough projects written by others. While I am a firm believer in “if you want to write well, read a lot” I had not applied that concept to teaching them how to write software. I had essentially taught them some grammar and syntax, talked about the parts of a story and then turned them loose to write a multi-chapter book.

Next year we’ll read a lot more code. That doesn’t mean it will be static. I’m hoping to follow some simple principles that will help us to not only observe how other experienced developers create code, but to interact with it in a meaningful way. The following article has some great advice related to traditional reading/writing.
https://writingcooperative.com/if-you-want-to-write-well-you-need-to-read-the-right-way-edec8b93abd9

1. “Set A Goal” – As we work through understanding other people’s projects it will be key that I have specific goals for what I’m hoping we extract from them.
2. “Pick A Work. Then Pick It Apart.” – More than just observing what they did, why did they do it? What could they have done better?
3. “Typing. It’s the New Reading.” – Zed Shaw’s “Learning Python 3 The Hard Way” utilizes this approach of not just copy/pasting code, but actually typing it in verbatim. Although it can seem tedious at first, it appears to be very effective for a lot of people.
4. “Finally, Keep it Fun” – Always good advice.

Now, on to summer 🙂