More like:
"IT people when software people talk about their requirements"No, we won't whitelist your entire program folder in Endpoint Protection.
As a software person i have to protest at being called out like this. It's the fucking weekend man...stop picking on me for just one damn day.
No, we can't get gigabit fiber everywhere. No, I don't care if your program needs it. Yes, the laws of physics are laws for a reason. Write more robust code.
Yep, unrealistic expectations.
Or "you need a 12th gen i7 to run this thing"... the thing is a glorified Avidemux.
Christ, if you could see the abysmal efficiency of business tier SQL code being churned out in the Lowest Bidder mines overseas...
Using a few terrabytes of memory and a stack of processors as high as my knee so they can recreate Excel in a badly rendered .aspx page built in 2003.
In my experience it’s been IT people telling me you can’t use a certain tool or have more control over your computer cause of their rules.
The expression is appropriate but the meme assumes that im doubting the IT person’s expertise. I’m not, I’m just not liking the rules that get in the way of my work. Some rules do make sense though.
And the more corporate the organisation the more rules, at least the places I have worked trusts developers enough to give local admin, that takes the edge off many tasks.
"Their rules" are basic security precautions
I think you probably don't realise you hate standards and certifications. No IT person wants yet another system generating more calls and complexity. but here is iso, or a cyber insurance policy, or NIST, or acsc asking minimums with checklists and a cyber review answering them with controls.
Crazy that there's so little understanding about why it's there, that you just think it's the "IT guy" wanting those.
I thought my comment was pretty clear that some rules are justified and that the IT person can just be the bearer of bad news.
Maybe not, hopefully this comment clarifies.
I worked in software certification under Common Criteria, and while I do know that it creates a lot of work, there were cases where security has been improved measurably - in the hardware department, it even happened that a developer / manufacturer had a breach that affected almost the whole company really badly (design files etc stolen by a probably state sponsored attacker), but not the CC certified part because the attackers used a vector of attack that was caught there and rectified.
It seemingly was not fixed everywhere for whatever reason... but it's not that CC certification is just some academic exercise that gives you nothing but a lot of work.
Is it the right approach for every product? Probably not because of the huge overhead power certified version. But for important pillars of a security model, it makes sense in my opinion.
Though it needs to be said that the scheme under which I certified is very thorough and strict, so YMMV.
So you don't trust me, but you trust McAfee to give it full control over the system. Yet my software doesn't work because something is blocked and nothing is showing up in the logs. But when we take off Mafee, it works. So clearly McAfee is not logging everything. And you trust Mcafee but not me? /s kinda.
I think the meme is more about perspectives and listening to the way someone thinks about operating IT is very different from the way someone things about architecting IT
"IT people" here, operations guy who keeps the lights on for that software.
It's been my experience developers have no idea how the hardware works, but STRONGLY believe they know more then me.
Devops is also usually more dev than ops, and it shows in the availability numbers.
Absolutely agree, as a developer.
The devops team set up a pretty effective setup for our devops pipeline that allows us to scale infinity. Which would be great if we had infinite resources.
We're hitting situations where the solution is to throw more hardware at it.
And IT cannot provision tech fast enough within budget for any of this. So devs are absolutely suffering right now.
I've always found this weird. I think to be a good software developer it helps to know what's happening under the hood when you take an action. It certainly helps when you want to optimize memory access for speed etc.
I genuinely do know both sides of the coin. But I do know that the majority of my fellow developers at work most certainly have no clue about how computers work under the hood, or networking for example.
I find it weird because, to be good at software development (and I don't mean, following what the computer science methodology tells you, I mean having an idea of the best way to translate an idea into a logical solution that can be applied in any programming language, and most importantly how to optimize your solution, for example in terms of memory access etc) requires an understanding of the underlying systems. That if you write software that is sending or receiving network packets it certainly helps to understand how that works, at least to consider the best protocols to use.
But, it is definitely true.
. I think to be a good software developer it helps to know what's happening under the hood when you take an action.
There's so many layers of abstractions that it becomes impossible to know everything.
Years ago, I dedicated a lot of time understanding how bytes travel from a server into your router into your computer. Very low-level mastery.
That education is now trivia, because cloud servers, cloudflare, region points, edge-servers, company firewalls... All other barriers that add more and more layers of complexity that I don't have direct access to but can affect the applications I build. And it continues to grow.
Add this to the pile of updates to computer languages, new design patterns to learn, operating system and environment updates...
This is why engineers live alone on a farm after they burn out.
It's not feasible to understand everything under the hood anymore. What's under the hood grows faster than you can pick it up.
20 year IT guy and I second this. Developers tend to be more troublesome than the manager wanting a shared folder for their team.
Rough and that sucks for your organization.
Our IT team would rather sit in a room with developers and solve those problems, than deal with hundreds of non-techs who struggle to add a chrome extension or make their printer icon show up.
Yup. Programmers who have only ever been programmers tend to act like god's gift to this world.
As a developer I can freely admit that without the operations people the software I develop would not run anywhere but on my laptop.
I know as much about hardware as a cook knows about his stove and the plates the food is served on – more than the average person but waaaay less than the people producing and maintaining them.
I know this is not everyone and there're some unicorns out there but after working with hiring managers for decades i can't help but see cheap programmers when I see Devops. It's ether Ops people that think they are programmers or programmers that are not good enough to get hired as Software Engineers outright at higher pay. It's like when one person is both they can do both but not great at ether one. Devops works best when it's a team of both dev and Ops working together. IMO
It very much depends on how close to hardware they are.
If someone is working with C# or JavaScript, they are about as knowledgeable with hardware as someone working in Excel(I know this statement is tantamount to treason but as far as hardware is concerned it’s true
But if you are working with C or rust or god forbid drivers. You probably know more than the average IT professional you might even have helped correct hardware issues.
Long story short it depends.
As a devops manager that’s been both, it depends on the group. Ideally a devops group has a few former devs and a few former systems guys.
Honestly, the best devops teams have at least one guy that’s a liaison with IT who is primarily a systems guy but reports to both systems and devops. Why?
It gets you priority IT tickets and access while systems trusts him to do it right. He’s like the crux of every good devops team. He’s an IT hire paid for by the devops team budget as an offering in exchange for priority tickets.
But in general, you’re absolutely right.
Am I the only guy that likes doing devops thatbhas both dev and ops experience and insight? What's with silosing oneself?
As a developer I like to mess with everything. Currently we are doing an infrastructure migration and I had to do a lot of non-development stuff to make it happen.
Honesly I find it really usefull (but not necessary) to have some understanding of the underying processes of the code I'm working with.
Could you give an example of something related to hardware that most developers don't know about?
Simple example, our NASes are EMC2. The devs over at the company that does the software say they're garbage, we should change them.
Mind you, these things have been running for 10 years straight 24/7, under load most of the time, and we've only swapped like 2 drives, total... but no, they're garbage 🤦....
I work on a team with mainly infrastructure and operations. As one of the only people writing code on the team. I have to appreciate what IT support does to keep everything moving. I don't know why so many programmers have to get a chip on their shoulder.
In my experience a lot of IT people are unaware of anything outside of their bubble. It's a big problem in a lot of technical industries with people who went to school to learn a trade.
That's how I look at 90% of the shit "systems" I'm forced to interact with (xiaomi's MIUI, banking apps, govt apps, apps that should've been fucking websites, websites that "gently nudge" you to use the app, electron apps that are windows only)
MiUI is not that bad IMO. The ad services and the integrated apps are horrible (even without the ads), but apart from that, the UI is fairly usable. They really haven't changed that much from what Android comes with by default.
I don't get it. And I've been both.
Is it about how some software shouldn't need the resources that they demand for?
I took it as software engineers tend to build for scalability. And yep, IT often isn't prepared for that or sees it as wasted resources.
Which isn't a bad thing. IT isnt seeing the demands the manager/customer wants.
I'm glad you've done both because yeah, it's a seesaw.
If IT provisions just enough hardware, we'll hit bottlenecks and crashes when there's a surprise influx of customers. If software teams don't build for scale, same scenario, but worse.
From the engineer perspective, it's always better to scale with physical hardware. Where IT is screaming, "We dont have the funds!"
Meh it's usually for shitty companies that expect their devs to write real software, ssh into things, access databases, but put the same hurdles in front of them as joeblow from sales who can't use an ipad to buy a sandwich without clicking a phishing link. So every new project is slowed down cause it takes weeks of emails and teams conversations to get a damn db sandbox and it's annoying.
On the other hand IT doesn't know you and has millions of issues to attend to
I'd say... elitism
More likely tribalism.
