The cardinal programming jokes

I'm depressed. What I'll do is I'll tell you the 3 cardinal programming jokes. And if it helps cheer me up, I'll consider my job well done.

I must warn you about those jokes. Firstly, they are translated from Russian and Hebrew by yours truly, which may cause them to lose some of their charm. Secondly, I'm not sure they came with that much charm to begin with, because my taste in jokes (or otherwise) can be politely characterized as "lowbrow". In particular, all 3 jokes are based on the sewer/plumber metaphor. I didn't consciously collect them based on this criterion, it just turns out that I can't think of a better metaphor for programming.

By the way, I was recently told by a very strong programmer that of all things, he wanted to become a plumber as a kid. 'Cause it was very interesting to him, the tools, the pipes, how you make the whole thing work. And then he felt he understood enough of it, so he figured he'd become a programmer instead. And now he is, and he has enough (virtual) pipes full of (virtual) shit to keep him curious about how to make it work for the rest of his life. By which I mean to say, hey, it's not just my bad taste, it is a good metaphor, see?

So, the jokes. Lowbrow, depressing stuff. You have been warned.

Expanding your skill set

A very important thing. You should be learning stuff. Yada yada.

With many things though, people have this strange tendency to avoid knowing them, and instead ask someone else unfortunate enough to already know them. Say, Makefiles. Is it just my experience or do people worldwide pretend to be incapable of dealing with a hairy Makefile, and leave its regularly scheduled tweaking to a small set of knowledgeable victims?

Or debugging of the lowest kind, with race conditions and creative memory corruption. People like to give up on that, as long as someone else can take over. "I just don't know how to proceed". Right.

Sometimes I wish I could put this claim to a test. Check if they'd say this at gunpoint. Or, more humanely and therefore much less cheaply, propose them $1M if they do know how to proceed. I bet they'd think a bit harder. If you're working on AI, specifically on preparing it to the Turing test, don't forget to teach it this principle, or else it has no chance of passing for a human.

I find that the following describes the double-edged sword that is skill set expansion quite well:

A plumber and his apprentice pay a visit to a manhole requiring their attention. The plumber goes down the manhole, and the apprentice stays above with the toolbox. The plumber asks for wrench #3, and the apprentice puts the wrench into his hand. 2 minutes pass. "Wrench #5!" The apprentice finds the wrench and passes it to the plumber. 5 more minutes. "Wrench #6!" The plumber is given that, takes a couple more minutes and finally comes out.

The next scene should really be a small piece of pantomime, but I'll have to get by with words alone. Not unexpectedly for this type of joke, the plumber comes out with his arms covered with excrement. He slowly sweeps his right hand over his left arm, then the left hand over the right arm, shakes his hands and reaches for something to wipe them with. And to the apprentice he says:

"Watch and learn, son, or you'll be passing wrenches for the rest of your life".

Really, you should learn things. Expand your skill set. Who wants to be passing wrenches?

Layers of abstraction

Abstraction is good. Or should I say legitimate. Or should I say inevitable. I mean, you have to count on something. Something has to work, because you can't build things on top of nothing.

Except it won't work. That something you build things on top of won't work.

What's that? "Whining"? Yep, definitely. This here is whining.

Whining is good. Or should I say legitimate. Or should I say inevitable. Because if you aren't allowed to whine about frigging data channels which drop chunks of data and duplicate chunks of data because some fucking hardware subcontructor couldn't be bothered to implement arbitration for shared data access, if you aren't allowed to whine about that…

If you aren't allowed to whine about that, you should be allowed to whine about memory, which flips bits, and zeros bytes, and it does so once per hour for some weird sequence of accesses having nothing to do with the address where data actually changes. Fuck that, OK? Fuck DDR2. Fuck its controllers and the zillions of their configuration parameters.

A plumber climbs out of a manhole, this time without a preamble, and his arms are covered with - guess what? - excrement! A beautiful little girl in a beautiful white dress happens to pass by. The plumber seizes the opportunity and (another piece of pantomime) quickly, but firmly sweeps his hands over the girl's white dress.

