On Becoming A Better Programmer
or "Please please please ask your 'stupid question'"
By Kevin Conroy
Back to the Main Page
Last updated September 15, 2004
A while ago, a student asked me the following question (this is an actual e-mail that has been sanitized to protect the innocent):
I'm really interested in trying to become a better programmer, better thinker. I'm having a really tough time in class, trying to wrap my brain around some of the concepts. I do alright but I'd like to be better. I'm not exactly sure who to approach and how to ask, "How do I get better?" at programming. It's a bit of a broad question to ask. I really don't like asking people for help, not like an ego thing, I'm just scared most of the time unless it's a question I know I can't look stupid asking.
Before I give my answer, allow me to give you some background on my experience in the undergraduate CS program at UMCP. I was a TA for four CMSC classes (CMSC214 twice, CMSC311, and CMSC420 where I was in charge of the project [spec, newsgroup, test data, etc]). Since I was also an undergrad and took the whole track starting with CMSC106 (or CMSC131 in C for the new students), I've got a pretty good handle on the kinds of things that the average student is exposed to during their undergraduate education.
Why Errors Occur
Part of a research project that I'm working on with Dr. Hugue is to
examine common errors in programming and to look at why programming errors
occurred. For instance, if you have a bug in your program, is the bug there
due to a lack of understanding of Java or due to a lack of understanding of,
say, how B+ tree delete works? The distinction is important because
knowledge-based errors on Java are much easier to correct! But further more,
even if one knows Java and understands B+ tree delete, that doesn't mean
that one can get a working B+ delete. The error in this case comes from an
inability to integrate knowledge of B+ delete and Java into working code.
One of the biggest problems that we have in the CS department is our size. Due to the huge number of students in the lower levels (upwards of 300+ in [106|131]/114/214), we have had to adopt certain policies to enable automatic mass grading. As you know, you've been given .h files for the vast majority of your projects here. By giving students the skeleton structure, we alleviate the hardest part of programming: design. Being a code monkey that writes code that conforms to a predetermined spec and structure is fairly easy to do - that's why these jobs are being outsourced to India! To really become a good programmer, you have to really get your hands dirty in program design and structure.
The Question of Design
It's not just as simple as saying which classes you should
make. You have to consider not only how to design the classes so that you
can solve the problem at hand, but also how to design the classes so that
you can write code to test your program (unit tests, in particular) easily.
Also, what framework should you use to support your development? (Meaning
how do you detect, track, and save errors/faults? How do you ensure that
input is correct? How can you write reusable code that will actually be
The question of design is not a simple OOP issue. To be a good designer you not only have to have an understanding of the problem (i.e. how B+ tree delete works) but also have a grasp of many techniques of software engineering, algorithms, system/network design, fault tolerance, in some cases security, and of course, my personal favorite, human-computer interaction (yes, that's right HCI; if you take an extra 45 minutes to write a GUI test environment for a command based program that fits the
testing/development needs that you have, you may save yourself hours and hours of painful debugging or unnecessary grunt work).
The real trick is to figure out the problems that you have as a
programmer and figure out ways to fix these problems. For instance, I used
to have a problem with while loops; I'd always forget to update the stopping
condition and would hit an infinite loop which on a pre-Win2K machine means
deadlock and a hard reboot. After doing this to several live, production
servers at work (don't ask me why I was doing un-tested development on a
production server) I learned several valuable lessons: (1) always develop
and test on a non-production machine and (2) always use for loops or if you
have to use a while loop, write the stopping condition update code before
the rest of the while loop. It's not a trivial example - I've witnessed many programmers have silly problems like this for several years yet they don't change their ways!
And now to address the most concerning part of the student's e-mail: the question
of "how do I become a better programmer" is NOT, I repeat NOT a stupid
question. You must realize that this question is pervasive to all of
computer science and is a question that educators have to repeatedly ask
themselves everyday. (They also have to ask themselves: "How can i teach
them to be better programmers?"). This question is SO difficult, in fact,
that many TAs or professors won't know how to answer it and they may blow
you off or give you a canned response with trivial examples and suggestions.
Having held nearly 250 hours of office hours and answered a countless number of questions, I can tell you that I have only seen on the order of 3 students as a question as intelligent as the one put forth in the student e-mail quoted above. I know it may sound like a silly question, but you have to recognize that the only way to become a better programmer is to admit that you don't know everything and to find a way to learn.
As an ex-TA I want to stress how important it is for a student to ask every"stupid" (note the quotes) question that they have to a TA or professor. College is not about looking smart - it's about figuring out the questions and then finding the answers. Even if you can't quite put your finger on the question, you should still go and talk about it with a professor or TA. Many of the people here have more experience than you'll realize and may have insight to share with you that you are not aware of. Obviously, the more self-reflection you do, the more precise your questions will be. However, we all have to start on the ground floor with the broad, general questions, so you shouldn't feel bad about asking.
It's Not About Ego, Stupid
It may not be an ego thing, but it's just as bad as an ego thing. You should NOT be afraid of asking questions, especially this one. Integrating knowledge from a class and incorporating it into your programming habits so that your habits change to make you a better programmer is one of the most difficult challenges that we face as computer scientists. As far as I'm concerned, I'll be asking this question of myself for the rest of my career. And in fact, for the rest of my life (in the form of "how can I become a better [person|programmer]*?")
Asking "how do I become a better programmer" is the right question to be asking... or at least the
right question about what questions to ask (if that makes sense). If you get a computer programming
job/internship over the summer, try to apply what you've learned during the school year to your work and
constantly step back and examine how you're doing things and try out new
approaches to problems and new programming methods that you've heard of.
Eventually, you'll find a set of techniques that will protect you from the
problems that you have (i.e. while loops) thus freeing you to worry about
more complex and more interesting problems. The same techniques work at that
level; I'm currently trying out many design patterns and integrating various
design techniques into my own programming habits. Even within a few hours of
trying out a technique I'm able to see improvements in my habits.
The most important point that I want to make is that every student SHOULD ask these questions. These are the RIGHT questions to be asking. You should NOT
feel stupid. I cannot tell you how refreshing it is as a TA to have someone come in and ask an open-ended question about computer SCIENCE rather than how to get another 5 points for their grade. (99% of questions a TA gets is about fixing problems with projects/homeworks... not general CS questions such as this one, even if it were in the context of a particular project!)
As you can see, I've written you a short novel here because I feel it is my due to try to answer these hard questions when I am asked them. And I take the time to do it because so few people actually take the time to ask (I only get to give this spiel three to four times a year!!)
After being a TA for so long, I can tell you with a great amount of certainty that there are no stupid questions, only shy people.
By Kevin Conroy
Back to the Main Page
Last updated September 15, 2004