May 2020
One programming aphorism is that the less code you have, the fewer places there are for bugs to hide. Bill Gates is quoted as saying "Measuring programming progress by lines of code is like measuring aircraft building progress by weight". So when solving a given problem, it's better to have less code. But wait! Even my Emacs config is over 1400 lines! That's a lot of places bugs could be introduced.
So what are some ways of shrinking code? We might make a general solution, so multiple features can be implemented merely by configuring our powerful framework. Or we might decide to simplify the problem. We might also choose to write in a more expressive language, skipping boilerplate by abstracting away code patterns.
These are all good solutions to having less code. But note that these are all about making there be less code. What if we were selfish? Could we simply make us have less code, and rely on other people doing work for us? The obvious answer is to find a library that implements part or all of the solution. But what good is that? Isn't it more fun to write it ourselves? Let's rule out using libraries, and assume we're doing the enjoyable part of writing all the code ourselves.
A lot of the time we're stuck. However, if we're customizing or extending free software, there's another possible solution: push the code upstream. The total amount of code will stay the same, but the amount of code we have to deal with will decrease. And then we won't have to deal with it anymore; the maintainers of the software we contribute to will!
As a bonus, if we push our code upstream, other people will be able to use it also. And it'll be easier than downloading a dependency of a library our made, because it'll be part of the base software package.
And don't forget about bragging rights.