7 ms·

Do Software Engineers Get Enough Respect?

30 points by keda 12y ago

mcmancini 12y ago
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 12y ago
  What is the software engineering PE? Been programming professionally 18 years, never heard of it.
  - deleted 12y ago
    [deleted]
  - ColinDabritz 12y ago
    I think the parent post is referring to the "Practice of Engineering" exam: http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-for-software-engineering/ 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.
  - mcmancini 12y ago
    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 12y ago
      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
  - kec 12y ago
    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.
- michaelochurch 12y ago
  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.
deleted 12y ago
[deleted]
angersock 12y ago
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.
- mikegioia 12y ago
  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.
andyidsinga 12y ago
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 12y ago
  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 12y ago
    okaaaay. sorry to me, staff software engineer != director.
bfwi 12y ago
Did the author use one of his own tweets as source material?
jasode 12y ago
>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 12y ago
  (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.
FLUX-YOU 12y ago
>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 12y ago
  > 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.
- SonicSoul 12y ago
  did you read the post or just the title? nobody is arguing that engineers are the least respected people in the world.
deleted 12y ago
[deleted]
ianbicking 12y ago
> [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.

30 points by keda 12y ago

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 12y ago
What is the software engineering PE? Been programming professionally 18 years, never heard of it.
- deleted 12y ago
  [deleted]
- ColinDabritz 12y ago
  I think the parent post is referring to the "Practice of Engineering" exam: http://ncees.org/about-ncees/news/ncees-introduces-pe-exam-for-software-engineering/ 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.
- mcmancini 12y ago
  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 12y ago
    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
- kec 12y ago
  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.
michaelochurch 12y ago
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.

deleted 12y ago

[deleted]

angersock 12y ago

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.

mikegioia 12y ago
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.

andyidsinga 12y ago

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 12y ago
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 12y ago
  okaaaay. sorry to me, staff software engineer != director.

bfwi 12y ago

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

jasode 12y ago

>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 12y ago
(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.

FLUX-YOU 12y ago

>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 12y ago
> 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.
SonicSoul 12y ago
did you read the post or just the title? nobody is arguing that engineers are the least respected people in the world.

deleted 12y ago

[deleted]

ianbicking 12y ago

> [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.