I’ll freely admit it – I’m quick to lose focus when something really catches my attention. Such was the Word Cloud Generator that I had written about earlier. I thought that it was done very nicely and the mathematics angle to it was really intriguing. As I mentioned in the post, there’s a great about the generator page attached to it with some really interesting insights. One is that the source is available on GitHub. Curiosity got the better of me so I checked it out.
The whole process reminded me of university days and I distinctly remember one of my Computer Science professors’ comments “There will be more people in this class hired in the computer science field doing things other than programming.” This included things like writing manuals, doing technical support, being a debugger, etc. Now, this was in the days before the class had personal devices to fact check a wild claim like that so I just took it as a truthful statement because it did make so much sense.
It was advice that I took with me into my own Computer Science classroom. I used to get complaints from students “Siiiiiir, this isn’t English class”. But, I persevered and required that any project submitted to me included internal documentation (commenting), meaningful variable names, and that each project submitted also included a paragraph or two written in the student’s voice describing what the program would do and what the expected output was. It also made marking easier to visit the README file first before looking at the code. To further drive home the point, I would make programs/projects build upon each other so that students could actually go back and reuse code rather than always starting from scratch. From a marks point of view, it gave the student the opportunity to get some marks even if the ultimate project didn’t work completely. It didn’t make the project coding all or nothing.
It was my way to pay forward the professor’s advice and to have students think about their coding beyond just “Getting it to work”. I also wanted to remove the mentality that “if a program was hard to write, it should be even harder to read”.
I have had contact with former students who did acknowledge that it was helpful advice in their careers. I couldn’t help but remind a couple of them their complaints when I used to take off marks for spelling…
These days, remixing and sharing code has taken a more global perspective and this Word Cloud Generator is a great example. If I had the skills and desire, I could take the code and make it better. I could do so because the program is very well documented. It’s not the sort of thing that everyone appreciates or even cares about. And yet, for repurposers, it could mean everything. If something is well documented and algorithms explained, then modifications are so much easier.
It does make me thing about the current state of coding. Alfred Thompson, for example, has recently updated his list of block coding languages. I’ll bet that you don’t know that there are so many options!
At the recent CSTA conference, I had a conversation with my friend Chris about this topic. One of the things that I see as missing with some of these introductory programming languages is for the student to really document internally what logic they’re using as they write their code. One of the approaches taken for the Hour of Code is to sit down and hammer out a program as per the recipe and then get excited when you can make the computer do your bidding. That is important and can serve as motivation to do more. We all know that the followup question is “does it really?”
But I think that there’s another question that needs to be answered in this whole thing. If we’re skipping the step about internal or external documentation, are we missing a key component for understanding just what’s going on when you tell a computer to do something? I think so and Chris agreed, taking notes to share with her team.
My question is to anyone who does coding with students. What value do you place on things other than the actual computer code. The algorithm, the internal/external documentation, the ability to describe how the program works to someone else. I’d love to hear your thoughts about the state of things in your classroom.