Hacker News Reader

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.

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.

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.

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

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.

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.

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

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

This is a rather human failing - complexity is fractal: you only notice it when you get close enough to it.

However, I disagree that engineers only have to deal with the complexity of the computer; instead, I argue they have to translate the messiness of the organization and of every customer of the program and make it coherent to an inflexible computer.

And every exception and case added is a permutation that echoes through the system. (And, quite often, outside the system due to shadow processes that people use unintended consequences of the system to encode.)

That said, it's why I have so many of my senior engineers start learning the terms of business so that they can deliver those messages without me. It's part of my toolkit I expect them to learn.

I'd also argue most engineers don't think very hard about what's actually valuable to a company. A smooth build pipeline and ample test coverage are only worth whatever fraction of risk reduction of the product they are delivering. I have told teams to not do basic maintenance on software because nobody is going to care if it crashes because it has too few users. In the same vein I've asked them to fixate on making a tiny feature absolutely perfect because we know it's the thing 90% of users focus on.

> I'd also argue most engineers don't think very hard about what's actually valuable to a company.

My experience differs: many software developers think deeply about what is valuable to the company, but don't play the ferocious political games that managers do play (the only winning move is not to play).

Relatedly and because of their logic thinking, they thus often come to the conclusion that these scumbags of managers are clearly not what is valuable to the company.

This reminds me of a story my dad always told.

One time the organs of body had an argument. The brain said "I am the most important. I allow the body to think and avoid danger. If I die the whole body will die with me." The heart screamed "I am the most important! If I stop even for a few minutes the entire body will die."

So the argument continued. The kidneys, the liver, the skin, and the spine joined in. No one could agree who was the most important.

Then the butthole closed up!

I don't think the article claims that there isn't any hidden complexity in other functions, but that ignoring the hidden complexity of engineering/programming cause all sorts of issues and pain. The language is quite aggressive though.

I think a major part of the frustration is more the _assumptions_ around the work complexity. Like decision-makers more easily make invalid assumptions regarding the complexity of the software portion. A good PM will listen to the SWEs when forming these assumptions and good SWEs must be able to communicate about them.

This could be bias talking, though. Is it common for sales or support teams to be given milestones that are off by 50%?

> .. the most frustrating part about software engineers believing themselves to be the part of the business with the most complex, unknowable work. ..

>_Every_ function in a tech business has hidden complexity.

In my opinion, the conflict is in the distinction.

Stereotypes abound, but I have always found in this battle between worlds, there is a simple bridging maneuver: never work for someone, or accept management guidance, from someone who cannot also comfortably do your work. corollary: never manage someone unless you're prepared to do their job for them comfortably.

Yes, this is cold and hard, but so are those stereotypes, kids. There are Manager Engineers and there are Engineer Managers. But there's also just managers and engineers with both skills, simply focusing their work as needed for the specific project. The ultimately fun organization to work in is where different people have different roles in multiple projects, comfortably.

Key word. Getting this mix comfortable is the job of a good CEO, fwiw.

And guess what, it doesn't matter whether the salesperson can do any job but understand just how great this particular hierarchys' products are, and why the end result of this configuration is worth the spend.

> engineering only has to deal with the complexity of the computer which is at least deterministic

Engineers outside business structures can scramble themselves and produce value. It's messy and inefficient, but doable. Sometimes, it's a lot of value.

This requires human communication. Engineer-to-engineer brawls. It's nothing like the well oiled JIRA machine. It's a mess, but it is undeniably human.

I think that deserves a little more respect.

The article talks about JIRA metrics. Teams the measure productivity, time spent, code produced, deadlines. Ins't that a poor attempt at making human team work _deterministic_? Don't get me wrong, I don't think that's completely useless, but it certainly can be detrimental to both engineering and business.

I'm not saying you do those things or preach that pure metric-based system. However, you are making a comment on an article about it, and I think that in the middle of your rant, you reversed the roles a little bit.

>"By comparison, actually, engineering only has to deal with the complexity of the computer which is at least deterministic."

This statement is on big pile of BS. From a practical standpoint there is nothing deterministic about software systems and their interactions in enterprise.

There are so many hidden variables in these kind of systems that I agree with your statement. You cannot account for the unknown unknowns.

One of the hidden variables being the same machine which is supposed to bring order to chaos: product managers and their interaction with sales teams and upper management.