Are Programmers Engineers?

Written: 6 Oct. 2005

Eric Sink, who's blog I heartily recommend, calls himself a software craftsman, an excellent and highly accurate title for any good computer programmer. But Eric also thinks that programmers are not engineers. He thinks this, apparently, because he majored in computer science and has worked only as a programmer, never as as an engineer - and that's why he's wrong.

For example, he says, "To be an engineer, you have to be licensed. You have to pass the Professional Engineer exam."

Nonsense. Very few working engineers are licensed Professional Engineers, simply because there's no reason for them to want to be. There are probably entire sub-fields of engineering (chip design, perhaps) where no one holds a PE license. The NCEES Fundamentals of Engineering Exam [1] is the first step in the process of getting a PE license. As it happened, I passed it, and was duly anointed an "Engineer in Training", but I knew I didn't need to pass that exam or get a PE's license - and probably never would even if I spent my whole working life as an engineer.

Engineering has never really been one of "The Professions" in the sense that Medicine and Law are. It seems at least arguable whether that's a bad or a good thing. (Much ground for further research there...)

I am now a programmer - software developer, craftsman, call it what you will. But my degree was in Chemical Engineering, and before I leveraged the tail end of the dot com boom to switch industries, my job title was "Process Engineer". And you know what? It wasn't all that different from what I do now.

Well, that's not really true - it was hugely different in many ways, many of which are very important to me personally - but most of those had little or nothing to do with the putative differences Sink outlines in his article.

Indeed, some of my most useful and enduring contributions as a Process Engineer involved writing shell scripts to work around brain-dead equipment limitations and automate repetitive engineering tasks. [2]

And after my first year as a professional programmer (hacking away at database backed web sites, an automated bond order matching engine, etc.), I reflected that I would now be much more valuable in my old engineering job, than if I'd continued to work at that job for one more year. [3] That says a lot about how much faster I was learning new stuff in my new job, but it's only plausible at all because of the overlapping skill sets - and because of the now utter pervasiveness of computers and computing in all of technology, and thus in engineering.

It is true that in our universities, engineering and programming are taught differently, and that this does seem to occasionally have real consequences.

For example, I was once shocked to encounter an MIT Computer Science graduate who apparently didn't realize that his software performance testing experiment was, well, more or less worthless crap, because he hadn't properly controlled its conditions, and in fact didn't even know what some of its important conditions were. [4]

I don't think any of my state school engineering classmates would have made that particular mistake, even though that MIT guy was probably brighter than most of them - which is why I was shocked. I don't know just what they taught him at MIT, but perhaps they did miss some of the fundamentals of an engineering education, even though their computer science undergraduates are all technically part of the department of Electrical Engineering and Computer Science.

But then, I also knew working engineers responsible for machinery they couldn't understand because, ultimately, they were dazed and confused by the computer systems embedded into and controlling that machinery. Engineers who largely could not fulfill their putative job functions, at least in part because they were computer-clueless.

Even the sharpest and hardest working engineers I knew were often handicapped by having Microsoft Excel as the only computer programming and analysis tool they knew how to use at all. (Spreadsheets like Excel are a wonderful tool, but they have limits. And even within those limits, poor and unmaintainable use of Excel and Word was rampant.)

And it is true that programming is often poorly taught - but then exactly the same criticism is often leveled at engineering, and rightfully so!

I assert that in practice, for most engineers at most companies, the job of an engineer is to solve problems and fight friction - to struggle valiantly to Make Things Happen and Get Things Done - and to do so substantially through use of technology. It's the "substantially through use of technology" bit that makes engineers different from other problem solvers.

But, aren't programmers also solving problems, "substantially through use of technology?" Yep, they are. The difference is which technologies (and perhaps, how they're applied). But then, chemical, mechanical, civil, and electrical engineers are also all applying a wide variety of very different technologies...

Tell me, for the following cases of company founders and/or salaried professionals, which have greater or lesser similarity to the others?

A programmer building a version control tool in C#.
A process engineer writing a Bourne shell script to safely use rsh and NFS to transmit process recipes to a (cranky, and very expensive) photolithography stepper while it's running.
A mechanical engineer analyzing the failure modes of the Tacoma Narrows bridge.
A programmer analyzing the software failure modes of the Therac-25 radiation therapy machine.
The person, presumably an AECL engineer, who did the egregiously faulty (because it assumed that all software was perfectly bug free) overall safety analysis of the Therac-25.
A video game programmer machining aluminum, soldering electronics, and writing real-time flight control software for rocket ships.

