Infrastructure Is an Implementation Detail
developer.appEvery time I work somewhere where developers have no idea how their code actually ends up running on a computer, it results in bad software architecture.
To me, it's about finding the right level of abstraction. At some point we developers have to trust that the underlying system will do what it says it's going to do.
There is a difference between knowing that an infra component will work as intended and how the choice of that component will impact the application.
Consider storage... is it local SSD storage or an object bucket... is it used as a scratch space, caching, or for blob storage
To add to GP, not only will bad or messy architecture arise, but I've seen serious bills occur because devs make a decision to use something without understanding the impact. Architected a different way would have saved the company more than the cost of one FTE
A counter point is that being a professional software developer is more than shipping features, you have to ship something that is profitable in the long run, which requires you have a broader perspective than your desire for a narrow focus.
I agree with the storage example.
> A counter point is that being a professional software developer is more than shipping features, you have to ship something that is profitable in the long run, which requires you have a broader perspective than your desire for a narrow focus.
I think what's more common, particularly in mature companies, is that the responsibilities are getting split between those that manage the complexity of infrastructure and software developers. Software devs might dictate the infrastructure requirements in their own terms like systemA should have access to systemB, but they're not going to be setting up the Amazon security group.