Four words programmers should know
I like words, I subscribe to r/logophilia, own multiple dictionaries and am visibly delighted when I come across a word I have never heard. One of the things I love about words is that they take a concept or a pattern and make it easier to talk about by naming it[1]. Schadenfreude being the classic example. The word resonates with people because they have felt it and it gives them a way to talk about the emotion.
In programming we haven’t yet come up with names for all the concepts that we see on a regular basis. Since naming something helps define it and makes it easier to work with I’d like to propose some words for some concepts I have seen. Instead of coining new words though it’s easier to appropriate another profession’s words for our use. People may already know the words and if they don’t it’s easier to look up an already existing word than scour the internet for someone’s a made up word. So these are words from other professions that I find myself wishing other programmers knew.
Apophenia
Have you ever been looking at conversion rates, trying to make sense of why changing the landing page’s font size improved conversion rates by 23%. Or why the server’s memory utilization went up by 2GBs after you made the front page of Hacker News, but nothing else changed. Then you may have suffered from apophenia. It is “the experience of seeing patterns or connections in random or meaningless data” and is something programmers easily fall prey to.
Figuring out cause and effect is something we spend a lot of time doing (debugging) so it’s something we’re good at. But sometimes things just happen and none of the data we have can explain why. Admitting this fact is hard but can save you a lot of time over the long run. It’s important to note the difference here between not being able to explain why something happened and not being able to explain why something happened *with the data we have*. The former hurts our ego the latter is just saying we were given insufficient data to solve the problem. Sample sentence “We aren’t seeing any relationship between the two, are you sure we have enough data and aren’t suffering from apophenia”
Iatrogenesis
Have you ever just tweaked the layout and the user could no longer submit the form on IE9. Or have you ever said “Well the only thing that changed was Ted increased the monitoring so let’s see if that could have cause the slow down”[2]. Iatrogenesis is “any consequence of medical treatment or advice to a patient” with the implication that it was unintended. Chemo killing cancer is not iatrogenic. Chemo making you bald is.
When I use iatrogenesis I use it to encompasses “side affects”, new bugs, regressions, performance profile changes, surprises etc. Pretty much any changes that were unintended by the person who introduced them is describable as iatrogenic, but so are things that changes behavior that users were relying on. If I improve logging speed, but change the file name and that breaks a back up script the user was running they would describe that as a bug while I would describe it as working as intended.
Similarly if you are changing a core part of the system the system is more likely to suffer iatrogenisis than if you are changing a feature. This is especially true of ‘secondary’ systems like logging, monitoring and metrics which often get broken because people sometimes forget about how they are used when making changes. A useful question to ask is “What are the iatrogenic risks associated with this change”. This word is more useful as your system grow larger and has more users, while on greenfield projects you won’t use it as much.
Provenance
Figuring out the sequence of events that caused a particular problem to occur, especially since most problems are unexpected, is no fun. A ficticious example:”Our CC processor timed out for this one card so we locked the associated account. The client signed in, saw their account was locked for failure of payment and called customer service. That opened a help desk ticket but by then the account had unlocked because the CC authorization had finally gone through. But that meant the customer service representative couldn’t resolve the ticket.” That story involves at least three different systems. at least 8 states of those systems and how they interact. (It’s also a good example of why you should always build in some type of override but that’s a different essay). Without a full history of each of those systems states it would be nearly impossible to reconstruct the chain of events.
Talking about the full state history of an object is a pain so instead I’m co-opting the word provenance. It actually means
“The history of the ownership of an object, especially when documented or authenticated” but I’m using it to mean “the history of states of an object and how/why it transitioned from one state to the next” In the previous example the credit card charge transitioned from not charged to pending to timed out to successfully charged. You could easily imagine a system that only tracked the not charged and successfully charged state.
If you have this information it makes figuring out the full history of your system much easier, which may or may not be worth it to you. You may make the decision not to know the full provenance of everything in your system. Maybe it’s not worth tracking when each user got their first cookie from your system. But it’s worth having a word to describe what you are lacking.
Gadarene
if I co-opted the meaning of provenance, iatrogenic and apohphenia, gadarene can be used without changing an iota of meaning”involving or engaged in a headlong or potentially disastrous rush”. Everyone has been on a project that had to be finished “right now” no matter what technical debt was added. Or had someone tell them to switch everything over to the hot new language or they would fall behind. An element of the definition I want to highlight is that the decision’s rightness is irrelevant to using the word. It’s that you’re concentrating on the speed instead of the rightness of the choice
