Subtraction vs addition, blockchain qualities, reading later 💡
Subtraction vs addition, blockchain qualities, reading later 💡
Monday 3-2-1 – Edition 37
Hey, Luca here 👋 welcome to the Monday 3-2-1 ✨
Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.
You will also receive the regular long-form one on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
1) 🔪 Subtracting over adding
Research demonstrated that we have a bias towards addressing problems by adding new things (e.g. components, initiatives, ideas) rather than removing existing ones.
It is unclear why it is so, but it seems people do not consciously discard subtractive solutions — they do not consider them at all.
This is particularly unfortunate as removing stuff is often faster and cheaper than adding more of it.
So keep that in mind and add it to your arsenal. Ask yourself more often: can I solve this problem by just removing something?
Subtraction is a form of inversion — I wrote more about it in a previous article 👇
2) ⛓️ Blockchain is composable and dependable
Whatever your opinion of the web3 space, whether your think it is a piece of the future, or just a box full of scams, it is useful to reflect on the qualities of the blockchain as a technology.
The most interesting angle to me, is that blockchain is actually a computer — one with two peculiar qualities: it is public, and it is immutable.
These qualities matter because:
A public computer makes data and software 🧩 composable
An immutable computer makes it 🔒 dependable
🧩 Composable
More than 99% of software that runs on servers today is open source.
Open source won because of its composability. When you think about it, it allows to solve a problem exactly once for everybody, and allows in turn to combine that solution with others.
Software, however, cannot run itself.
It needs to be hosted on servers — and these are arguably private. This means production software gets controlled by private entities, and, crucially, this includes data — as databases are software themselves.
Private servers, and especially private databases, vastly reduce the potential for composability. APIs and access are limited to what companies allow people to do.
You can think at Ethereum (and other similar projects) as a protocol that enforces public data and publicly run software. This vastly increases composability because it makes it permissionless.
You can use and contribute to the same database everyone uses, and combine public software at API level (not source code level).
🔒 Dependable
Composability wouldn’t work if the blockchain wasn’t also dependable. Blocks are immutable, you are guaranteed that data and software won’t change.
This means we have now software that can make commitments. It is no mistake that such software is called a smart contract. It is a contract because it is binding.
With regular software, databases and apps are run under control of some entity, so software is dependable only if you trust such entity to uphold its commitments. With blockchains, instead, commitments are upheld by software itself.
This allows you to build and combine apps without the need to trust (to a certain extent) parties involved, which in turns expands the design space of what you can build.
You can find more ideas about web3 engineering in this two-part article I wrote in the past 👇
3) 📚 Reading later
These days I mostly read things from my Instapaper backlog, which means I very rarely read on the spot. So, I always save and revisit rather than just reading what is in front of me.
I feel this time-shifting behaviour makes me escape the reactivity loop. By separating the moment I find something that looks interesting from the moment I actually read it, I am able to apply a better judgement to what it is actually worthy of my time.
Many things feel urgent to be read just because of the state of mind we are in. Things we want to read when we are angry, anxious, or bored, are very different from what we want to read when we are happy, or at peace.
By constantly saving content for later, I find that what seemed interesting at a given time, it often isn't anymore even just a few hours later.
I wrote a full article about my reading process, which I use to write this newsletter 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️
Luca
Power of Inversion is a great framework to change the situation in a very agile manner. It is really surprising that such topics are not taught.
I would like to know your views on use of Inversion in productivity instead of growth.
Hmm, had never considered the "composable" angle. Def something to think about.