4 ms·

“Software engineers don’t understand the problem they’re trying to solve, and don’t care to.” In environments where management judges by (and is judged by) oth

“Software engineers don’t understand the problem they’re trying to solve, and don’t care to.” In environments where management judges by (and is judged by) other metrics, this result is inevitable.

user68858788 9y ago
This is the environment of large software companies.
jasonmaydie 9y ago
it's like blaming the assembly line worker for a badly designed car. Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.
- TeMPOraL 9y ago
  Also, a software engineer, being a technical person, can probably understand the problem quite well - but that doesn't help when the management doesn't care about solving the problem, but about sorta-solving it in order to maximize profits.
- Jtsummers 9y ago
  The analogy would be more appropriate if you said programmer and not software engineer. Anyone calling themselves a software engineer should be providing input into the design of the thing they're producing. Their role is very explicitly managing requirements and codifying them in, well, code. Either directly doing the programming or managing those who do.
  - vorotato 9y ago
    Except software engineers are often placed in subordinate roles because "WE WANT ONLY THE BEST". If you aren't given the authority to change the design, caring about it is an unnecessary source of anxiety and stress.
    - busterarm 9y ago
      Many times, I feel this. Really though, caring about what the problem is and trying to solve it means: 1) you work slower, 2) you ask a lot of questions, 3) you push back on things. Basically you're spending more mental effort trying to encapsulate what the problem is than the stakeholder. Those things will often make people either hate you or think you're bad at your job.
    - arvinsim 9y ago
      I agree with this. Imagine studying about web design, accessibility and usability for many years. You feel that you have something to contribute to the design of any app. Then the higher ups just hands you a spec and assigns you to a task to fix this bug/implement this feature without your input. That's pretty damn demoralizing. It will just push you towards caring more about streamlining your own workflow to rather than care about the actual usability of the app. Maybe that's the reason why there is so much interest in the in what workflow to use, what IDE/text editor to use, which languages to program in, etc.
  - Epenthesis 9y ago
    Are there companies that actually distinguish between these roles? For all the ones I've ever worked at, "software engineer" and "programmer" are synonyms. (I'm aware that there's been some effort to extend the legal significance of the word "engineer" to the software industry, but I'm curious if that difference is actually in practice anywhere today)
    - Clubber 9y ago
      I dunno, it's just a title game. I would guess it's because programmers in the 90s simultaneously had massive hubris and insecurity issues and wanted to be just as respected in the community as actual engineers, but who knows. Engineer invokes a sense of design, but so does programmer. When I started, there was no job where you just coded straight pseudocode specs. Business described the problem the way business does, and you had to convert that into a computer solution. Within that solution, different developers would own various parts of it. I would say the entire process of having coders who design systems and coders that just write code is inherently broken. Businesses want to think of development as prod-ops, but it's more like book publishing. I'm of the mind that if a coder who designs a system in enough detail to write pseudocode, he should just write the application. The better approach is have an architect/lead model subsystems and a general skeleton of the application, then have different teams implement the subsystems. Clearly defined interfaces on all inter-subsystem communications.
    - user5994461 9y ago
      Depends where you live, the distinction is clear where the title of "engineer" is protected.
    - jcranmer 9y ago
      There was definitely a time in the 90's when there was interest in having specialized software engineers/architects produce comprehensive designs for software that code monkeys would be tasked with fulfilling. I wouldn't be surprised if there were places today with strong management bias that thinks of "designing" as high value-add and "coding" as low value-add, and the two tasks as falling under the purview of different individuals.
- jakelarkin 9y ago
  Was thinking about this the other day: in big companies SWE individual contributors are the new line workers. Large enterprise ends up trying to manage them with business metrics goals without much visibility into the process issues that hamper overall quality or the production efficiency. Has anybody thought to apply the Toyota Production System in Engineering management? https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System
  - emodendroket 9y ago
    Yes, a whole lot of people have thought of that.
  - zdw 9y ago
    DevOps takes this as a primary input.
