I've been that engineer and with good reason. That obscure edge case which rarely comes up in production is very disruptive when it does come up. The product person waving it off is also not the one that will get paged at 2am to address the issue when it occurs. Accepting that 90th percentile use case is infuriating because it is tacit consent for an unfinished solution with the rest being made up later with additional toil, now constrained by load bearing things you cannot change. Thanks for rushing the thinking and making my life harder later for no reason.
> it is tacit consent for an unfinished solution
No. It is cutting unused features to make a manageable product.
* "That won't work on GCC 5.5." We don't support GCC 5.5, or any compiler which wasn't shipped this decade.
* "What about FreeBSD?" What about it? We only have Linux servers
* "This only works on systemd." Good, we're a systemd shop.
Don’t forget months or years later when shit hits the fan, developers will be blamed for being lazy and not the product person. No one will remember Joe said something on one or two meetings we build for 90th percentile - code in git repository will point to a developer who wrote and GitHub will point to the one that approved merge request.
In online discussions people always blame „lazy developers „ like there would be no product owners, testers, business analysts, scrum masters etc.
This is one of the reason I like a ticket tracker. I make my commit as descriptive as possible and I tag them with the ticket number. Also I add comments when Product says to cut corners. It's nice to spread responsibility around when things take a bad turn.