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.
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.
People are reverse engineering binary blobs, I’d say your software can be deciphered. It would be an hassle, but doable.
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.
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?
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.
For me, AI assistance has simply sped up the code I already know how to write (like structured test setups etc.) so I can focus more on the problems related to the business, which AI has no clue how to solve.
What is that French quote about: the more things change, the more they stay the same?
Or that George Santayana quote.
Which one?
I initially kind of assumed that most people would know about it, because it is a somewhat famous one, or at least, I've read it in many places. But your question made me realise that may not be the case. So, here it is, from the top of the above Wikipedia article about him, just below the header:
[ Santayana is popularly known for aphorisms, such as "Those who cannot remember the past are condemned to repeat it" ] .
IIRC, K&R said something similar in the first edition of their C book (referring to others' imagined reactions about the C strcmp function:
"What, you mean I have to call a function to compare two strings?"
They went on to add that they had tried to make C function call overhead quite low, to handle this issue.
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).
I use ChatGPT as a study partner in learning new direct-skills, as a soft-skills partner in navigating business dynamics, and a strategy partner in product work. It's very good at helping me learn to think better.
GPT 4 is basically useless for outputting the type of code (or writing) I need on a regular basis. It just doesn't have the right context to even be a viable tool beyond boilerplate/bootstrapping.
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.
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.
3 years a tens of millions later the whole project is shut down with no value delivered except a single data store and a couple API endpoints. That exec went back to his IBM sales job.
Last I heard they were still paying for and maintaining all of it because that endpoint was used in a key product offering.
A former manager at another fairly old-line company, it will presumably be the only company he will have ever worked for--albeit through a couple acquisitions and some stuff during dot-bomb.
The thing I've found that best captures the essence of IBM is how they love bringing *everyone* to every meeting, and then insist on full introductions. Every time.
I've been on a few different projects where we would routinely chew up 20 minutes of a 30 minute call hearing every last one of them announce their name and role. Thanks folks, I already know who you are. Can we talk about the project now?
My last interaction with them, I remember they kept claiming the sky was falling (aka schedule slip) if we didn’t rework the library to do exactly the API they worked out before any line of code was written and with no input from the four other teams that needed to consume it.
This culminated in 2 of our leads sitting in a room with a giant table, in a meeting of what had to be ten people at least, for three hours one afternoon while we dictated pseudocode and sequence diagrams for their next three months’ of work (if you can describe a month of work in an hour, it’s really not as complex as people are making it out to be)
So we paid six or seven of them to listen while we did half of their job for them, with our two most expensive employees.
That same other lead and I had figured out that IBM was perpetually 5 weeks behind, and always fishing for problems on other teams they could use to invoke day-for-day schedule slippage.
And the reason we knew it was five weeks is this: they would not take patches or hot fixes from us. Because doing so would indicate that we hadn’t fulfilled out contract to deliver on X date. So I’d give them version 1.0.4 (had to be exactly 1.0.4, if the CI/CD pipeline glitched and I gave them 1.0.5 they would demand an explanation, fuckers). And then I’d go off working on catching up with automating functional testing that we were still figuring out, trying to get it to run faster on one particular underpowered destination system, or get feedback from other teams about how some feature in the release was fundamentally broken, and I’d fix those problems and issue 1.0.5-7.
I’d tell them they needed the patch and they would say no. Then eight weeks after we gave it to them they’d complain it was broken, they are blocked, and the schedule will slip “day for day” until we fix the bugs - often bugs they should have seen week one if they were actually using the deliverables we gave them.
In one case it took me about 14 clock hours to fix their problem, but in all other cases I had already fixed that bug almost exactly six weeks before they found it. I just informed them that 1.0.7 already fixes that, upgrade. They were hoping for a week and every time they got less than a day, and only then if the meeting schedule aligned so the could stall for half a day. That was honestly one of the more satisfying aspects of that job.
Ten times they came at us with that schtick, and it worked once. Barely.
Near as I can tell they were spending a month at the beginning of each milestone cleaning up tech debt from stapling together the feature set for the previous milestone, and not getting around to our stuff until much later than they wanted the company to know.
We were almost always the first to say that we needed an extra week. Tons of harrumphing. We were, however, never (maybe 1 exception) the last team to ask for another week.
The thing is when we said we needed 1 week, it meant we needed 3-6 business days. When they said 1 week, it meant they were too scared to ask for three.
The inanity of the whole thing is that the project we were on was behind by a year that people would admit to (it was more like 30 months), so who the fuck cared if our division delivered our part three months late? It was going to collect a lot of cobwebs before it got properly exercised.
Bunch a drama with absolutely no purpose whatsoever.
For a while there, I had a weekly meeting at a former employer that had 63 people on it. The goal of the project was to change the IP address on an Oracle server.
Nobody wanted to take responsibility for the change, because if it broke, they might be unemployed.
So it just dragged on, week after week after week.
Anyway, the "job" involved more meetings than actual, real work. I'd guess 4 hours of meetings and status updates for every 1 hour of work. I don't know how some places even function.
I told him I didn't care what he called me, what mattered is whether people would listen to me when I asked them to do stuff, like use a better solution to a problem. If you want to be a lead, you have to do a lot of that yourself. But I was young (1st lead position) and his lack of backing that up were making it all more complicated than it needed to be.
Made all the weirder by the fact that he was good at selling people on ideas, to a fault (it took me 3 tries to quit that job, he was such a smooth talker)
Any technical excellence at IBM is probably an island and definitely doesn't represent the rest of the company.
In my time there, only one thing mattered: head count (or more precisely, body count). It didn't matter if those heads could think. It was all about closing outsourcing contracts and making a profit. With the occasional sprinkle of Watson propaganda sprinkled on top to make it look like you were at the pinnacle of computing.
I'm surprised IBM still exists. I can't remember a single company that I worked for where IBM would have helped anything.
PKI is like a kitchen knife. The hard part is not getting one, or picking it up, it's using it without cutting yourself. But people treat the 'knife' like all aspects are magical.
I've put my favorite learning resources and tools into https://www.bbkane.com/blog/learn-ssl/
It took from ~2 weeks after my start date until ~1 week before my last day to get a vSphere cluster provisioned for my development work.
PKI? Sounds hard, by comparison.
Then there was Weblogic, that worked as well and mostly by standards. Devs I met everywhere loved it.
MQSeries predates Java itself and started out on MVS; it was already the way it is when the JMS spec was developed. There's no real excuse for WebSphere, though.
Well, if the firm doesn’t know how to engage in its core business, just fire the employees, close the offices, take the names off the buildings and return the capital to the owners!
Not all of the lost seeing stones have been accounted for. We don’t know who else may be listening.
If they want to be Sauron.
That's Palantir Technologies' customer base.
AS/400 can still be found in the checkout line at Costco. I don't think it is the main POS system but is used for things like looking up customer information. IIRC Oracle is taking a lot of that retailer backend business now.
I once saw the original architecture document and it was actually very nice -- though perhaps unorthodox. The implementation was like an encyclopedia of Worst Practices.
I also worked a summer for IBM Global Services doing some sysadmin and security work back in 1997... I'd characterize the whole thing as... mediocrity.
Another time, I worked a contract in another part of IBM and saw other parts and got to attend presentations and lectures there and see the patents on the walls, and be exposed to some of the really smart people and history there, and that product side of the organization (people who worked on DB2, etc.) seemed much better.
If memory serves I helped our IT guy replace the whole mess with Apache, so we’d never have to talk to them again. I used to compete with Netscape so there was no small amusement in costing them contractor hours.
In my very first consulting gig, my employer intentionally buried all of the best documentation on an internal forum. I can't even count all the hours I burned up on troubleshooting, only to learn days later that the thing I was encountering was a known issue that was completely undocumented and the only way to know that was to be present in the office... which was 3000 miles away.
I tried to get management to open up the forums to public consumption, but they were dead set against it, said that their "intellectual property was too valuable."
I've long ago learned that people misremember all the time. I trust the person who quickly looks up the correct answer in the manual over the person who thinks they din't need the manual and uses what they think is right. Sure often the second person gets things right, but when they get it wrong they waste a lot of time trying to figure out which thing is wrong.
Nothing they were doing was worth $250 an hour.
Since this is the real "engineering" spirit that HNs love, I'm not going to argue. But I definitely prefer SpaceX' run and break things spirit.
Their Global Services division could be summarized as a War on Kernighan's Law. Find clever people, and have them strain themselves to stand up a system so complex that you not only need to keep paying GS to show up and maintain it, but in fact you probably need to hire two more people just to keep the wheels on.
That has made them many enemies on the technical side of things. People like me go out of our ways to sabotage any inroads they try to make because we know what will happen if we don't. Presentations of systems so complex you get a headache trying to wrap your mind around it.
If we talk about it, it's not for long and with as few ears to overhear as possible. It's like guerilla warfare. Targeted attacks against a foe who could crush you like a bug if they knew where to find you.
Oracle sniffing around is merely an irritation compared to the spectre of IBM GS getting their hooks into your CTO.