
Do Software Engineers Get Enough Respect? - keda
http://techcrunch.com/2014/08/16/do-software-engineers-get-enough-respect/
======
mcmancini
If we're talking about someone that passed the software engineering PE, then
yes, I think they get plenty of (well-deserved) respect. I'm guessing that's
not whom the article is referring to however...

I met a lot of "software engineers" that think their mad coding skills are
singularly notable or worthy of respect in business. They're wrong. Technical
ability is but one aspect of business. The developers who get that, who have
other business skills and/or are willing to learn other business skills I
greatly respect and value. A developer who is competent at coding and has one
of good communication skills, project management skills, interpersonal and
conflict resolution skills, is of much greater value to me than a developer
who is excellent at coding and mediocre elsewhere.

~~~
csbrooks
What is the software engineering PE? Been programming professionally 18 years,
never heard of it.

~~~
mcmancini
In this context, PE is the professional engineering exam. You take it in a
specialty area, and software engineering was added last year. It's one of the
last steps for licensure as a professional engineer.

Some states, like Texas, are extremely picky about who calls themselves an
engineer, irrespective of industrial exemption (which the vast majority of
people fall under). PE licensure in other engineering areas (like civil
engineering) is required to offer services to the public, helps when offering
expert testimony, and can be required for principals at consulting firms. The
software engineering PE is an extension of IEEE's efforts in software
engineering, and is probably a good thing for safety-critical industries.

Since passing the fundamentals of engineering (FE) exam is (usually) a
prerequisite, someone who has a PE in software engineering probably knows
their way around a free body diagram or Laplace transforms or MSD systems,
i.e., stuff the other engineering fields do.

~~~
angersock
Huh. Now that's fascinating.

So, if my FE is still valid, I could look into the PE for software? I'm
intrigued.

EDIT:

