Avoid hidden complexity
It's tempting to admire complex code that takes time to understand. But complexity is bad precisely because it takes longer to understand.
A subtle form of complexity is hidden complexity. This happens when code does something that you may not even think about until you need to understand what's been hidden.
Here's a simple C program. I'm not trying to trick you; it does what it looks like — it prints out "Hello, World!" Think about what may be hidden here:
Imagine this code base grows a bit, and you find yourself using tools like homebrew or apt-get to install libraries. You've been happily including header files from these libraries willy-nilly until BAM you get an error like this:
Suddenly you realize that you have no idea how your C compiler found stdio.h or other header files. Maybe you vaguely remember that they might be in /usr/include, but if you're on a recent version of macOS, that directory no longer exists.
You might say "well, that's ok, I'll just use -I flags and tell the compiler exactly where to look." But this is clearly a workaround, and it comes with the cost of not knowing how to fix related problems. What if two different library versions exist in two locations — which one will your compiler use?