wpietri 9y ago
More specifically, I think those engineers are trained not to care. The have tried caring, experienced unpleasantness from their "superiors", and learned to stop. But this is reversible. I've done coaching in large-company environments and it's not at all hard to wake developers up, to get them to care again. The hard part is changing the environment so that caring is rewarded, not punished.
humanrebar 9y ago
> Software engineers don’t understand the problem they’re trying to solve, and don’t care to. I think this is unfair. Engineers usually have great (at least qualitative though often quantitative) insight into potential, cost, and complexity. The problem tends to be in getting that feedback back into "the room where it happens", the place where budgets are set, approvals are given, disputes are resolved, and performance is evaluated. In that room, there is usually a heavier presence by people who understand organizations, political concerns, messaging, and revenues. So when the cost and risk experts (the devs) are not in the room, of course we end up with overly complex, poorly understood products that chug along for a while and then become so massive that either: a. the project collapses under its own weight b. the project creates its own "gravitational pull" and starts pulling in resources to support itself; sometimes this is locked-in customers who cannot migrate away, sometimes this is locked-in enterprises who can't imagine how (and sometimes why) to kill it off
- DrScump 9y ago
  In some cases, however, ignorance on the part of the engineers (especially those with any say in the architecture of the application) of the users' needs can seriously damage the user experience for the life of the design. I face numerous examples in the sports-ticketing world all the time. For example, if you are going to a football game, what is the most important consideration to a fan? I say the most common priorities are: 1) nearness to midfield ("What yardline are my seats nearest?") 2) sun exposure ("Will I be baking in the sun all day? Do I need sunscreen? Will I be looking into the sun when trying to watch play on the field for a portion of the game?") 3) home vs. visitor side 4) elevation ("Am I low enough to see the players? Am I high enough to not be obscured by bench and media personnel?") If you're designing the site/app and you've never been to a (an American) football game, you won't know these criteria are important.
  - humanrebar 9y ago
    Sure. I was just saying the cluelessness goes the other way, too, so putting it on devs is at least one sided. Maybe a product genius can come up with better ways to sell shady stadium seats. But the technical contributors would be able to tell you that the shade-o-matic feature is layers of bad hacks that cost the company $X million a year in dev costs and astronomical security and maintenance risk since it is still running (partly) on old hand-configured Windows XP boxes using a hand-rolled UDP server library backed by an Access database. And that's for a key differentiator for the company. Profit and success doesn't happen until both sides of the story are accounted for.

user68858788 9y ago

This is the environment of large software companies.

jasonmaydie 9y ago

it's like blaming the assembly line worker for a badly designed car. Software engineers don't solve problems, they implement solutions someone else thinks will solve a problem.

TeMPOraL 9y ago
Also, a software engineer, being a technical person, can probably understand the problem quite well - but that doesn't help when the management doesn't care about solving the problem, but about sorta-solving it in order to maximize profits.
Jtsummers 9y ago
The analogy would be more appropriate if you said programmer and not software engineer. Anyone calling themselves a software engineer should be providing input into the design of the thing they're producing. Their role is very explicitly managing requirements and codifying them in, well, code. Either directly doing the programming or managing those who do.
- vorotato 9y ago
  Except software engineers are often placed in subordinate roles because "WE WANT ONLY THE BEST". If you aren't given the authority to change the design, caring about it is an unnecessary source of anxiety and stress.
  - busterarm 9y ago
    Many times, I feel this. Really though, caring about what the problem is and trying to solve it means: 1) you work slower, 2) you ask a lot of questions, 3) you push back on things. Basically you're spending more mental effort trying to encapsulate what the problem is than the stakeholder. Those things will often make people either hate you or think you're bad at your job.
  - arvinsim 9y ago
    I agree with this. Imagine studying about web design, accessibility and usability for many years. You feel that you have something to contribute to the design of any app. Then the higher ups just hands you a spec and assigns you to a task to fix this bug/implement this feature without your input. That's pretty damn demoralizing. It will just push you towards caring more about streamlining your own workflow to rather than care about the actual usability of the app. Maybe that's the reason why there is so much interest in the in what workflow to use, what IDE/text editor to use, which languages to program in, etc.
