| ▲ | tmpz22 an hour ago | |
Apologies my comment was very tongue and cheek. I understand what you're getting at with regards to dedicated DB style teams being a potential bottleneck and not effective for every organization, as for example most orgs get by fine with a simple RDS instance with minimal management and optimization. What I'm calling out practically is a de-specialization in roles and the trade-offs it imposes. For example, the "jack of all trades master of one" that was already propagating under the guise of "Full stack engineer" or "DevOps" is further exasperated when those consolidated roles are also delegating critical knowledge acquisition to LLMs. Further, as we consolidate roles and delegate knowledge acquisition to llms, we're also paying people less, giving less job security, lowering the general quality of life not just for developers, but for operations staff and users, and generally promoting total consolidation within big tech. | ||
| ▲ | zbentley an hour ago | parent [-] | |
No apology needed; I understand what you're getting at, and I broadly agree. It's a spectrum between "extremely easy-to-hire people that operate in such a narrow niche that they're an operational liability with limited capabilities" and "expect everyone to be an expert at every level of the stack". The right point on that spectrum is different depending on context, but I do think that a majority of software shops would be better served by moving their required skillset more towards the generalist end of that spectrum, because the default is often far too niche (driven by poor tradeoffs and short-termism in service of growth/hiring, usually). I wanna re-emphasize that this is not a new problem. It's not because of DevOps culture or cloud complexity or scale or whatever. Very limited-specialty people were always operational liabilities and had limited positive impact on feature delivery once you accounted for the help they needed to do anything that spanned multiple levels of the stack. There are just more engineers working on more systems with tighter timeline expectations now, so it seems like the complexity incumbent on the engineering role went up in general. It didn't (it went up in some situations and down in some situations), we just started noticing operational pain more often. I definitely do agree that there's widespread ignorance of the velocity and difficulty-of-work tradeoffs that arise from requiring a wider range of specialties from engineers, and a similarly widespread failure to adjust compensation and timeline expectations accordingly. | ||