First, I want to acknowledge that neither article was actually about who gets to call themselves a software engineer. That said, clearly that's all the HN comments are going to be about , so I'm diving in.
I call myself a software engineer because it makes me feel smart and important. To me, that's the only difference between an engineer and similar jobs. I don't want to heap scorn on people who make sandwiches at subway, like many will use this discussion as an excuse for. Nonetheless, the reason the term engineer doesn't apply to them is that their job is neither important, nor requires a lot of intelligence.
Things like following a specific process, taking ethics courses, or being certified, are just things that some engineers happen to do. If you're smart and capable, you will do what is necessary to do the job well. Sometimes, this involves following a specific process, and sometimes regulation is necessary to ensure that everyone does this. But other times, individual judgement is the only solution. I believe this is the case for software engineering.
I don't really care about the word that much (although I really like calling myself and engineer), but what I do care is the implication that our industry needs to be regulated like professional engineers are. In fact, I'm opposed to all forms of organization, either unions or professional organizations, because they have nothing to offer the industry, and can do a lot of harm through rent seeking behavior.
I'm not opposed to regulation that forces businesses to protect user information better, or provide better privacy safeguards. But these are regulations of the business practices. I don't want to have to get a certificate for something I can read online, even if someone else worked really really hard to get their certificate.
I agree with most of what you say, but there has to be more to the definition of engineering than "important stuff smart people do". The best working definition I have comes by way of several of my college professors:
An engineering problem is one in which you are given a set of requirements and asked to minimize cost; anyone who solves such problems is an engineer.
Most subdisciplines of engineering have developed their own language and standards for how to specify the requirements, develop potential solutions, and analyze the cost of those solutions. In young subdisciplines, like software engineering, these can appear more like folk wisdom than rigorous processes sometimes; that doesn't mean they're not engineering, just that we still have a lot to discover about them.
I don't work in the software industry. But I'm often frustrated by nitpicking over who is or isn't A Real Engineer.
Implicit in these discussions is the concept that engineers are superior to mere technicians or operators. As an engineer I have worked with technicians who want to go back to school to become an engineer, because of the perceived prestige and earning power that would come along with it. Often, they don't even realize that they make more money than I do [1].
In my industry the chief divide between engineers and technicians is that engineers design systems whereas technicians construct and operate them. These are fundamentally different jobs, each with its own challenges and benefits, although they often overlap. Pay is roughly the same, though engineers tend to have more generalized knowledge that can help them shift into a different sector more easily during a downturn. Both roles are essential, and I like to joke that if all the engineers disappeared, the technicians could keep things running for at least a decade, but if all the technicians disappeared, the lights would be out within 24 hours.
Good engineers can't function without good technicians. Both have a good deal of specific knowledge that the other does not. And somebody who is good at one role is rarely good at the other.
Be an engineer because that's what you want to do, because you genuinely feel that designing systems using the application of engineering theory is better situated to your skills and personality, not because you think it might be more prestigious or respectable that what you're currently doing.
[1] I work in the power industry where a skilled technician commands a similar or higher hourly rate to an engineer, more overtime and usually does a hell of a lot more work, like fixing overhead power lines at 2am during a winter storm.
In general, this article seems pretty weak. It's light on actual arguments (including any real arguments for its titular conclusion) and instead is basically saying "I'm successful and happy despite calling myself a programmer, so you should too."
> The impact of these choices on relationships could thus be weighted as more important than the impact on career advancement because it's more predictable.
That's an extremely lazy argument. Something can easily be both very hard to predict and also crucially important.
For a business example, it's much easier to predict the cost of your rent than it is to predict the success of your employees but the latter is much more important to success.
It strikes me that much of the advice in "Don't Call Yourself A Programmer" is more actionable than the counterpoints in "Do call yourself a programmer". While there may well be advantages to working for 10+ years in one company, it can be difficult to engineer your (programming) career to achieve that these days. Companies go bust, get acquired, go through re-orgs and cost-cutting rounds of layoffs and it's not easy to select a company at the outset of your career that will be unusually safe from such events.
Over the course of my career I've seen many good engineers laid off for reasons having little to do with their engineering ability. I've also seen companies go bust with very little warning for the employees, people who were happy with their jobs re-org'd into positions that made them miserable and engineers who weren't laid off but did make friends with their co-workers see many of their close friends laid off and often as a result move away to another city/country.
I think even if your ideal outcome is a long career at the same company working with many of the same co-workers you'd be well advised to plan for not having that option and to be prepared for finding other work at any time if your circumstances change due to external events.
A big disadvantage to working for the same company for a long period of time is that you will almost certainly get paid less than you would if you changed jobs regularly. The biggest raises these days come during job hops, rather than annual performance reviews.
The strange thing about the real world is that your salary is almost completely divorced from your actual skill. Take a skilled person who never negotiates and the result is that they're paid less than someone many times less skilled but who negotiates.
So it's not necessarily about "are you good enough?" but rather "how much do you want to get paid?" And once you focus on the latter question, you realize that skill is a tiny portion of it. Your salary is mainly dominated by how much time you have to shop yourself around, how quickly you can get several offers from different companies, and how long you can afford to say "no." The last one is very important, because if you get through an interview stage and are unable to say "no" if you need rent for example, then you'll end up with a low non-negotiable offer. You can bluff, which is always worth attempting since I'm not aware of anyone who lost out on a job offer for bluffing, but if their initial offer is $X, and you say "no, $X + $Y please" and then they say "$X + $5k is our final offer," then your options are to accept or to shop. And if you have no time left to shop around, then you're forced to settle. That's how you end up with a low salary.
All of this is obvious when someone explains it like that, but the trouble is, few people talk about stuff like this. You can spend your time from college to career without even really examining any of this, to your personal detriment, and you won't even realize it. As Patrick said, you can easily get +$5k at your next job with a minimum of effort. If you have time to shop around for several months, then you can get +$40k or more in the right circumstances.
Sorry for the ramble. These are just some unintuitive things which were surprising to me.
This is far from the true most of the time. In my experience the only places where pay doesn't mostly depend on skills/smarts/effort are government and to a lesser degree the big monopolies/oligopolies like Comcast.
What I'm saying is, if you're pretty sure you're more skilled than some of your coworkers based on whatever heuristics you choose to use, there's an excellent chance those less-skilled people are making more money than you if you haven't been aggressively negotiating your salary.
The cool thing is that negotiation skills are a hundred times easier to learn than programming skills. A few weeks of effort will net you thousands or tens of thousands. The effects are cumulative over your life, so the sooner you start, the better.
> In my experience the only places where pay doesn't mostly depend on skills/smarts/effort are government and to a lesser degree the big monopolies/oligopolies like Comcast.
Your experience is definitely different from mine them. Even in startups, I regularly see developers with less skill being paid much more than their better colleagues merely through negotiation.
The key determinants of salary, in order of importance, are:
I never understood why "developer" became the dominant nomenclature for professional coders - to me it's short for "real estate developer". Since I do design and optimize processes etc. I prefer to call myself a "consultant" rather than developer or programmer, which I always felt were too limiting and made clients think of me as the guy doing who-knows-what in the basement.
The problem with "consultant" is the big-5 consultants out there who absolutely dilute the term as many of them don't know a thing about coding... even the ones billed e.g. "Enterprise Software Consultant" - could only be implementers and not developers.
I call myself programmer, but we generally refer to ourselves as developers now. At the previous place, we were Programmer/Analysts and then right before I left they had changed it to Software Engineers. I find it all pretty amusing.
Calling yourself a Software Engineer when you're not is like calling yourself a Surgeon when you're a Nurse. A Software Engineering degree is way more difficult than a Computer Science degree, they are not the same. A 3rd of students drop down to Computer Science or something else after they fail in the first 2 years. This is at least the case in Canada.
Isn't it cultural imperialism or something to insist that other cultures honor the standards of your own?
Seriously, this whole "my culture says you need this certification X to be an engineer so you can't be one if you don't have it" is just a stupid definitional debate. It doesn't even matter if you win... nothing changes! Not a single person will lose their job Monday or even so much as change their title even if you somehow "win". So who really cares?
Maybe it's an ingroup vs outgroup thing. Living in an area in Canada with a large population of engineers (in oil and gas), I meet a lot of people who are touchy about who gets to be called an "engineer".
They seem to forget that military engineers are "engineers", and they've apparently been around since the early 1600s [1]. And locomotive engineers are "engineers", and it looks like they don't even need post-secondary schooling [2].
And the rules around the P.Eng. titles are provincially regulated as opposed to federally, meaning the rules in Ontario (where apparently the term "Engineer" is protected) is different than in Alberta (where the protected term is "Professional Engineer").
That's why in Alberta, Raymond Merhej was sued for using the title "systems engineer" (as an Apple Canada-certified systems engineer) but the suit was dismissed in late 2003. In response, the Association of Professional Engineers, Geologists and Geophysicists of Alberta (APEGGA) said basically they'll lobby the government to amend the laws to prevent that in the future. [3] I don't know if such an amendment was ever completed though.
I wonder if engineers in traditional fields are protective of their title because they work with a lot of engineering technicians, so they feel they need to differentiate and protect their work?
I am only stating what it is in Canada and many other countries as a response to "this is the way it is in the States" viewpoint. Having proper accreditation means when I visit a doctor, I know they have the skill sets required and not someone that just wants to be a doctor. Software has become more and more important to things like personal and financial safety, national security and to ensure in general planes don't drop out of the sky because there was a bug in the autopilot. This is why it's been separated in many countries. If you lie about your accreditation in Canada, you will definitely lose your job.
So everywhere else in the world should do exactly as I do and given that both the Uk and USA (the two largest English speaking technical nations) don't enforce CEng / PE to use the term engineer I am not sure what your point is.
GEE GOLLY GOSH I FIGURED THAT OUT FROM ALL THE OTHER POSTS.
Seriously, what was the point of your posting that YET AGAIN? Could you not infer that I already knew that from the contents of my post? You're moving beyond tedious into making me wonder if there isn't actually something a bit wrong with you people who can't stop talking about this when it's not even on topic.
In the USA they don't have the same "protected" status or definition of "engineer" that exists in parts of Canada. In Quebec, only graduates with a degree in engineering can legally call themselves an engineer. In the USA, anybody can call themselves an engineer... there isn't the same distinction between Computer Science and Software Engineering.
There are some restrictions on how and when you can use the term engineer in the US. I believe the way it works is that the are practice restrictions and title restrictions.
For instance, I wouldn't be allowed to call myself a Structural Engineer or practice as a Structural Engineer without the proper licensing. Industrial Engineering, on the other hand, is just a title restriction - you need to pass the Industrial Engineering PE to call yourself one, but there's no restriction on practice associated with it [1]
But yeah, generally speaking, sticking the word "engineer" after something is allowed here. You can be a "special effects engineer" or a "sanitation engineer" or whatever. "Software Engineer" is actually controlled in a few states, though.
One other thing to keep in mind is that in the US, elite universities like MIT, Stanford, Berkeley, and so forth typically offer a CS degree, but not a software engineering degree - though top CS programs are often ABET accredited.
Be careful about applying your specific experience (from your country) to slander entire groups of people.
For one thing, engineer is not a protected term in the US. It's not at all like the fraud which would be committed by a nurse calling himself a surgeon.
More importantly, the majority of excellent US universities don't even have a "software engineering" degree. Almost universally, the good developers I see coming out of top universities majored in "computer science."
Anecdotally, most people with "software engineering" degrees come from shitty vocational programs.
We'd all be better off if we stopped fussing over titles and realized that the only reasonable way to evaluate someone is to look at their actual experience/education.
Thanks, yes it seems to be very different. It takes longer to get a SE degree in Canada so a clear distinction is made. By no means would I even say that it's necessarily better as I've hired and worked with some amazing developers with no post secondary education at all, so good people are good people. But it is a longer degree with quite a few more courses and a clear distinction is made if you decide to pursue it here. Cheers.
Anecdotally, the SE & Non-CS courses I've taken (at a well-known US university) were kind of joke business-y classes; 90% of the time I spent on those courses was in lecture.
What you say may be true in Canada, but I'm pretty sure at best the opposite is true in the US (in terms of direction of attrition). But it's probably better to just admit that different fields are different, and rank-ordering is nothing more or less than a way to start flame wars and make people feel inferior for not being like you.
edit: also, your analogy is completely absurd. Even in Canada, the schooling/accreditation disparity between RNs and doctors is completely incomparable to the schooling disparity introduced by choice of undergraduate major...
Absurd in the States. My analogy was to show that falsifying your title as an engineer here is the same as claiming to be a doctor, both are against the law here. The course load for SE is higher and it's a longer degree so the number of courses required to obtain it is actually a lot more (here).
That is mostly because the class workload requirements are higher. In terms of math, csc, and seng courses you would be taking, it's fairly similar. It's because you have to take the general engineering core where you learn the start of mechanical, electrical and other engineering specialities and you take ~5 high workload classes per semester than ~4 to make up for it.
So the amount of stuff you study is about is more broad because you are studying other somewhat unrelated topics.
It's more like working 60hrs/wk vs 40hrs/wk as a nurse. Your still just being a nurse.
Besides workload issues, I think some people who drop computer/software engineering programs to go into computing science programs may simply be finding that they have no interest in things like physics or chemistry at the university level.
First year engineering courses in Canada, at least at the universities I know of, are pretty similar across all of its sub-disciplines. At UBC, first year courses include 4 physics courses (1 of which is a lab course) and 1 chem course [1]. At U of Alberta, first year courses include 1 physics course, 2 mechanics courses, and 2 chem courses [2].
At both UBC and U of A, first year engineering students get to take just one course on computing science/programming. So if you love to code and go into engineering to become a software engineer in Canada, you better also at least tolerate taking a bunch of chemistry and physics/mechanics courses...
Pretty surprised how many people are so offended. I apologise. But this is not an opinion and it is indeed apparently very different than the states which I wasn't aware. I didnt say anyone was better than someone else, just stating facts that certain titles require more accreditation, the same as other designations and using the medical field as an example since it's also upheld by the law in the same way. Calling yourself an engineer in Canada if you're not is illegal. Apologies again to anyone who was offended.
What a load of crap. You also can't call a Ferrari a Lamborghini because they're trademarks. When someone says "your race car isn't a Ferrari so you shouldn't call it a race car", we look at them funny, scold their irrelevant and shallow opinion, and redirect our attention to someone more mature.
My title is literally "Software Development Engineer". I don't actually call myself an engineer, but it's ridiculous to say that I shouldn't be allowed to call myself one when my company seems to think I, along with thousands of other people, am one.
I like how this will get down voted because people don't like it. This is a fact, you will not be recognized in Canada as a Professional Engineer and if you claim you are one in your practice there are legal consequences, the same if you practice as a doctor without the acknowledged certification. I am just stating facts...
The fact that you cannot claim to be an engineer in Canada without the appropriate credentials is a fact. Your statement that "[a] Software Engineering degree is way more difficult than a Computer Science degree" is not a fact. I have seen this whole 'CS vs SE' debate in the past, typically in a joking manner. Your manner however is downright insulting.
Apparently only in Canada but it is a longer degree with many more courses and is considered (here) to be more difficult to obtain. This doesn't seem to be the case in the US though. Cheers.
I don't think it's "because people don't like it", but rather because it's only true in a few countries that most HNers neither live nor work in, and you spoke as if it was applicable everywhere. That, on top of the fact that the article had nothing to do with the term "Software Engineer."
Facts of Canada, not the entire world. The counterpoint is equally valid in other countries. I can call myself an engineer all I want, nobody will bat an eyelid[1].
[1] Well, not me personally, I do hold an electronics engineering degree.
You can only call yourself an Engineer under specific circumstances:
1) You follow a well defined and repeatable process
2) You are able to measure progress
3) You have predictable results
4) You are capable of adapting to requirements change
5) You follow a standard of some sorts (coding style, organization, etc)
6) You provide thorough documentation
People who don't adhere to these principals are just developers/programmers. If you just set out and hack on some project, then you are not engineering something. A lot of engineers hack/develop/program on their free time, but as a professional on a professional project they adhere to these principals (and therefore are engineering).
There are a lot of people in this world who call themselves engineers without actually being an engineer. "Customer Service Engineer"... what are you actually engineering? In software in particular, there's a lot of people who just don this title because it sounds more impressive ("Systems Engineer" instead of just calling themselves an Admin)... but if you speak with them about their process, etc... it becomes clear they just hack on something until is works (sort of). That's not engineering; that's not a well defined and repeatable process that one can follow every time and produce predicable results. They aren't able to measure their progress other than a best-guess.
None of this is true. You can call yourself an engineer for any/no reason whatsoever.
What you're getting at is some kind of industry certification, like the PE, that would only allow those who qualify to call themselves engineers.
But software engineering doesn't have that. Therefore, anyone can call themselves an engineer if they want to, and don't have to pass your little criteria here.
Just to clarify, in the US a PE (Professional Engineer) is not certified: Professional Engineers are licensed at the State Level to practice independently. Licensure comes with direct personal liability that cannot be assigned to a corporate person and a legal obligation to protect the public even if doing so is contrary to a client's wish or interest.
There's no equivalent in software, and the term "software engineer" has little of the rigor envisioned when Margaret Hamilton coined it.
That is interesting - the idea of direct personal responsibility for flaws or bugs is one which would soon make NASA's development processes look lacksidaisical.
I do wonder how we will manage to actually become a profession.
It is true that a person whose primary area of practice is software can become a professional engineer in all Canadian jurisdictions, but is comparatively difficult to meet the experience requirements relative to traditional engineering disciplines and very few software professionals hold a P.Eng. license even though they may have the relevant degree.
The license is also seen as largely irrelevant in software as unlike traditional disciplines there are no legislative requirements to have a P.Eng. sign off on certain types of work, nor does most software development fall under the definition of engineering. In contrast, I work in the power industry and the involvement of a P.Eng. is usually a necessity at the design, construction and commissioning phases of utility electrical work.
Also, Canadian jurisdictions do not distinguish between disciplines of engineering in licensing, a Professional Engineer is responsible for self-regulating themselves to the areas of practice in which they are competent. That is, a Professional Engineer holding a degree in mechanical engineering can seal electrical schematics, if she feels that she is competent to do so.
In short, yes you can be a Professional Engineer as a software developer in Canada, but since most software work is not considered to be engineering under the official definition[1], one does not need to be a P.Eng. to do it.
It is actually a specific degree that is a minimum four years at specific Universities and then at least one year under another acknowledged Professional Engineer. You are then honoured with an Iron Ring that is well known in Canada that you can only obtain through the proper certification (as some colleges try to offer lesser degrees that aren't acknowledged). It's no different than a doctor or dentist, you can't legally professionally practice without it. The courses are geared towards theory, business, management and ethics rather than just proper or efficient coding and documentation.
The Iron Ring has nothing to do with the licensure of professional engineering. It is administered by the Corporation of the Seven Wardens which is not connected to Engineers Canada or any of the provincial or territorial licensing bodies.
I actually wonder if (and subsequently when) software will move in that direction, though.
As computers become more and more involved in systems where loss of life is extremely possible (e.g. driverless cars), I wonder if there will be a big push to have PE-equivalents sign off on software architectures, etc.
I especially wonder if there will be a big push to do this in the near future simply for liability reasons ("well Jane Smith is the PE we contracted with and she signed off on the software architecture that didn't account for rain, so go sue HER.").
Not that computer errors haven't already cost lives to-date, but as software starts truly running everything we'll likely see a lot of grumbling and response to software errors that cost lives.
OTOH, it's worked pretty well without licensing to-date, so perhaps not. I do think regardless we'll see a more evident bifurcation into "developers" (most of us) and "software engineers" (people who work on mission-critical software) in the upcoming decades.
The title of "Systems Engineer" generally refers to someone who designs and implements systems, as opposed to a "Systems Administrator" who administrates these systems.
Are they a "true" engineer? That's probably not for me to say, but the roles of "Systems Engineer" and "Systems Administrator" are very different things in my experience.
1) You follow a well defined and repeatable process
2) You are able to measure progress
3) You have predictable results
4) You are capable of adapting to requirements change
5) You follow a standard of some sorts (coding style, organization, etc)
6) You provide thorough documentation
Let me just sit back and take in a big whiff of that smug. Ahhhhh....
Engineering is implementation. Nothing more nothing less. Sometimes it's messy and barely getting something done. Sometimes it's about dotting every i and crossing every t. A good engineer knows when each and how much of each is needed when implementing a solution.
Truth be told, a lot of people with mainstream engineering titles (electrical, mechanical, etc.) don't actually engage in engineering according to your list. It's remarkably easy to be turned into a glorified CAD operator. A lot of product design work is tantamount to hacking -- mostly by trial and error.
> but if you speak with them about their process, etc... it becomes clear they just hack on something until is works (sort of).
Do you think these sort of people still try to possess the underlying mental model needed to know how the system works and what effects changing something will have on the system? Or are they literally cut-and-paste/change-something-till-it-works coders to whom the actual code is little more than meaningless incantations?
> Do you think these sort of people still try to possess the underlying mental model needed to know how the system works and what effects changing something will have on the system?
I think that would depend on the individual -- but largely yes, I think they do. But that still isn't engineering. They haven't clearly and thoroughly documented the system so that anyone else can step in and replace them if need-be. They aren't capable of measuring their progress since it's going to be an unknown guestimation (which phase of the project are you in currently and how long until this phase is completed and we can move onto the next phase?). A massive requirements change might throw this type of individual off and lead to a mental wall since the new requirements don't fit into their mental model of the system. And most importantly, their process is not well defined nor repeatable to the extent they could follow the exact same steps on new projects and predicably produce results.
A "Customer Service Engineer" is building/implementing a process where customers are able to interact with the company about the product they have paid / are paying for. Think of it as a SaaS where not everything can be automated (which is similar to creating a website to determine product/market fit that just includes a form which when filled out has you do the legwork related to your service manually.)
When disagreeing, please reply to the argument instead of calling names. E.g. "That is an idiotic thing to say; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
It's not a matter of truth, just convention. "Software Engineer" is a title used in many organizations - not a subtype of engineer. It means programmer. Trying to apply arbitrary qualifications after the fact to make it more "engineer-like" is misguided. Some of us are called Architect even though we don't design buildings or use CAD software to design our products.
I call myself a software engineer because it makes me feel smart and important. To me, that's the only difference between an engineer and similar jobs. I don't want to heap scorn on people who make sandwiches at subway, like many will use this discussion as an excuse for. Nonetheless, the reason the term engineer doesn't apply to them is that their job is neither important, nor requires a lot of intelligence.
Things like following a specific process, taking ethics courses, or being certified, are just things that some engineers happen to do. If you're smart and capable, you will do what is necessary to do the job well. Sometimes, this involves following a specific process, and sometimes regulation is necessary to ensure that everyone does this. But other times, individual judgement is the only solution. I believe this is the case for software engineering.
I don't really care about the word that much (although I really like calling myself and engineer), but what I do care is the implication that our industry needs to be regulated like professional engineers are. In fact, I'm opposed to all forms of organization, either unions or professional organizations, because they have nothing to offer the industry, and can do a lot of harm through rent seeking behavior.
I'm not opposed to regulation that forces businesses to protect user information better, or provide better privacy safeguards. But these are regulations of the business practices. I don't want to have to get a certificate for something I can read online, even if someone else worked really really hard to get their certificate.