Little girl (appalled): AAAH!!

Plumber (outraged): Oh yeah? I bet you love to take a shit though.

Yep. You love to allocate objects in memory, don't you? Megabytes of them. And then a board designer decides to wipe his filthy hands with your beautiful white huge software system. Debug that, you perverted memory-addicted individual.

Taking pride in your work

And still, I actually like my work, on a level. Why? It feels inherently cool to design stuff that becomes this bunch of tiny parts, transistors and all, switching hundreds of millions of times a second, and then to write code that manages all the flying circus.

I know people who feel the same about computer vision. People for whom it's a personal priority to work on computer vision, where they are given images and they look for stuff in them. Who wants to be doing that? Who wants to be responsible for the solution of a problem that can't even be precisely defined? Me, I wanna be doing hardware.

What do I actually do most of the time though? I eat hexadecimal. I sit near a debugger, and I keep hitting Page Up in a memory view window, to find the beginning of the array that overwrote this piece of data (I guess the element size from the repetitive patterns and such), and along comes a computer vision geek and he says, "damn it, man, you got out of the Matrix!"

Well, I dunno, I find it much easier to guess what buggy code did to my memory than to find out "why" an algorithm thinks this here is a person when in fact it's a shade of a tree. Because if you look closely at the pixels, the shade kinda looks like a person, but of course we could reject it based on its motion, but of course that would mean we'd approve these reflections over here based on their motion, but, but, but…

What my bogus example is saying is that you have lots and lots of cues but each can work both for you and against you, and now how do you weigh all that, without even a formal spec? I'd rather eat hexadecimal, thank you very much.

And we look at each other, and sincerely think that our jobs are pretty nifty, but the other guy's job is awful and how can he be doing it. And I suspect that if one looks at this from aside, one might wonder where the actual fun is, because there is actual fun in here, or so all the participants testify. And I think I know the answer.

An airplane lands, and passengers come out. One of them notices a guy underneath the airplane. As you'd guess, the guy is a plumber. The plumber touches some lock, and immediately gets covered by excrement streaming from an opening at the bottom of the plane.

The pantomime cleanup routine follows, and then comes the turn of the dialog.

Passenger (appalled): What on Earth makes you keep this job?

Plumber (proudly): Hey, I'm in the aerospace business!

The aerospace effect happens to different people with different things. With some, it's "Hey, I'm making real hardware!" With others, it's "Hey, I'm finding real objects in real images!" It's a good thing people are different, because so are the currents of excrement, and someone ought to swim in each. We can't all be passing wrenches.


#1 woongiap on 09.17.08 at 6:26 pm

a really good one, i like the first joke. i'm learning c++ currently and my ultimate is to understand linux kernel source code, could you be able to point me some good reference on c/c++, especially makefiles?

#2 Yossi Kreinin on 09.17.08 at 9:25 pm


C: Kernighan and Ritchie's "The C Programming Language".

C++: Bruce Eckel's "Thinking in C++". Side note: the Linux kernel is in C, not C++; Linus Torvalds isn't particularly fond of C++: (and, um, I'm not a big fan of C++ either as you can see at - so it's kinda funny that you ask me about reference on C++… but anyway, Bruce Eckel is really good).

Makefiles: not really related to C or C++, except that these languages are hard to "build" (as in, locate include files, set up preprocessor definitions), so you end up with hairy makefiles. I'd recommend the GNU make reference manual (, under the assumption that the Linux makefiles use the GNU extensions so this is the make flavor you need to know. Makefiles suck, but at least the GNU make manual is thorough and complete. Another approach to makefiles is to not care and simply copy whatever people do in existing makefiles (check how they add source files to a library or a library to a project and do the same). Copy/paste programming is a reasonable thing to do when your programming language is that sucky… Also, makefiles are frequently auto-generated by "autotools" (autoconf, automake), and this is the level of the mess which I never mastered beyond the copy/paste level; but that level proved to be good enough to hack on, say, LLVM or valgrind. So I wouldn't take this part too seriously.

#3 woongiap on 09.17.08 at 11:47 pm

