4 ms·
> It's partly because I'm not a DevOps expert and even if I wanted to be one, that would also take time, patience and energy. It's this exact divergence that c
by cookiecaper 6y ago
> It's partly because I'm not a DevOps expert and even if I wanted to be one, that would also take time, patience and energy.
It's this exact divergence that creates the disconnect. If someone doesn't understand and doesn't have to care about the whole experience, they're going to focus on their side and stop when their side is good enough.
On the other hand, if that same someone is going to be regularly developing the application, making changes to the database, and triggering deployments, they will find a way to make the process flow. They'll make it adaptable enough that it's not a day-long pain any time they need to run a migration or spin up a test DB.
The whole toolkit can and should be available because every piece of the stack opens up new possibilities. You want, and at least at some level, can have, people who know this well enough to make good use of it. Nitpicking over "not my specialization" is the antithesis of a smooth engineering process.
- davedx 6y ago> Nitpicking over "not my specialization" is the antithesis of a smooth engineering process. Counter argument: jack of all trades, master of none. I'm already a full stack developer. I work on a complex front end application, a GraphQL server, a .net core platform split into multiple microservices, and a MSSQL database. I know my way around these components fairly well now but it's taken a good couple of years to get to this point. I could also invest a bunch of my time learning all the intricacies of cloudformation templates and how IAM roles work too, sure. But is it the best use of my time as a developer, when I'm much more productive writing code? You can just end up stretched too thin.