I think both view points are true.

- In orgs that don't trust dev typically have significantly less understanding of dev, and in my experience have really poor security postures. Everything is a slow manual process decided by people who don't understand apps or automation.

- In orgs that trust dev too much, you usually get a federated architecture that doesn't make any sense from a strategy point of you. Some teams are great; others don't have basic controls. You typically have a bunch of different consultancies playing land and expand and selling expensive solutions that don't actually work.

As usual, the sweet spot is probably somewhere in the middle.

Regarding your first point about security, I see the opposite on a weekly basis. Devs, especially in startups, make secure technology decisions, but in a very narrow and entirely technical scope that essentially encompasses "their world". Once induced to see the larger picture either due to a compromised system, or table top exercises that include the rest of the business, they and leadership start to realize they've had a false sense of security.

Yeah, it's a problem on both sides of the fence.

Finding the balance is key.

The problem is that the devs are smart and stupid at the same time.

They're smart when discussing code complexity, callbacks, functions, APIs and the like. I've seen this time and again where many devs would get together to flesh out a chunk of a project and work together rapidly for the best way forward, along with nearly all edge cases. This is not simple or stupid in any sense of the words.

However they are also stupid when it comes to a larger view of what they work on. Perhaps myopic is a better term. I've seen devs write code expecting a database server has commodity access to the internet. I've seen devs include untested, unpatchable by WSUS software in generated system images. I've seen devs not give a second thought about logging, monitoring, error handling and more sysad level things, as it was outside of scope.

I trust devs in their domain, which is a narrow view of code. They've demonstrated they cannot be trusted with systems.

You said those are smart people. If they don't understand certain aspects that are relevant, why not try to teach them the importance of it (e.g.: here's what matters when we log, and why; if necessary, teach them how to monitor the system using logs so they see the importance firsthand). If they are truly smart and professional, they should be able and especially willing to learn about it.

But yeah, I think that as an industry we overemphasise (both in hiring and in our weird pseudo-meritocratic community) raw coding skills and underemphasise big picture thinking, communication, collaboration, etc.

If IT is too helpless to pick Zoom vs Ubeeconference vs whatever, what’s the point in having them?

Conversely, if you are a developer and you have time to be shopping for video conferencing solutions, what’s the point in having you?

“Conversely, if you are a developer and you have time to be shopping for video conferencing solutions, what’s the point in having you?”

I am often forced to spend a ton of time dealing with tools that don’t work. At my company a lot of meetings start with 10 minutes trying to make the phone conference work. So it’s good use of time to look for tools that work.

Same with Jira. IT bought it and promised to customize it but the last three years they haven’t done anything. so we are now setting it up ourselves. it’s not what we want to do but still the most efficient way to allow us to work.

I don’t know how buying decisions get made but I am pretty sure that user satisfaction is on the lower end of factors that get considered.

Every conferencing solution shares one trait: at least one person on a call of N+1 people will have trouble joining and getting everything to work.

I have been making the same "joke" for years on calls that everyone on the call should join me in quitting our jobs to create a teleconference solution that works. Hardyharhar.

(The practical solution for teleconferencing issues is to get people to join a couple minutes early)

My joke is that the unrealistic thing about Star Trek is not the faster than light travel or the matter transmitters it’s that their videoconferencing always works.

FWIW, our company used and loved Zoom for many years. We switched to Webex and it has been far more difficult to use.

I wouldn't discount the parent's post so quickly.

That’s really weird as WebEx is more costly and less featured in most cases. Zoom was designed by the same people, so I’m surprised it’s been a challenge for users.

Do you know why they switched to Webex? I work at NIH and there is talk of moving from Webex to Zoom and I can't be more excited. Of course being the government it probably won't happen for another 2 years...

> (The practical solution for teleconferencing issues is to get people to join a couple minutes early)

If everybody has to join early, then "early" is the new "on time". It's just sacrificing a different n minutes for setup issues.

Well, sure. My point is that showing up "on time" to an appointment and THEN making sure your tools work is backwards. No one says "I was on time except for needing to park, walk in, turn on the lights and sit down".

And I'm saying that if everybody is using unreliable tools, especially mandated ones, then it's not particularly backwards. E.g., during a consulting gig in Manhattan, it was not uncommon for a subway failure to cause the majority of people to be late for the first meeting of the day.

Similarly, I've seen a few companies where it's just assumed that a 9:00 meeting really starts at 9:05, so everybody has time to travel from their last meeting. I think the videoconference nonsense is effectively the same. It doesn't really matter if you designate 8:57-9:00 as your "make sure your tools work" time or 9:00-9:03. It just matters that everybody has the same expectation.

If the host has at least tried the conference solution before the meeting it is usually ok for us, but that quickly become a specialized task that only one person care about, when s/he is away there is a high chance of wasted time.

I think the rule is that the other conferencing system always works better than the current system until you buy it. Then they all seem to fail :)

Right now we are using MS Teams which so far has been reliable. I am just waiting for the day when it becomes flaky too.

The Teams UI on a Mac seems like a horrible abomination. Using it as a guest I have 45 sec startup time with a blank screen, no UI pieces visible other than a logo. I have lost the chat function and it is nowhere to be seen. The workspace is confusing. I could go on. I hope it is better on Windows, as on the Mac it is terrible.

Teams is just using Skype for teleconferencing under the hood I believe. Unfortunately it has been terrible quality for my distributed team in comparison to other options. Results definitely vary!

Teams actually works well for us too. My only complaint is about startup time and the consistent 2 or 3 second hangs that happen when I'm typing things sometimes.

So for the n+1: For us there are lots of problems. Bluetooth headsets seem to make it nondeterministic if and how sound works. Sharing and videoconf have sometimes extreme bandwidth problems. People aren’t getting into the conference sometimes.

>At my company a lot of meetings start with 10 minutes trying to make the phone conference work.

You are most certainly not alone. In one Joshua Fluke's video, he accurately describes the feeling [1].

1. https://www.youtube.com/watch?v=ELrQyUIQkiY#t=7m55s

I was more referring to the "big corporation" example where you don't get to pick postgres. Or the general sentiment of "developers behave like children". They do, but because we encourage that behaviour.