- Epenthesis 9y ago
  Are there companies that actually distinguish between these roles? For all the ones I've ever worked at, "software engineer" and "programmer" are synonyms. (I'm aware that there's been some effort to extend the legal significance of the word "engineer" to the software industry, but I'm curious if that difference is actually in practice anywhere today)
  - Clubber 9y ago
    I dunno, it's just a title game. I would guess it's because programmers in the 90s simultaneously had massive hubris and insecurity issues and wanted to be just as respected in the community as actual engineers, but who knows. Engineer invokes a sense of design, but so does programmer. When I started, there was no job where you just coded straight pseudocode specs. Business described the problem the way business does, and you had to convert that into a computer solution. Within that solution, different developers would own various parts of it. I would say the entire process of having coders who design systems and coders that just write code is inherently broken. Businesses want to think of development as prod-ops, but it's more like book publishing. I'm of the mind that if a coder who designs a system in enough detail to write pseudocode, he should just write the application. The better approach is have an architect/lead model subsystems and a general skeleton of the application, then have different teams implement the subsystems. Clearly defined interfaces on all inter-subsystem communications.
  - user5994461 9y ago
    Depends where you live, the distinction is clear where the title of "engineer" is protected.
  - jcranmer 9y ago
    There was definitely a time in the 90's when there was interest in having specialized software engineers/architects produce comprehensive designs for software that code monkeys would be tasked with fulfilling. I wouldn't be surprised if there were places today with strong management bias that thinks of "designing" as high value-add and "coding" as low value-add, and the two tasks as falling under the purview of different individuals.
jakelarkin 9y ago
Was thinking about this the other day: in big companies SWE individual contributors are the new line workers. Large enterprise ends up trying to manage them with business metrics goals without much visibility into the process issues that hamper overall quality or the production efficiency. Has anybody thought to apply the Toyota Production System in Engineering management? https://en.wikipedia.org/wiki/Toyota_Production_System https://en.wikipedia.org/wiki/Toyota_Production_System
- emodendroket 9y ago
  Yes, a whole lot of people have thought of that.
- zdw 9y ago
  DevOps takes this as a primary input.

wpietri 9y ago

More specifically, I think those engineers are trained not to care. The have tried caring, experienced unpleasantness from their "superiors", and learned to stop. But this is reversible. I've done coaching in large-company environments and it's not at all hard to wake developers up, to get them to care again. The hard part is changing the environment so that caring is rewarded, not punished.

humanrebar 9y ago

> Software engineers don’t understand the problem they’re trying to solve, and don’t care to. I think this is unfair. Engineers usually have great (at least qualitative though often quantitative) insight into potential, cost, and complexity. The problem tends to be in getting that feedback back into "the room where it happens", the place where budgets are set, approvals are given, disputes are resolved, and performance is evaluated. In that room, there is usually a heavier presence by people who understand organizations, political concerns, messaging, and revenues. So when the cost and risk experts (the devs) are not in the room, of course we end up with overly complex, poorly understood products that chug along for a while and then become so massive that either: a. the project collapses under its own weight b. the project creates its own "gravitational pull" and starts pulling in resources to support itself; sometimes this is locked-in customers who cannot migrate away, sometimes this is locked-in enterprises who can't imagine how (and sometimes why) to kill it off

DrScump 9y ago
In some cases, however, ignorance on the part of the engineers (especially those with any say in the architecture of the application) of the users' needs can seriously damage the user experience for the life of the design. I face numerous examples in the sports-ticketing world all the time. For example, if you are going to a football game, what is the most important consideration to a fan? I say the most common priorities are: 1) nearness to midfield ("What yardline are my seats nearest?") 2) sun exposure ("Will I be baking in the sun all day? Do I need sunscreen? Will I be looking into the sun when trying to watch play on the field for a portion of the game?") 3) home vs. visitor side 4) elevation ("Am I low enough to see the players? Am I high enough to not be obscured by bench and media personnel?") If you're designing the site/app and you've never been to a (an American) football game, you won't know these criteria are important.
- humanrebar 9y ago
  Sure. I was just saying the cluelessness goes the other way, too, so putting it on devs is at least one sided. Maybe a product genius can come up with better ways to sell shady stadium seats. But the technical contributors would be able to tell you that the shade-o-matic feature is layers of bad hacks that cost the company $X million a year in dev costs and astronomical security and maintenance risk since it is still running (partly) on old hand-configured Windows XP boxes using a hand-rolled UDP server library backed by an Access database. And that's for a key differentiator for the company. Profit and success doesn't happen until both sides of the story are accounted for.