The “DevOps” makes the developer

Developing is More than just Coding

This morning I read a very interesting article by Jeff Knupp entitled “How DevOps is Killing the Developer”. In it, Jeff argues that developers are at the top of the technical expertise chain (having the most niche, specific expertise), and as such shouldn’t be distracted spending time doing “DevOps” (or indeed QA, sysadmin, database admin, and so on), which he claims require less specific expertise.

While this is an interesting point, in my personal experience I enjoy doing a lot of things in addition to writing code that is still part of my job – all the while still considering myself to be a “developer” and my primary responsibility to be writing code.

Another interesting article on this topic is “Time to hug your QEs and DevOps” by Ken Wronkiewicz, who argues that developers need to be aware of the individual specialisations that are required of other members of the tech team as they require additional, niche skills that Jeff doesn’t discuss.

Let’s be clear that import.io is still a small company, and we do still need everyone to be flexible in order to make our complex technology work and usable by everyone – in fact it is that very nature that got me into some of the “extras” I now do as part of my role.

As we are now growing our team, I do these additional parts, not out of necessity, but because I genuinely enjoy them. They increase the variety of what I do in my role to make it what I want it to be, in addition to what the company requires of me.

Developers doing Ops

When we were much smaller, I put together our AWS architecture as we had nobody with any more experience in infrastructure deployment at the time. I already knew that I enjoyed doing sysadmin style work from previous experience in other companies, and over the last couple of years I have greatly expanded my knowledge in this area. In fact, I have taken a great amount of enjoyment and pride in maintaining and developing our cloud-based infrastructure.

For me, all developers should be responsible for collaborating on getting the software that they develop packaged up and deployed to production. It is only when considering the deployment process, workflow and steps while it is being developed that you produce software with sensible configuration options, decent release documentation, and better procedures for deployment and maintenance. All of this eventually yields improved reliability, availability and robustness for clients who are using the system.

To an extent, DevOps allows a much smoother transition from the development to the deployment of a feature or piece of technology, which in turn makes all of the developers and ops team member’s lives easier.

In fact, at import.io, we have a rule for checking off features on our planning board: “It’s not finished until it’s in production”. This means that it is the responsibility of everyone involved in feature development (all of the members of the pod), from the domain expert to the developers, to make sure that a feature makes a smooth and painless transition into production use.

Developers doing Marketing

Ops isn’t the only non-programming aspect of my “developer” role that I enjoy.

Participating at Hack the Bank Participating at Hack the Bank

I also write technical blog posts (such as this one), do technical presentations (such as this one, which is conveniently on the topic of AWS infrastructure), attend technical events on behalf of the company (and for my own enjoyment), and provide technical user support.

Again, a few of these I started doing out of necessity – we were small and someone needed to help technical people get the hang of the import.io APIs, for example. But now that we are a much larger organization (and growing rapidly), I could remove some of these tasks from my day-to-day work.

I don’t, because I genuinely enjoy these other tasks: I get to work with colleagues from right across the organisation, and I can enhance the work I do as a developer with the knowledge that I gain through doing them. There is no better way to get feedback about your APIs, so you can build better ones, than by getting feedback directly from your users!

Making your job what you want it to be

Of course, I could spend the majority of my time programming, and that would be fine – there would be other people to fill in the other aspects of my role that I would be leaving behind.

However, one of the biggest advantages of the OKR planning methodology we use at import.io is that each quarter we set our team and personal objectives to match up to the company goals overall.

This approach – of filtering goals from the organisation level all the way through the teams, down to individual goals for the quarter – means that we can tailor our roles (to an extent) to what we love to do.

Practicing for a presentation Practicing for a presentation

For me, this means making my role encompass these “Developer Experience” tasks – collaborating with the rest of the organisation to make sure that we deliver great support, APIs and documentation in addition to a cool product that people love to use. Additionally, it gives me a solid understanding of the specialisations that these other aspects require – and while I can’t fulfill them entirely, this cross-team work at least gives me the perspective for how I can contribute best to those other roles.

So while I still consider myself to be a “Developer” and coding is by far and away my primary responsibility, working on our ops, marketing and other aspects of the business make my role something that I can enjoy in many different ways, and in my opinion produces better outcomes for the business.

Extract data from almost any website


INSTANT ACCESS