[ Content | View menu ]

Why Hiring a DevOps Engineer is Okay

Mark Mzyk July 6, 2013

DevOps engineer is shorthand. It signals that a company is looking for an engineer who understands DevOps practices, such as continuous delivery and configuration management. It says that the company is looking for someone who has knowledge about development and operations. The company is looking for someone who can bring the two sides together. It’s a convenient way of saying all of this in two words.

It’s no different than when companies look for a full stack engineer. We ridicule the notion because we know the stack is so large that no one can know it all, but we’re missing the point. Companies aren’t looking for someone who knows every detail of the stack. They are signaling that they are looking for a generalist. Someone who understands how all the pieces of the stack fit together and has the knowledge to know when they should ask a specialist. A full stack engineer doesn’t know the full stack, but they know enough to recognize potential problems across boundaries and to seek help if needed.

Is every company that is seeking a DevOps or full stack engineer using these words in this way? No. Some companies probably really do believe that all they need to do is hire a DevOps engineer and then the magic of DevOps will descend upon them. It’s your responsibility as a job applicant to screen those companies out. DevOps Engineer is a convenient shorthand that is here to stay. It would be nice if companies said what they meant and didn’t use shorthand, but that’s an even harder change than spreading DevOps.

What is a DevOp?

Mark Mzyk June 22, 2013

What is a grit, anyways?

Vinny, My Cousin Vinny

More and more there are job posting that are looking for a DevOps engineer. In response to this a series of blog posts have appeared bemoaning the fact that there should be no such thing as a DevOps engineer because DevOps is a cultural movement. It’s a movement about cooperation between development, operations, and the rest of the business. So how did seemingly smart people decide they need to hire a DevOps engineer?

When the agile movement started there wasn’t a corresponding spike in job postings looking for agile engineers. It was understood that agile was a cultural movement. It wasn’t until later that systems came along that tried to codify practices that good agile shops did (Scrum, etc) and then we started seeing job postings for scrum masters and other related positions. Perhaps it was clear that the agile movement was a cultural movement because it started with a manifesto. DevOps has no corresponding manifesto.

It’s worthwhile to consider where DevOps started. While DevOps doesn’t have a single genesis, it seems widely agreed upon that it really came to light with John Allspaw’s and Paul Hammond’s 2009 presentation on developer and operations cooperation. The presentation is clearly a cultural presentation, at least when viewed in hindsight. While I wasn’t paying attention to the presentation when it came out, based on what I’ve heard the main take away was Flickr doing ten deploys a day. At the time that was amazing. And while it was a culture that enabled this, the was also a lot of technical practices in the presentation. Perhaps highlighting ten deploys a day in the title was a mistake. It made it easy to focus on the technical and miss how important the cultural aspect was.

Further confounding the problem is that good DevOp shops are most easily recognized by the tools and technical practices they follow. They use configuration management (Chef, Puppet, etc), they do continuous deployment, etc. While these tools are part of a larger culture they are the easiest thing to recognize about DevOps. Therefore, if you want to implement DevOps it’s easy to make the mistake of thinking that you need a DevOps engineer to implement these tools and miss the larger cultural shift that is also needed.

Going back to the comparison with the agile movement, when trying to find a good agile shop one is looking for the culture. Do they use short iterations, do they avoid heavy documentation unless necessary, etc. I’m not saying there isn’t plenty of argument over what makes a place agile, but we can agree that the argument is over cultural practices. Now look at DevOps. We say DevOps is a cultural movement, but then we look at the practices that define a good DevOps shop and we largely talk about the tools, software, and technical implementations that are used.

Is this a perfect break down? No. Certainly there is a conversation going on about the cultural side of DevOps. See Allspaw’s continued conversation around blameless post mortems, as well as Gene Kim’s book (along with co-authors Kevin Behr and George Spafford) The Phoenix Project which links DevOps to the work of Goldratt and shows how DevOps fits into the wider business culture. However, cultural change is hard. If given a choice between changing culture and changing some technical practices, it’s easier to change the technical practices.

