Live data from Hacker News

Phrases in computing that might need retiring

sicpers.info

171–180 of 291 posts

Re: Phrases in computing that might need retiring

#171
post #95

Earlier quoted context omitted.

> also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of everyone's shit" but with a flashy name that sounds important so mgmt will agree to it If that's what "devops" is now, sure, kill the term. Devop is not a job title, and I will die on that hill. The concept of DevOps is close collaboration between development and infrastructure teams throughou…

If that's what "devops" was before, we needed to kill the term earlier than you might think. Devops was originally a set of software release practises and culture that result in higher quality software, including high release cadence, blame-free postmortems, small patches, time for experimentation, automated testing, continuous integration, etc. These practises normally require close collaboration between dev and inf…

The title/subtitle of the talk mentions both of these definitions: https://youtu.be/LdOe18KhtT4

Re: Phrases in computing that might need retiring

#172
post #7

If this were a comment on HN, I would give it one of my rare downvotes. It's dismissive and negative without any compensating value or positivity. Maybe suggestions of terms to use?

I always find the position of telling people to never point out problems, only suggestions or solutions odd.

From something as basic as a management philosophy of "don't come to me with problems, come to me with solutions" to this "Don't suggest terms not to use, suggest terms to use"

A person can identify a problem without having a solution, or identify something is wrong without knowing the full solution.

So in this context a person can believe people using "DevOps" or "Agile" or "Tech Debt" in various ways to be a problem without having to suggest a solution to the problem

If we just ignore problems we have no personal knowledge of the solution then I think that would end in every bad results over all, take for example a basic concept I think everyone would understand, my car is making an odd noise, I know that is a problem, but I have no idea what the solution is. I don't think anyone would say you should just ignore it, or have to present the auto mechanic with a fully fleshed out solution to the problem before taking it in for service.

Re: Phrases in computing that might need retiring

#173
post #169

Earlier quoted context omitted.

I feel like you misunderstood me. I wasn't arguing about the definition of a "DevOps engineer". Since the author didn't give one, I went by the charity principle and used a definition that would make their argument stronger (a DevOps engineer that really is just an operations engineer). But even with that definition, having an operations engineer on a team does not preclude it from practicing DevOps and is arguably i…

The point of the article is that even if we go by your interpretation where "a DevOps engineer that really is just an operations engineer", then we can completely retire the term, since it's not really special and we can just keep using "Operations". The difference between Ops and DevOps isn't just in how the team is organised, but rather what the job itself consists of. Moreover, in a lot of places there are "DevOps…

> The difference between Ops and DevOps isn't just in how the team is organised, but rather what the job itself consists of.

Do you mean that a DevOps engineer's role and skillset is different from an operations engineer? And that hiring DevOps engineers instead of operations engineers is more in line with DevOps?

Re: Phrases in computing that might need retiring

#174
post #170

So, just because people misuse the term, we should find a different term --- to be misused again? Agile is what agile manifesto defines. What the author defines sounds more like Scrum. And we can call the corporate BS, Jira-based development. Technical debt also has a very specific meaning, nothing about hobbyist programming at all.

Yes and no. Whether or not you should use a word depends on whether the word will be understood to mean what you want to convey when you use it. If you mean “agile” in the original way, but people hear “agile” and think you mean the modern so-called “agile” (full of bureaucracy, and many people actually hate it), then communication will fail. Therefore, using the word “agile” will fail to aid in communication, and yo…

Fair point. Perhaps, “agile as in the manifesto” would be a way of conveying in a concise way the intended meaning.

Re: Phrases in computing that might need retiring

#175
DevOps should really mean "Someone who builds systems and pipelines that allow developers to more seamlessly and sensibly deliver value to the end user".

What DevOps actually means in practice is "We had someone without any operations knowledge build a system before someone with the correct design skillset arrived, you can't remove it or change it because it is business critical, your job is now to maintain this like a classical Sysadmin would".

(I have been an Ops/DevOps engineer for slightly more than 15 years)

Re: Phrases in computing that might need retiring

#176
post #84

Earlier quoted context omitted.

