31–40 of 87 posts
I've called this ritual-taboo programming for decades. It happens for user interfaces and APIs when the documentation is absent, or only consists of examples. If there's no reference documentation, everything is a copy of something someone else did. Nobody understands how it really works. Now, for some interfaces, this isn't too bad. Most people don't know why US AC power plugs are polarized, or what the ground prong…
Earlier quoted context omitted.
> ritual-taboo programming I like to think of it as "cargo-cult programming", along the lines of the well-known essay by Feynman.
Cargo cults don't work at all. Ritual-taboo systems sort of work but are suboptimal.
One also could say that the opposite of open source is superstition. It works with the example given in the article: OneNote is proprietary software, and it is documented, though incompletely. Had it been open source, one could see exactly how shape recognition works, bugs, quirks and all. No documentation will give that amount of detail. Sure, not everyone has the time and skills for that, but maybe someone on stack…
No one has time to read the code in depth so it is also mostly reading tea leaves like „oh it has a lot of stars and a lot of downloads so it must be good”.
Don’t get me started on left pad ;)
Programmers have the luxury of documenting the previously undocumented for their repos (assuming management allocates time).
End users would need to reverse engineer but that assumes predictability. Without that you get superstition as per article.
I have also used the phrase "tribal knowledge" in the documentation-vacuum context.
I have also used the phrase "tribal knowledge" in the documentation-vacuum context.
There could be a business to be made in capturing and disseminating tribal knowledge for organizations. Even orgs with the best documentation don't have a great mechanism to capture and make available tribal knowledge which is un-authoritative, sometimes conflicting, and constantly changing. In the past I made an effort to address this by creating a unofficial but quickly searchable document repository documenting ev…
The trick is to get people to get their tribal knowledge down in public Slack channels or their docs system.
Recording most Zooms with AI summaries may help.
A) insufficient docs B) programmer can't be bothered to read the docs C) programmer doesn't trust the docs D) programmer had a bug once, blames the underlying library, not his code E) programmer had a bug, changes code, bug goes away, jumps to conclusion.
Trust in the docs is a big thing. If the docs are wrong a lot the the programmer is skeptical even when they're right.
But I've also noticed that most developers simply don't read them. "I'm too busy (fixing bugs) to read the docs." Or "my backlog is so long I don't have time to learn how to do it right, I just want it done fast "
Superstition occurs with the absence of knowledge - the existence of docs is necessary, but not sufficient, in overcoming that absence.
Earlier quoted context omitted.
Cargo cults don't work at all. Ritual-taboo systems sort of work but are suboptimal.
Only if that's how you make the distinction between the 2. Copying something hoping it will do something you want because it did do that thing elsewhere, without understanding at all how or why it works is essentially the definition of CC programming.
I have also used the phrase "tribal knowledge" in the documentation-vacuum context.
There could be a business to be made in capturing and disseminating tribal knowledge for organizations. Even orgs with the best documentation don't have a great mechanism to capture and make available tribal knowledge which is un-authoritative, sometimes conflicting, and constantly changing. In the past I made an effort to address this by creating a unofficial but quickly searchable document repository documenting ev…
If the workers values it, it would likely be documented knowledge. Undocumented knowledge can be job security.