Programmers and software developers lost the plot on naming their tools
141–150 of 563 posts
Re: Programmers and software developers lost the plot on naming their tools
#142The cognitive load is unavoidable and in some ways worse in industries with highly technical names.
At one point in my career I was an engine calibrator at a large automotive OEM. Our lexicon included physics industry terms (BMEP, BTDC, VVT, etc), a large software package where every variable, table, and function was an acronym (we had about 75k tunable parameters, each with an acronym), and all the internal company jargon and acronyms you'd expect in a large corporation. But every name was as technical and functional as the author would desire.
During my first month I was exhausted. I would doze off in afternoon meetings or pass out in my car as soon as I pulled in the driveway. I finally mentioned this to a more senior coworker and his insight was that my brain was working overtime because it was busy learning another language. He was entirely right! The constant mental load was a very real and tangible load. He relayed an anecdote when he went to S. America on his honeymoon and despite him and his wife having taken ~4 years of HS/college Spanish the mental work they had to do to function basically nixed half the daily activities they had planned due to exhaustion. That was what I was experiencing.
The idea that more technical and specific names reduces mental load does not track with my experience. The complexity is intrinsic not incidental and I don't think it has much to do with the specific names chosen.
Re: Programmers and software developers lost the plot on naming their tools
#143I disagree for public/open-source software, because: So many kinds of software actually have good names. Yes they use mythical names but with the similar function or relatedness.
Meanwhile, I agree for internal names, because: So many (legacy) code I worked with had terrible naming. This goes beyond only the names themselves but also their capitalization or consistency. I kid you not, in a $FAANG company I saw "SpidermanActivity" and "BatmanActivity" on a system that is used by Tier-1 services' on-calls.
> (Although this thing was not a Tier-1 service, it was not also completely Tier-2 either, as it was actively supporting operations of Tier-1 services, depending on the incident, a downtime could cause significant problems...)
Imagine you are trying to make sense of a large system, which has maybe tens of dependencies and as much of dependents, you are also trying to remember which API was Spiderman and how it related to the business at all...
More on the naming conventions, the horrible case of acronyms (which spans outside of software engineering) and PMs creating polls/surveys for "fun names for our new shiny thing that does X but we don't wanna call it that".
Going even lower-levels, engineers themselves are not careful. I had way too many CDK stacks named with not only varying dash vs underscore differences, but also with subtle "case-sensitivity" differences.
Each year, I am solving issues of Java devs' issues. Some of being "but it works on my machine" type of problems. And significant percentage of that is most developers use a Mac & macOS. Hence the filesystem is case-insensitive by default. But the deployment target & CI being a Linux, filesystem is case-sensitive. As you can see here, The camel-case combined with inattentiveness can simply cause many hours of waste.
> It's a plague.
Yes, there is an AI slop, but there is also human sloppiness too. I am quite happy with LLMs/GenAI that it is able to catch and capture these and less prone to make such sloppiness in the first place. (As it being a "predictive-text engine", next word suggestion is a clone of existing copy of historically occurring words)
At the same time, amount of "hallucinations" for various acronyms are staggering. Obviously I cannot expect otherwise. Even as a human, if I am missing the context, I would be either confused or plug-in something I already know...
Re: Programmers and software developers lost the plot on naming their tools
#144The author is vastly overestimating the general legibility and familiarity of things they happen to know well and are used to. Boring names are also very generic, by definition, and thus often harder to remember. Especially when there are 10 other similar tools. Is it sql-validator, sql-schema-validator, schema-validate, db-validator, or god knows what else? Edit: I am in favor of better “sub titles” / descriptive sl…
curl cheat.sh/grep # fetches brief grep cheat sheet
Re: Programmers and software developers lost the plot on naming their tools
#145> This would be career suicide in virtually any other technical field. This article would certainly disagree with you: https://en.wikipedia.org/wiki/List_of_U.S._Department_of_Def... > the Golden Gate Bridge tells you it spans the Golden Gate strait. Is that even a meaningful distinction? Does anyone think, "Gee, I'd really like to cross the Golden Gate strait?" or do they think "I want to get to Napa?". > The Hoover…
I think the author makes a hard distinction between consumer products and infrastructure/engineering products. The Shelby Cobra has a funny name, but its engine is the memorably named V8. The Hoover Dam is a dam, and the Golden Gate Bridge is a bridge. We can argue about namespace pollution and overly long names, but I think there's a point there. When I look at other profession's jargon, I never have the impression…
Names are just names. It’s nice if they are kind of unique and have no collisions.
Re: Programmers and software developers lost the plot on naming their tools
#146That glorious day when I explained to my boss what wiki is and that we should have one internally, he fired "viki" into google, with smoothly honed muscle memory clicked first result..and got full screen of poon.
I asked to have LaTeX installed at one site, several years ago. The first Google results were eye-opening.
Re: Programmers and software developers lost the plot on naming their tools
#147> This would be career suicide in virtually any other technical field. This article would certainly disagree with you: https://en.wikipedia.org/wiki/List_of_U.S._Department_of_Def... > the Golden Gate Bridge tells you it spans the Golden Gate strait. Is that even a meaningful distinction? Does anyone think, "Gee, I'd really like to cross the Golden Gate strait?" or do they think "I want to get to Napa?". > The Hoover…
The author is just wrong. Chemistry is fairly jam-packed with various cutesy names either to amuse the authors or because they’re attempting to make an algorithm memorable to the field.
Off the top of my head:
- SHAKE and RATTLE: Bond constraint algorithms.
- CHARMm: An MD package but you’d never guess it from the name
- Amber: Another MD package that you’d never guess from the name.
- So so many acronyms from NMR: COSY, TOCSY, NOESY
The list goes on and on and permeates most of the subfields in one form or another.
If you want really cutesy names, though, look in molecular biology.
Re: Programmers and software developers lost the plot on naming their tools
#148> This would be career suicide in virtually any other technical field. This article would certainly disagree with you: https://en.wikipedia.org/wiki/List_of_U.S._Department_of_Def... > the Golden Gate Bridge tells you it spans the Golden Gate strait. Is that even a meaningful distinction? Does anyone think, "Gee, I'd really like to cross the Golden Gate strait?" or do they think "I want to get to Napa?". > The Hoover…
I think the author makes a hard distinction between consumer products and infrastructure/engineering products. The Shelby Cobra has a funny name, but its engine is the memorably named V8. The Hoover Dam is a dam, and the Golden Gate Bridge is a bridge. We can argue about namespace pollution and overly long names, but I think there's a point there. When I look at other profession's jargon, I never have the impression…
Which is really funny considering he talks about emacs.
Re: Programmers and software developers lost the plot on naming their tools
#149> grep (global regular expression print), awk (Aho, Weinberger, Kernighan; the creators’ initials), sed (stream editor), cat (concatenate), diff (difference). Even when abbreviated, these names were either functional descriptions or systematic derivations. If you asked someone unfamiliar with unix tools what they thought each of these commands did, diff is the only one which they would have even the slightest chance…
However once you learn that sed means stream editor, you won't ever forget it. libsodium is forgettable.
C programmers are great. I love C. I wish everything had a beautiful pure C API. But C programmers are strictly banned from naming things. Their naming privileges have been revoked, permanently.