This is second post in the The Three Pillars of DevOps series

In this post we will dive in to the first pillar – Developers.

I apologize in advance – but I will be using a number of stereotypes in this series – on purpose. I will probably exaggerate – also on purpose – but this is in order to get a point across.
I do have the utmost respect for all people in all three pillars – and I promise you, I will dump on each and every single one of the pillars (hopefully equally).

Whenever I hear someone say developers – the first thing that comes to mind is the famous Steve Ballmer dance.

But these people are not as crazy as Steve on stage.
They are probably the people that work with you side by side. They create the things you use – daily.

For example – I can guarantee you that no Operations Engineer or management director was the one who wrote the applications and the functionality built into something that each and every one of us use every single day.

Be it your:

• Web browser
• Mail Client
• Facebook application
• Phone

All of these things need to be written in code. And I have the utmost respect for people who have the capability to create something from scratch and build it into something like the examples above.

Being part of the Pillar

1. Understand what you know how to do best (and learn what you don’t)

   
   I do not know everything, I don’t think anyone can, and if they say they do – then don’t believe them. You know how to write code, you know how create an interface and I could go on with examples all day. But there are also things you don’t understand, such as Operating system security, firewalls, resource usage, network traffic, databases – and again I can go on and on and on…
   
   There are people who have been doing this – just as long as you have been writing code – so use them, consult with them – learn from them.
   

2. Build with the broader picture in mind

   
   Applications do not run in a vacuum – they are part of a complete solution – they need to run in parallel or on top of other applications – so take that into account.
   
   Think about how you will interact with other parts of the solution – because it happen – you will interact with other pieces – all the time.
   

3. Take full responsibility for what you produce

   
   You created it, it is your baby. The same way you bring a child into this world – you worry and care for it. You send them to day care (where someone looks after them) but if there your kid has a fever – you will come and get them – and nurture them back to health.
   

4. Assume the worst will happen (eventually it will!)

   
   Nothing is perfect (and again if someone says it is – don’t believe them). Thinking out of the box and out of your comfort zone, not cutting corners and hoping for the best – but rather planning for the worst case scenario – will make the product you are creating a better one – and you a better developer as well (by the way).

Not being part of the Pillar (or being Samson)

1. The Operations Engineers job cant be that hard

   
   I mean how hard can it be to spin up a server, create a DNS record, run a Load balancer in front and have 5 million people hit the site at the same time. What could possibly go wrong?
   
   This is a quote I just saw yesterday on Twitter.
   
   

   "We don't need an ops person" ... shortly followed by ... "How does DNS work? What's a CIDR? Can't you do it for us?"

   — Colin Panisset (@nonspecialist) August 26, 2015

2. My application is the only one that counts

   
   I am writing something that will change the world. And I heard that this new fangled database will help me out – so that is what I will use, for a number of reasons. It is quicker for me to produce like this, the performance is very good, and I like trying the new stuff of course. I don’t care that every other application is using another database – because adapting to that standard is boring and more difficult. And of course I don’t care about what kind of resources my application needs – just give me whatever you have. I need it all!
   

3. It worked in Vagrant, in DevStack, on my laptop

   
   I tested it, I ran it and I got it to work. My unit tests passed. My acceptance tests passed. I got green on my dashboard. So obviously it is not something wrong with the application. It is the “other guy”.
   
   I also don’t care how the application is maintained over time, my job was to get it work, so obviously that when you upgrade – you will need to restart services – but hey – they was not part of the original specs and requirements.
   

4. My application works perfectly – and never fails

   
   I invested time in writing this baby, and I made sure that everything is perfect, runs like well oiled engine, purrs like a kitten, a masterpiece. I checked that everything works, and every possible scenario was covered (at least those that I thought of).
   
   And of course the assumptions that I took will always be true (such as – hardware never fails, networks are always available, I have an unlimited amount of resources available to me, all the time)