What does it mean to be a computer programmer? What are we doing when we program that computer?
I've been programming computers of one stripe or another since I was about 13 (giving me 30 years of experience, more now actually, ouch). In some ways, I am a very good programmer. In other ways, I still suck horribly. Daren, a co-worker of mine, put it the most eloquently: "All software sucks. Even the stuff I write." Daren, by the way, is a very smart, very capable programmer who simply recognizes the inherent limits of this field.
At the most basic level, "computer programming" is the process of breaking down some task into the steps (codes, literally, "a system of symbols used to represent assigned and often secret meanings") that a computing machine must take to perform that task.
Easy, right?
No. We've been programming computers, as a species, for what SEEMS like forever, but in actually is just a short blip of time. Frankly, in spite of all the techniques and methodologies and religions (yes, religions) of computer software development, there is still a large component of random luck and guesswork involved. We don't know what the heck we are doing.
I'm sure some folks are sputtering now, ready to defend their own fabulous skills and methodologies, demanding that I provide specific examples of our ignorance. How can I let such a sweeping statement stand?
Well, if we knew what we were doing, software development would be a more deterministic process. It's a rare (and usually boring) project that hits its time estimates the first time.
I _do_ know a few things that programming is _not_. For example, knowing the syntax and semantics of one or more computer codes (languages) does not make you a programmer (though you SHOULD know what I mean when I say "syntax and semantics").
Writing code that "works" is not programming. Sure, it looks like programming from the outside, but "works" is a fragile metric. I know one programmer who writes code that works, for certain liberal definitions of "work", but it is fragile and prone to stop "working" with the least provocation.
Writing clever, complicated code is very definitely not programming. Cleverness is a curse, and code that makes you go "wtf?" when you look at it is _not_ good code [1]. You should look at a piece of computer code and exclaim "well, duh!", as if someone just told you, in all seriousness, that water has zero calories, or the sky is blue.
Maybe good programming is just as Albert Einstein said: "Make everything as simple as possible, but not simpler."
Another source of ugly incomprehensible code is the programmer's own ignorance (as opposed to cleverness). It's not necessarily the programmer's fault, it's just that some problems (e.g. most of the interesting ones, and often ones where you are working within or next to a poorly-documented system [2]) are not very well defined and the code and the understanding of the problem inch forward, hand in hand. This syndrome is the cause of some truly, amazingly bad code that I have written.
A good programmer, however, knows when his code has turned into garbage and will re-write it as soon as possible, redesigning the solution so that it is clear and comprehensible.
I spent most of my career in small teams where I got to live with the code through the entire life cycle. One thing I noticed, coming in to my current job at Big Technical Company, is that "clear and comprehensible" is in the eye of the beholder. Everyone's brain works differently, and the code you put into the computer matches the thought process between your ears. Sometimes it is painful to wedge someone else's code into your own brain.
So what is good programming? Writing good programs. And a good program? Is one that works, that is easily understood, that is robust against changes, that is a pleasure to use, and that is economically rewarding. Do we, as a species, as a profession, know how to make good programs reliably and predictably? In the immortal words of Robin Williams, "Fuck No!"
But all is not lost. There are some good tools out there, the crescent wrenches and screwdrivers of the profession. Object-oriented thinking. Patterns. This and that.
But programming is still more craft than engineering. And now I have to go to a meeting, so more random pedantry will have to wait for later.
Meetings, by the way, do not improve one's programming.
[1] There are exceptions, and times when you must be clever. Some 3D texture-mapping code I wrote once _had_ to be clever, to be able to run fast enough. Very small or very efficient code most sometimes be clever.
[2] Most engineers SUCK at documentation, and poorly-defined systems are the bane of my existence. Come on guys, if you can't communicate it, you don't understand it. Try again.
Posted by Edwin at April 9, 2008 01:32 PM