22 insults no developer wants to hear
Parsing, unpacking, and sorting the insults that developers sling takes a thick skin. No one likes being told their ideas and code are anything less than insanely great, but some slights are better than others, cutting to the core of your coding faults. In fact, a good insult can contain a road map for moving your project forward. If your rival is willing to explain what you need to do to make your code worth using, well, that’s worth putting up with someone calling you or your code “heavy,” “crufty,” or “full of anti-patterns.”
Some people are explicitly rough, and part of that might be the mechanisms by which we receive insults -- almost never face to face. Linus Torvalds argues that email is an inherently flawed mechanism that often hides subtle cues, like the ones that the marketing department swaps by moving their eyes. Torvalds once told a thin-skinned developer, “it's damn hard to read people over email. I think you need to be *more* honest and *more* open over email.”
For a bit of fun, he inserted a logic bomb into the calls for more sensitivity by saying that his culture includes cursing. Whiners might try remembering that he comes from Scandinavia, the home of Viking warriors.
In the interest of helping the technology world cope with the slings and arrows of outrageous fortune, here is a list of some common insults that no developer wants to hear -- but often will. Brace yourself.
These three words may seem innocuous, factual even, but they hide true venom. After all, they signal that the code may run smoothly on your machine, but that doesn’t matter to anyone else. They gave it a go where they wanted your code to run, and it bricked. It could be that they don’t have the right libraries installed. Maybe they’re using a different version of the compiler. They may even have a different switch set on the optimizer. Whatever the real reason, nobody knows, and nobody cares. All they want to tell you is that you skipped the second lesson of programming class, the one when the instructor teaches where to put the semicolons.
Here, coding and stoner rock diverge. For some reason, “light” is a compliment when it comes to programming and “heavy” is an epithet, like putting way too many notes in your guitar solo. But “feature rich” is a compliment and “missing features” is an insult, so go figure. You can’t have features without adding code and making the stack fatter and thus heavier.
If you associate fine dressing with power and status, in the programming world, you have another thing coming. After all, only the clueless ninnies who know nothing about computers but want to wade in and manage a project would ever wear a suit. The people who build software wear something more comfortable. A cross between a kimono and kilt might be nirvana -- otherwise, that old Phish tie-dye or a hoodie if you’re younger.
Linus Torvalds once wrote, “if you want me to ‘act professional,’ I can tell you that I'm not interested. I'm sitting in my home office wearing a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords.”
If you, as a programmer, even seem to be guilty of one of those, you’ll be wearing the epithet, regardless of how you dress for work.
Some call them bad strategies, stupid ideas, or sloppy thinking, but programmers like to toss around the phrase “antipattern” to describe a way of building code that isn’t recommended. It sounds more scientific -- and because science is the religion of the console, saying your code is full of antipatterns is worse than saying it’s bad. It’s saying your programming is immoral.
Long ago when PCs ruled the planet and Apple was almost bankrupt, a few loyal users continued to sing the praises of Apple and predict that the world would one day come to cherish the beauty and sophistication of its products. The PC-lovers dismissed their addiction by calling them “fanbois.”
Though the Apple-loving nuts were right, it doesn’t mean that someone is now paying you a compliment by calling you a fanboi. They mean you’re willingly ignoring reality because of overzealous devotion to a weird principle or idea, such as Perl or maybe .Net, not that we’re making any suggestions.
Computers are fast. As they say in the marketing department, that’s part of their brand. You might even say it’s a foundation of the brand. After decades of Moore’s Law, everyone simply expects computers to get faster and faster.
Alas, programmers don’t always deliver something that’s fast. Many hardware designers like to crow that they’ve delivered their side of the bargain. It’s the software teams that produce bloated, inefficient code that sucks the life out of the faster chips.
Although turning down the temperature and taking your time results in the best-flavored meats, slow-roasting your code is a no-no.
Could anyone be as clueless as a new hire They would probably spell this with letters and not digits. (See also: “gnubie”: one who doesn’t grok open source.)
Funny, there’s a whole department bent on relating what’s human in us to the economic term "resource." It seems vital to our employability to at least appear to be resourceful. But if a programmer calls you a resource, he might as well call you a Lego brick in the wall or another cog in the machine. You’re not even a piece of meat -- you're an automaton or function call that spits code.
Crufty: A design that’s tossed together, often with leftover detritus from other projects. A cobbled-together mess assembled with little foresight or intelligence. A sloppy, stitched-together Frankenstein that barely works. Take your pick, when you see the word “crufty.” Likely, it’s not only your code they’re commenting on; it might be you and your ideas.
In Unix world, the null device is a black hole that forgets all information sent to it. It’s mainly used to test device drivers and other code that processes data. As a metaphor, it’s a perfect offhand way to say the memo you wrote isn’t worth storing on disk or sending to the printer.
Sometimes you don’t have time to polish that side project you put together on the weekends, only to find 2,000 other devs suddenly depend on it. With the second wave of interest come the insults. What is this thrown-together repo in a single file A solution that’s expedient, not elegant. A cob job. A virtual collection of baling wire and duct tape designed in an instant because that’s all the time there is. This is how your code gets to wear a badge marked “kluge.” At best your programming is seen as a fix that may succeed temporarily but will eventually fail because it isn’t thorough enough to solve the problem correctly -- even if it stands the test of time.
Code will generally start to fail as the operating system, libraries, or other systems are updated. The newer versions have more features, take different parameters, or sometimes make different assumptions. In other cases, the programmers have fixed a bug that your code assumed was there. The old code doesn’t fail completely, at least at first. But it starts to get creaky as more and more calls to the OS or the libraries begin to fail. If you don’t invest in renewing your knowledge and improving your code, you start to rot like an old fish. Folks can be harsh when pointing this out.
Electricity travels through a stream of electrons. Light travels via photons. Stupidity The bogon particle is responsible for bogus behavior and general bogosity. You'd better hope the bogon flux through your fingertips and the keyboard isn’t measurable. (Note: Opposite of a cluon.)
In the early days, Apple tried to append copy protection to software by adding an extra bit to the application file header. If it was set, the operating system would refuse to copy the file. This worked well until everyone figured out how to edit the header and flip a bit. Although everyone enjoys being compared to Apple, no one likes hearing that a slick new architecture or feature set reminds someone of the bozo bit.
Code that is fragile and unable to function with any necessary resilience -- that is, what they are saying about the results of your labor. Sure, when your code compiled and passed all of the unit tests, you celebrated. But then someone changed the inputs or tossed in a divide by zero and your code crashed. That’s when you realize there’s more to writing code than making sure it works on the first test.
This insult references a famous tale from Richard Feynman about an ancient tribe that lashed together some logs to build what looked like an airplane. Why They knew the winged contraptions brought amazing visitors with valuable cargo from the sky. They thought that building something that looked like it had wings would produce the same results. In the case of software, the one who builds a system based on a shallow misunderstanding of the problem is the one who gets labeled a “cargo cult programmer.” One day the half-baked theory you based your work on might look humorous even to you.
Some people write command-line code that delivers the answers in simple text. Others build flashy user interfaces with dancing code, flashing buttons, and eye-catching colors. They may even embed several videos, sometimes with beautiful models with eyes that never quite meet yours. Is there anything underneath The boss isn’t going to look at the code. In other words, a pretty visage covers an empty core.
The work “hack” is overloaded with various meanings, some positive and some negative. "Hackish" is much the same. Some use it to suggest a clever maneuver that would be appreciated by the wiliest hackers. Other times it’s a trick that’s not quick enough to be a hack, not solid enough to be real.
"Mangler" has an obvious insulting quality and a subtle one. If you’ve mangled the code -- well, what else can you expect The term is also used, at least in coding cubicles, as a replacement for the word “manager,” as in “project mangler” or “division mangler,” to show how the artisans feel about the bureaucrats. Of course, managers have a different term for the people who overpromise and underdeliver. They’re called programmers.
Someone who does nothing is a no-op, in reference to a blank binary instruction that flows through the CPU without changing anything. No-ops pad the instruction stream and help with debugging. Some processors use no-op codes with clever representations in hexadecimal. (See “deadbeef.”)
Some of the cleverest algorithms rely on a steady stream of completely random numbers to find solutions -- some, that is, but not all. In fact, most don't. You can see how those perturbed by perturbations in your code might label it as such. You certainly don’t want your emails, memos, or documentation to be seen as random tacking in hopes of hitting on something important. (Antonym: knowledgeable.)
The only thing worse than being insulted is being ignored.