4 ms·

The rub is that not all problems are as simple as others try to make them out to be. Engineers who are able to vastly think through all of the nuance from busi

The rub is that not all problems are as simple as others try to make them out to be. Engineers who are able to vastly think through all of the nuance from business requirements and other systems that adds necessary complexity are by nature going to be seem like engineers who are attempting to add unnecessary complexity. A lot of the examples posted in this thread don't necessary sound like this case, but it's something I see on a near-daily basis at one of the BigCos -- engineers complaining that X is too complex when they're only looking at it through the Y lens and missing the other Z edges. Even Senior Principals seem to over-ask "why are you building this new service when you could just work with the other team to modify theirs?" when in actuality working with that team would also mean working with 4 other teams who all have set roadmaps; it would result in a complete failure to launch. Even very smart people in high positions can very easily not grok such a situation.

crote 4y ago
The flip side of that is that not all problems are as complicated as they seem. "You Ain't Gonna Need It" is a thing for a reason. Often the best solution from a business perspective is to ignore the complexity and throw the problem down the line. Sure, it won't scale to 1 billion users, but right now we are a startup trying to acquire our tenth customer. And there is often more than one way to skin a cat: why waste developer time trying to optimize something like CPU & memory usage when you can just spend a few dollars and throw an extra AWS instance at it? Someone smart will solve the issue a few years down the lines when it actually becomes an problem.