How 'DevOps' Is Killing The Developer

It's more like wanting to be a painter without knowing how paint brushes are created. Ideally I don't need to know how a system is configured (to an extent, of course), I just write the code.

You can't really draw a hard line between administration and development, in the end you are just building a system and the more you know about it from all angles the better design decisions you can make and the easier it is to fix issues.

I diagnosed a few problems over the years that arose as apparent issues with a web application but that I gradually narrowed down to things like network issues, or kernel bugs, or system misconfiguration, or database issues etc. Modern stacks are very complicated and the interactions can get really messy, it is close impossible for someone who doesn't understand the whole thing to find issues that aren't neatly isolated. I perfectly know that I do not have the full qualifications of a sys-admin proper, and would not like to do a sys-admin job full time, but in those particular cases a pure sys-admin would not (and often actually could not) find those issues. As an example, I can remember many situations where the application showed different behaviour depending on which application server you hit, and typically both "pure" developers and "pure" sys-admins were having a hard time finding the issue.

Good sys-admins anyway have to learn, at least, C programming, shell scripting, and network protocols and programming, so it's should not be a big deal to add some Rails/Django/Node to their skillset. Good developers anyway have to know things about hardware, networks, protocols and so forth. You do want to have people that are specialized in one or the other area and focus on it on a day to day basis, but you also do want to have people that can understand a particular aspect of the system top to bottom when such a need occurs, and it does happen quite often.

Pure developers are a problem because they will the information do their job well.

I go back a few years, to an old, waterfall-like job. I was handed work by an analyst, that was handed a task to analyze by an engagement lead, who might at some point talk to someone using the application. The work was always handed out on time, but the product often failed, not because it was buggy, but because nobody actually had much of an idea of what we were really trying to solve.

So us developers got much work done, but the work didn't actually solve real problems: The force is applied to the wrong vector. Then the product fails, and the blame game begins: Changes are too expensive, because the developers didn't know what the real invariants are. Queries are slow, because the database architect wasn't told about the questions that the database had to answer. The business analysis just wrote documents. It was all a big catastrophe.

That company moved to Scrum, the terrible way: Here, have this self organizing team full of specialists that don't know anything outside of their domain. They are still failing to this day, but now they blame each other in retrospectives.

So I'd much rather be stuck coding less, but then being aware that my code is actually solving a problem for someone, than just writing castles in the sky, because everything I've been told about what my userbase needs comes from a game of telephone.

There is also an aspect that I enforced in my devop team: you built it, you will deploy it and you will keep it online and running. Don't develop something that's a pain to deploy, because you'll be the one deploying it. Don't develop something that's crazy on the database side, because you'll write the database script. As the devop, you'll have to balance the ease of development, deployment and maintenance yourself, there's no "someone else will deal with it".

That limits the crazy stuff like esoteric package function for the database, crazy port opening on the machines, esoteric daemons, or tools that can only be deployed from sources. Because the guy deciding that will be the one updating and debugging the VM creations script (for 2 different cloud provider).

But at the same times, they have access to all the tools they want, they can evaluate if something is best done on the admin or development side, they use mostly the same tools, code conventions and languages for administration and product development, and they have an immediate feedback sur how much logging to send from the application.

It's definitely more complicated than the post implies, and it most definitely is NOT only for startups. Soon after I started out - at a mature company already making plenty of money - I was a full-stack engineer. There were a number of reasons:

- New development happened sporadically; day-to-day work was a mixture of maintenance development and admin work

- Culture. They started with a small team, and never grew it. Having more people didn't fit with the way the company saw itself.

- Difficulty hiring specialists. Various reasons for it, but still valid.

At another company I worked, there was a lot of "integration development", where your time was spent connecting various internal and external systems together, software-wise, developing tools that support systems work (i.e., tools for sysadmins), and developing other tools that are for end-users, but have a heavy systems component (management software for DNS, for example.) That meant understanding each part of the stack from both a development and system perspective. Another is interest level. A few of us were full-stack developers because we were studied more than just development in our free time, and we took that with us to work. This wound up benefiting everyone. This also led to us being the go-to people (that is, the top level of internal support) for both more specialist internal developers and sysadmins, as we had deep knowledge of the internal systems from the bottom to the top the stack, and the knowledge and experience to explain and troubleshoot problems to people in those other roles.

The author is correct in that this may be more /common/ at startups (the previous startup I worked at did in fact operate as the post describes), and is sometimes done out of necessity. It is by no means limited to those environments, however.

Edit: I'd also separate DevOps from full-stack engineer. They sound like the same thing, and if you squint from far enough away, they look like the same thing. The terminology may be fluid, but I think (as some other comments state), that DevOps is more centered around "coding for systems automation", whereas "full-stack engineering" is a much more general term which can encompass a variety of different types of tasks in different environments with varying levels of knowledge/experience in the different parts of the stack/tools.