Okay, maybe “plumbers” isn’t quite the right analogy (though since the Internet is, after all, a series of tubes, it can’t be wholly inappropriate). Then again, you don’t often hear about plumbers going home and doing a little recreational plumbing, or hacking on… outhouses? More efficient septic tanks? I don’t know. Maybe we’re carpenters. The point is: we programmers are tradespeople.
It’s true that, like engineers, we build things. It’s also true that, like doctors, we’re often on call. And it’s true that many of us (not me!) did our undergraduate work in computer science and it’s therefore plausible, at least on the surface, that we might call ourselves scientists. But most of us are not computer scientists, and with rare exception, neither are we engineers, nor doctors. As programmers, we’re closer to plumbers, carpenters, electricians, and masons.
This isn’t a value judgement: plumbers and carpenters are neither better nor worse than engineers and doctors. The point is that the type of work done is qualitatively different, and I think analogies and mental frameworks that suppose otherwise are counterproductive at best and actively harmful at worst. The most pervasive one of which I’m aware is in the programming community, where writing software is thought of as a science (like medicine or engineering) and not as craft (like carpentry).
It’s true that our work is based on and informed by science. Just as plumbing and carpentry are based on materials science and various engineering disciplines, writing software is based on computer science, mathematics, and electrical engineering. As is also the case with trade professions, however, our work is not itself science. With the possible exception of the on-board shuttle group at the Johnson Space Center, no group of software engineers in the world would be mistaken by a professional scientist for one of their own.
If anything, the analogy between tradespeople and programmers is a disservice to the carpenters and masons of the world. As a friend of mine once pointed out to me, when you tighten a bolt on a bridge in San Francisco, a bridge in Tokyo doesn’t fall down. Yet this is exactly what happens to us in the world of software engineering: large, distributed systems with millions of events and thousands of people working on them exhibit this kind of bizarre behavior every day. We can argue that this is the result of programming being a hilariously young discipline—if we want to be generous, we’ve been writing software only since the 1840s, when Ada Lovelace wrote the first text we would recognize as a program for the analytical engine, as compared to millennia for building bridges—and this is true, but it’s not the whole truth. Most of us are making proto-bridges by gluing APIs together to varying degrees of success.
It’s true that there are a bunch of folks in the programming community who are doing research & development and are actively expanding our sphere of knowledge, but this is not most programmers. There are exceptions to every rule, and I’m reasonably sure there are self-identified programmers who are doing the kind of rigorous experimentation and data analysis that qualifies as science. These are, in my limited experience, actually the least likely people to insist on being called computer scientists or that they are doing engineering work. The rest of us are using their tools to build websites, desktop applications, mobile apps, and so on. The rest of us are doing craft, not science; realizing this and accepting it is, I think, beneficial for the collective culture of our industry.