Do call yourself a programmer, and other career advice (2013)
yosefk.com
yosefk.com
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.
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.
That also means we have a few millenia of catching up to do!
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.
Then again, so are most of the other comments 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.
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.
I do call myself a programmer. Some people prefer software engineer, architect, etc. I think it is very contextual.
1. https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
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.
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.
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:
1. Negotiation ability
2. Years of raise accumulation ("experience")
3. Skill
Working out what the product should be and how users interact with it for example.
[1] Well, not me personally, I do hold an electronics engineering degree.
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?
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.
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?
[1] http://cmea-agmc.ca/our-heritage-and-our-stories
[2] http://www5.hrsdc.gc.ca/noc/english/noc/2011/Profile.aspx?va...
[3] http://www.itbusiness.ca/news/it-industry-wins-round-in-engi...
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.
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...
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.
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.
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...
[1] http://students.engineering.ubc.ca/registering-courses
[2] http://www.engineering.ualberta.ca/ProspectiveStudents/First...
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.
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?
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.
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.
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.
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.
Source: I have an iron ring.
You can still be a developer, of course, and be responsible for critical software projects. You just can't call yourself an engineer.
There's no equivalent in software, and the term "software engineer" has little of the rigor envisioned when Margaret Hamilton coined it.
I do wonder how we will manage to actually become a profession.
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.
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.
Spend a few hours reading about the industrial revolution and you'll see NONE of this applies to the greatest mechanical engineers in history.
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."
http://en.wikipedia.org/wiki/Source-to-source_compiler
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