Boiling the DevOps frog
These are the requirements for a random “junior full-stack developer” role I found advertised this morning. These bullet points have been copied and pasted verbatim:
This job description is not an outlier or for a particularly desirable company, and you can find dozens of these kinds of jobs on any employment website.
This list of requirements for a junior role demonstrates just how thoroughly we have boiled the DevOps frog and created environments where it is impossible to answer the question, “What am I not responsible for?”
But how did we get to a point where entry-level jobs require experience with Kubernetes, AWS, Azure, MongoDB, Express.js, React.js, Node.js, API design, secure coding practices, and the omnipresent requirement of having “excellent communication skills”?
Zero dollar budget, unlimited time budget
I’ve been working in DevOps teams for over two decades now, and I have been personally responsible for spending perhaps $2000 on software. I have never had a company credit card, I’ve never had a discretionary budget, and I have never been incentivized to consider the buy half of the build/buy decision.
What I have had is the opportunity, and often the requirement, to self-manage my time in order to learn and implement new technologies. My salary is a solved problem and my time and attention is a fluid resource that can be redirected as long as my manager utters the magic phrase “Your existing responsibilities must take priority.”
DevOps team members have a zero dollar budget. Enterprises do not have a gradual ramp-up in which individual contributors can spend actual money on software. Instead, they place all kinds of processes and requirements on any kind of monetary spend, disincentivizing any individual contributor from ever considering a software purchase.
In contrast, DevOps team members have an unlimited time budget. Ok, maybe not unlimited, but as long as BAU work is completed, DevOps engineers can spend much time learning new technologies and implementing free software with almost no oversight.
Individual contributors with a zero dollar budget but an unlimited time budget provide the foundation for the DevOps frog boiling industrial complex.
Open source as user acquisition
Open source started as an egalitarian philosophy that gave end users the right to view and modify the software they relied on. The collaboration open source inspires has created software that underpins our lives.
But open source is also uniquely positioned to exploit DevOps teams with zero dollar budgets and unlimited time budgets, as implementing open source projects requires nothing more than time and patience.
For all practical purposes, cloud native platforms must be open source in order to attract new users. Take a look at the CNCF Landscape – it is a periodic table of open source projects.
The downside to open source software is that all support is community-based. Those open source projects that have a commercial offering will almost certainly offer professional support as a paid option. I can’t think of the last time I worked in a DevOps team that was eager to pay for professional support, meaning the vast majority of open source implementations place the burden of support squarely on the DevOps team that adopted them.
领英推荐
Employee turn over
The CNBC article How much job-hopping is too much? notes that:
Another research by CareerBuilder in 2021 found that Gen Z workers would spend an average of two years and three months in a job, while millennials (25 to 40 years old) stayed for just six months more.
As employees move to new jobs, support for any new open source platforms they successfully productionized must be handed over. This creates a cycle where DevOps teams must internally distribute responsibility for new platforms every few years.
More importantly, though, there is rarely any formal process for this kind of responsibility transfer. It is assumed that teams will continue to support any production platforms, regardless of how complex these systems may be.
The programmer skill fetish
Finally, we have the fetishization of programmer skills.
The post The Programmer Skill Fetish, Contextualized is nearly a decade old and still depressingly relevant for DevOps teams. It describes a fictional moving company where the ability to bench press 400 pounds becomes the measure of a person’s ability to move furniture as an analogy for the modern DevOps mindset:
We all recognize that programming skill is a murky-at-best concept without a ton of direct correlation with market value (after basic competence).? Yet we fetishize it anyway.? We love competitions and the illusion of meritocracy.? We celebrate the generalist and a labor market that forces pointless competition instead of specialty and expertise.? Get really good at moving medical equipment?? Scrimshaw!? A true mover should be good at moving?everything.? So let’s have a 10,000 person weight lifting competition!
This creates an environment where not having the skill or desire to become competent in yet-another-devops-tool is seen as a personal failing. If you don’t understand Kubernetes (or any other complex cloud native platform), read the docs, do an online course, and certify yourself with an industry recognized institution. If you can’t, you’ll be replaced by someone who will.
Putting it all together
This is how we ended up with an industry that unironically embraces the very concept of a junior full-stack developer:
Where do we go from here?
There is hope for DevOps teams though. DevEx is slowly starting to take root in DevOps teams, and the core dimensions of prioritising flow state, reducing cognitive load, and improving feedback loops are squarely aimed at the excesses of DevOps culture.
Sadly though, I suspect that it will be many years before DevOps culture is meaningfully changed. Leetcode interviews are still common, the 2023/24 layoffs created an oversupply of engineers, and AI is poised to place even more responsibility on DevOps teams.
This is why the question “What am I not responsible for?” is such a powerful tool for surfacing how well a DevOps team understands its processes and how confident it is in distributing responsibility amongst funded specialists. No company that believes in the myth of junior full-stack developers will be able to provide a compelling answer to the question.