Programmer Humor for the Holidays

-
Code Monkey
Maybe we programmers take ourselves too seriously.  How else do you explain the infamous Google Manifesto written by James Damore linking programming ability to gender?  Or  Levandowski being charged with stealing Waymo's intellectual property and fleeing to Uber?  Or the growth of the tech-bro culture?

If only a sense of humor could be tested as part of the interview process!  I've found humorists and comedians to be remarkably intelligent, as a good sense of humor requires imagination, a strong grasp of wordplay, and the ability to read a room.

To help with the upcoming holiday gatherings, I've collected a handful of programmer jokes.  Use at your own risk.

Q: How do you get rich with C++?
A: Inheritance!

Q: Why is C a rude language?
A: Because it has no class.

Q: Why do Java programmers wear glasses?
A: Because they can't "see sharp."  (C#, developed by Microsoft, gets grudging respect as Java done right)

The one-liner below is credited to Eric S. Raymond, and is less of a joke and more of a programmer and managerial insight:

If you have four groups working on a compiler, you'll get a four-pass compiler.

This next one is popular among those who studied the physical sciences.  It's not related to programming per se, but top programmers will get it:

So, Heisenberg and Schrödinger get pulled over for speeding. The cop asks Heisenberg "Do you know how fast you were going?" Heisenberg replies, "No, but we know exactly where we are!" The officer looks at him confused and says "you were going 108 miles per hour!" Heisenberg throws his arms up and cries, "Great! Now we're lost!" The officer looks over the car and asks Schrödinger if the two men have anything in the trunk. "A cat," Schrödinger replies. The cop opens the trunk and yells "Hey! This cat is dead." Schrödinger angrily replies, "Well he is now."

 A variation for electrical engineers adds Georg Ohm to the car just so he can be charged with resisting arrest.

 Lastly, what is the difference between Ops, Dev, and a project manager?  Originally, the joke posed the question with an engineer, a physicist, and a mathematician,  but I've reworked it for programmers.  Apologies for making the project manager the punchline.  Indeed, I have had the good fortune to work for some very good project managers, but I am taking the easy way to make the joke work:

Ops walks into a room, sees a fire on the floor and a bucket of sand hanging on the wall.  Taking the bucket, he pours the sand over the fire, puts it out, and leaves the room.  (Ops, being very practical, handles fires such a network outages, disk crashes, and security breaches.)

Dev walks into a room, sees a fire on the floor and a bucket of sand hanging on the wall.  Taking the bucket, he carefully circles the fire with the sand, sits down, and studies the flames. (Devs studies bugs, what causes them and what are their impacts.)

A project manager walks into a room, sees a fire on the floor and a bucket of sand hanging on the wall.  Seeing that the problem can be solved, he leaves.  (Ha ha. Like the mathematician who lives in a theoretical world, the project manager hands off real work to someone else.)

Happy Holidays!







Comments

Post a Comment

Popular posts from this blog

Bookshelf: UNIX A History and a Memoir

-
Image
  A man page will give you, in black and white, specific information about UNIX. Brian Kernighan's new book adds color and depth about UNIX you won't find anywhere else. I'm not a gray beard (yet), but I imagine they would plow through the book knowingly, but at the same time, learn a few things. Those new to UNIX -- recent college grads or those experimenting with Raspberry Pi -- would be better off starting with Chapter 8 which describes more relatable events and the descendants of UNIX, including Minux and Linux. It's when they start to ask questions like "Where does UNIX come from?" and "Why is Gamora grep?" that they should start from the beginning: Bell Labs, 1969. Kernighan opens with a birds-eye-view of Murray Hill New Jersey, zooms in on the buildings, the offices, the significance of Center 1127, and offers a brief look at some of the key players there. As I progressed through the book, the two factors that made UNIX not just possible, bu
Read more

Bookshelf Classic: The C Programming Language

-
Image
My first job had me programming in Microsoft BASIC for the IBM PC (DOS).  BASIC worked well enough, but its limitations were clear.  The language was interpreted and therefore slow.  More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement.  Anyone who has read Dijkstra knew  GOTO was a bad thing . Having learned a structured language in college ( PL/I ), using BASIC felt unnatural.  When a C compiler became available for the PC, I saw a chance to improve and modernize our software.  The problem was selling the idea -- a problem made harder because I wasn't fluent in C. "It would be a staffing problem.  Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager. The argument was strong as my knowledge of C was weak.  But I knew that C, by design, was a small language and thus easy to learn.  "It has about 30 keywords," I proffered to another manager. U
Read more

Connections

-
Image
Opening a drawer in my hotel room in Toronto, I found this.  I worship at the altar of tech, but I imagine the reaction between two priests might go like this: Mormon Priest:  "At least we're wireless!" Catholic Priest: "And from the very beginning too!"
Read more