[1337shadow]

"DevOps" used to be a methodology where a Dev and an Ops share a same goal of delivering value into production, at least, that's in the book I have read.

A sort of extension of the Lean System where workers from different areas share a common goal of delivering value to the final customer (in production), the same card may require a backend dev, frontend dev, and an ops to share the goal to take this card from idea to production, and then monitoring how it behaves in production.

For people who have not read the same books, "DevOps" mean things like "applying dev method in the operation field" ie. with ansible and the likes, coding the infra. After all, that's what that word seems to mean at first glance.

This reminds me of the term full-stack, some people consider it's just about being good at both frontend and backend, in my opinion a good full-stack is also a good networking engineer as well as good at customer acquisition.

For best ROI:

- integration must be automated and continuous

- delivery must be automated and continuous

- tech debt includes untested code and being late in dependency versions

- the above should be treated as impediments

The purpose of "DevOps" being to deliver faster from idea to production, it does necessarily include a toolchain of CI/CD/IaaS & monitoring tools. From this "DevOps toolchain", taylorists opened positions for developers that can maintain it around a software, they called that position "DevOps", which explains how we got there on having different meanings for the same word.

I highly recommend "Continuous Delivery & DevOps: QuickStart" by Paul Swartout for a first quick read on the matter.

[eropple]

> But I don't think you'd be doing "DevOps" all by yourself, unless you are what I call a full-stack, good at: communication, frontend, backend, and networking.

This is pretty much how I sum up what you'd have to be to be "a devops engineer": an actually-full-stack developer with a strong facility for communication and for process.

Such folks are hard to find. I only know a few, out of the dozens of folks I've worked with.

[1337shadow]

They are rare because it takes like 15 yrs of day and night hacking & learning from books that range from software to sales, through system & networking and communication, and found ways to practice, not something many people are both willing and able to do.

[hosh]

They are rare because the primary skill of a devops person is creative problem solving in an unknown situation and with unfamiliar tooling. You are plumber, not a cowboy or farmer.

While I have some deep knowledge in a few areas, most of the work I do has a lot more to do with researching tools, tracing down problems, and figuring out solutions that do not always appear on Google or StackOverflow.

That mindset has also served me well when I write backend code.

[1337shadow]

I would also add that I consider this practice as a triangle: science, art and sports.

Science: because a scientific protocol is to be used when making and testing code, to understand every detail, and because it's based on logic

Art: because code should first be written for another human (or you in 6 months) to read and understand, that it works or not is secondary,

Sports: because you need everyday to be in the retrospective of your past performance and try to improve it

[goatinaboat]

you'd have to be to be "a devops engineer": an actually-full-stack developer

Completely false. A full-stack developer applies JavaScript frameworks to create websites. A DevOps engineer applies development methods to infrastructure i.e. infrastructure-as-code. Totally different both skillset and mindset.

[eropple]

Perhaps I was unclear. The reason I scarequoted the term "devops engineer" is that to have such a thing (and we simply must stop abusing the term engineer, we're not) you'd need to find somebody who does absolutely everything in the stack, from technical to business-strategic. Which is why "devops engineer" makes as much sense as "Agile engineer". They're processes for people, they're not computer-touching anythings.

The idea that a "full stack developer" is "hurr, JavaScript" but that devops engineers are somehow different is...questionable. I've shipped mobile apps, web apps, backend APIs, and build and operate computing infrastructure at scale in cloud and on-premises environments, while having also had success at the strategic level with regards to the development of and the pursuit of business requirements and objectives.

Write code to tell computers to do stuff. That's all any of it is. The elaboration of the details is important in the small but not important in the large.

[KronosNull]

I think that's the point that post and the parent comment are making. A "Real-full-stack" (actually-full-stack) would actually include communication + networking.

I think it's more of a criticism on the term "full-stack" for someone who works on a backend and touches front-end every now and then.

I think everyone is in agreement that what we call "dev0ps" devs and "full-stack" devs have completely different skill sets and mindsets but if I had to attribute "full-stack" to either of these it would be a "dev-ops" dev. (theoretically, real life is messy)

[temac]

That's quite arbitrary and you likely defined it as this to fit your current business or occupation. Or even just your current main competencies.

I could say a real-full-stack should actually include EE, chip design, compiler design, kernel hacking, model checking, machine learning, virtual reality, power supply design, and 20 years of experience in Rust.

Or anything, really.

[viraptor]

I think you're missing the point a little by adding hardware and chucking in the 20 years experience with rust at the end. But, as long as you stay in software land, yes. I'm happy with real-full-stack description for experienced DevOps people who can say - I'm not a master of JS, but this caching strategy needs reorganisation on multiple levels, I can handle that. Or I'm not a master of kernel, but if we have this specific crash repeating, I'm happy to dig into it and create a patch/workaround. Whether you work with machine learning / VR / other environment changes the specific tech, not the idea.

[sk5t]

Is this a joke? "Full-stack" implies much broader skills than banging together Javascript frameworks (even if some of those frameworks are unrelated to websites).

[hosh]

I think he focused on the practical, day-to-day realities of this. His experience pretty much aligns with mine’s.

[1337shadow]

What I find confusing is how in a perspective he serves the DevOps methodology by pushing DevOps tooling and Human interaction, but in the other he seems to be doing the sysadmin work for the rest of his team, which seems contradictory from a higher (managerial) perspective.

[hosh]

He isn’t pushing human interaction. That is part of the job and problem solving. There was this story going around about what kind of developer you are: cowboy or farmer? Good devops people are plumbers.* Plumbers get stuff working by making sure all the disparate components of the the whole system work together. Human interactions are necessarily part of the whole system.

A solution can be technically fantastic, and yet people may not adopt it for one reason or another. You have to get buy-in from people.

I recently interviewed at a place where they vaguely know they needed devops but there wasn’t sufficient buy-in. I made the mistake of taking the interviews at face value. I should have been treating it as consultation from the get-go, drawing out any issues they might have (by starting with pain points), coming up with solutions. I didn’t realize I can be applying the same skills I have while working to at the very earliest stages.

If I were to build a consultation firm, I would sell organizations on the human interaction (because that is easier for people-managers to grasp; it is what they fo for their jobs). However, if I were hiring someone within my hypothetical consultation firm to do this kind of work, I would look at their problem solving mindset and people skills, at whatever experience level they are at.

*And it seems reading that Small Farmer Journal article about how to get started as a farmer with no money, real farmers have to problem solve too.

[mmcnl]

> - the above should be treated as impediments

Why do you say this? This only deflates the meaning of the word impediment. To me it would only create ambiguity when we start using the word impediment for things that are not impediments to the common goal. How would you differ between those?

[dijit]

Q: Does it fundamentally impede?

A: If yes, it is an impediment.

You say nothing to negate the assertion that the parents statements impede the organisation.

[yadayada123]

lolz