Before I pack my bags, close the laptop and head over to laying down somewhere green, here's some reading material from the Around25 headquarters + a quick rant on reviewing pull requests.
First, on PRs.
Working in a team is all about writing code that can be understood by most (all) of your teammates. Martin Fowler famously stated that:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
That should be enough, right?
Starting from this, I'd like for us to take the reviewer's perspective. You open up the PR, start reading and you find this:
Well, not exactly that, but something similar. It's a piece of code that makes you stop. You go on and find a couple more pieces of code that are not really making you happy. Some truly seem unacceptable, some do not adhere to the project's coding style and some are failing your own style rules. What to do?
The reviewer's job is to make sure quality code ends up in the repo. Nothing more, nothing less.
Personal coding style and expectations should be left behind. A different implementation than what I had in mind is fine as long as the architectural decisions are right. And also, sometimes good enough is better for the team and the project's velocity than top-notch perfect.
Rant over & on to our readings.
0. How to Be Great? Just Be Good, Repeatedly
“Greatness” comes from an identified or researched process that when followed, has some degree of certainty in the outcome.
“Moving fast and breaking things” is not a strategy, unless you are clearly defining a process of learning so that in the future, you can “move fast and break less of the same things”.
On consistency, compounding and a fair amount of Atomic Habits quotes. From Silvia.
1. Things I Learnt The Hard Way (in 30 Years of Software Development)
"Blogging about your stupid solution is still better than being quiet"
Observations and advice on software craftsmanship. Everything from development to teamwork and personal life. It even contains a changelog at the end 😄.
2. When should you be using Web Workers?
You have ~16ms until the next frame needs to get rendered to make animations feel smooth to the human eye. These numbers are fixed, because human psychology doesn’t change depending on what device you are holding.
On RAIL time budgets and chunking work into tasks that can be put in a queue to be executed off the main thread. From Alex Voica.
3. The Problem with Time & Timezones - Computerphile
Q: How hard can it be to build a web app that works out how many seconds ago something happened?
From Alex Voica.
That's it.
As I said in the beginning, This month is having a break. Until we come back (in this form or another), maybe follow our twitter account to keep close to what we read or watch around. Cheers!
