5 ms·

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

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

ownagefool 7y ago
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.
- grosswait 7y ago
  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.
  - ownagefool 7y ago
    Yeah, it's a problem on both sides of the fence. Finding the balance is key.
Spooky23 7y ago
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?
- Ididntdothis 7y ago
  “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.
  - goatherders 7y ago
    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)
    - emj 7y ago
      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.
      - Ididntdothis 7y ago
crankylinuxuser 7y ago
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.
- Tainnor 7y ago
  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.

ownagefool 7y ago

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.

grosswait 7y ago
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.
- ownagefool 7y ago
  Yeah, it's a problem on both sides of the fence. Finding the balance is key.

Spooky23 7y ago

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?

Ididntdothis 7y ago
“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.
- goatherders 7y ago
  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)
  - emj 7y ago
    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.
    - Ididntdothis 7y ago

crankylinuxuser 7y ago

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.

Tainnor 7y ago
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.