alt Hacker NewsI think a DBA/ops/infrastructure person as an imposed bottleneck is a useful capability in some environments.
But I won't follow you as far as "expecting developers to have expertise in how and where their software runs is unreasonable".
Like, yeah, it sucks that added DevOps responsibilities etc. don't come with adjusted compensation/time allocation expectations. I'm with you there.
But it's simultaneously true that a ton of "just regular developer" people are significant liabilities because they don't understand anything about the environment where their software runs. That liability manifests operationally (if someone's just running integration tests on Windows for their Java business logic changes and don't have any familiarity with e.g. the Linux, container, or cloud environments where their code runs, they're going to be useless when their code breaks in production and operations staff needs context), and it also makes them less effective when writing code--this culture of "developers should just live in business logic and not have to context-switch or fill their brains with other levels of the stack" is what leads to full table scans, lack of awareness of memory use, N+1 query hell, looping microservice dependencies, misunderstanding of what HTTP fields are set on requests that are mutated by load balancers, mistaken assumptions about how many instances of code can run and what concurrency/thread/coroutine behaviors are present, and so on. Those are very common problems, and it's incumbent on developers in every specialty to gain familiarity with how and where their code runs in order to write and maintain that code effectively.
If your code runs on Linux in Kubernetes, all of your developers should know how to read Linux system logs, check database sessions/queries issued by parts of the application, ls/grep/cat/strace/ps their way around, interpret k8s/application dashboards, check application logs both in log storage and as they're emitted from a process, exec into a container, restart pods, check deployment liveness, etc. Even if they don't have permission to do those things in production.
That was true in 2005 when they deployed their code to IIS on Windows Server/MSSQL, too--just with different operational specifics.
That's a low bar that's often unmet, and all sorts of teams suffer from that failure. Those skills can be trained, kept up to date, and hired for; I don't think there's a great excuse for not expecting them.
Replies
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.
> But I won't follow you as far as "expecting developers to have expertise in how and where their software runs is unreasonable".
In my professional experience, management tends to treat this as a dichotomy rather than a range. And its lead to situations where we're choosing to route every decision through a small number of 'experts' and expecting that to scale, or have people make very bad decisions about things like indices, data layout, etc.
I align with you on this. If you are using some sort of system, there is a sort-of minimum bar of expertise one should acquire. When using analytical platforms, having a basic understanding of how data is stored and the levers it gives you to optimize data processing should be standard.
Some examples:
MySQL - I would expect developers to be able to come up with a list of columns to index and why, understand why UUIDv4 is a bad choice for primary keys, know how to write performant SQL by hand and understand when their ORM is going to do the wrong thing, etc.
Redshift - Understand dist and sort keys and have some mental models on how data shuffles and is pruned based on each choice.
Iceberg + Spark/Trino - Understand that data tends to be stored/loaded as batch files. Understand how deletes work. Understand partitions and sort as options. Understand generally how bloom filters work and when you should decide to place a bloom filter. Understand why UUIDv7 is better than UUIDv4 when its part of a partition key.