Hacker News Reader

> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

-Robert A. Heinlein

A human being is capable of all of these. Very few actually could. Even less could do all of them well.

Human 1.0 - Humans now. A common single entity can't do that.

Human 2.0 - Sure, why not! :)

Remember that in-universe those words were spoken by an arrogant super human who was hundreds of years old.

I mean, I got 17 out of 21. Subhuman? I see nothing about having to do any of those well, either, so I may human, yet. It's that last one I may have some trouble with. I think I'd much rather sleep through it. I think.

Interesting. I had never considered full stack to reach into the operations space. I always figured it meant development all the way from the server code to the front-end UI, but it was still 100% confined to code and not the operational aspects of keeping the application running.

My thoughts on full-stack is like your thought. It's a developer position. Once you start throwing in tasks that include the word "administration" in the description then that's likely a different job for a different person.

I agree that full-stack doesn't include ops and furthermore, it only refers to web developers.

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

Hell, I thought "full stack" meant all the way down into OS drivers, and ability to debug damn near anything.

Same and that ends up being in the operations wheelhouse.

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

I joke that I'm a "full full stack" developer. Writing JS (bare, or in a framework like React or Angular or whatever), backend (Python, Elixir, Go, Ruby, etc...), install the OS or design cloud infrastructure, attach GDB or ptrace to processes if they're misbehaving, use tcpdump to watch packet flows, program kernel drivers, put together a toolchain and JTAG for microcontrollers, and design schematics & board layouts (analog or digital, not great at RF... yet).

I've considered calling my title FullStack++ because I'm full stack + devops, but I don't think any hiring mgr will understand that at later roles..

.. 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"

> "Wide Area of Responsibility (AOR) Developer"

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.)

The term "Full Stack Developer" is especially problematic because taken at it's literal meaning it suggests that a developer should be fully competent at ALL aspects of developing an application, which necessarily include deep understanding of system administration, database administration, tertiary dependency (caching apps like Redis, for example) administration, network infrastructure configuration and maintenance -- all of which are impossible for one person

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.

You could consider it to be another API - like that provided by AWS. An API with hundreds to thousands of endpoints, and each endpoint can have several dozen endpoint-specific arguments. An API that evolves over time, that you need to keep on top of.

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?

You don’t just consider it an API, it is an API. No matter how you are using AWS - via the console, cloud formation templates, the cli, the various SDKs, etc. It all boils down to an API call.

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).

To me it's not about gatekeeping, it's about specialization. If you have a thousand lines of Javascript to write, troubleshoot, optimize, and deploy, you don't call the Ruby guy if you have a Javascript gal.

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.

I can see that. But when the developer needs to add a few more resources and configurations to AWS wouldn’t you rather have them already figure it out on a Dev account and give you a CF template to review than to hand you a list of resources they need?

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.

> all of which are impossible for one person and we haven't even gotten to code yet!

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.

Yep, absolutely. What folks are calling devops (wrongly or rightly) to me is simply what I considered a senior level sysadmin. The guys who can basically fix anything needed in a pinch - but guys you probably don't want designing and building large scale applications.

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 a DevOps contractor/consultant (depending on the gig), I don't agree with that. Maybe it's just the way I approach my business, but I am also the guy you want designing and building large scale applications. Well, maybe not you, but a decent chunk of my clients do. ;) One startup-unicorn client hired me to advise on DevOps practices and implement the baseline stuff for a new project and I ended up the de facto team lead, banging out JavaScript alongside Chef, just because...it's all the same. Sometimes I write code to spit out web pages, sometimes I write code to spit out EC2 instances or Azure instances. That's what a "devops engineer" is, to me.

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.

I'm with you on this. One of the huge advantages of having worn all of those hats is that you have pretty good experience of having seen how badly some interactions can go. I can look at a system design and point out problems that specialists miss. And on the other side of it, I'm a swiss army knife. Need someone to figure out how to get your web app talking to the crusty old COBOL app? I've got ideas on how to pull that off too...

A true 'sysadmin' in those days was not a pure-IT person, he was an expert of the systems

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

Yes, we are rare indeed. There's not much of a market for writing tools that work with the OS, developers usually want to stay away from the OS-provided mechanisms, like build and packaging systems, network configuration, event logging, HA tools, configuration management, and others.

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.

>developers usually want to stay away from the OS-provided mechanisms, like build and packaging systems, network configuration, event logging, HA tools, configuration management, and others.

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.

>done wrong

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"?

Because if doing it right were easy, everyone would already be doing it and it wouldn't be a named process or methodology.

My take is incentives. "No one gets fired for choosing IBM".

Good question