Hence the rise of the DevOps engineer job posting. It’s a sign that the wider and more important cultural aspects of DevOps are being missed. It’s also a sign that those of us who are on the front lines of the DevOps movement are doing a poor job communicating it. We’ve muddled the message. Can we change this now? No, but neither should we try. Both the cultural and technical aspects of DevOps are important and we should be glad that businesses are trying to implement them, even if they don’t fully understand the entire picture. We can see from how the agile movement has developed that change like this is messy. As much as we as engineers would like it to be bug free, that simply isn’t going to happen.

What we can do is continue to preach the virtues of DevOps, both the cultural and the technical aspects of it, but we should highlight how the technical aspects fit within the larger culture. Highlight that while continuous delivery is good, it can’t reach it’s full potentially without the cooperation that DevOps advocates.

I am sure the day is coming when DevOps will get its first set of defined practices similar to how Scrum defined a set of practices for being agile. It’s inevitable, it will happen. Please write blog posts and bitch about it when it does. But also rejoice, because it will mean the flag has been raised and DevOps will have won the battle for minds, even if means the battle of how to implement it will continue. Then we can turn our attention to the next movement and start this same argument all over again, because culture never ends.


The Pragmatic Programmer Reread, Part 1

Mark Mzyk May 31, 2013

I’ve begun rereading The Pragmatic Programmer. It was originally recommended to me by someone at my first job out of college, which was six years ago. Now I’m in a position where I’m the more experienced programmer working with younger programmers. It’s good time to pick up the book again and see if what lessons I’ve forgotten from it and what I can pass on to others.

As I’m read it I’m taking notes, especially around each of the tips. Presented here are my notes, copy and pasted. There will be eight of these posts, as the book has eight major sections and that’s how I’m dividing my notes. Hopefully you find this useful as an abbreviated guide to what the book teaches. If you haven’t read the book, pick up a copy and read it, because no notes can do it full justice.


A Pragmatic Programmer is:

Early adopter/fast adapter – ties into Jack of all trades – try lots of new things

Inquisitive – try lots of new things, always learning – never know when you will need the knowledge

Critical Thinker


Jack of all trades (specialize when need to, but keep abreast of developments)


Tip 1: Care About Your Craft

Tip 2: Think! About Your Work

Tip 2 follows from Tip 1

Be a craftsman. You may be part of a larger team, but in your individual work you can leave your mark.

If one builder of a cathedral doesn’t give a damn about his bricks, won’t that stand out when you marvel at the otherwise amazing building?

(To expand on the analogy used in the book)

Learning and improving is a continuous process. You get better one small step at a time.

So too, we’re learning this about software. Small steps lead to large improvements (continuous delivery anyone?)

Always be aware of the big picture in which you work – it informs your work and what you do.

And the big picture changes in scope – it’s your team, your company, your country, the human race, the universe. All apply, but how often do we think of each of these?


Tip 3: Provide Options, Don’t Make Lame Excuses

Take responsibility for your work, which means admitting when you are wrong and providing ways to fix things.

Also remember: if the situation you’re in is impossible, you can step away and not take responsibility – but don’t act like you are going to take responsibility only to bail later.


Tip 4: Don’t Live With Broken Windows

Simple idea: take care of your code. If you inherit bad code, clean it up. Maybe you can’t right away, but start. Put up signs that you are, so it is clear someone cares.

Then others will care to.

See Tip 1.


Tip 5: Be a Catalyst for Change

Sometimes to make change, you have to go rogue, which can be as simple as hiding your larger intentions while getting a project rolling.


Tip 6: Remember the Big Picture

The big picture is why you do the work you do. It’s easy to get caught up in the code, but if you don’t put things in context that’s when you build the wrong thing,

or you miss how things are changing around you.


Tip 7: Make Quality a Requirements Issue

Let the user decide when a piece of software is good enough – not everything needs to be gold plated.

Corollary: Ship Early, Ship Often


Tip 8: Invest Regularly in Your Knowledge Portfolio

Straight forward: Keep learning.


Tip 9: Critically Analyze What You Read and Hear

Learning doesn’t help you much if you don’t think about it.

See Tip 2.


Tip 10: It’s Both What You Say and the Way You Say It

Effective communication and persuasion take work. You’ll need to practice it just like you would practice a new coding skill.


[Author’s Note: This post edited on June 11th to improve formatting for easier reading from the original posting]