Reading to Learn How To Write
Matt Gertz over at the Visual Basic Team Blog had a great post titled How Do We Learn to Be Good Programmers? that really got me thinking. I’m a big fan of learning about programming by reading well written programs. I’ve written about the art of the code review before and I am a firm believer that code reviews help everyone involved become a better programmer. Unfortunately a lot of the code that we give students to read is just plain bad code.
The problem is that we try to show students concepts and in order to make the demonstration manageable we over simplify, leave things out, and often even revert to “do as I say not as I do.” There is not a good way around this in most cases though. You have to be practical after all. But at the same time you have to make sure that students understand that practical for sample/demo/example purposes is not the same as practical for real live put it in front of a customer purposes. A tough sell.
The Advanced Placement Computer Science curriculum recognizes this principal and a case study – a long piece of professionally written exemplary code – is an important part of the course. It’s a good start but it is still a fairly small piece of code. In fact I would argue that any piece of code that one person could write in a year is too small. Alas there really isn’t time in most high school courses to do that sort of thing.
Earlier today I visited New Hampshire Technical Institute (one of the fine members of the New Hampshire community college system) and watched demos of the second year projects from students in their Animation and Graphic Game Programming (AGGP) program. I somehow messed up and missed the morning session where the first year students showed off their XNA based projects. But the afternoon was very interesting. In this course the students built some very impressive games using the Source Engine from Valve.
To build these projects which are complicated modes of existing games the students had to work with 100s of thousands of lines of code. They had to understand them, modify them and expand them. Along the way they read a lot of professional code. They also learned a lot about large projects and the unintended consequences that seemingly small changes can have. I wish more people had that sort of experience in college.
But even in high school (and younger) students can read professionally written code in manageable chunks. I think of sites like the Visual Basic Code Samples site that has lots of examples for people to read and to learn from. Of course there are C# code samples as well. And many more that are easy enough to find with a brief search. I would encourage students to look for professional samples and read them. Learn from them. Emulate their best practices. It will make you a better software developer.
Comments
- Anonymous
May 08, 2009
Interesting posts -- both yours and Matt's... Re: Matt's post --> Growing up, I was a pretty good writer. I'm sure some of that came from having the Chicago Tribune newspaper on our breakfast table every morning, and I would read news and sports and columnists each day. I remember getting a writing award in grade school for a narrative piece with a conversational style resembling that of the late great Trib columnist Mike Royko. Even the essay in my latest teaching job application borrowed a creative interviewing style from current Trib sportswriter Steve Rosenbloom. As Matt says in his post, we are by nature "pattern matchers" in our writing and in our behavior, and definitely in our coding as well. Indeed, very much of "Good Teaching" is leading by good example. Exposure to good code will inevitably help us be better coders. Re: Your post --> At my company today (doing software dev in the financial world), we've discussed the idea of having a more "open-source" approach with our internal code ("open" within our company and between teams, not "open" to the public). The idea is that teams could not only make suggestions and improvements for each other's code, but also learn and grow from seeing the techniques that other programmers are using. There are definite risks to this approach (One disgruntled exiting employee now has more code to take with them!), but it would also be an easy, cheap way to improve developer skills and improve teamwork.