Amazing disruptive devOps person required for blah blah blah….. goes the job advert.

I’ve been lucky enough to have some professional experience (aka success) of good devOps or code and infrastructure and systems programming.

Where the infrastructure and software works.

In my practical experience if you are a developer, who has an interest in, and are good at the above, you make yourself a target for bad devOps.

Bad devOps is when the above is not applied, the work is done on the cheap, is not delivered on time, testing is patchy, infrastructure automation is patchy. But let's go live anyway.
We will fix all this, have a party, and then live happily ever after.

Actually you won’t…

A team in this situation will work amazingly hard at minor fixes, which are a nightmare to apply, kill themselves in trying to adapt, up-skill, learn, and context switch.

There will be loads of gnashing of teeth, service outages, and the business will likely do it again.

Because the right people are not listening to the engineers.

Unsurprisingly (at regular intervals) the development team will state the obvious….. “you need to fix alot of these things…”, because waking me up at 2am is taking the proverbial, when you ask me to clear some log files, or disk space.

  1. I didn’t sign up for this.
  2. I’m an enthusiastic developer who likes to design, implement, fix, and solve. You are treating me like a support 101 person.
  3. I value my career. I’m not coding (good devOps).
  4. I’m better than this. I’ve not built a career for it to be unravelled.

Are you thinking “how arrogant”?

Don’t, these points are important. This is my career, you are playing with.

"Abit of this won't hurt. Let's reward them with a party"
This is the embarrassing bit. The agile practitioners think that a party is going to fix this situation.
Don't worry team, we will fix it all in our six weeks of technical debt. ROFL.

These well meaning people are not the engineers who are woken up at 2am, to clear some disk space, or logs.

You are all badly mis-informed. Your business and commercial decisions are the problems. You have cast-in-stone dates, and your mess now has to be cleaned up by engineers. Developers never asked for this?

Too many hats aka too much context switching

It may be new news, but to become competent at anything involves practice.

When you are asking people to fix load balancers, play with infrastructure, and fix third party load software integration issues (it doesn’t scale)…

“you are not following this basic learning principle, of allowing people to learn through focus, and relevant continuous experience.”

You don’t care for the development team

And we will do what any self-respecting team does. After almost burning out, we will all leave.

So the next time a recruiter has the killer devOps job……and it doesn’t look quite right … run.