Except-for-whens
When to tack on, and when to build deep
A common request: your system works fine in most cases when X
...however when I Y, I need it to Z.
In the age of AI, internal users are empowered to self-serve improvements to products/processes on platforms built by engineers. They don't need deep domain knowledge to do this. The hard part is when I receive a PR that misses the "architectural point" by a mile - and then we need to have a very un-fun conversation about why I'm not merging your PR.
Here's an exercise that you can communicate fairly simply. Any product has a core system, oriented to solve a common pain-point. From granular to gigantic - be it a dashboard or a Tbps data pipeline. The reason why this product exists should be clearly motivated, or it shouldn't exist in the first place.
From there, ask the question - what are the rules that this dashboard applies? If, for example, we've got a "dashboard for all incomplete batches that require action", then that's your rule.
If someone contributes a bit of code that "allows viewing all the orders attached to this batch of orders" - then great, we're tacking on functionality in the form of convenience.
if someone attempts to contribute code that "allows viewing completed batches that match a particular condition", then - no. We're clearly missing some key understanding of what the state "complete" means. This is where the codeowner/engineer of the platform needs to take a step back & build deeper.
In short: your senses should tingle if you can explain a feature with the phrase "except for when".