One of the points in this list by Paul Osman that I recently stumbled on is that things like “staging” are indeed mostly useless however much people want to keep using them.
I usually get a lot of resistance when I suggest using monorepos but this article explains really well what cultural benefits that choice entails.
That is a fully comprehensive and excellent list of guidelines to unlearn toxic behaviour in code reviews by Sandya Sankarram.
A long treatment of how to scale work as organizations grow with some helpful guidelines: “Keep the work parallel, the groups small, and the resources local.”
I’m glad that this takedown of Clean Code by Dan Abramov got so much traction. I have no problem with clean code (lowercase), but inevitably the process of getting there and the things people do as a consequence make the entire endeavor an anti-pattern.
“Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.”
As always, people get too attached to the parts that are the most obvious and the least important.
A long article by Robert Arkwright that uses react server-side rendering as a hook to discuss various scalability issues.
A nice write-up of how Gitlab diagnosed and fixed an outage before it could even happen.
I have nothing but immense respect for these people who built a Slack client for Windows 3.1, turning retro computing into retro programming.
Then we get at Chapter 05: Composing and I really don’t understand the need to faff around so much when it comes to such a mathematically simple subject.
Composing is really easy, it’s just that programming languages make it hard. Especially if you look at this:
const compose = (...fns) => (...args) => fns.reduceRight((res, fn) => [fn.call(null, ...res)], args);
That curried function is left unexplained and I’m still not sure I can read it.
I’m documenting this because every chapter is spawning off one too many bunny trails for my taste. That also makes it clear how learning functional programming is a reclusive undergrad’s game.
I got sick of it and I want to learn the weirder stuff of functional programming seriously now.
I’m under the impression that these are fundamentally very simple things that people overcomplicate either because they don’t really understand them or because they are poor communicators.
I think it should be possible to explain the concepts and their use without any jargon, so I asked for sources:
- The Mostly Adequate Guide to Functional Programming
- Learn You a Haskell for Great Good
I’m now working with the Mostly Adequate Guide which starts of really good but at some point also dives off into mathematical weirdness. Let’s see how far I get.