I’ve been writing a pubsub listener for work recently and had this silly “shower thought”: the ideal queue should be empty. Why? If the queue is not empty, it means that whatever job is consuming from the queue is not keeping up with messages coming into it. Ok, then if queues are supposed to be empty, then what are they good for?
Source: Queues should be empty, an article by Josh Voigts.
I've read some nice articles recently which I can sum up as “advice you might as well take.” This is stuff that's good to consider at the beginning of a project, or when you're about to add a feature to some existing software.
These articles run counter to YAGNI (You Ain't Gonna Need It), the software design principle that says you should only ever add things you'll be using right away. Many even call this out in their titles! One even addresses this by coining an alternative term, PAGNI (Probably Are Gonna Need It), so let's start with that one.
Source: advice you might as well take, an article by Brian Hicks.
Writing good code is hard - it takes a ton of effort and care. Writing bad code that does things correctly is incredibly hard. Of course, goaccess is a program that is stuck forever in the form you see it now, because adding new features is nigh impossible, but looking at the code, knowing that it was valgrind tested, the thing is a masterpiece.
Source: Lessons learnt while trying to modernize some C code, an article by Dorin Lazăr.