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.
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.
While I take the point that there is a difference between code-monkeys who don't have deep understanding and serious well grounded engineers, I don't agree that a two year old exam in a field that's had a history of failed certification attempts is a reasonable benchmark.
I think part of the problem in the field that contributes to the article is that the field is young and we don't have strong, well accepted professional organizations and licensure yet. We're still figuring out what those look like, and dealing with some serious challenges in breadth as we do so.
The "software engineering" PE is apparently pretty new (first offered in 2013) and kind of an oddball since this industry didn't grow out of any engineering tradition and doesn't really place too much value on certification.
(Edit: On first read, I didn't know what the PE was. I thought you were just talking about the typical tech-company interview process.)
Difficult interviews (which many focused on, more than I did in the original article) aren't the problem. In fact, I think that difficult interviews are generally a good thing. My problem is that passing the difficult interview doesn't necessarily confer respect.
If I have to spend a whole day at a whiteboard proving my intelligence, fine. I'm confident that I'll pass. If after proving myself, I'm still offered 0.05% (at 50 people) and no relocation package, then I'm going to be pissed. I've already proved myself qualified for a real job with a real package, so either come up with one, or don't waste my time in the first place.
Challenging interviews are a good thing. Challenging interviews with no upside (i.e. even if you're smart, you still get the default shitty/take-advantage-of-clueless-people-in-their-20s engineer offer) are a total waste of time.
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.
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.
"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.
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.
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.
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.
Middle management (MacLeod Clueless) used to be the bilge pump system of the company. It cleaned up messes made above by self-dealing executives (MacLeod Sociopaths) and from below by checked-out subordinates (MacLeod Losers). Now, that function is being pushed increasingly to tech. We're what self-dealing HR thugs and narcissistic executives externalize their costs into.
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".
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.
looks like it was a game of manipulation...
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.
