This post by Elizabeth Ayer got me.

The most significant mind shift for me has been my growing appreciation of systems and system thinking. I try to “make sense of the complexity of the world by looking at it in terms of wholes and relationships rather than by splitting it down into its parts”.

Are there any tried and battle-tested strategies to learn effectively, keep the information longer, and improve comprehension? In fact, there are, and they're backed by cognitive psychology.

Memory and learning

Learning is all about memory, and memory influences every aspect of our lives. Think of the last time you gave your telephone number, think of your date of birth, were they easy to recall? I bet they were.

What about a sport you’ve been practising for a long time? Let's imagine you've been swimming freestyle for years and had a coach who taught you the right technique, is swimming something you have to think of on every stroke, or does it come naturally?

The other day I saw a comment about a way to write some code that shocked me. It was about using uppercase and snake case with constants—LIKE_THIS.

The style of writing constants that way wasn’t what shocked me, as it’s quite common. The shock came from the idea that they felt justified to doing it like that because it was “industry standard” and that, in their many centuries of programming, they had always done it that way. Moreover, it was implied that if we really cared about quality, this “industry standard” had to be followed. I forgot to mention a crucial piece of data, the codebase doesn’t use that style anywhere.

Conventions are just conventions.

Convention: a usual or accepted way of behaving, especially in social situations, often following an old way of thinking or a custom in one particular society.

This week’s newsletter comes from the archives of my blog. It’s been a weird week, and couldn’t find the time to finish the article for this Friday—although the resources in the end are actually new, check them out. See you next week with a fresh article!

What's the truth behind deploying on Fridays, is it worth it, is it a gate to hell?

The main argument against it is that we should care about people and their weekends. Code pushed on Friday could cause an incident over the weekend, outside working hours. I've even seen an extreme version of this argument: that people who do Friday deployments need to grow up, they are not experienced enough, or they aren't considerate of their teammates.

You’re working on a new feature, a bug fix or on extending a piece of functionality. After identifying what needs to change, you go ahead and make the change. Backed by the confidence of some unit and manual tests, and by the fact that another developer checked your work and approved the Pull Request, you merge the code into the main branch a week or two after you started.

Everything’s hunky-dory, you look at your backlog and pick the next item. The Wheel of Time turns.

You find yourself working on another piece of work when a message pops up on Slack or, worst, you get an alert on your pager. It turns out that ticket you worked on a few days ago is causing the app to go down! You fix it in no time, no big deal.