Peeling the Onion
Over the years, the one lesson I've learned in computing the strongest -- the one which will stick with me long after everything else in my brain has faded -- is that everything is encased in layers of unnecessary bullshit.
Sometimes the bullshit is there because computing people, like all people in technical fields, have a tendency to speak their own language and don't realize how incomprehensible it is to everyone else ... unless they are programmers who only write code because it's the only thing they can do that keeps the bills paid, and are actually writers who value lucidity and good communication. Which is to say, unless they're me. And, apparently, only me. I know several people who became programmers from other fields, but they're always other technical fields, and since each of those technical fields is swamped in its own peculiar jargon, they barely even notice when they've switched from, say, biochemistry jargon or physics jargon to programming jargon.
Now, the folks in these tech fields will tell you that jargon is often an aid to precision; that it's better to have a specific term-of-art that means a specific thing than to have to describe that specific thing every single time using other words. They say to me, "As a writer, you know the importance of picking the one right word for the job, so why are you so down on our terminology?"
I reply to them that specialized terminology is great when it's actually in the interests of precision, but it's often not ... in fact, far more often it's used to obfuscate or misrepresent -- to introduce deliberate imprecision.
Take all this generative stuff which is currently destroying the world in multiple ways. We do not call it "AI" in this space, because it is not. All of the language surrounding these tools is designed to misrepresent what they are and what they do, and to create a false aura around them. That includes even the most basic terminology, such as referring to reasonably-good-at-choosing-which-word-to-draw-next-out-of-the-hat text mungers as "artificial intelligence." It includes referring to when they get stuff wrong (or glue things together especially incomprehensibly) as "hallucinating." Even calling it "lying" would be a mistake. Both of those terms feed into the idea that there is a sentience behind these tools. There is not. For an LLM to be lying would imply it understood what any of the words it glues together actually means, and it does not and will not, not for the foreseeable future.
An LLM cannot lie, because it does not have the necessary comprehension to lie. The people who are trying to shove LLMs down your throat and into every aspect of your life, though -- they sure as hell can lie, and they do it every day, and they do it by picking words which add that all-important layer of bullshit fog. They do not want you to have the slightest idea what these tools actually are and do, because they are pulling a big-ass scam, and their jargon is meant to facilitate this.
But back to writing code.
With programming, there is a second level of bullshit problem. Unrelated. That is the inexplicable desire to surround everything with layer upon layer of "framework" or "toolkit" or other alleged organizational structure.
Now, I've softened a lot on buy-vs-build in my old age. Just as my personal time-to-money expenditure ratio has changed such that it is no longer a good value for me to change the oil in my car myself (and my back thanks me for it), there are places where twenty years ago I'd have built code to do certain things from scratch where now I'll just go find a good library function that does the same thing. Someone else has already done a better job of writing that function than I would have, and the time and effort I save on not reinventing the wheel more than compensates for the additional overhead of learning how to use that function and dealing with all the inevitable additional bullshit it sweeps in with it.
But sometimes you have to understand what you're doing.
This is the thing that's going to kill us. The younger programmers, many of them run strictly cargo-cult. They don't actually understand a thing they're doing; they just paint by numbers. They don't write any of their functions. They just glue stuff together. Or, worse, they get Claude or some other tool to glue stuff together for them (and it usually doesn't fucking work, because Claude does not understand what it's gluing together).
We've got a lot of people "writing" critical code who aren't actually writing it and don't really know what it does, which means when it breaks, they won't really know how to fix it. I need more people to understand that this is a problem.
Meanwhile, I've got some code I have to change. I am using an authentication protocol called CAS which is now deprecated because we have changed authentication methods/providers. See, a sentence absolutely full of jargon.
What that means in English: Some of our applications need to know who you are, so they can determine that you're actually entitled to use the app. You go to that app, you get redirected to a login page if you're not logged in already. It's 'single-sign-on' because it's the same login tool for all the apps at $EMPLOYER -- no matter what you're trying to do, you'll log on the same, consistent way. This means there's a transfer of information:
1. Go to app, app sees you need to log in;
2. App passes control to login method, which is somewhere else entirely;
3. Login method passes control to authentication provider, again somewhere else;
4. Assuming auth provider says "sure, looks fine," they tell the login method that;
5. Login method sends a message back to the app saying "Good to go, here's who it is."
2. App passes control to login method, which is somewhere else entirely;
3. Login method passes control to authentication provider, again somewhere else;
4. Assuming auth provider says "sure, looks fine," they tell the login method that;
5. Login method sends a message back to the app saying "Good to go, here's who it is."
The login goes through an authentication provider because we use two-factor authentication, and nobody does 2FA handling themselves, homegrown; you let the people do that who do it right, because if you get it wrong, your auth is not secure and what was the point? Ours used to be something called Duo. You may have used it. You may have it on your phone. Now it's something called Okta.
While we were using Duo, using CAS as the protocol was fine. "Protocol" here means "the format in which information is transmitted." Each of those five stages above involves slinging messages around, and you have to know, and be able to decipher, the format those messages are in -- more so because this is a security matter and those messages are likely to be encrypted in some way. For years now, I have used a protocol called CAS. Okta does not allow CAS. So I have to switch to a different protocol, callled SAML.
The reason this entry is called "peeling the onion" is that over and over and over, across my forty years at sea, I have found that when I first tackle a new programming need I am usually confronted with many layers of accreted bullshit, and I now have to take several days to try to work my way down to what it actually does. Often, when I get there, I find that "what it actually does" is about four lines of code and so I just use those four lines of code and don't bother with any of the bullshit snowball.
It's hard to peel back the onion sometimes. I have been looking for good materials on SAML and Shibboleth (I'm not even going to explain that one, it's not worth it) for weeks. There is nothing. I would like to keep this code as simple as my CAS code. I don't think I'm going to be able to. Everything I can find is one hundred percent impenetrable jargon. I have been unable to peel this onion.
Eventually I'm going to have to give in and install thousands of lines of library I don't actually understand and which have no useful documentation whatsoever, just to do this thing which I suspect is actually about three lines long, give or take an encoding/decoding function or two.
I am not thrilled about this.
28 April 2026