91–100 of 131 posts
Earlier quoted context omitted.
Standardizing a set of supported tools inside an organisation isn’t exactly a stupid corporate protocol, especially if it’s a very large organisation.
It is stupid. There's no room for growth if you standardise tools. What they should be doing is standardising protocols. There's a big difference.
The problem with this whole thing is that nobody really embraces the zen of devops (really the zen of everything) -- there should be one way to do things. Prod is something that runs in the cloud, staging is something sorta like that, but the data is garbage and nobody maintains it, and dev is whatever someone could cobble together in a bash script to get something running using homebrew dependencies -- if you're luc…
It's actually k8s-ifying everything (docker-ifying was 2015-2018).
> nobody really embraces the zen of devops
I know exactly what you mean, as am struggling to get people around me understand the value of tooling, developer delight but to no avail.
Management, other non-tech teams (sales, product, Ops etc) that have learn/worked mostly in regimented setups have a long long way to go before they even start to understand what DevOps really was supposed to be - all about actionable faster feedback loops.
But, faster, actionable feedback loops also bring out the the orgs's / dept's systemic rot/muck in policies/deficiencies/politics and make it visible in-the-face. That's very threatening to many who put up a make-believe fakeshow that "our stuff's all cool, that other team/dept has all the problems". Hence, all that pushback against the new or throwing the tool in (docker/k8s/cloud) and claim that it would act as deep magic to fix the fuckery happening all over.
I learnt it over my exp at big, small, medium sized firms - over last 15+ yrs.
Only way to get to achieve DevOps (yeah, not "adopt"; one can't just 'adopt' that) is to get CTO/COO/CFO to really really understand the value. Else, lost causes!
Now there are so many applicants for one job, I am sure they will. Especially if the dev experience is miserable.
Yes this a 1000 times and also candidates should stop lying on their resume.
I once joined a company of couple of thousand employees (as software engineer). The interviewer assured me that employees can pick whichever laptop or PC they want. Ok, great, I thought, then asked for a Thinkpad. A funny thing happened after I started to work - IT department was unable to procure me that laptop. After ~3 weeks they said that the company they order hardware from can't provide Thinkpads for the forese…
So many security issues with that - that it was never a reasonable request on your part.
Moreover, having also helped with support and procurement. BY FAR, the most efficient thing to do is get the exact same laptop model for everyone. Otherwise, the IT support team is constantly fighting with driver and support issues on different brands, models, bloatware-in-drivers - a new battle for each configuration.
One-size-fits-all laptops for the company makes 100% sense for a company.
My personal favorite was: Company supplies horrible laptop locked down in ways that prevent any real work from being accomplished, but allows unfettered VM use because they don't understand or care about security outside of the environment they designed. Some developers use an underground system of sneaker net and whisper doc hodgepodge to get real work done, but that largely isn't a problem since productivity is mea…
I think developers assume those choices are made for political reasons "hey, I did something", but in reality we are often countering known mechanisms of infection propagation.
Remember what happened to Sony? So we disabled SMBv1 and PowerShell - devs complain. Then we see someone in accounting installed a fake version of Adobe something - so we prevent software installs in that department. Then a VP forces us to give him a "dev-mode" OS without restriction and subsequently gets a virus that brings down his department. ...so we have to then role those restrictions to everyone.
...and, you're right, we don't pay much attention to devs setting up VMs and tunneling around firewalls, because the vast majority of risks we combat don't use those methods. But once they do, yes, we'll lock them down too. (and VMs are becoming more common in malware space, fyi).
Not being able to select your own hardware for a job is perhaps one of my worst experiences to date. At one company, I was handed laptop with an older version of Windows, preinstalled bloatware, 3rd party encryption software, anti-virus, VPNs, etc. Even worse, the laptop was about more than 16 inches and weighted over 3 kg because the company crammed in as much expensive hardware in it as possible -- so that the comp…
There's nothing wrong with standardization as long as the standard laptop isn't crap.
I find it hypocritical that developers preach "languages don't matter, a good engineer is a good engineer", while also being very specific to work environments. Personally, I want the environment thats most similar to my coworkers to create the least amount of friction during on-boarding and documentation based learning. Don't get me wrong, there are bad dev experiences that can be had. However, from my experience it…
It never even occured to me to lie on my resume. Surely I can't be the only one.
My personal favorite was: Company supplies horrible laptop locked down in ways that prevent any real work from being accomplished, but allows unfettered VM use because they don't understand or care about security outside of the environment they designed. Some developers use an underground system of sneaker net and whisper doc hodgepodge to get real work done, but that largely isn't a problem since productivity is mea…
Corporate IT security is always a juggling act - and it's not easy. I think developers assume those choices are made for political reasons "hey, I did something", but in reality we are often countering known mechanisms of infection propagation. Remember what happened to Sony? So we disabled SMBv1 and PowerShell - devs complain. Then we see someone in accounting installed a fake version of Adobe something - so we prev…
Earlier quoted context omitted.
Corporate IT security is always a juggling act - and it's not easy. I think developers assume those choices are made for political reasons "hey, I did something", but in reality we are often countering known mechanisms of infection propagation. Remember what happened to Sony? So we disabled SMBv1 and PowerShell - devs complain. Then we see someone in accounting installed a fake version of Adobe something - so we prev…
Is there any reason policies have to be universal? It seems odd that a one-size-fits-all approach should be entertained at all.
1. These rules are usually distributed via GPO, and the AD system it uses may or may not have a useful and/or well maintained notion of who is a "developer". At best it's done at the departmental level, which isn't that great - since a lot of IT/dev people work in all departments.
2. Whenever you make an exception to a rule that restricts behavior, it's always the worst actors that game that system to get the exception. It's exactly that one VP who thinks he's tech "enough" to handle the risk that'll figure out how to get the exception for himself - he's also the one to run a torrent client to download a free copy of "PDF Writer" or a malicious keylogger.
3. GPOs can be complex to apply - errors happen. The simpler you have your rules, the less likely there is an error that leaves core/critical systems unprotected.