

The Problem with Job Titles: Part 2 - themullet
http://blog.workshape.io/the-problem-with-job-titles-part-ii/

======
poppahorse
Great article, and fascinating insight into the analysis of your data. Its
definitely a problem both ways. Companies hiring can't be sure their initial
hook will return appropriate candidates. Then candidates looking for a
suitable role can't really be sure what they are applying for will suit their
skill set and desires. Your classification of roles and candidates is
certainly a much more complete approach for ensuring various parties get what
they want, good work!

------
danielknell
looks like a trend towards more general skills than highly specialised people,
I'm calling that a win for cross stack engineers.

------
geebee
Interesting posts.

I'm not especially keen on the title "Software Engineer", though I accept by
now that it is deeply entrenched. While the title "Engineer" doesn't carry the
same general expectations of specific education and credentials as "Lawyer" or
"Physician", it does carry those expectations within more narrow titles - a
"Structural Engineer" means something very specific and people do have
specific expectations for it. It's a complicated topic, but I'm one of those
people who thinks that programming has deeper roots in math than engineering,
and I am unsettled by the idea that the PE people would be able to leverage
their control over the word "engineering" to gain control over who is allowed
to call themselves a "software engineer", and then use this power, through
scope creep, to start to restrict the practice rather than just the title. I
lean against the idea of formal exams (a "bar" for software). I'm not
completely opposed to it, but if it happens, I'd prefer to establish it
completely independently of any professional _engineering_ accreditation,
since I just don't think computer science, or even the modern practice of
writing software, is sufficiently similar to engineering to be considered a
subset of the PE exams.

Software Developer is fine. I never minded "Programmer", I guess some people
feel it's a low status sounding term that focuses too much on writing code
rather than the other tasks that are equally or more important to writing good
software.

Now, that second part there does hint at why job titles and especially (not
mentioned in these blog posts) job _descriptions_ ("job cards") can be so
essential for software developers. As I've gotten more "senior" in my career,
I have found my job card to be an essential line of defense on more than one
occasion. There are a lot of people out there who want to put software
engineers (I'll revert to the commonly used term here) in a box. They want to
see the programmer as the worker who can execute someone else's vision, but
they will try to deny the programmer the autonomy and decision making
authority that comes with a more senior role.

There is, of course, a limit to autonomy on all sides, and there are grey
areas between technical and business decisions, but it helps enormously to
have a document that lists what it is you were hired to do. Job cards for more
senior technical workers often have phrases like "establishes system
architecture", "evaluates and determines technology choices", or even more
deliberately ambiguous things like "works with business units to align
business goals with technology" (where autonomy can clearly overlap). But it
makes it clear - the technical side engages collaboratively with the business
unit, but it isn't simply there to execute whatever it is the business unit
tells it to do.

People often don't like job cards because they imagine the phrase "that's not
in my job card." However, I've found that's not really the problem, at least
for me. I'm more that happy to do things that aren't in my job card if that's
what needs to be done. But I have found myself in a position where I'm saying
"that _is_ in my job card." A business leader may want to take a decision that
at least (according to the organization) requires my input, and tell me how it
is going to be. If this escalates, it's very useful to have a signed, sealed
and delivered document establishing your role in the organization.

~~~
lambdaelite
> I lean against the idea of formal exams (a "bar" for software). I'm not
> completely opposed to it, but if it happens, I'd prefer to establish it
> completely independently of any professional engineering accreditation,
> since I just don't think computer science, or even the modern practice of
> writing software, is sufficiently similar to engineering to be considered a
> subset of the PE exams.

Too late, the first NCEES software PE exam was in 2013. It uses the IEEE/ACM
Software Engineering Book of Knowledge as a base and seems close to what the
old IEEE CSDP certification was trying to do. It's intended (as I see it) for
formally trained engineers who are working on software-intensive projects
rather than developers who want to do engineering work. Your point about
having someone besides NCEES do the licensure was tried (IEEE) and at least
for now will not be happening going forward.

To your earlier point, I do expect someone calling themselves an engineer to
have a basic grounding in chemistry, physics (mechanics, E&M, thermo), heat
and mass transfer, calculus, etc.—basically, the first 2 years of engineering
education common to all disciplines. I also expect that they're respecting
professional standards and ethics. I realize that "software engineers" feel
like they're an exception and it irritates me to no end, but I also don't see
the cat being stuffed back into the bag at this point.

edit: One frustration I've had recently was in hiring an engineer on a
software-intensive medical device project, and getting a bunch of web
developers applying for the role. I needed someone with an actual engineering
background, and tried filtering by including engineering undergraduate degree
as a requirement and "professional engineer" as a preferred requirement, to no
avail. If Silicon Valley wants to call everyone off the street a software
engineer, that's fine, but I need a job title to use in hiring for safety
critical software projects.

~~~
geebee
Thanks for your response.

I feel ambivalence about the use of "engineering" in software. We do have
"sound engineers" and "special effects engineers", consistent with a
vernacular use of engineering to mean "the ingenious use of technology" (made
up by me). Within that context, the term software "engineering" really isn't
especially outrageous. I think that the public is not threatened by this use
of the word, since they are not confused by the difference between a sound
"engineer" and a licensed structural engineer. However, software "engineering"
could slip into that grey area.

One thing that makes me worry less is the restructuring of the FE exams to
reflect the body of knowledge in the various fields. For instance, Industrial
Engineering is now substantially different from Mechanical even at the FE
level. Another interesting thing I learned is that certain fields are just
title based - I believe that this means you can't represent yourself as an
"Industrial Engineer" in a professional context if you aren't a PE, but there
isn't a practice restriction (at least that is how I interpreted it, because I
don't do either it doesn't really affect me).

