Hacker News Reader

Comment by agarden | Hacker News Reader

His distinction between 'engineer' and 'developer' is artificial and easily criticized. That isn't what is interesting in this article. There are a lot of things that are.

Their method for avoiding the proliferation of different tools is interesting.

His discussion of the kind of people they want, once you ignore the semantics, is interesting. They want people who take responsibility and are always pushing the boundary of their knowledge into new fields. That's interesting.

My favorite part of the article was right at the end: "instead of asking questions about “why did something fail,” we want to ask why something succeeded, which is really easy to skip over."

View on HN

I agree that the use of the 'engineer' vs 'developer' terms in his context was not important.

What does irk me is that in real life, software developers who meet the Etsy CTO's standard often can't call themselves engineers. In many countries, misrepresenting oneself as an engineer without accreditation is against the law! [1]

In the U.S., there's no official occupational category for Software Engineer. It's just Software Developer (Applications), Software Developer (Systems), and Computer Programmer.

It is possible to get accreditation (http://ncees.org/exams/pe-exam/, under Software), but it didn't appear very useful to me aside from being able to call yourself an Engineer.

[1] http://www.canadianconsultingengineer.com/engineering/quebec...

I just want to point out that you can't become a P.E. in almost any jurisdiction just by taking a test. You have to complete a number of other requirements first.

I'm curious why it irks you.

There is actually software engineers. At the U of A, where I went, Software Engineering is separate than Computing Science. Software Engineering was run by the Engineering department, and they had the same rigours as the rest of engineering has. However, Computing Science was run by the Science department.

At the U of A? Could you ground that symbol, please?

University of Alberta, in Canada.

Ah ha!

UofA means University of Arizona around here

Note that, even though you can get a Software Engineering degree from the U of A, your likelihood of ever qualifying for your PEng is next to nil.

In 99.99% of software jobs in the Canadian or US job markets you're simply never going to be able to accumulate enough eligible hours in your 6 year EIT eligibility period, because of the way APEGA defines things. Software jobs where you're supervised by a P.Eng., as required by APEGA, are likewise virtually unheard of.

In Quebec, programming is not considered an engineer-reserved task and therefore experience cannot be used towards getting the PE. In practice, it means that even thoug there is such a thing as software engineering degrees (most universities offer it), no graduate ever becomes an engineer.

My opinion (as a jr mechanical engineer) is that the whole law is a bit outdated and seems to be geared 100% to civil engineers who actually need to stamp drawings.

> In Quebec, programming is not considered an engineer-reserved task and therefore experience cannot be used towards getting the PE. In practice, it means that even thoug there is such a thing as software engineering degrees (most universities offer it), no graduate ever becomes an engineer.

APEGA has essentially the same rule in Alberta. That's what makes it impossible to log enough eligible hours to qualify for a P.Eng. It may well be the same in all provinces.

Consequently, although APEGA insists that only Professional Engineers can use the title "Software Engineer", they simultaneously make it impossible for anyone to ever use that title in practice. There's been at least one court case about it that I can recall.

APEGA accepted my work experience record without issue, and I don't think it was a problem for anyone I worked with. Maybe that's because I worked at an unusually engineering-heavy shop? The software was rigorously tested for safety reasons, and a P.Eng. had to sign off on each release.

It's reasonably common for engineering grads of any speciality to simply end up working somewhere they don't need a P.Eng. While it might be nice if that were less common for Software Engineers, a P.Eng. must stand behind their work. Qualified candidates should show they worked in a manner that made an existing engineer comfortable ok'ing their work. That may not be common, but it's fundamental to the process.

I work mostly in the web services and web related technologies, and I've never even encountered a software engineer. However, I would want a software engineer working on my pacemaker, or perhaps other fields where safety is paramount like medical devices.

> Maybe that's because I worked at an unusually engineering-heavy shop?

Must be. Of the dozens of people who graduated from the Software Engineering program that I know or have worked with, you're the first I've heard of who's actually managed to obtain their P.Eng. I've known a couple of people who talked to APEGA extensively and were told that nothing they were doing (writing code, architecting solutions, etc) counted. Probably comes down to 99.99% of places aren't doing safety critical work and/or don't want to pay for formal verification.

Glad to know the title is being used, anyways.

This is why a bunch of my friends would go to companies like CDL systems where there are many software P.Eng.

I've heard that APEGBC is now regulating the term "Software Engineer", when it didn't before. Hootsuite had to change its job titles to "Software Developer".

Software engineering is a separate degree from Computer Science or Computer Engineering in (at least some) Canadian univs. Source: A Canadian client of mine.

> His discussion of the kind of people they want, once you ignore the semantics, is interesting.

semantics == meaning. once you ignore what he's trying to say, the discussion ends, no?

edit: yes, i could care less about semantics of semantics, but i can't bring myself to it.

Whether 'developer' and 'engineer' really mean what he says they mean is a question of semantics. Getting bogged down in a discussion of the appropriate uses of said terms, however, ignores what he is trying to say.

Will I be rewarded for responsibility of imperfect things? Will the company provide compensation and the necessary environment (trial equipment and software) for training to push the boundary of my knowledge?

How much time out of each day will be dedicated towards "pushing new boundaries of knowledge"?

When large projects squeeze into tight deadlines, how much of that boundary pushing will be abandoned in favor of shipping things?

Programming is a liberal art. As in: it involves language and explication of processes. The amount of actual engineering involved in making a successful application (like Etsy) is actually quite low. The amount of clear code that focuses relentlessly on the mission at hand (an admittedly squishy metric — after all, that's the nature of art) also seems to be quite low in the typical application, but naturally needs to be much higher.

For instance just putting a platform like Etsy entirely on Google App Engine would allow Etsy to focus on the liberal arts side of the problem. Because GAE "solves" most all the engineering problems that typically have plagued software practices on the web...

It is artificial and easily criticized but I think it is also widely understood and accepted.

Reply on news.ycombinator.com