Programmers: Stop Calling Yourselves Engineers
theatln.tc
theatln.tc
And building things in the public interest? Please. These things our built in our client's interest. Yes, sometimes that client is "the public" in the form of a local, state or Federal government, but not always, and for many engineers, hardly ever. It's also dubious that the government's interest coincides with the public interest. I worked for a firm that bid on the contract to design the NSA's 60MW datacenter in Utah. We didn't win, but someone did, and they happily took the money to build it. Public interest indeed.
Yes, we recommend building things in sustainable, efficient ways whenever possible, but at the end of the day someone else is footing the bill. As long as they aren't asking for something outright illegal or dangerous, they'll get it. If they want to knock together a building that barely meets code minimum requirements, that's what they'll get.
> Today’s computer systems pose individual and communal dangers that we’d never accept in more concrete structures like bridges, skyscrapers, power plants, and missile-defense systems.
It's still pretty early days as far as computer systems go. It's only a little over a hundred years ago that hundreds of people died in a fire[1] causing us to realize the egress doors need to always swing outwards and should not be locked. And that's after how many millennia of building buildings?
We don't accept these dangers now because we know what they are after people having died from them in the past. We won't know what things we will need to watch for in computing until they happen.
[1] https://en.wikipedia.org/wiki/Triangle_Shirtwaist_Factory_fi...
As soon as I read the tagline, I thought, "Surely he's presuming all engineering is civil engineering." That's the only way that argument holds.
"Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education. Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver."
I DO have an explicit responsibility to public safety and reliability (it comes with the degree). I have to consider the implications of my work and could be held criminally liable for errors resulting in injury or death. If one was designing and building - or even updating - the software for a radiation therapy machine, for example, wouldn't you want it to be that way? https://en.wikipedia.org/wiki/Therac-25
With that, understanding your goals is important in deriving strategy. Developing software for NASA space shuttles is going to be inevitably slower and more scrutinized than working on Google Music. Therein lies a traditional engineering problem of using the right tools for the job.
Software also does contribute to the public good in that an open-source mindset is built into the subcultures of the profession in general. It's pretty cool that I can get involved in programming using free tooling from day one, where my friends in finance or more traditional engineering careers cannot.
Overall, the author feels like they're arguing from some twisted version of the "golden age fallacy." In fact, this seems like the same type of tired arguments I hear stipulating that video-games are not art: built as an argument from the old guard to bully the new kid on the block.
Complex systems, yes. Critical... well that depends on how you define critical.
The whole "quick iteration strategy" idea depends, largely, on the idea of "fail fast" or "move fast and break things". This necessarily makes iterative software development into an exploratory discipline, poking at something that doesn't work with a stick so that you understand it better and then creating something that does work off the back of that.
You simply cannot "move fast and break things" in a field where your created artifacts are expected to last a long time; we'd live in a fragile world of prototypes and conservatism were that the case.
In pretty much every other field populated by people who call themselves engineers, there's a whole lot more thought and maths going into the design of constructed artifacts, fed by a whole lot more science, before doing the actual construction. This approach is not just passé, but anathema in the software world. We just don't do engineering the way the rest of the world does.
"The traditional disciplines of engineering—civil, mechanical, aerospace, chemical, electrical, environmental—are civic professions as much as technical ones."
I would like to introduce the author to something called "Open" "Source":
The server that his article is reaching the world via is almost certainly running multiple pieces of infrastructure designed and built in the public interest, and given away for free.
Software suffers from being universal, inexpensive and omnipresent, so people notice all the crap (I certainly bitch about software quality myself) while ignoring the thousand miracles per minute that it provides for us.
My house builder is accredited by X, Y and Z but their management and customer service is so poor that I fail to see how the business functions. I think this projects a some what idealistic view, not founded in reality.
They did a quick "Program in <Language> in <X> Days"
They don't understand too much about what's going on under the hood. Just press this and it happens.
Software Engineers on the other hand have a deeper understanding of software. They have studied the field and learned how a computer actually works from the bottom up. They understand assembly language, state machines, data structures, algorithms.
A programmer has trouble adjusting to the technological landscape as it evolves. A software engineer sees the evolution and can see why solution y is better than previous or if it's just marketing hype.
A true software engineer understands software is more than code.
Ok, if you must, I actually agree that programmers should stop calling themselves engineers. Like I've said before here on HN, I don't think it helps us (programmers). We should own our title and wear it with pride. Taking someone else's title does two bad things - first, it opens programmers to the charge that they are insecure and are misappropriating someone else's hard earned title and reputation. Second, it may give engineers (the PE kind) the impression that they have some claim on software development. That last part is important, because I would prefer not to see software regulated by the PE exams (though my objection to this diminished greatly when they went to much more industry specific exams).
I consider software development to be a genuinely difficult task, one that can push very smart people past the edge of their own capabilities. It can be intensely creative, and the stakes can be very high. However, I think we should just consider it to be its own thing.
Now, all that said, I'll go back to my first statement: eh. In a world of train engineers, special effects or sound engineers, financial engineers, pft. Calling someone who reads a book on PHP (or buys one but doesn't read it) and throws up a bug ridden website an "engineer" seems a bit of a stretch, but is it really so outrageous to call someone who has spend decades learning to design highly complex, scalable, performant software applications that need to be reliable in a high stakes environment an "engineer"? Is that really such an egregious use of the word?
Like I said, I'd rather software developers redirect that impressive accomplishment back to the word "programmer" or "developer", but in the end, this whole thing is completely overblown.
Maybe instead of simply labeling the skills or the needs, we could spell out our experience (résumé) or requirements (job description.) But we still need a label to get the proverbial ball rolling, to pique the interest of employers and employees; something that says "I know how to tell a computer to do what you want done."
"Software Engineer" sounds like a fine phrase for that.
"Laravel Artisan"
"Web Alchemist"
"Node Artificer"
Moral of the story is inquisitiveness and problem solving are the two big skills to look for. Anyone can learn syntax.
Jack Dorsey calls himself a computer programmer and so does Douglas Englebart. Mark Zuckerberg, Richard Stallman and James Gosling all call themselves computer programmers and not one of the people I have mentioned calls themselves an engineer. I think that if you are a lowly computer programmer then you find yourself in some good company.
Software engineer: 3-4 years work experience required, maybe Masters degree, professional certification. http://www5.hrsdc.gc.ca/NOC/English/NOC/2011/ProfileQuickSea...
Computer programmer: Bachelors degree required, no work experience. http://www5.hrsdc.gc.ca/NOC/English/NOC/2011/ProfileQuickSea...
"Progression to information systems analyst, software engineer or Web designer is possible with experience."
In software business there are no mandatory degrees, only positions. Person without formal education can be in "chief leading senior engineer" position if he has good personal track record.
Personally I like the word programmer more than engineer.
I actually have an engineering degree so I do take offence at non-engineers calling themselves engineers. I've done the work to become one, I've passed the requirements including the law and ethics exams while non-engineers haven't. My father worked for his whole career as a technician at Ontario Hydro doing work on nuclear and coal reactors and while there were engineers who did the same work, he never was called an engineer.
A self-taught developer might apply for a software engineering job, but they won't be able to apply for a mechanical or electrical engineering job. My degree isn't meaningless. It's just annoying because people refer to hiring engineers when they're looking for "software engineers". I have training over and above simple technical skills that a developer wouldn't normally have (e.g., ethics and law).
1. Engineers design and build the same types of things over and over again, from principles that have been developed, tested and put into practice over, literally, thousands of years. These principles are rarely expanded upon, and only after careful testing and proven performance. Programmers on the other hand consider building the same thing over and over again to fall in one of three categories (1) stupidity (2) ignorance or (3) market failure.
2. If an engineer builds two bridges of exactly the same specification, the cost of building the second bridge will be reasonably close to the cost of building the first one (technological advances and inflation not withstanding). If a programmer writes a useful program, and wants to share it with his friends and family, the cost of each additional copy of the program is fairly close to zero. Unlike the engineer building a second or third bridge, there is no need or reason for the programmer to create another copy of the software by designing, writing the code and compiling a second or third time.
3. Following on from (1) and (2) above, an engineer designs blueprints that describe _exactly_ how the structure is to be built, but a programmer usually has no idea how the program is to be built, because if s/he did know, then it means someone has built this before, and therefore there is no reason to build it again, because the marginal cost of copying a previous design is zero. This tends to make the best programmers experimentalists (because the risk is small) and plagiarists (because the cost of copying existing designs is zero), and the worst programmers are those that think like engineers. Conversely, experimentation in engineering is discouraged, especially on things like bridges, because it is costly and dangerous.
4. But what about the domain known as computer security? Shouldn't security be 'engineered'? Yeah, good luck with that. People who crack computer security are nimble experimentalists. Because the cost of experimentation is so low, security cracking tends to be a never ending series of probes until a weakness is found. Protecting against that approach cannot be 'engineered', because the engineering process is one in which you plan for every known contingency. But if you knew every possible contingency, there would be no security issues, because they would all be covered off.
Sorry, the above is a bit rough. I'm still refining my ideas on the topic. Feedback welcomed.
No idea what should be the name for that job.
Most of my Comp. Science friends have had the same experience, one went so far as to return the offer and replace the title with "Computer Scientist".
So HR, please stop calling Scientists (or in my case, people with incomplete degrees), Engineers.
I'll see how it goes.