Programming with Erik


20 Funny Programming Fact and Quotes

Please put down your coffee, just to be sure

Image for post
Image for post
Photo by Frank Busch on Unsplash

Here’s a collection of the funniest programming quotes I heard on the work floor, mixed with some history and best practices as well. Let’s go!

1. Java is to Javascript like car is to carpet

I love this one because it summarizes the Java vs. JavaScript story perfectly. Most of you know that Java and Javascript are two entirely different things, despite their names, but many beginners get confused by it.

So why are they named this way?

From an interview with its creator Brendan Eich:

InfoWorld: As I understand it, JavaScript started out as Mocha, then became LiveScript and then became JavaScript when Netscape and Sun got together. But it actually has nothing to do with Java or not much to do with it, correct?

Eich: That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.

So the JavaScript name is the result of a co-marketing deal between Netscape and Sun, in exchange for Netscape bundling Sun’s Java runtime with their then-dominant browser. At the time, Java applets allowed you to distribute applications efficiently. It was not a bad idea. In fact, it was quite progressive for the time — it would make software distribution a lot easier. Unfortunately, Java was heavy to load and felt a bit clunky at the time.

JavaScript was meant to be a lightweight language that could be mixed with HTML, to make simple HTML pages more interactive and compelling without requiring the heavy Java alternative. Nobody at the time would have predicted that JavaScript would evolve into the most used language in the world.

2. It works on my machine

Bad developers tend to write code that works on their computer but fails anywhere else. How’s that? It can have several reasons:

  • They are using packages that are only installed locally and don’t mention them anywhere in the documentation
  • They forgot to check-in essential files in the version control system
  • They use the most recent, bleeding-edge versions of a toolchain that nobody else is using yet (or the opposite)

I’ve cursed at others more than once while trying to get their code to run, only to find out I was the one doing it wrong. So don’t judge too quickly!

3. They named it .NET so it wouldn’t show up in a Unix directory listing

In case you’re not familiar with Unix file systems, a file starting with a dot is hidden by default. So yeah, funny, because it’s coming from Microsoft. Next!

4. Some people, when confronted with a problem, think “I know, I’ll use regular expressions!”

…and now they have two problems.

Regular expressions are a pain. When you think you finally got it right for one document, it matches 70% of the next document you feed it. Arghh!

5. It’s not a bug — it’s a feature

I guess sometimes you’ll get away with this one!

6. The cheapest, fastest, and most reliable components are those that aren’t there

Attributed to Gordon Bell. You should keep a system or piece of software as simple as you possibly can. This reduces complexity and the number of bugs.

Image for post
Image for post
Photo by Bench Accounting on Unsplash

7. It works, but I don’t know why

Sometimes you fixed a bug, but you don’t understand why. We’ve all been there, more than once. I promise it’ll get better, just keep learning and practicing. But never, ever leave it at this. Always make sure you understand your code. Don’t be ashamed and ask someone else if you need to.

The same holds for copy-paste code. Yup, we all use StackOverflow sometimes! But if you don’t understand the code: either don’t use it or ask someone else for help.

Creating or using code you don’t understand is also referred to as voodoo coding. It’s is a bug waiting to happen.

8. Software is like cathedrals. First, we build them, then we pray

It sure feels like it sometimes. This also reminds me of the Cathedral and the Bazaar. It’s a book that contrasts two different development models:

  • The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers.
  • The Bazaar model, in which the code is developed over the Internet in view of the public. Linus Torvalds, leader of the Linux kernel project, is seen as the inventor of this process.
Image for post
Image for post
Photo by Bogdan Todoran on Unsplash

9. Code never lies, comments sometimes do

Comments are often forgotten while you change your code. Sure, comments have a vital function, but if you can, don’t use comments and write more descriptive code instead.

There are three ways to document code:

  1. Use comments inside of your code.
  2. Write documentation in a separate document.
  3. Write self-documenting code.

