Every place I worked had a different culture. I found this interesting and, when the conditions are proper, very entertaining. The workplace culture can strongly motivate you, making you feel part of something unique happening right here and now.
When I worked at Ubisoft, I compiled a dictionary of all the jargon we used.
My current job is not different. During the years, recurring rants and complaints made my friend Francesco and me create a list of despicable types of people. You know when you see something in the code that it is not just right, or some approach to the problem that you consider plainly wrong? That’s the base idea. Then take into account other colleagues who have strong ideas about what is Holy and what is Evil, and you get a lot of jokes only you and your team can understand.
So the list has a split nature, half a satire against Absolute Truth and half a complaint against those who write code for a living, but are not Real Programmers. That’s how this ever-growing list of wrongdoers came together.
Here is our current list. It is very nerdy, and most puns and jokes are likely difficult to catch even if you are a seasoned programmer, so I will offer a decoding table at the end of the post. Ready? Let the rant begin?
Despicable types of people (in no particular order)
- those who don’t do a memset at the beginning of each function
- those who define nonsense operators
- those who start counting from 1
- [C++] those who pass references without the const modifier, even when they do not change the argument
- [C++] those who don’t place const in the signature of methods that don’t change the status of the instance
- [C++] Those who use delete without [] to free an array
- those who don’t program in C
- those who don’t use Windows XP
- those who use the very same logging message in several lines of their code
- [C++] those who do delete this with no reason
- Those who don’t know Z80 assembly
- Those who don’t remove every warning from their code
- those who check in an if condition if a boolean variable is == true in languages where booleans can only be true or false
- those who name variables and functions in a language, but not in English
- those who use DBs
- those who create animations using .obj files
- those who punctuate randomly
- those who pronounce acronyms half in Italian and half in English
- Those who write programs that exceed 48k RAM.
So here is a little analysis/explanation
| point | analysis |
| 1 | This means “to perform a memset of the variables on the stack, so that everything is initialized in a function before doing actual work”. Therefore, this belongs to a sort of self-defensive programming approach – trust no one, yourself included (after all, who is going to use the variables freshly created on the stack?). |
| 2 | It is aimed mostly at languages where you can redefine operators – C++ and Scala. In Scala, you can define every sequence of symbols as a custom operator. Usually, this is utterly confusing for beginners, and everyone who is not fluent with the library that defines such operators. Personally, I find DSL a messy confusion that brings no real advantage for at least two reasons – first, you know the host language, but you need to learn the DSL that has different syntax/semantic and then the DSL forces the “host language” but has to comply with it, and this results in odd-looking syntax, misleading punctuation or phrasing. I much prefer a traditional library with a possibly well-defined interface to Vulcan gibberish such as :::, |–>, ~>. |
| 3 | How many times have you found code where the programmer started counting from 1, even if the language was C? This is annoying because there are very good reasons to start from 0… but someone prefers to ignore them and sticks with medieval culture, lacking the concept of zero. |
| 4,5 | In C++ (and to a lesser extent in C), you can enforce a type-checking strategy called const-correctness. Basically, this strategy marks data that is expected to stay constant throughout some operation. This helps in writing better code because the user programmer can make stronger assumptions. Unfortunately, you can’t use non-const-correct code from const-correct code (and possibly this is why Java has no const-correctness concept), so the lazy programmer prefers to ignore the whole issue. |
| 6 | This is a plain bug, because delete new int[10] is undefined behavior as per the C++ standard. Nonetheless, poorly written (and tested) code has such patterns. |
| 7, 8 and 15 | These are basically exaggerations of what some people with Absolute Truth assert. Taken out of their contexts, these sentences sound even more absurd, but the meaning is “simple and tested systems tend to be more reliable than complex and new ones”. |
| 9 | Logging is helpful to get insights into the sequence of operations inside a running software. If you replicate the very same text, then it is quite hard to figure out what the executed sequence was. This is plain dumb. |
| 10 | Deleting this in C++ can be colorfully depicted as cutting the branch on which you are sitting. This is something that you usually don’t want to do. If you find yourself needing this, it is likely that you are approaching the problem from the wrong perspective. This operation is seldom correct. |
| 11 | Z80 CPU was a popular microprocessor back in the 80s. Programming in Z80 assembly was easy, surely easier than programming the 6502, another popular micro of the same years. This point is another overstatement that refers back to a Golden Age where everything was proper and sound. |
| 12 | Compiler warnings, most of the time, are just picky annoyances, not much different than a crooked picture on the wall. Sometimes they are actually errors – the intention of the programmer was not caught by the lines he wrote, and some subtleties were detected and reported by the compiler. This is one of the reasons why you want zero warnings when compiling your code. The other reason is that if your output space is cluttered by harmless warnings, you will hardly notice the dangerous one. |
| 13 | When a programmer is insecure about the language she/he is programming in, the first thing that she/he should do is to study the language rather than writing code with it. Adding redundant or useless structures (such as this – comparing with true) is a clear sign of doubt and uncertainty, and usually it appears in code of below-average quality. |
| 14 | Like many programmers, I like tidy and well sorted out thing (even if my desk could tell a different story to the casual observer). Programming languages (at least most of the commonly used ones) have English keywords. So, yes, the official reason is that your code should be read internationally; the real reason is that mixed-language code looks really ugly. |
| 16 | Once upon a time, you made animations by playing different images (frames) one after another at a given speed. This worked fine, but the production was labor-intensive. OBJ files contain static 3D models, so in order to play them, you need to perform a lot of data transfer to the graphics adapter. New techniques based on morphing and skeletal deformations arose in the years so that animations can be created with less data production and transferring, and – more importantly – can be optimized by the 3D accelerator. Making an animation with objs means that you miss where the bottlenecks in the graphics pipeline are, together with a good part of the last few decades in 3D technology. |
| 17 | Code punctuation is used to separate stuff. Keeping a consistent punctuation style (i.e., relative position between spaces, parentheses, commas, and the like) is a good habit is good manner to those who will read it and shows that you care for your code. And if you don’t care about your code, then you don’t care about your work, and don’t care about who is going to read your code, then you are despicable. |
| 18 | This is much like 14. Italian programmers (but I guess that this is shared by all non-English native programmers), while speaking, mix Italian and English words in the same sentence. This is fine because quite often technical documentation is written in English, and for many terms there are no Italian equivalents. Pronouncing an acronym half in Italian and half in English is something that tells about the English knowledge of the speaker and his/her desire to show off with unfamiliar buzzwords. |
| 19 | 48K RAM was the memory size of the ZX Spectrum, a popular home computer back in the 80s. This is much in line with points 7, 8, and 15 – a simple system tends to be more reliable than a complex one. There are also some implications about how lazy programmers are who are no longer willing to spend time doing their homework (optimization), and waste memory and CPU for no good reason. |
There are basically two main interesting ideas: the love for the code, meaning the care for your craft, and that simpler is better. I am not sure I actually heard the sentence “this code hasn’t received enough love” referring to an ugly or messy source file, but that’s the core idea. What I wrote above is true – if you don’t care for the details, why should you care for less evident characteristics?
Simpler is better, though put a little dramatically on the list, is not a new concept. KISS principle is also called. No sane programmer is going to oppose this; on the other hand, it has to be balanced with development time. Programmers that uses more than 48k are not lazy, but have deadlines to hit.
The list is over, but we’re still looking for wrongdoers to add. Do you have any suggestions?
Valentino says:
19 should be extended with: or put time critical code in the first 16KB.
max says:
@valentino you got the spirit right! 😉