Do you see any clear bright line dividing the "programmers" from the "engineers"? I don't.

Is a bad programmer ipso facto a bad engineer? And is a bad engineer ipso facto a bad programmer? No, of course not. But the correlation is significant, and I suspect increasing over time.

In short, it might be true that according to Eric Sink's criteria, programmers aren't engineers at all. But if it is, then most engineers aren't either.

The truth must be somewhere in between. Programmers and other sorts of engineers have both substantial similarities, and substantial differences, as do their fields. Precisely which similarities, which differences, to what degrees, and how and why? Ah, that's a much more involved question, and I welcome any pointers to useful thoughts or research on it.

Notes:

[1] The FE exam is an open book test, and the provided 1996 "FE Reference Handbook" is a wonderful little 118 page compendium. I've kept mine to this day.

[2] My first real real-world programming was in Bourne shell, sed, and Awk, learned on the job. I'd fooled around with BASIC in high school and taken one semester of C programming in college, but none of that was particularly useful to me as an engineer. More important (both to my then-job and to jumpstarting my future programming career) was probably that I'd signed up for a university UNIX account my freshman year on the very first day it was possible to do so, before classes even started. By the time I was working for a living, I'd heard that Csh was Considered Harmful, and the only programming tools installed on many of the Unix machines I needed to use were various versions of shell, sed, and awk, so I asked the site's Unix sysadmin to recommend a good Bourne shell book, borrowed a fellow engineer's copy of sed & awk, and away I went...

[3] In my experience, many, many "engineering" tasks are greatly aided by "computer programming" skills. Simply using a version control tool (for code, yes, but also for specifications and other documents) is a simple one. More specific examples include:

I spent a week or two learning enough Perl to write a script to properly organize lots of SEM photos into HTML pages, which was a non-trivial part of the multi-month studies to justify a process change.
Process engineers are also responsible for throughput. Modern photolithography tools are very expensive, and are used repeatedly throughout the chip-making process, so they are always designed as the rate limiter for the entire fab. At the time I left that engineering job, I was maintaining a very complicated Excel spreadsheet embodying a steady-state throughput model of the principle Photolithography machines. The steady-state model might have been good enough, but its input data - hand-collected run-times of certain representative recipes - wasn't.
Fortunately, many of the machines generated detailed timestamped logs of their internal processing steps, so I started archiving those, but so far they'd never been used for anything. It was already clear to me then that in order to understand and optimize recipe throughput, what I really needed to do was load all that data into some kind of RDBMS, join it with additional data from the central fab-wide CIM (Computer Integrated Manufacturing) group's databases, and then figure out how to crunch it.
Similarly, since we had a complex mix of many different products requiring frequent reticle changes, my boss had already realized that the reticle stocker was likely to become a serious bottleneck for Photo as we added more lithography tools. He figured we might need some sort of linear programming or other optimization technique to efficiently schedule use of the stocker based on what lots were arriving. Years earlier during initial design of the fab, some consultants had whipped up a simple prototype reticle stocker scheduling model in AMPL, but of course no one had looked at it since. Somebody would need to dig it out, understand it, and turn it into a real solution.

Funny, those sound a lot like programming tasks, but it was only us poor engineers around to do the work. There were real programmers over in another building (in the CIM and IT groups), but they were swamped with their own work, and we saw them only rarely.

[4] As best I recall, he was comparing the performance of some particular version of AOLserver + ACS against some Java based system. He concluded that Java was faster than AOLserver, therefore even though we kept hearing that Java was slow, we could switch to Java and everything would be happy - which fortunately for him was probably what management wanted to hear anyway.

There were however some problems in that analysis. Unlike most other high volume AOLserver users (e.g., AOL), the ACS made very heavy use of *.tcl pages, and at the time (probably early 2001), only a relatively recent version of AOLserver had added caching of each *.tcl page's compiled Tcl 8.x bytecode. No surprise, recompiling the source on every single page hit can be a significant slowdown. Naturally, the busiest ACS sites had already switched over to the newer, faster version of AOLserver. In fact it was precisely such sites which drove Rob Mayoff to add the bytecode caching support in the first place.

So, which version of AOLserver did this MIT-trained computer scientist use in his performance testing, one that included the *.tcl bytecode caching, or not? He didn't know, and didn't seem to care. And if he got that wrong, how much confidence would you place in the rest of his experiments? Or in the business decisions which they influenced?

atp@piskorski.com

$Id: are-programmers-engineers.html,v 1.4 2006/07/14 10:11:52 andy Exp $