-Robert A. Heinlein

Human 2.0 - Sure, why not! :)

< Dev who does Operations full time but is not "DevOps"

I usually use the phrases Programmer / Operator and Computing Engineer to encompass the whole shebang.

.. or are we just redefining the stack? I suppose db + api + FE is already a lot to call a full stack, but adding devops (not to diminish it) wouldn't really change the definition of full stack here..

But unless every full stack dev also knows devops, no one will know that I know devops too from my title.

Open to suggestions but until then I'm a "full stack + devops"

This is a necessity in small organisations and a problem in large ones. A problem because they have to have all the keys, like a janitor; and they tend to end up being treated as either janitors or dictators by the rest of the company. Also tends to have a high "bus factor".

(I semi-jokingly have "Full Stack From the Transistors Upwards" written on my CV, because I have at one time or another in the course of employment done everything from chip design to web design; that doesn't mean I'd be happy to do all of them at once.)

Why is that impossible especially in the age of cloud? Infrastructure setup and configuration is just another API.

My knowledge of the full stack may not be wide, but it’s fairly deep. If you tell me I have to design and implement a full web application from scratch with no preexisting infrastructure, I can choose a pretty good set of technologies and best practices to get it done as a cloud hosted implementation all the way from net ops, dev ops (CI/CD), backend RDMS or NoSQL storage, a modern server side language, a web server, and a website.

The only part that would be wanting is the website implementation would be a simplistic Bootstrap UI without any modern front end frameworks. The best I could do right now would be either ASP.Net MVC or Jquery + handlebars. But not knowing a front end framework well enough is just because of lack of time to learn and that’s not what I’m concentrating on now.

As the size of the project grew, I would need to bring in specialists for the web (that’s not my forte) and devops (it would be a waste of my time to manage devops/netops) at scale.

And an API which, like all forms of abstraction, falls apart at the seams. There are still networks, interfaces, operating systems, files, cron jobs, sockets, flow logs, ACLs, security holes, and so forth.

Do you, as a developer, want to spend all the time required to keep up with that API? To be the one expected to fill the gaps when the abstraction falls apart? Or do you want to hire someone to take care of that for you?

I don’t want to have to be the only one, but I like having both the knowledge and the access not to have to wait on someone else. I gave up a job as an architect with so much red tape I couldn’t get anything done at a large company to be a senior developer at a small company where from day one I was given admin access to AWS (yes I have the skill set and the certifications for what they are worth).

The same way you don't write, maintain, and extend a thousand lines of IAM policies and roles, network ACLs, and launch configs in CloudFormation templates when you can have a specialist do it for you.

That said, I can understand the desire to gatekeep as someone in an operations role. Our role (as a generalization) is about scalibility, reliability, and availability. Developers (as a generalization) tend to care more about velocity, blue sky projects, and minimizing effort for the outcome.

Maintaining a balance between those two mindsets requires a lot of skill.

The same with devops. I know the devops folks enjoy having sql upgrade scripts and build and deployment scripts (currently yml or CF templates) handed to them that have already been tested in a Dev environment.

Also, if the developer isn’t knowledgeable about scaleability for instance, no matter how many servers you add behind a load balancer, if they store session state in memory instead of using something like ElastiCache, there is nothing you can do operationally (well technically you can have sticky sessions but that’s gross).

Even if the developer doesn’t do every part of the stack, they still have to know how to.

impossible is a stretch. harder than it appears perhaps.

If one looks at the original unix devs, this was often the case - modify the kernel to add a new system call so that your runtime system can do X to enable your application to do Y. A true 'sysadmin' in those days was not a pure-IT person, he was an expert of the systems. It is only with the rise of binary-only systems (e.g. SunOS) and IT commercialization that a 'sysadmin' crystallized into a separate pure-IT task distinct from 'developer'.

In my view, what is called 'DevOps' for the operationally focused, and 'FullStack' for the software focused, is really just a return to this mode of operation, which is what a true 'sysadmin' or 'hacker' already was since the dawn of time.

It's been a very strange 10 years to see the title of "sysadmin" start to become "IT button pusher" and the actual skilled role turn to the title of devops.

As far as the move for the word "sysadmin"--no joke, I blame it on Windows and small- to medium-scale businesses. When for a long time the conception of a "system administrator" is "mouse-driven process-follower", a competent software developer who happens to develop systems that throw EC2 instances around just isn't going to want to be associated with that title.

Back in the day these were called Systems Programmers but they’re a rare breed these days.

In my career I've seen maybe four people who can be called system programmers. It's a pity, because there's still so much to build, and it takes a system programmer to spot what ops tools to build, why, and to actually build them.

That's somewhat ironic, since doing development and building software tools in such areas (and system software in general) can be very interesting work: including not just the programming, but also the conceptualization, the product requirement definition, the design, seeing it in deployment and iterating to make changes, add new wanted features, etc.

That has not been my main area of work, but I have some background in it, and have done some pieces here and there (small products or parts of others) and find it to be really enjoyable work. In fact, for many developers, it can be more fun than doing business domain-level development (LOB apps), or social media / consumer apps kind of stuff. I've done some work in all those 3 broad areas, hence the comment.

Let me pose a rhetorical question: Why have all the hot trends in software project process/management for the last 10 years been so risk-prone to being "done wrong"?

Good question