5 ms·

A lot of this mentality has to do with wanting a throat to choke if something goes south. The bigger the throat, the more the C-Suite rests easy, despite the co

A lot of this mentality has to do with wanting a throat to choke if something goes south. The bigger the throat, the more the C-Suite rests easy, despite the costs. The old "Nobody ever got fired buying IBM has morphed into nobody ever got fired buying Microsoft/Oracle/AWS/whatever the flavor of the day." I've worked in places that refused to allow us (IT) to write programs to automate processes that would have saved enough money yearly to buy a house. They were "severely concerned" because "if you leave or get hit by a bus, who will maintain it?" I work at a place now where I can automate away with permission and prototype to show use case. I've been at this job a year and have already automated a goodly portion of the grunt work. Some of my colleagues look askance at me, and one has said, "you're automating us out of jobs, eventually, you do know this, right?" These guys/girls fear AI. I don't. I don't use it because God gave me a brain and I'm expected to exercise it. AI also feels like cheating to me. Sure, I may have to read the docs more, hit up someone on Stack Exchange, debug my code a little more, but you know what? I enjoy the challenge. I'm basically getting paid to have fun, despite the daily grind.

latchkey 3y ago
> A lot of this mentality has to do with wanting a throat to choke if something goes south. You're absolutely right about this on many levels. I also heard that quite a few times from my CEO, even though we often went with single smaller providers for things because he also wanted to cut corners. In this case though, I'd say it was more about nepotism. The CEO wanted the deal with his old pals in exchange for access to the IBM sales pipeline so that we could sell their customers on storage deals on our hardware deployment. The only way to get access to the deals was to buy IBM hardware that was extremely over priced and far more "capable" than what we actually needed. The fact that their sales teams outright lied about things they didn't even fully understand, was sickening for me. Thankfully other people on my team stepped up and helped prevent anything from moving forward. I agree with you, automation is key.
hiAndrewQuinn 3y ago
>Some of my colleagues look askance at me, and one has said, "you're automating us out of jobs, eventually, you do know this, right?" These guys/girls fear AI. I don't. I don't use it because God gave me a brain and I'm expected to exercise it. AI also feels like cheating to me. I'm... Not seeing the logical connection here. If you could automate more of the work faster using AI than not using AI, why wouldn't you?
- secretforest 3y ago
  I got into IT because I want to be challenged. Asking some generative AI bot about how to write a better hotpatch function or how to automate a terribly-detailed set of steps that require two people would defeat my own learning. I'd rather take 3 days to sort that out than solve it in minutes with AI. I get better by slogging it out and the mistakes I make help me avoid future mistakes. I don't want the answers, per se, I want guidance. AI would solve the issue for me. I don't want some bot thinking for me. I'll retire when I cannot suss out how to write code that solves problems or makes life easier. And yes, I'm one of those holdouts who has never had the desire to even test out generative AI. I'm not worried about it supplanting me. I worried that I will lose my own edge and curiosity.
  - tivert 3y ago
    > Asking some generative AI bot about how to write a better hotpatch function or how to automate a terribly-detailed set of steps that require two people would defeat my own learning. I'd rather take 3 days to sort that out than solve it in minutes with AI. I get better by slogging it out and the mistakes I make help me avoid future mistakes. That is a good answer. Certain kinds of tools can become a crutch that limit you and stifle your own development. Maybe that's tolerable when it's not a core skill (e.g. never learning your way around your city because you only know how to react to GPS prompts), but when you're talking about a core job skill, it's a recipe for disaster (e.g. letting your skills atrophy or not developing them in the first place).
  - jhbadger 3y ago
    While I think there has been a lot of hype in generative AI and expecting it to replace programming as we know it is premature at least, programming has always become "less challenging" over time due to improvements in technology. The famous "Story of Mel" was about a programmer in the late 1950s refusing to use those newfangled optimized assemblers rather than writing machine code directly. Then there were compiled languages like Fortran and Cobol that were far easier than machine code/assembly. Then higher level languages, etc.
    - 3y ago
johnvanommen 3y ago
> I've worked in places that refused to allow us (IT) to write programs to automate processes that would have saved enough money yearly to buy a house. They were "severely concerned" because "if you leave or get hit by a bus, who will maintain it?" I mean... they kinda have a point don't they? I was the sole maintainer on an app used by a Fortune 500 company, and if I were to get hit by a bus, it would've been very difficult (possibly impossible) to support it. There was very little documentation, because nobody but me was maintaining it.
- deleted 3y ago
  [deleted]