just read through your early posts, totally agreed that low-level programming should be easier than high-level. after working for more than 8 years on j2ee apps, only i found that learning low-level languages like C is a must for a software programmer. you are not a big fan of c++, then what about c? what's your favorite programming language? thanks for the pointers.

#4 Yossi Kreinin on 09.18.08 at 11:07 am

I think C is fine, I'm kinda fond of it. It's limited in a variety of ways, many of them "random" in the sense that they could be fixed without changing the "core traits" of the language (say, adding garbage collection changes the "core", but import instead of #include or a better macro facility doesn't). Of course it doesn't really matter because for years, most of the importance of C comes from it being a standard, so things can't be changed. I think C is a grand achievement, in terms of influence (basically everything is built on top of it today) and elegance (considering the constraints of real-world development).

In general, I don't have a "favorite" language, but I think most mainstream ones are fairly good, that is, they have their quirks and limitations but the pain from that doesn't exceed the joy of having lots of tools and libraries available.

Regarding non-mainstream languages - the ones where you are more likely to feel pain in the tools/libraries department - I like Lisp and D, for example. In general, I like safety but not bondage and discipline, so I'm not attracted to, say, Haskell with its strict type system and its resistance to the natural act of side effects.

In general, I'm not very critical of language designers, and on average, I admire their taste, among other things (even with languages I don't personally enjoy, like Perl). I've done language design on a small scale and I can say that it's really hard to prevent sucky things from sneaking in. My attitude towards C++ is rather special because it has those many complementary defects amplifying each other and this awful smug, misguided culture that eats the brains of the brightest, turning them into cannibalistic template metaprogramming zombies. Yes, rather special.

#5 SteveC on 10.23.08 at 7:13 pm

Here's a joke which (so far as I know) I invented, and which I think you might enjoy.

It is very short, more of a "one liner" than a joke, and works best as a sort of throwaway comment made when a relevant topic has conveniently arisen in conversation.

It goes like this:

I don’t think the guy who invented C++ knows the difference between “increment” and “excrement.”

#6 Yossi Kreinin on 10.24.08 at 2:37 am

I try to stay away from wordplay in English because it's hard to tell the difference between an exquisite specimen and a totally crippled one (like, I dunno, something around "then" and "than"), unless you're a native speaker. That said, I once worked with a somewhat hateful DMA controller having an "external increment" mode bit, and I did allow myself to call the complementary mode bit "internal excrement".

#7 Warren on 12.05.08 at 8:46 pm

So there isn't a language that makes you all warm and fuzzy? Or was it lisp? How about Python? Pascal? Oberon? Ruby? Anything else? The One True Way? No?

w a r r e n dot p o s t m a at g m a i l dot c o m

#8 Yossi Kreinin on 12.05.08 at 10:21 pm


I'm intrinsically all warm and fuzzy.

#9 John Cowan on 05.11.09 at 8:04 am

The canonical version of your third joke, at least in English, is about a guy who's spent his whole working life sweeping out a theatre after each night's play is over. Finally, the star takes pity on him and asks him why he doesn't try to improve himself and get a decent job. The sweeper is outraged:

"What, and give up show business?!"

#10 Yossi Kreinin on 05.11.09 at 8:19 am

It's good to know the canonical version, although mine has the benefit of presenting arguably better opportunities for pantomime.

#11 Amir Barak on 08.05.09 at 6:59 am

Funny jokes, what do they sound like in Hebrew? Was just reading your FQA on C++; also funny stuff [well, sort of]. You ever hear of Lolcode?

#12 Yossi Kreinin on 08.05.09 at 7:57 am

Well, actually only the last one was originally in Hebrew, and the guy told me the punchline in English, leaving few to spell in the Holy Language except for the excrement description you could improvise just as easily as myself.

The stuff in the C++ FQA isn't funny - it's very, very sad.

Can haz lolcode.

#13 blue-slonopotam on 01.03.11 at 3:40 pm

Strugatskie "A doomed city" has a much better version of the first joke.

#14 Yossi Kreinin on 01.03.11 at 11:54 pm

What bought for, sold for…

Leave a Comment