

Sometimes you just need to document the business reason behind what you’re doing, regardless of how clear the code might be 😆
Sometimes you just need to document the business reason behind what you’re doing, regardless of how clear the code might be 😆
For a month or two I still kept the app on my phone. As a memento.
Reddit’s official UX experiences suck balls
Some of them, sometimes. But some are adulated and free and contribute vast swathes to our culture and understanding.
This is the most excellent summary of Go I have ever read. I agree with everything you’ve said, although as a fan of Scala and in particular its asynchronous programming ecosystem (cats for me, but I’ll forgive those who prefer the walled garden of zio) I would also add that, whilst its async model with go routines is generally pretty easy to use, it can shit the bed on some highly-concurrent workloads and fail to schedule stuff in time that it really should’ve, and because it’s such a mother-knows-best language there’s fuck all you can do to give higher priority to the threads that you happen to know need more TLC
Literate programming as an ideal works at very very high level and very very low level. Plumbing code often doesn’t benefit from comments at all, and is the usually the most subject to refactoring. Code by amateurs/neophytes is often not gonna be written in such a way that a clear description of the intention or mechanics is achievable by the coder. Unobtainable standard, smh. I like comments with a ‘why’ at the top and a ‘what’ at the bottom (of the stack. I’m talking about abstraction layers. Why am I doing this piece of logic in the code you can clearly understand at the top, what the fuck am I doing these weird shenanigans with a fucking red-black tree of all things in this low level generic function)