I agree, and I love the metaphor too, but you have to admit that something about the metaphor isn’t reaching peoples’ brains the way a good metaphor does. A good litmus test here is to ask someone, “what if I told you that technical debt was originally a good thing?”... Like “Yes! Let’s go and get some technical debt, it will be great!” And so, can you understand why it might have started out that way? People who rea…

> People who really get the metaphor, can understand why it was originally a good thing to be desired. Because debt is a useful tool for the same reason In that case, it is a very apt metaphor because most people naturally see debt as a bad thing. But with some nuanced thinking and deeper investigation you recognise that it can be useful sometimes.

I think they weren't saying that it's not an apt metaphor, but that it's not a good one, because now you first need to explain to people why regular debt is not necessarily bad, before being able to move on to your actual point that technical debt is also not necessarily bad.

Re: Phrases in computing that might need retiring

#177
post #8

Strong disagree on "technical debt" Rather, the entire world is built on it and there's some level of acceptance required, but we definitely need a shorthand phrase for "we're doing something stupid that will save us time now and make us hate ourselves a year from now" Edit: thinking on it, also "devops". It's really job title for "sysadmin but paid and owned by the software department to keep ITs fingers out of ever…

I think "technical debt" is a good metaphor, as long as you recall that taking on debt to fund investment can be a good idea sometimes. Debt isn't always bad in the long term.

It's arguably what makes it such a good metaphor.

Re: Phrases in computing that might need retiring

#178

Earlier quoted context omitted.

> no longer means anything much to do with integration, which I always found kinda funny. I thought the point of CI was to avoid (what we would now call) long-lived feature branches; e.g. a team spending 6 months on their own copy of a codebase, then struggling to merge it back into the mainline when finished. In other words, CI isn't just about running tests on push; it's about the frequency of pushes, often several…

When the term 'continuous integration' was originally conceived, the point was to avoid branching altogether. It was not features branches that was the problem (there was no such thing at the time), the problem was synchronising work between groups that were working on different parts of the same application. So the original CI server concept was that everyone would get a nightly update. Having a branch run for even…

>> Having a branch run for even 2-3 weeks means that you are not practicing continuous integration ... as originally conceived.

Unless you're updating the feature branch from the main branch frequently (at least daily), thereby continuously integrating your code from the mainline.

Problems arise when everyone's working on their own long-lived feature branch and the mainline doesn't move until they all try to merge their feature at the end of a sprint. Refactoring makes this worse.

Re: Phrases in computing that might need retiring

#179
post #169

Earlier quoted context omitted.

The point of the article is that even if we go by your interpretation where "a DevOps engineer that really is just an operations engineer", then we can completely retire the term, since it's not really special and we can just keep using "Operations". The difference between Ops and DevOps isn't just in how the team is organised, but rather what the job itself consists of. Moreover, in a lot of places there are "DevOps…

> The difference between Ops and DevOps isn't just in how the team is organised, but rather what the job itself consists of. Do you mean that a DevOps engineer's role and skillset is different from an operations engineer? And that hiring DevOps engineers instead of operations engineers is more in line with DevOps?

If we go by the original usage of the term, then yes, it's different skillsets between Ops and DevOps. You can't announce an Ops position with a DevOps title since the two are different by definition.

However, even if we go by your definition that it is the same thing, then the "Dev" part is completely redundant and we should just call it "Ops", since it's by definition the same thing and it doesn't warrant a new title, because it's the exact same thing. However I doubt that's what the case the original article is talking about.

Re: Phrases in computing that might need retiring

#180

Earlier quoted context omitted.

Those are polar opposites. A button for 'disagree strongly' should upvote a comment. When Einstein and Niels Bohr 'strongly disagree' on quantum physics in 1927, they start a debate that makes both of them more enlightened. When a bullshit artist, who couldn't care less about the truth, hijack a discussion to make it all about Him (it's almost always a dude), everyone become dumber. "Moving along" is not enough becau…

> (it's almost always a dude) Yes you are https://news.ycombinator.com/item?id=32247166 > hijack a discussion to make it all about Him Yeah, irrelevant misandry will do that.

I have seen 25 years of internet trolling and this kind of attitude is gendered yes. Not in a binary way but in a bimodal one. I could have avoided the point because it's obvious though. I don't hate men because as you found out I'm one myself.
Post reply on HN