Comment by Tainnor | Hacker News Reader

Comment by Tainnor | Hacker News Reader

Parent Full thread

Eh, the problem with the "IT department dictates all the choices because the devs are stupid" approach is that it takes ownership away from the devs, therefore leading to a self-fulfilling prophecy. If I can't be trusted to make technology decisions for the system I know about (and the IT department knows nothing about), then why should I care about delivering the best possible product?

Sorry, I've seen exactly that pattern happen in my (still) current company and it just leads to teams that are completely unable to think for themselves and work like machines in a cog.

I'm not saying company guidelines shouldn't exist or that you should allow a proliferation of 200 different programming languages, but I have never seen the "devs are stupid" approach work; if this is indeed a problem in your org, hire better people! (Which doesn't mean: smarter hackers. It means: responsible, professional individuals that work well together in a highly effective team and can be trusted to make decisions in the best interest of the product.)

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)

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.

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.

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!

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.

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...

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.

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.

> (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.

>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.

Reply on news.ycombinator.com