Aspiring rockstar here. The rigid formalism of engineering cannot capture the full extent of my creative expression.
Only a rockstar? We’re looking for rockstar ninjas.
Rockstar Ninjas? Weak. We’re looking for Wizened Sourcerers.
Need a roadie?
“Creativity”, “programmer enjoyment”, and impressionistic poetry uber alles. Dijkstra was a prophet, but unfortunately he was also a Cassandra.
[Comment removed by author]
The assumption that people do not come to harm because of tech is precisely the crux of the matter. It is a discipline where sooner or later, your work has the potential to cause harm, and so if you’re not learning about the ethics of what you’re doing from very early on, you can easily do harm.
bridges are stable because no one cares about driving over the latest and greatest bridge.
and nobody ever wants stuff added to bridges once they are already built. Nor does the gravity suddenly change because gravity was deprecated and has been replaced by gravity 2.0 which is much better. As a matter of fact, many buildings fail to stay upright when their operating conditions suddenly change (like earthquakes or fires)
The problem behind the instability isn’t (just) budget or bad engineers. It’s the constant demand for change either to the solution itself or to the foundation required by the solution.
I think that the title can and should work for different types of software developers, and that it should require a PE-style certification. Software Engineers should be the people designing and implementing software that runs cars, elevators, healthcare systems or really any shit that can kill people. These people can’t move fast and break things. They can’t ship bugs. That kind of development should absolutely require the rigor that a PE is supposed to guarantee.
Other software developers, like the ones that make up many companies in the Valley don’t need to meet such requirements. People’s lives (thankfully) don’t depend on any code that I, or most others in SV, write. That’s fine. There shouldn’t be any shame in not being a software engineer, and SV companies shouldn’t require a PE to do work for them.
Both titles can exist, but they should absolutely imply different qualifications. Ideally, the term engineer should become less ambiguous than we’ve made it.
I looked around, but can’t find the position paper the ACM published about fifteen years ago, explicitly refusing to participate in creating a certification process for software engineers. It had some very strong words about how no such certification would be able to guarantee or even measure the things that certifications do in other engineering fields. Given that it would be a liability-shunting fiasco that made everything worse by creating a false sense of safety, they felt they shouldn’t be involved.
I notice that they have a professional code of ethics, today, but that’s it.
I’d love to read that.
Here you go - http://www.cs.cmu.edu/~Compose/bok_assessment.pdf
As background, this article is largely the ACM side of a 1999 disagreement between IEEE and ACM over Texas’s move to create a category of licensed software engineers.
In 1997, the IEEE and ACM had formed a joint working group to better define the body of knowledge making up the field “software engineering”, with the main agreed goals of improving standards in the field, providing guidance to educators, and better establishing software engineering as its own discipline, rather than just a fuzzily defined variant of “computer science”. SWEBOK (SoftWare Engineering Body Of Knowledge) is the acronym for that effort, and both groups initially thought it was a good idea. Where they diverged was over the political question in 1999, when that Texas move unexpectedly arose: IEEE supported engaging with Texas’s process and thought the SWEBOK effort could be used to positively influence it, avoiding a negative outcome of Texas making up its own standards, while ACM was strongly opposed to professional licensing, and pulled out of the SWEBOK effort entirely out of fear that it might be used that way, both in Texas and elsewhere.
IEEE went on to approve and publish the document in 2004. The ACM and IEEE also somewhat reconciled over part of the original agenda, and formed a different group in 2001 to develop a set of guidelines specifically for software-engineering curricula, the “Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering”, which were also released in 2004. That side of the agenda has been fairly successful: there are now a lot of software-engineering degree programs, distinct from computer-science programs.
Saw that last night…it’s rather telling that you can’t simply just download the damned thing.
Thanks. I was young enough at the time that that background went over my head; it’s nice to close the loop on it.
Side note: Fortran and Ada are fine languages for their domains. In fact, had Twitter used Ada instead of Ruby we wouldn’t have seen the fail whale. It is a fallacy that new is better or that old is worse.
“No programmers are engineers” is just as stupid and annoying a trope as “all programmers are engineers”.
I didn’t read the article as saying “no programmers are engineers”, but rather something more like: most of what goes on in Silicon Valley under the job title ‘engineering’ is not, and this is more than just a terminological problem. Yeah, the headline is less nuanced, but headlines are picked by sub-editors for pageviews. The article itself I found to be making an argument that fits how I see much of the industry.
The actual title “engineer” to me isn’t the main point, anyway, but rather the lack of an engineering mindset. I think the article is mainly arguing something like: Engineering has at least two major facets that programming in the tech industry often lacks. One is careful design, planning, testing, etc., rather than just throwing things together. Although this is the aspiration of the field of software engineering, much of what goes on under the title “software engineering” hardly is even pretending to meet this aspiration, and is more from the “move fast and break things” school of improvisation-oriented hackery. And secondly, engineers are traditionally seen as a kind of public servant, who, although they may work for private companies or be in business for themselves, nonetheless ultimately see themselves as having a responsibility to the public regarding the quality and nature of their work. He doesn’t quite say it, but much of the startup scene in particular has adopted more of a business mentality than an engineering mentality here, where your ultimate responsibility is to whatever makes money, rather than doing the job right.
Yeah. See, I do like the label “engineer”, because I aspire to it. It does also make sense as a job title at companies which want to foster an attitude of care and planning, though it won’t do anything noticeable to bring it about without a lot more effort than just a title.
But you’re exactly right - not all programmers are engineers, and not all companies want them to be.
Fine. They can call me “Dr. Boojum” instead.
More seriously, I take issue with all the dodging around about the various definitions and meanings of engineer and silliness about things like why graphics designers and hedge fund-managers aren’t engineers. But then there’s this line:
An engineer is a professional who designs, builds, and maintains systems.
By that definition, yes, I am a software engineer. I design software systems, build (implement) them, and maintain them.
I do think that one of the things going for most professional engineers is that they have the collective clout to push back and make sure they have enough time to do a solid job. If I tried to hire a civil engineer to design a suspension bridge for me but only gave them a week to do it, I’d be laughed out their office. No engineer would agree to that. Yet, too many people fail to see how absurd it is to ask the equivalent of a software practitioner.
I go back and forth on this. I’m skeptical of the idea that traditional engineers are necessarily acting in the public interest in some way. Are the mechanical engineers who designed, say, my printer, or the electrical engineers who designed its circuitry, somehow performing a public service in a way that programmers who designed its firmware and its drivers are not? Are they less driven by mercantile expediencies? I suspect the idealized working culture that the author describes is probably shared by relatively few engineers even in the traditional engineering disciplines. There are a lot more people designing printers and microwaves than bridges or passenger jets.
That said, I share the author’s respect for those ideals and I prefer “programmer” for myself because I know that I and we don’t live up to them. I’d love to work in an industry where we think of the users first and the stockholders second, but we’re a long way from that.
Foundation of this article was: “Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education.”
I spent 5 years as an aerospace engineer with no regulation, no certification (beyond a bachelor’s degree), and no apprenticeship or required continuing eduction.
It’s true that some engineering disciplines require these aspects (which is probably where the context of the author is coming from), but it’s certainly not required across the term “engineer.”
For me, personally, I consider some programmers to be engineers. It’s a bit fuzzy, but to relate it to my previous profession in aerospace, it’s the difference between the engineers and the technicians/drafters.
When I have to write my occupation on a form or something I always write ‘programmer’.
Glenn Vanderburg gave an interesting talk about this subject at LoneStarRuby 2010:
As much a fan as I am of having some more rigor in our industry, the fact is that your average developer (or programmer, or coder, or whatever) does a style of work that cannot reasonably be compared with engineering.
I had a huge and sprawling rebuttal, but I’m leaving it out. Basically, this is an ongoing sore spot for our industry, and while I don’t know in which direction we need to resolve it, we all would benefit if we picked a damned side.
““—oh, engineer, in tech-bro speak.” I am starting to write the pontifications of people using ‘tech-bro’ to refer to “men who write software” non-ironically off, or at least discount them from importance. It tires me to read derogatory slurs, and it reveals a deep seated nastiness about things. Yuck.
That said. No one(*) wants to pay for top-quality software. It’s expensive, the processes and administration are burdensome, the technology will be outdated years before release, the customers have to conform to rigid deployment requirements, and requires deep education on the part of all involved in the design and creation process. The market demands cheap, the market demands yesterday, and the market can tolerate errors. See: Windows 3.1, 95, 98.
Now, let’s talk about Real Engineers. Real Engineers don’t make mistakes. Real Engineers have Certifications. They have Papers. They build things The World Relies On, Sent Men To Space and the Process Protects Everyone. Real Engineers did not build the Tacoma Narrows. Real Engineers did not build Bertha in Seattle. Real Engineers did not launch Apollo 11, and they didn’t design Apollo 1. Real Engineers did not design the Challenger Shuttle. Tech-Bros did, those wild-eyed men doing reps at the gym with their dubstep and swilling beer afterwards. Because those efforts have had Issues, and Real Engineers don’t have Issues, for their Process Protects them.
Back in non-satire land, I’ve worked in a Real Engineering shop. The main difference is that people care about defects. Really, really, really care. And they release fixes when defects occur, which happens periodically.
(*) if you work for a team which does, you know you’re in the 0.001%. You also almost certainly work in medical or space.
There’s a follow-up here collecting a bunch of the reader responses that were posted/emailed/etc. to the author and The Atlantic, which I found interesting.
I have an electrical engineering degree. I worked a few years designing electronics. But the last 25+ years, I’ve mostly been programming desktop software and occasional firmware. What am I?
The only one who can answer that is you. Identities aren’t about the objective facts; they’re about your intent. The next time you’re between jobs, consider what it means to be an “unemployed engineer”. To the unemployment office, it means precisely the same thing as “unemployed barista”, and they act accordingly… those also both mean the same thing as “unpublished writer”. Personal identity isn’t about how we interface with capitalism; it’s about what things are core to who we are.
One point: while I do not call myself an engineer, that is the title assigned to me by my employer. It’s important to note that these aren’t always self-chosen labels.
My title was technically “lead software engineer” for a little while. Thing is, just like the article says, I did not need to go through any certification process and should one of my projects cause injuries or damage, even though I might be fired, I would not lose my ability to code as a job.
Given that it was my actual title, when people asked, I responded saying so; however, when people ask me what that entails, I answer truthfully and mention that it’s just programming. I also mention that “software engineers” average around 10000–20000$US/yr more than “software programmers” despite it being a title-only distinction.
Oh well, nothing in the world is perfect.¹
1 The exception that proves the rule? Bagels, of course.
Engineers bear a burden to the public, and their specific expertise emanates from that responsibility.
I work in money-processing and I’d say my code has a pretty significant impact to the public. I’ve worked with real engineers (meaning non-tech) before in the dam valve manufacturing business and all they do is push excel spreadsheets around all day and churn out autocad drawings that are barely different than the previous one they drew. I’d say our work is pretty damn similar.