| ▲ | Insanity 2 hours ago | ||||||||||||||||
Not sure why this is being downvoted. It’s spot on imo. Engineers who don’t want to understand the domain and the customers won’t be as effective in an engineering organization as those who do. It always baffles me when someone wants to only think about the code as if it exists in a vacuum. (Although for junior engineers it’s a bit more acceptable than for senior engineers). | |||||||||||||||||
| ▲ | williamcotton 2 minutes ago | parent | next [-] | ||||||||||||||||
Isn't it a bit of both? When it comes to noticing whether or not code will be a security nightmare, a performance nightmare, an architectural nightmare, etc, haven't experienced developers already learned to watch out for these issues? | |||||||||||||||||
| ▲ | johnnyanmac 2 hours ago | parent | prev [-] | ||||||||||||||||
We're assuming we all somehow have perfect customers with technical knowledge who know exactly what they want and can express it as such, while gracefully accepting pushback over constraints brought up. Anyone who's worked in a "bikeshed sensitive" stack of programming knows how quickly things railroad off when such customers get direct access to an engineer. Think being a fullstack dev but you constantly get requests over button colors while you're trying to get the database setup. | |||||||||||||||||
| |||||||||||||||||