Tags

, ,

During high school and college, I took a number of programming courses. I did OK, but never really felt like a “programmer.” That is, I could implement the assignments using the tools provided, but beyond that I was fairly clueless.

When I decided to take up programming for a living, I settled on C as my language of choice. It was in high demand at the time, and I really loved the terseness, speed, and lack of abstraction layers between me and the hardware. (Or rather, I really hated Pascal’s verbosity, so typing ‘{‘ instead of BEGIN really spoke to me).

At any rate, I decided to take a course in C at the local community college in order to get moving in my new career path. When I attempted to sign up, I found that they had a 100-level course in structured program design as a prerequisite. They were going to make me spend a semester drawing flowcharts with a template! I was not pleased, but rules are rules, so I took the course.

That course was the most important course I’ve ever taken.

Before that course, I’d never really been exposed to the idea of “program design.” You know how it goes — you get assigned to write a program to do, say, matrix multiplication. You write a little 100-line program, get it working, and turn it in. The end.

Well, that’s not how it works in the Real World. In the Real World, you’re working on systems with perhaps millions of lines of code, with a team of perhaps tens of programmers, over the course of many years. If I’d have tried to pursue Real Programming with my initial naive approach, I’d probably have walked away from the field in frustration.

Having a formal course in design as a starting point was critical for my growth as a programmer. It introduced me to Programming in the Large — thinking of the big picture, before getting into the nitty-gritty of banging out code. It introduced me to the idea of thinking of program design independent from the implementation language. Most critically, it showed me that, if I run into a problem that I don’t currently have an answer to, I can simply create a subroutine to perform the operation, defer the implementation to a future time when I’ve figured it out, and press on with a solution.

The question “What language should a beginner start with?” is a common one, and everyone has their own arguments and pet languages. But I’d suggest that the best language for a beginner is no language — rather, they should take a 100-level course in program design. Once you know how to design solutions, the choice of language is a lot less critical. Since those days, I’ve made money programming in C, C++, Visual Basic, C#, Java, JavaScript, umpteen dialects of SQL, various Pascal dialects, Perl, REXX, etc, etc. But the principles I learned in the 100-level design class have remained just as useful as the day I learned them.

If you don’t have access to a basic design course, here’s a course description of the current version of the course I took lo these many years ago:

http://www.nvcc.edu/academic/coursecont/summaries/ITP100.pdf

 

Advertisements