But one other thing I would like to mention - while I phrased my argument in
the context of not wanting PE to gain control over software licensing, I do
agree with you about the term "engineering". I do agree that you should have a
background in those things you mentioned to be using the title where
"engineer" implies this sort of background, and it is hard earned.

So I'd agree that software engineers may be grabbing a title they don't really
have rights to, though I would still argue that software has far more in
common with math (even math theory, like abstract algebra) than heat and mass
transfer.

Oh one more thing - your description for the intended use of "software
engineering" as "formally trained engineers who are working on software-
intensive projects" sounds reasonable - it covers software for specific
engineering systems. My worry is of scope creep - the initial process is
limited, highly relevant, and justified, but it later morphs into an "I'm
licensed and you"re not" situation. If that happens, I'd almost want to see
some math body establish a degree requirement and math background (including
things like abstract algebra and real analysis), along with very intensive
algorithm questions, as a counterbalance (au contraire, mon frere, _you 're_
not licensed).

I read Milton Friedman's bit on "abolish the AMA" and enjoyed it, but
ultimately, I support limited licensing and credentials to protect the public
- however, I do feel that scope creep really is a serious risk here.

~~~
lambdaelite
> We do have "sound engineers" and "special effects engineers", consistent
> with a vernacular use of engineering to mean "the ingenious use of
> technology" (made up by me).

And railroad engineers! Can't forget them! :)

> One thing that makes me worry less is the restructuring of the FE exams to
> reflect the body of knowledge in the various fields.

I don't know anyone that took their discipline-specific FE exam instead of the
general one. Way back in undergrad, it was suggested that the general exam was
easier. Do you know what the advantage is of the discipline-specific FE exam?

> Another interesting thing I learned is that certain fields are just title
> based - I believe that this means you can't represent yourself as an
> "Industrial Engineer" in a professional context if you aren't a PE, but
> there isn't a practice restriction (at least that is how I interpreted it,
> because I don't do either it doesn't really affect me).

That's certainly the case for systems engineering, which feels related to IE,
but IE has a PE exam and systems engineering doesn't. You look at the projects
that systems engineering is applied to, and they're certainly the sort of
critical things (like aerospace) that you would want oversight over. I guess
those in charge see the systems engineering trade association handing things
fine without NCEES getting involved. Long live the industrial exemption I
guess.

I'm curious to see what happens to software consultancies, and if perhaps
principals are going to need a PE like you would see at other engineering
firms even if they're not handling safety or mission critical projects. A PE
certainly helps in qualifying as an expert witness. This point goes towards
your concern over scope creep, certainly a valid one.

~~~
geebee
The FE exams changed very recently - I'm not sure if there even is a general
FE exam anymore, though there probably is an FE common core to each exam.

[http://ncees.org/about-ncees/news/ncees-announces-changes-
to...](http://ncees.org/about-ncees/news/ncees-announces-changes-to-fe-exam/)

