Always ask why and why not to do X. Talk in terms of value add and intrinsic costs. Don't pitch building a lawnmower if you just want to trim a tiny grass stem.

Always ask why and why not to do X. Talk in terms of value add and intrinsic costs. Don't pitch building a lawnmower if you just want to trim a tiny grass stem. The key here is simplicity. You want a system that 1) does what you want it to do 2) is simple and 3) easy to maintain. These points may mean different things to people within different domains, but for me, having fewer dependencies mean less points of failure, easier to understand/document and less prone to failures imo. Hah, I had to deal with a code review comment recently where someone pitched creating a whole new C++ container to track just a minor exception case. Doing it this way is gonna cost a lot of engineering time plus added risk of a regression, on top of insignificant value add to the existing implementation. Realistically speaking, we could've just limp on that edge case if statement check that's well documented to describe what its intent was, and if more hairy edge cases come up down the road, we can throw up our hands and circle back to implementing THAT "more ideal" solution. (I doubt we'll even get there. I have questions for Product if we have such hairy requirements before I touch code tbh).