Do Software Engineers Get Enough Respect?(techcrunch.com)
techcrunch.com
Do Software Engineers Get Enough Respect?
http://techcrunch.com/2014/08/16/do-software-engineers-get-enough-respect/
25 comments
What is the software engineering PE? Been programming professionally 18 years, never heard of it.
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.
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.
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
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
I think the parent post is referring to the "Practice of Engineering" exam: http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-f...
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.
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.
Engineering as a profession has a licensing system similar to medicine and law. In the US this involves several years of on the job training as a Jr Engineer and then passing two exams: the generic FE (Fundamentals of Engineering) and then a field specific PE (Principles and Practice of Engineering). Passing these exams and becoming licensed is all but required to practice civil engineering, but much less important in most other fields.
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.
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.
[deleted]
If we're talking about someone that passed the software engineering PE, then yes, I think they get plenty of (well-deserved) respect.
(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.
(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 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.
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.
>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.
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.
> 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.
"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.
did you read the post or just the title? nobody is arguing that engineers are the least respected people in the world.
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.
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'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.
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.
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.
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.
This is absolutely great and 100% on the mark. I especially agree with "we feel the effect of every hack put in to make a deadline". It's almost a relationship you can develop with the codebase; you can spend so much time in there that it begins to mean more. We finally removed a section of ugly code that's been in the system for over 2 years and I'll tell ya, I felt emotionally uplifted after it, as if a weight had been removed.
Perhaps 10% of managers and executives are talented and worth a damn. The other 90% are really good at playing politics and externalizing costs. Technical debt is a great way to externalize costs, because the ones who suffer are usually late-coming maintenance engineers (who tend to be juniors, with no credibility).
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.
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.
>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".
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".
(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.
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.
[deleted]
[deleted]
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...
looks like it was a game of manipulation...
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.
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.
okaaaay. sorry to me, staff software engineer != director.
Did the author use one of his own tweets as source material?
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.