3 ms·

While I agree with some of your points, this comment is actually doing the thing you're criticising, just in the other direction. You're claiming that your work

While I agree with some of your points, this comment is actually doing the thing you're criticising, just in the other direction. You're claiming that your work is complex and unknowable to outsiders (SWEs in this case). As a SWE-turned-product-manager, you're in an ideal place to teach SWEs about: - how to present to the business the risk of the kinds of complexity they deal with - the human realities of working on a team with other people - why the salesperson turned CEO just doesn't get them, man _Every_ function in a tech business has hidden complexity.

disgruntledphd2 1y ago
Every function in human society has hidden complexity. Like, reality is very very detailed. Everytime I learn something new I discover oceans of complexity and nuance. That's just the way the world is. Now, software is hard because the complexity isn't as visible to most of the org, but also because software people tend to be less than good at explaining that complexity to the rest of the org.
- Raidion 1y ago
  I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Tech debt is real, but so is the downside of building a system that has constraints that do not actually align with the realities of the business: optimizing for too much scale, too much performance, or too much modularity. Those things are needed, but only sometimes. Walking that line well (which takes some luck!) is what separates good engineering leadership from great engineering leadership.
  - disgruntledphd2 1y ago
    > I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Hey, I resemble that remark! Yeah, I get where you're coming from but i do really feel that it's more of a communication issue, along with the abstract nature of software. I mostly do data related stuff, and have often had the experience of finding "wrong" data that doesn't have a large impact, and every time I need to remind myself that it might not matter. You can also see this in the over-valuation of dashboards vs data engineering. Stakeholders lurve dashboards but value the engineering of pipelines much less highly, even though you can't have dashboards without data.
  - hjeepn 1y ago
    To be fair, this bias for "correctness" is both logical and necessary, and not something that stems from inability or unwillingness to understand business goals. That tech debt you took on to meet the latest oh-so-important deadline? Prepare to live with it forever, because the next hare-brained initiative is right around the corner. Frankly, the business's goals are not my goals, and unless I own the place, I'm not sacrificing good work for it.
- icameron 1y ago
  This is spot on, and a very good explanation why the Agile Industrial Complex is so despised: It papers over the nuance and detailed complexities of software engineering. There are probably similar oversimplifications in other domains but the AIC particularly frustrates SWEs because it deceives management types into believing there isn't actually as much complexity that we are “less than good at explaining” as you accurately stated.
potatolicious 1y ago
> "You're claiming that your work is complex and unknowable to outsiders" I didn't get that message at all. If anything they're saying that the complexity of PM work is entirely knowable, but the many engineers do not bother, because they do not acknowledge the existence of that complexity in the first place. And honestly, they have a point! Our industry is rife in this attitude and it sucks. Look at how many posts about totally disparate fields are on HN all the time where coders suddenly become experts in [virology|epidemiology|economics|etc] without so much as a passing acknowledgment that there are real experts in the field. We even do it to ourselves - the frequent invocations of "pffft I can build that in a weekend" dismissals of other software projects, for example. Shit is complex, that complexity is knowable to anyone willing to roll up their sleeves and put in the work, but there is definitely a toxic tendency for people in our field to be wildly dismissive of that complexity in fields that aren't ours. And yeah, that includes dismissal of complexity in our own field but not directly in the function of programming.
watwut 1y ago
> the human realities of working on a team with other people Developers work in teams with other peers. You know who dont? Managers - they exist in hierarchy but do not have peers they wpuld actually cooperate with. They have competitiors and tactical allies, but never cooperate with equals. And it shows.

disgruntledphd2 1y ago

Every function in human society has hidden complexity. Like, reality is very very detailed. Everytime I learn something new I discover oceans of complexity and nuance. That's just the way the world is. Now, software is hard because the complexity isn't as visible to most of the org, but also because software people tend to be less than good at explaining that complexity to the rest of the org.

Raidion 1y ago
I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Tech debt is real, but so is the downside of building a system that has constraints that do not actually align with the realities of the business: optimizing for too much scale, too much performance, or too much modularity. Those things are needed, but only sometimes. Walking that line well (which takes some luck!) is what separates good engineering leadership from great engineering leadership.
- disgruntledphd2 1y ago
  > I would also argue that software (and the people that write it) have a "correctness" bias that is not fully aligned with business goals. Hey, I resemble that remark! Yeah, I get where you're coming from but i do really feel that it's more of a communication issue, along with the abstract nature of software. I mostly do data related stuff, and have often had the experience of finding "wrong" data that doesn't have a large impact, and every time I need to remind myself that it might not matter. You can also see this in the over-valuation of dashboards vs data engineering. Stakeholders lurve dashboards but value the engineering of pipelines much less highly, even though you can't have dashboards without data.
- hjeepn 1y ago
  To be fair, this bias for "correctness" is both logical and necessary, and not something that stems from inability or unwillingness to understand business goals. That tech debt you took on to meet the latest oh-so-important deadline? Prepare to live with it forever, because the next hare-brained initiative is right around the corner. Frankly, the business's goals are not my goals, and unless I own the place, I'm not sacrificing good work for it.
icameron 1y ago
This is spot on, and a very good explanation why the Agile Industrial Complex is so despised: It papers over the nuance and detailed complexities of software engineering. There are probably similar oversimplifications in other domains but the AIC particularly frustrates SWEs because it deceives management types into believing there isn't actually as much complexity that we are “less than good at explaining” as you accurately stated.

potatolicious 1y ago

> "You're claiming that your work is complex and unknowable to outsiders" I didn't get that message at all. If anything they're saying that the complexity of PM work is entirely knowable, but the many engineers do not bother, because they do not acknowledge the existence of that complexity in the first place. And honestly, they have a point! Our industry is rife in this attitude and it sucks. Look at how many posts about totally disparate fields are on HN all the time where coders suddenly become experts in [virology|epidemiology|economics|etc] without so much as a passing acknowledgment that there are real experts in the field. We even do it to ourselves - the frequent invocations of "pffft I can build that in a weekend" dismissals of other software projects, for example. Shit is complex, that complexity is knowable to anyone willing to roll up their sleeves and put in the work, but there is definitely a toxic tendency for people in our field to be wildly dismissive of that complexity in fields that aren't ours. And yeah, that includes dismissal of complexity in our own field but not directly in the function of programming.

watwut 1y ago

> the human realities of working on a team with other people Developers work in teams with other peers. You know who dont? Managers - they exist in hierarchy but do not have peers they wpuld actually cooperate with. They have competitiors and tactical allies, but never cooperate with equals. And it shows.