HOWTO: turn a student into a software developer
Yesterday I was frustrated. I'm teaching my open source Mozilla courses, and I happened to look at our blog planet. Right now we've got more than 30 students working on various open source projects, and to look at their blogs, you'd think they were all on holidays. I view blogging as a barometer for development activity. "I don't have anything to write about" is synonymous with "I am not doing anything worth writing about." I went around the room and asked my students why they hadn't done the coding I'd assigned (I asked them to modify something simple in Firefox). The answers were weak.
I've been teaching long enough to know that students often do the minimum required to get a grade. And while that might be a reasonable way to get grades, it's not going to turn them into software developers. Software is hard. I was commenting to Chris yesterday that a computer is basically just a box built on a system of reason you don't understand yet. Programming is mostly about overcoming your own limitations. It's creative, problem solving work, and it is something you have to spend a lot of time to get the hang of before you're any good.
Some of my colleagues talk about students either getting it or not getting it. I'm not sure I believe this. I think the right way to think about this is that there are students who push themselves, and those who don't. I know some developers who seem to just be built for the task of thinking through these problems. I also know that they've worked really hard to get to this place, and that it's easy to confuse their ability now for something innate vs. something acquired. Sure, you have to have certain qualities in order to get there; but the one we don't talk about enough, which I think is the most important, is that you have to be willing to put in the time and push yourself.
While I was getting after my students, I pulled up a favourite essay of mine, Peter Norvig's Teach Yourself Programming in Ten Years. He's writing about a phenomenon I don't see as much today--the "Learn X in 21 Days!" books. What I wanted to show my students, though, is how well what he's saying maps onto open source development. Here are some examples:
- Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
- Talk to other programmers; read other programs. This is more important than any book or training course.
- Program. The best kind of learning is learning by doing. To put it more technically, "the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve." (p. 366) and "the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors." (p. 20-21) The book _ Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life_ is an interesting reference for this viewpoint.
- If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
- Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do (because they make you do it for them).
- Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.
- Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).
Notice how your grades aren't really what matters here? Some of the best programmers I know never went past high school, and some of them went to Harvard. It turns out that there is something other than grades that makes you good at this stuff. I honestly believe that involvement in open source for students is one of the most critical things to doing what he describes. How do you do some of this stuff without open source? How do you work on projects with other programmers if you can't get hired somewhere (no experience? no job)? How do you get to work with programmers who are better than you if you don't know any? How do you get to work on large code bases after someone else has written them if you can't access them? How do you learn half-a-dozen languages without a need for them all? How do you learn how to read code without code to read? Open source might not be the only way to do what he describes, but it is the most readily available way for large numbers of students.
The last thing that happened in my day before I went home was that another student (not in my class) came to see me to ask about how to fix his Firefox debug build. He came to me a while ago looking for a bug he could do in Mozilla. "I want to learn, what do you suggest I work on?" I gave him a non-trivial C++ bug in Mozilla's XPCOM system that is causing some strange crashes. Since then he's taught himself a lot, started to ask some useful questions, and gotten underway on his 10 years to becoming a software developer.
What is necessary to get students to do this kind of work? They have to want it. They have to push themselves. There's not much you can do to make them do it, since no course lasts 10 years. It's not that there are those who are good at this and those who aren't. There are those who push themselves and those who don't make the time. Want to get good at this stuff? What are you doing about it?