As DevOps engineers, our day-to-day involves a lot of interaction with developers — good, bad, and those who have quietly quit. To help with that, here are a few things to remember about your coding co-workers.
Developers have a very short memory
You’re always going to want to try and teach them the right way to do something. You’ll show them the correct way to run their software, how to run and troubleshoot their local containers, how to access test databases, and how to check logs in Datadog.
As you do all these things, keep in mind that as they nod and say how it makes sense, they won’t remember any of it. A week later, they’ll ask the same questions, make the same mistakes, and do the same wrong things.
It will infuriate you, but once you accept it, let the frustration go, pity them and their lack of recollection skills, and gently tell them what they need to know. One thing you can do is link them to the previous Slack conversation where they asked the same question and let them find your previous answer from there.
You might think you should document these things so that you only have to point them to the docs. If only that was the answer, but it can’t help for everything because…
Developers don’t read
They especially don’t read error logs. Most of the time, the problem is right there in front of them, spelled out in the logs. But even if we parsed the logs through ChatGPT, asking it to reword it so a 9-year-old could understand it, they wouldn’t read it and would still send it to us to fix.
Here’s a true story. A senior Rails developer with 20 years of experience kept running into the same issue. It had an easy fix, and I had told him what to do many times. Being in charge of the logging agent, I was able to append a short message to the end of the error log:
“This is the same thing that happened last time, you know how to fix it. DO NOT cut and paste these logs and send them to DevOps.”
So why do they always cut and paste and blindly send errors to us? It’s because…
Developers will always think it’s your fault, not theirs
A dev deploys a change to production, and 10 minutes later, someone notices something in production isn’t working as it should. The developer, rushing to the rescue, sees there was an infrastructure change overnight, or that there was a change to the GitHub pipeline that pushes the image to ECR, or a memory setting change 4 days ago to an unrelated part of the stack.
Whatever it is, the devs will assume that’s the problem. It wasn’t their code, it wasn’t their change. They will come straight to us with the accusation that it must be something we did. The migrations in a release were broken and caused the deploy to fail? It must be our GitOps process that is broken. Their local container failed to start because they removed a Python library? Must be our Docker Compose file that was changed 2 weeks ago. Their tests fail in the CI/CD pipeline because of their code changes? Of course, it must be our new pipeline that builds ARM and x86 images.
We spend most of our working hours proving to devs that the infrastructure is fine and that the code they just pushed out is actually the problem.
And when we do show them…
