So why are they named this way?
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.
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.
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:
- Use comments inside of your code.
- Write documentation in a separate document.
- 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!
13. There are two difficult things in Software Engineering
- Naming things
- Cache Invalidation
- 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”.
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!