Ciao!
What’s in your opinion the most crucial factor in remote work?
I believe asynchronicity is a big one. Having a well-specified area of responsibility and autonomy on how to perform a task is a killer combo.
I’m privileged to be part of a team that thrives with remote work. Most of the time, I don’t know when other people are working and, to be honest, I don’t care.
It’s just awesome to focus on producing value rather than keeping my eyes on the clock or being distracted by notifications.
It comes with a price, though. I find myself shaping and structuring my thoughts much more in-depth. I cannot afford to write something unclear in an async thread because it would cost a round-trip of messages to clarify what I meant in the first place.
But is having a crisp and clear idea of what you are trying to communicate such a bad thing? Of course not! And I hope we will bring that discipline back to the office.
Elsewhere on the Web
When costs are nonlinear, keep it small by Jessitron
Batching work is more efficient … until cost rises nonlinearly with batch size. Then smaller batches are the most efficient. So don’t delay maintenance!
(Riccardo: When a client asks why you are so obsessed with frequent and small deploys, just send them a link to this article.)
Using checksums to verify syncing 100M database records by Simon Eskildsen
In this issue of napkin math, we look at implementing a solution to check whether A and B are in sync for 100M records in a few seconds. The key idea is to checksum an indexed updated_at column and use a binary search to drill down to the mismatching records.
(Riccardo: Wow, I wouldn’t even know where to start estimating a napkin math lower bound in a similar situation!)
Breaking Up the Behemoth by Sandi Metz
Sticking with procedures too long is just as bad as doing design too soon. If important classes in your domain change often, get bigger every time they change, and are accumulating conditionals, stop adding to them right now. Use every new request as an opportunity to do a bit of design. Implement the change using small, well-designed classes that collaborate with the existing object.
(Riccardo: Wisdom from the OOP world. We are going back to Haskell though, right?)