11–20 of 84 posts
OP seems to think SRE and DevOps are seen as lowly by management, yet those jobs still exist here, while the "real programmers" were offshored long ago. Good luck getting a job Actually Building Stuff, almost no one does it any more.
Earlier quoted context omitted.
>Then "DevOps" emerged as a job title, which meant a dozen things to a dozen people, and the same issue happened, it was the same operational needs and the same operational solutions, just with better tools as the passage of time allowed better tools to exist. DevOps was/is not just better tools, it's the same team that builds the software, operates the software (and underlying infrastructure). Maybe when it became a…
DevOps has that meaning to you, maybe. I would implore some reading into the origin. Cliff notes version, things that happened around the same time: * Dev+Ops days is made by Patrick Dubois, the intent was for Sysadmins to use Agile ("Agile Systems Administrator" was the desired job title), he used "dev"+"ops" to signify a unification in working methodology, not as a team * 10+ deploys a day from Flickr; where the au…
Earlier quoted context omitted.
DevOps has that meaning to you, maybe. I would implore some reading into the origin. Cliff notes version, things that happened around the same time: * Dev+Ops days is made by Patrick Dubois, the intent was for Sysadmins to use Agile ("Agile Systems Administrator" was the desired job title), he used "dev"+"ops" to signify a unification in working methodology, not as a team * 10+ deploys a day from Flickr; where the au…
You need to also look into why DevOps became a thing. Because devs were sick of the BS dealing with Ops teams (want a server, that will take 6 months to provision). So devs decided they could do it themselves (with better tools).
And failed. Other people’s jobs always look easy from the outside
* Is on call
* Manages internal software (grafana, Prometheus, salt stack, etc)
* is the first line of defense for issues in the field, works with support and the engineering team to handle problems
* Manages a distributed fleet of servers (uses off the self and/or custom code to do so)
* Builds internal tools/automations to improve the reliability of our platform and/or address problems automatically
* Pushes us to make software/OS updates
I ask because that’s what I’d love to hire. Someone who owns the production environment and has the time/space to focus on improving/maintaining it.
“Ops” or “Production engineer” is what I’ve referred to it as in the past but this seems like a good place to ask what others would call it.
Earlier quoted context omitted.
DevOps has that meaning to you, maybe. I would implore some reading into the origin. Cliff notes version, things that happened around the same time: * Dev+Ops days is made by Patrick Dubois, the intent was for Sysadmins to use Agile ("Agile Systems Administrator" was the desired job title), he used "dev"+"ops" to signify a unification in working methodology, not as a team * 10+ deploys a day from Flickr; where the au…
You need to also look into why DevOps became a thing. Because devs were sick of the BS dealing with Ops teams (want a server, that will take 6 months to provision). So devs decided they could do it themselves (with better tools).
Now you pay AWS anywhere from 5-11x more for an instance, but you still have an ops team managing it (by some name).
If you had given even 20% of that investment to the sysadmins you would have had an equivalent system.
AWS just weaponised this short-sighted thinking that was killing ops teams.
Earlier quoted context omitted.
You need to also look into why DevOps became a thing. Because devs were sick of the BS dealing with Ops teams (want a server, that will take 6 months to provision). So devs decided they could do it themselves (with better tools).
> So devs decided they could do it themselves (with better tools). And failed. Other people’s jobs always look easy from the outside
People need operations staff, people don't like operations staff and keep trying to treat them like developers. But, operations staff do and have always developed software, just internal software for glue or orchestration, and they work differently to regular software developers in that their customers are usually themselves to meet an internal objective of reliability, stability or ease-of-use for developers. It's i…
Such a overused quote, but still, seems to apply to "position names" as well: > There are only two hard problems in computer science...
In some orgs, it's the title that dictates what you can/can't do.
In some orgs, eventually your title is decided based on your role/responsibilities.
In many orgs, your title is just an HR/accounting construct and has no relation to what you do and you do whatever your boss asks you to regardless of what your role on payslip says.