To elaborate on that last point, because that’s what I mean with writing more descriptive code:

  • Use good design, so your codebase is easy to navigate and structured logically.
  • Don’t try to save characters. Use full names for your variables, classes, and functions. So, instead of wm, name it windowManager. Instead of rf, call it readFileToString. This name helps tremendously when others — or yourself, after a few months of not looking at the code — try to understand what’s going on.
  • Extract as much as you possibly can into functions and make these functions do one thing. Name them accordingly. For example, create a function that reads a file into a string, and name it readFileToString(String fileName). Without reading the code in detail, people will know what it does. Ideally, your code is a sequence of function calls like this that almost read like human language. Only when needed, the reader can dive in deeper. This code documents itself!

10. I don’t care if it’s the proper way to do it, just get it done!

That’s the sound of technical debt in the making. What’s technical debt, you ask me? Good question!

Technical debt is the accumulation of extra work generated by making bad choices or taking shortcuts. Imagine building a very high building. If you start with a weak base, the cost of properly rebuilding that base will grow as you keep building higher and higher. At some point, the cost of repair is higher than tearing it down and starting over.

11. Cheap, fast, reliable — Pick two

I love this one because it makes the ones hearing it (your managers) think for themselves:

  • You want it to be reliable and fast? It can be done, but you’ll need to pay the best developers.
  • Cheap and fast? Sure, but don’t expect it to be reliable!
  • Reliable and cheap? Maybe, if you’re lucky. But it will take some time to find someone who can do it for cheap, or it will require a lot of iterations to get it right (or both).

12. Code as if the guy who ends up maintaining it will be a violent psychopath who knows where you live

In case you need that extra motivation!

Image for post
Image for post
Photo by sebastiaan stam on Unsplash

13. There are two difficult things in Software Engineering

  1. Naming things
  2. Cache Invalidation
  3. Off-by-one errors

We humans generally start counting at 1. Computers start at 0. This simple fact has been the fuel for numerous bugs and difficulties.

14. The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

This one is from Robert C. Martin. If you don’t know what functions should be small and should only do one thing, please read points #4 and #5 from this article.

15. Beware of programmers who carry screwdrivers

I’ve seen this one on t-shirts. I guess it means something along the lines of “stick to your specialism.” There are many programmers, but not that many software engineers. By which I mean, there’s a difference in being able to create scripts in Python vs. building a complex software system like an online shop or a customer database, that must be maintained for the years to come.

16. A good programmer is someone who always looks both ways before crossing a one-way street

The best software can handle all errors, and I mean all. Even those that “will never happen.”

17. One bad programmer can easily create two full-time jobs a year

This is a scenario that happens a lot. There’s a problem that needs to be fixed, like right now! Some consultant is hired, does the job in a few days and leaves. Everybody is happy. Then, a couple of months later, someone needs to do maintenance on that piece of the system. Only to find out it’s a big, undocumented mess, and the original consultant has another job by now.

18. Measuring programming progress by lines of code is like measuring aircraft building progress by weight

This one can be attributed to Bill Gates. More lines of code do not equal progress. The best code uses the least amount of lines to get the job done and is also the hardest to write. This is a well-known software principle, called “Keep it Simple, Stupid” (KISS for short). If you want to learn more about best practices like this, read my article “The 12 Habits of Highly Effective Software Developers”.

Image for post
Image for post
Photo by Kevin Hackert on Unsplash

19. There are 10 kinds of people — those who understand binary and those who don’t

I’m going to assume I don’t need to explain this one!

20. What about 19 Jan 2038 at 3:14:07 AM?

Remember Y2K? There’s another date like it.

In Unix-like systems, time is measured as seconds since January 1, 1970. This time is often stored in a 32-bit signed integer. That means that dates can range between −2147483648 en 2147483647 seconds from 1970. So now you know what it is about 19 Jan 2038 at 3:14:07 AM, it’s 2147483647 seconds after January 1, 1970!

Written by

Software developer by day, writer at night.

Sign up for Tech Explained

By Programming with Erik

Short, low-volume newsletter to keep you up-to-date on my latest articles Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Get the Medium app