- skydhash 3y ago
  > it would've been very difficult (possibly impossible) to support it. People are reverse engineering binary blobs, I’d say your software can be deciphered. It would be an hassle, but doable.
- jordanbeiber 3y ago
  But you wrote the docs and documented it’s place in the enterprise knowledge graph, because you’re a professional, right? As an eng manager at an enterprise (not SV style tech) I differentiate between coders and developers. Developers help our business by actively taking part in shaping software, automated workflows and integrations that makes us improve as a whole. At lot of time is spent documenting and figuring out how that piece of software someone wrote 7 years ago, before us, works and what integrates. This is why I firmly believe you need to tie documentation to running code in some way - at the very least a basic service graph that contains all services, dependencies and some metadata. Tie this database to automatic firewall and proxy configuration and you’re on a good track. We’ve on the other hand taken the strategic decision that tech and IT will help us win (is it the 90’s all over again?!) and we staff as such. A team is at least two, and no individual can own a service.
no_wizard 3y ago
best CTO I ever had was someone who was honest about churn: people leave, for multitude of reasons, that's why they stressed documentation and testing, so others can pick up where you will inevitably leave off, eventually for good. It was baked into the culture that hand off was going to happen eventually
WeAddValue 3y ago
Not only one throat to choke, but most C-Suite had direct or indirect experience with what the old IBM (not sure about the current IBM) could do in those infrequent situations with high-impact, high-visibility, nasty technical problems. IBM had a well-defined process in place to handle these when they occurred. If the local team couldn't fix it, they could declare a "critsit" (critical situation) that launched a process that allowed them to pull in amazing resources and bypass red tape. In one that I had direct experience in, they flew in one of the software's developers to do onsite troubleshooting. Also, being the hegemon of the tech world, IBM often would take the end-to-end role and not just stop at their boundary of a tech problem. I was involved in one in the late 1990's where we were running Netscape's iPlanet web server on an IBM JVM (on IBM's AIX) and it had a nasty memory leak in production where volumes were higher. We called Netscape and got what felt like a guy with a pager on the beach (it was outside business hours when we called); not helpful at all. We called IBM and things started to rock & roll. Eventually we had someone from their UK lab tracing the JVM until he found a JNI (Java Native Interface) call from external C-code (which would have been iPlanet's code) that had the wrong value for the flag that indicated who (JVM or C-code) should release the memory. He could have stopped there saying "not IBM's fault" but he just kept going reverse compiling the C-code to find the bad call. We were able to get back to Netscape saying in module yadayada.c, somewhere around line 47, there's a JNI call with flag=0, change it to flag=1. The patch from Netscape fixed the problem. These infrequent critsits are something the C-suite remember for a very long time. They know that no way in hell their own staff could resolve these situations, especially in the days before the web, Stackoverflow, shared-knowledge, etc. If not for IBM squashing the bug, their bacon would be fried giving unsatisfactory explanations to their CEO.

latchkey 3y ago

> A lot of this mentality has to do with wanting a throat to choke if something goes south. You're absolutely right about this on many levels. I also heard that quite a few times from my CEO, even though we often went with single smaller providers for things because he also wanted to cut corners. In this case though, I'd say it was more about nepotism. The CEO wanted the deal with his old pals in exchange for access to the IBM sales pipeline so that we could sell their customers on storage deals on our hardware deployment. The only way to get access to the deals was to buy IBM hardware that was extremely over priced and far more "capable" than what we actually needed. The fact that their sales teams outright lied about things they didn't even fully understand, was sickening for me. Thankfully other people on my team stepped up and helped prevent anything from moving forward. I agree with you, automation is key.

hiAndrewQuinn 3y ago

>Some of my colleagues look askance at me, and one has said, "you're automating us out of jobs, eventually, you do know this, right?" These guys/girls fear AI. I don't. I don't use it because God gave me a brain and I'm expected to exercise it. AI also feels like cheating to me. I'm... Not seeing the logical connection here. If you could automate more of the work faster using AI than not using AI, why wouldn't you?

