Michael J. Radwin

Tales of a software engineer who keeps kosher and hates the web.

How to Be a Programmer

I stumbled across How to Be a Programmer, a 40-page paper by Robert L. Read, a principal engineer at Hire.com.

It’s a relatively good paper so I’d recommend it to anyone who’s new to the field or is a college student considering a career in Software Engineering. The distinction between Computer Science and Software Engineering, while subtle, is an important one. This paper focuses more on the Software Engineering side of things, spending a good 50% of the time discussing interpersonal skills and how to be effective working with your team.

The paper does need some polishing, however. A simple grammar checker would catch a bunch of the mistakes that interrupt the flow.

This reminds me a little bit of a great lecture I heard by Leslie Pack Kaelbling back in 1996 about why she loves programming. Like Read, Kaelbling belives that debugging is the most important part of programming, but she spins it slightly differently.

In short, debugging is like detective work. You’ve got a problem that you need to solve, but it’s not obvious what the solution is. There are little hints here and there, and you begin to investigate each one. Each clue brings you closer and closer to the solution, but sometimes you realize that you just spent the last 6 hours going down a path that led nowhere, and you need to start over again. But at each moment, you always feel like you’re making forward progress.

As a consequence, debugging becomes an all-engrossing activity. It’s impossible to walk away from your desk when you’re just 5 minutes away from solving the mystery and fixing the bug! Of course, 20 minutes later, you still feel like you’ll get it nailed in another five.