[windows2020]

This is an example of classic software engineering. It's when the person writing the code understands why they're doing it, succeeds in that, then tastefully adds a little more, and has some fun, which in turn makes the product delightful.

Not to dismiss the importance of a strong Product lead, but often the role is a permanent stopgap for engineers who lack the talent and discipline demonstrated in this article. (Easter egg aside.)

[sublinear]

One of the deliberate outcomes of putting a product lead in place is to prevent the engineer from fully understanding the product.

This is politics baked into the heirarchy, not a lack of "talent and discipline".

[nradov]

One of the deliberate outcomes of putting a product lead in place is to train the engineer to fully understand the product. For any vertical market or B2B product the chance of hiring engineers who understand the business domain is virtually zero so they need clear guidance to build what customers want.

[whstl]

Having worked in both situations (product person vs no product person), this reads like fiction to me.

Most PMs I worked were nowhere near being able to guide anyone, especially on B2B domains. I had to train a lot of them just to do basic follow up stuff, and honestly the vast majority was below expectation, and mostly just receiving requests from customers and giving opinions on designs.

And even in the best cases, an understanding of the product filtered by a product lead was nowhere near as good as actually having engineers who care, dogfood, talk with customers, read feedback, design solutions and verify them with end users.

IMO the concept of product leads, PMs, etc, is ok, but the implementation is always lacking. It's always a "creative type" that is stifling creativity of engineers while not really adding a lot of value.

I much prefer the concept of "Product Owner" of Scrum: someone that brings the tasks but isn't really dictating taste (except via feedback) or removing the creative part of engineering work.

[sublinear]

I completely disagree, but your experience may vary. I am not trying to take away from that.

I am merely saying that maybe there should be a stronger discussion than just dismissing engineers as mere "thing-doers". I also accept that there are many people here who are exactly that, and I and they should find it shameful.

We can't control that, but maybe we should try harder to do instead of being lazy and assuming market forces are the boss... maybe we are the boss (we are).

[prinny_]

I have worked as an engineer on a product that didn't have a dedicated product lead and it was extremely hard to deliver new features without understanding the complex business side of things. Working without a dedicated product person to explain the business sounds hell to me.

[whstl]

The argument here is that we should shouldn't isolate engineers and dismiss them mere thing-doers.

Having someone to discuss the business with engineers is important, that's clearly not the thing being criticised here.

[baxtr]

No engineer is the same.

I had devs who told me they don’t care about product features. "Just tell me what to do, it’s my job to implement."

[sublinear]

I'm not saying every engineer has ambitions to be in management, but your quote is just as likely someone who has become fed up with sloppy management and deliberate gatekeeping.

[WesolyKubeczek]

In the days of the rampant layoff culture, where your competence, experience, or output quality no longer matters because someone sorted an Excel spreadsheet in a particular way and had you at the bottom 10% — it should be a miracle when companies are getting this much.

No more extra miles, not a single one.

[burnt-resistor]

Unions and worker-owned co-ops are the way out of corporate exploitation and layoff hell.

[YeahThisIsMe]

This is the result of advice being rejected too many times (and later turning out to have been correct).

[ferguess_k]

Probably someone who burned out and found the work not enjoyable. I wouldn't blame him as long as he delivers.

[pjc50]

I think that's far too cynical.

Usually what you end up with is a "three blind men and the elephant" situation; the product is simply too large for any one person to "fully" understand. Humans have a finite context window too.

So ending up with a product manager who is standing far enough away to see the whole elephant, but not in detail, while the engineers have detailed views of their part of the product but not the whole thing, is a reasonable position.

[sublinear]

> "the product is simply too large for any one person to "fully" understand. Humans have a finite context window too."

Not personal towards you, but we're gonna wheel that one out again? Bullshit.

We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.

[ben_w]

> We're living in a time where people who can't code and aren't organized enough by anyone's standards who actually gets shit done are under serious threat and hoping their AI god(s) will save them. None of these arguments surprise me.

Always was it so; the play remains the same, only the names are changed.

But that doesn't challenge the validity of what pjc50 wrote: literally nobody has time to count the transistors on a modern CPU (exceeds maximum human heartbeats), nor even the much easier task of skim the lines of code in say Windows 10 and the bundled drivers and apps.

We have division of labour because we need it, we have abstractions because we need them.