Stepping on the Rakes
This text is adapted from a similar text I wrote for an introductory programming class for non-CS majors that I teach (along with several other instructors) at the University of Chicago.
Over the years, I’ve found that one of the things that beginner programmers struggle with the most is not necessarily the technical aspects of programming, but the manner in which one learns how to program or, more specifically, the manner in which one becomes a better programmer.
Most notably, when a student in an introductory class keeps coming up with wrong solutions, or has a hard time figuring out a bug, or keeps failing the automated tests in an assignment, two things tend to happen:
- They do what has worked for them in some of their other classes: review the textbook, ask for additional readings, re-read your solutions to the homeworks and the grader’s comments, etc.
- They feel bad because their code keeps failing, and get into the mindset that “my code fails, therefore I must be a failure too”.
Let’s start with #1. While doing those things may help a bit, they are not a great strategy for a beginner to become a better programmer.
So, how do you become a better programmer?
By stepping on the rakes.
Wait, what? Let me explain what I mean with the following diagram:
While programming (and computational problem solving) are rooted in many foundational concepts in Computer Science that you need to study and understand to be a good programmer, programming is ultimately a skill and, like many skills, you get better at it the more you practice it. Unfortunately, while there are definitely a number of best practices that you can learn about in class (and in countless books), there are no Golden Rules of Programming such that, as long as you memorize and follow those rules, your programs will be guaranteed to always be perfect.
One of the best way to hone your programming skills is to write code, and then have more experienced programmers review it and tell you how to improve it (or, in an introductory class, getting your code graded, as long as the graders are more than just rubric-application automatons, and they actually give you feedback on how to improve your code). More often than not, you’ll start by writing some pretty awful code, and that is ok. That is part of the learning process. You have to write bad code to understand why it is bad, and how to avoid making that same mistake in the future.
In other words, you have to step on the rake to know to avoid that particular rake in the future. Seasoned programmers are not naturally talented or “born to program”: they’ve just stepped on so many rakes that they’ve gotten really good at avoiding them (but we still step on them now and then… and how!) Or, as a (probably apocryphal) art professor used to tell art school students: “You all have 10,000 bad drawings in you, and our goal is to get through those as quickly as we can”. Similarly, if you’re new to programming, you have a lot of bad lines of code in you, and you need to get those out of your system first.
Now, this leads us to point #2 above. For this learning process to be effective, you have to open yourself to doing a bad job so you can learn from it or, to quote Adam Savage from Mythbusters, you have to accept that…
Many people (including many students) are conditioned to interpret failure as an unequivocally bad thing. If your first programming homework turns out really poorly, you will likely see this as a negative: “I got a bad grade, therefore there is something wrong with me and/or I will never be good at this”. While I don’t deny that getting a poor score on your homework can be unpleasant, it does not mean you are a failure or that there is something wrong with you. Yes, you didn’t get everything right but, then again, it is very rare for beginner programmers to get everything right on their first try.
So, don’t be discouraged if it feels like you keep getting things wrong at first. Take that failure constructively, and learn as much as you can from it. Or, in other words, if you step on a bunch of rakes, don’t get angry or frustrated that you didn’t see the rake (or that someone didn’t yell “Hey, there’s a rake there!”). Instead, focus on not stepping on those rakes again!