secretforest 3y ago
I got into IT because I want to be challenged. Asking some generative AI bot about how to write a better hotpatch function or how to automate a terribly-detailed set of steps that require two people would defeat my own learning. I'd rather take 3 days to sort that out than solve it in minutes with AI. I get better by slogging it out and the mistakes I make help me avoid future mistakes. I don't want the answers, per se, I want guidance. AI would solve the issue for me. I don't want some bot thinking for me. I'll retire when I cannot suss out how to write code that solves problems or makes life easier. And yes, I'm one of those holdouts who has never had the desire to even test out generative AI. I'm not worried about it supplanting me. I worried that I will lose my own edge and curiosity.
- tivert 3y ago
  > Asking some generative AI bot about how to write a better hotpatch function or how to automate a terribly-detailed set of steps that require two people would defeat my own learning. I'd rather take 3 days to sort that out than solve it in minutes with AI. I get better by slogging it out and the mistakes I make help me avoid future mistakes. That is a good answer. Certain kinds of tools can become a crutch that limit you and stifle your own development. Maybe that's tolerable when it's not a core skill (e.g. never learning your way around your city because you only know how to react to GPS prompts), but when you're talking about a core job skill, it's a recipe for disaster (e.g. letting your skills atrophy or not developing them in the first place).
- jhbadger 3y ago
  While I think there has been a lot of hype in generative AI and expecting it to replace programming as we know it is premature at least, programming has always become "less challenging" over time due to improvements in technology. The famous "Story of Mel" was about a programmer in the late 1950s refusing to use those newfangled optimized assemblers rather than writing machine code directly. Then there were compiled languages like Fortran and Cobol that were far easier than machine code/assembly. Then higher level languages, etc.
  - 3y ago

johnvanommen 3y ago

> I've worked in places that refused to allow us (IT) to write programs to automate processes that would have saved enough money yearly to buy a house. They were "severely concerned" because "if you leave or get hit by a bus, who will maintain it?" I mean... they kinda have a point don't they? I was the sole maintainer on an app used by a Fortune 500 company, and if I were to get hit by a bus, it would've been very difficult (possibly impossible) to support it. There was very little documentation, because nobody but me was maintaining it.

deleted 3y ago
[deleted]
skydhash 3y ago
> it would've been very difficult (possibly impossible) to support it. People are reverse engineering binary blobs, I’d say your software can be deciphered. It would be an hassle, but doable.
jordanbeiber 3y ago
But you wrote the docs and documented it’s place in the enterprise knowledge graph, because you’re a professional, right? As an eng manager at an enterprise (not SV style tech) I differentiate between coders and developers. Developers help our business by actively taking part in shaping software, automated workflows and integrations that makes us improve as a whole. At lot of time is spent documenting and figuring out how that piece of software someone wrote 7 years ago, before us, works and what integrates. This is why I firmly believe you need to tie documentation to running code in some way - at the very least a basic service graph that contains all services, dependencies and some metadata. Tie this database to automatic firewall and proxy configuration and you’re on a good track. We’ve on the other hand taken the strategic decision that tech and IT will help us win (is it the 90’s all over again?!) and we staff as such. A team is at least two, and no individual can own a service.

no_wizard 3y ago

best CTO I ever had was someone who was honest about churn: people leave, for multitude of reasons, that's why they stressed documentation and testing, so others can pick up where you will inevitably leave off, eventually for good. It was baked into the culture that hand off was going to happen eventually

WeAddValue 3y ago

Not only one throat to choke, but most C-Suite had direct or indirect experience with what the old IBM (not sure about the current IBM) could do in those infrequent situations with high-impact, high-visibility, nasty technical problems. IBM had a well-defined process in place to handle these when they occurred. If the local team couldn't fix it, they could declare a "critsit" (critical situation) that launched a process that allowed them to pull in amazing resources and bypass red tape. In one that I had direct experience in, they flew in one of the software's developers to do onsite troubleshooting. Also, being the hegemon of the tech world, IBM often would take the end-to-end role and not just stop at their boundary of a tech problem. I was involved in one in the late 1990's where we were running Netscape's iPlanet web server on an IBM JVM (on IBM's AIX) and it had a nasty memory leak in production where volumes were higher. We called Netscape and got what felt like a guy with a pager on the beach (it was outside business hours when we called); not helpful at all. We called IBM and things started to rock & roll. Eventually we had someone from their UK lab tracing the JVM until he found a JNI (Java Native Interface) call from external C-code (which would have been iPlanet's code) that had the wrong value for the flag that indicated who (JVM or C-code) should release the memory. He could have stopped there saying "not IBM's fault" but he just kept going reverse compiling the C-code to find the bad call. We were able to get back to Netscape saying in module yadayada.c, somewhere around line 47, there's a JNI call with flag=0, change it to flag=1. The patch from Netscape fixed the problem. These infrequent critsits are something the C-suite remember for a very long time. They know that no way in hell their own staff could resolve these situations, especially in the days before the web, Stackoverflow, shared-knowledge, etc. If not for IBM squashing the bug, their bacon would be fried giving unsatisfactory explanations to their CEO.