Link for Texans:
[http://www.tbpe.state.tx.us/software.html](http://www.tbpe.state.tx.us/software.html)

------
ianbicking
> [As a managerial candidate] the CEO talked to Bill as an equal, not as a
> paternalistic, bullshitting, “this is good for your career” authority
> figure. There was a tone of equality that a software engineer would never
> get from the CEO of a 100-person tech company.

As I've gotten older I've learned people often interact with me the way I
expect them to. If I expect them to be patronizing while I am submissive, I
will be shy and withdrawn and the person will try to move on from the
conversation, often in a way I will find patronizing (especially because I
will compare their responses not to what I said, but to what I wanted to say).

Similarly if I interact with someone as an equal they will respond in kind.

Managers are more likely to have figured this out too (if they are any good),
while engineers are often quite poor at this.

------
FLUX-YOU
>as a class, we are downtrodden, disrespected, and disenfranchised?

Oh, please. If any of you ever want to know what this _actually_ feels like,
take a job in retail, customer service, food prep, or low-level hospitality.
There are many more jobs out of the limelight that are underpaid and under-
respected (in the USA, which is my perspective) and take just as much of a
toll on you as building a ridiculous system to please some suits to make the
thingamajig do the fancy voodoo.

Should engineers get more respect? That's a valid and fair question, and
companies will pay more respect or start seeing loss when your core team
leaves.

But don't play this off like you're some kind of victim in life. At the very
least this is just terrible word choice to describe the problem.

~~~
gopalv
> Should engineers get more respect? That's a valid and fair question, and
> companies will pay more respect ...

"You could do worse" is a rough straw-man in these scenarios.

I agree to that statement, but the cause of the outcry is rather interesting
to observe, if only from an "anthropology of small tribes/startups" angle.

In particular that Engineers seem to be bound by "passion" and that this costs
them from being economically rational.

When you equate economics to respect, then you get the message within the
tech-crunch article.

The rationals beat the irrational players and that's pretty much the way the
game is setup.

------
angersock
A lot of the problem is the sort of Morlock/wizard reputation engineers have
built for themselves--we are the magic fingers that make the magical machines
work, and woe be unto those who would pry into our secrets. We make a bunch of
theatrics about learning to program and code, but in doing so only cement in
the notion that it is somehow an unnatural act, not the logical extension of
communication and problem-solving we all know it to be.

So, of course, we're an _other_ \--and in a business sense, that means we're
less likely to be brought in for business decisions and less likely to be
trusted when we give feedback and honestly less likely (due to time spent with
an orderly worldview and fairly deterministic systems) to have useful
perspectives on how to do conduct sales or marketing.

And that sort of thing means that, when it's time to talk equity or raises or
whatever, we're at a disadvantage: we don't even see ourselves as normal
employees subject to the same progress of Labor that everyone else at a
company might enjoy, and they see us as magical unicorns that get treated
differently (and can be taken advantage of). You'll note in my language here a
strong us-vs-them streak, which somewhat underscores my point.

I think one of the biggest issues of respect is that there is something
different about writing software than making physical things on an assembly
line: if I write, in three months, a VBA/Access line-of-business package that
the folks sell for the next four years unchanged, I feel that I deserve a
different sort of compensation than if I did phone support/data-entry for the
same functionality for those same four years.

I think part of the issue is that we understand that, if well done, software
can be reproduced for free and yield dividends far out of proportion to the
invested effort: as such, it seems only right that we take a more equity-
focused approach. At the same time, because we are an "other", we're less
likely to be trusted with that sort of situation (a problem I face even now at
my current company).

Lastly, we have a sort of weird ongoing psychic trauma as we work on these
things--we feel the effect of every hack put in to make a deadline, every
corner cut to satisfy a weird business use case, and every test left unwritten
because goddamnitthishastobedonebyFridaythatsthelaunchday. It's a level of
madness that, if you're not an engineer, you don't appreciate...and then you
wonder why your engineers start jumping ship and you can't find new or good
coders.

~~~
ipsin
I'm curious about what you mean by _the theatrics_ of learning to code.

I like to present coding as "a thing you could do _right now_ if you wanted",
but I also think it's important to not _describe_ it as easy, because that's
frustrating to those trying to learn.

Your _Morlock /wizard_ comment is what scares me about the traditional office
environment, because I suspect that's the actual situation.

I had a friend who said I should come work at the phone company because "I'd
be the smartest one there".

First, I wouldn't be, and second, "you're the smartest one there" sounds like
a succinct description of hell.

~~~
angersock
So, the _theatrics_ \--and I say this like I'm not about to go out in 3 hours
and do volunteer work perpetuating the problem myself!--are that somehow
coding is any bit different from just breaking a problem into small, solvable
pieces and then explaining to somebody else (in our case, usually, a computer)
how to step through those pieces.

The theatrics are things like talking about whatever language is hot (doesn't
matter), whatever language is fastest (doesn't matter until later), how
important it is to learn to code (it isn't, except it really is), how
important it is to get subpopulation X into the industry (I'll explain more in
a second on that), how "not scary" things that look "scary" are, and so forth.

In some ways, I feel that we put so much an emphasis on learning to code and
making it accessible that we forget that it is a skill that is ultimately
vocational and practical--it's not snowflake work, it's done to solve a
problem. I fear that in our eagerness to make things more accessible we're yet
again making our field out to be somehow special enough to warrant that
different treatment.

I'd much prefer that we treat it as "this is how you solve a problem", or
"here's a cool thing we can do", or anything that's just more understated and
chill than how we seem to go about it.

A special note about the "making it more attractive to subpopulation X":

(I'm going to choose X = ciswomen, because that's what I've got the most
experience with)

Friend went to Chile and while there helped out at an "introduce women to
computing" event, of the same sort he and I volunteer at here stateside. He
reported (as memory serves) that the attitude there of the women was "Oh,
okay, new thingy, cool!", whereas at our events here it's usually "Oh,
computers/programming isn't really a girl thing, so we're trying something
foreign and maybe a little uncomfortable but fun".

I've even seen--much to my chagrin!--women helpfully setting double-standards
that serve to undermine their peers when new to the field. At one of our
recurring events, somebody who had some experience (hard-won, former non-tech
background, got in by way of blogging and SEO, now doing Python) was trying to
explain to one of her neighbors that "Oh, well, if you're a girl, you probably
haven't seen this before, right angersock?". I was quite flummoxed. The
problem there was that she was giving her peers the mental out of "Oh, another
woman had problems with this--so, it's okay if I have problems with it...it's
not expected of us anyways". It's incredibly subtle and incredibly toxic.

By contrast, in Chile, my friend found that because the computers and internet
and whatnot were (relatively) so new in their spread, _everybody_ was
considered a novice, and so there were a lot fewer gender boundaries
inhibiting learning and exploration.

I am saddened everytime we present tech as something being new or novel or
"something to be made easy" because I believe that in doing so we perpetuate
the idea that programming has to be hard or that it is some sort of optional
skill. Ideally, it should be something like riding a bike or sex--you know how
to do it, everybody kind of knows how to do it, and maybe you end up doing it
every day with people you enjoy the company of.

------
jasode
>Whereas in fact any engineer worth her salt will tell you that she makes
business decisions daily–albeit on the micro not macro level–because she has
to in order to get the job done. Exactly how long should this database field
be? And of what datatype? How and where should it be validated? How do we
handle all of the edge cases? These are in fact business decisions, and we
make them,

I would suggest that software programmers _do not adopt_ that mode of thought
unless they want to be disrespected by business people. Even with the author's
qualification of "micro-" as in micro-business decisions, it still does not
make the statement respectable.

I say this as a someone who's been on the business side _and_ the hardcore
software programming side. I think other engineering-entrepreneurs sympathetic
towards programmers would also be dismissive of such proclamations trying to
glamorize "VARCHAR(30) vs VARCHAR(40)" as a "business decision".

If software programmers want to be viewed as key business people, they have to
make _real_ business decisions and not dress up or redefine programming
thoughts as "business decisions".

~~~
ttctciyf
(Disclaimer: didn't read the article, just a response to the comment above.)

I agree that db field definitions are not "business decisions", but "edge
cases" can be.

I think the trick here, as a programmer, is to realise when the different ways
to handle edge cases of a design you've been asked to implement do become in
effect business decisions, and then _not make these decisions_ but instead
push back and insist the decisions are made by the business whose logic you
are implementing.

This can be hard work a) to make the product owners understand the
significance and b) to get them to commit to a decision, when often at heart
they'd rather you just "make it go away."

But it's much better in the end to be confident that corner cases and
unforeseen consequences of a design have been ok'd with the decision makers
whose actual job it is to make these decisions.

Rarely, but sometimes, you can open up or bring into view aspects of a product
design or business process that no-one suspected even existed like this, as a
side benefit.

This is from the point of view where there's a "separation of powers" between
tech and product teams, of course. If you work in an environment where that
isn't the case then you work with whatever process you have to make these
decisions.

------
andyidsinga
i followed the link to the original article ..then stopped reading it when i
got to: "...changing Staff Software Engineer to Director didn’t feel
dishonest, "

looks like it was a game of manipulation...

~~~
michaelochurch
There's job fraud and social status inflation.

Job fraud is claiming you can do something that you're objectively unqualified
to do, usually by counterfeiting formal certifications. For example, if you
claim to be a doctor but never went to medical school, you're guilty of job
fraud and should go to jail.

Social status inflation is something that everyone does, and that everything
has been doing for hundreds of thousands of years. It's ethically OK. Don't
get caught, because high-status people tend to be protectionist over their
pedigree, but there's nothing morally wrong with it. Generally it's best _not_
to put inflations in written form, for practical reasons. The answer to
"Should I lie on my CV?" is almost always "no". Write a truthful CV and keep
the inflations in verbal form as much as you can.

In truth, moving one's title to the management track is a _demotion_ in a way,
because it's so much harder to make "X-equivalent engineer" than X on the
management track. Take Google. It's ridiculously easy to make the Director
level on the management track. The main requirement is a pulse. It's extremely
hard to make Principal or Distinguished Engineer.

~~~
andyidsinga
okaaaay. sorry to me, staff software engineer != director.

------
bfwi
Did the author use one of his own tweets as source material?

