Impact culture, web3 layers, and tech debt effects 💡
Monday Ideas — Edition #86
Hey, Luca here! Welcome to the Monday Ideas 💡
Every Monday I send you an email like this with 3 short ideas about making great software, working with humans, and personal growth.
Paid members also receive a long-form, original essay on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider joining 1400+ engineers and get the paid membership!
p.s. learn more about the benefits of the paid plan here.
🗳️ The State of Engineering Productivity in 2024
Before we dive into this week’s ideas, I have some news! Together with the guys at Hatica, I am conducting a survey about what makes engineering teams productive: practices, usage of metrics, tools, etc.
The goal is to collect responses, gather insights 🔍 and write a thorough newsletter edition about this that will go out to all subscribers.
If you want to help me out on this, you can fill out the survey below 👇 it should take no more than 5 mins.
Thank you, it means a lot! 🙏
1) ✨ Good engineering culture is about impact
In his bestseller book Drive, Daniel Pink argues our motivation is driven by three factors:
🟣 Autonomy — the desire to be self-directed. We get motivation and joy by having control over our lives.
🔴 Mastery — the desire to improve our craft. We get satisfaction by getting better at what we do.
🟢 Impact — the desire to have a positive impact on the world. We are empowered by work that serves a higher purpose.
I love this framework and I quote it all the time. In my experience, however, the three elements have different weights for different people.
I have met engineers who were extremely driven by impact, and others who cared more about mastering their craft. Engineers who wanted maximum agency, and others who were happy to fit in a tight process.
These are not rigid categories. It is a spectrum, and everyone falls somewhere on it.
Since teams are, basically, just groups of people, this is true for teams as well. And for companies: companies inherit their founders’ traits, because founders hire people who are similar to themselves.
Now, I have found that the best engineering cultures are driven by impact. Impact is about what the business needs to achieve: if people are aligned and motivated to go after it, everything else follows.
On the contrary, a strong culture of technical mastery that is not also hungry for impact, may end up in bureaucracy and overly complicated tech.
That is not to say technical prowess doesn’t matter: it does, but the three elements work like a Maslow’s Hierarchy of Culture: without alignment on impact you can’t have safe autonomy, and, without autonomy, you can’t get healthy mastery.
I have written a full guide about creating good engineering culture a month ago👇
2) 🦠 Tech debt & second-order effects
The biggest reason why it is hard to sell leadership on repaying tech debt is that such initiatives mostly impact the business via second-order effects, like velocity, happiness, or reduced turnover.
Second-order effects have longer feedback loops and can be hard to assess.
If you strictly pit these against e.g. a feature that increases the conversion rate at checkout, it's not a level playing field.
So, most times, the #1 element that enables repaying debt is savvy leadership that understands this and isn't pedantic with requiring precise ROI and KPIs.
They understand their team and how bottlenecks work — and go for it.
Still, a good strategy for managing technical debt can be measurable and produce quantitative results. I wrote a full guide about this, which is one of the most popular Refactoring pieces ever 👇
3) 👾 Web3’s five layers
Interest in web3 has been on the rise in the past few months, and the recent approval of a Bitcoin ETF marks a historic moment for this space.
However, the architecture of a web3 application remains a mystery for most engineers — as it is wildly different from a regular web2 one.
Web3 applications can be organized in five layers. Most layers leverage existing technology and build on top of them. Let’s see such layers one by one and draw a comparison with web2 👇
Protocol Layer 🔀
When we talk of protocols for web applications, we usually refer to the ones defined in the OSI model — like IP, TCP, SSL, HTTP.
Web3 adds blockchain protocols on top of those. These new protocols regulate how data is stored and updated across the blockchain, and thus, across applications.
Infrastructure Layer 🏗️
Smart contracts are run by Nodes. Nodes are the basic infrastructure piece of the blockchain.
From an infrastructure perspective, the main difference between a node and a computer running regular software is that each node runs all the blockchain.
This poses obvious scalability concerns, which are being addressed in various ways. For example, Eth2 introduces sharding, while Solana has proof-of-history.
Platform Layer 🧱
When it comes to running software, just like people don’t want to run their own servers, they don’t want to run their own nodes.
To solve this pain there are companies that provide “Nodes as a service”, the main ones being Alchemy and Infura. They provide convenient APIs to access the blockchain (read and write) and allow you to scale while keeping the node layer below completely transparent.
They are the AWS of web3.
Contract Layer 📃
Nodes run virtual machines (EVM in the case of Ethereum) on top of which smart contracts run. This layer is about the business logic that affects the state of the application, which is stored on the blockchain.
Application Layer 📱
Applications that rely on smart contracts are still built with traditional backend / frontend stacks. In fact, most apps today are mixed — they manage part of the logic and state on the blockchain, and part on regular centralized databases.
This is to be expected because, as we will see, smart contracts impose rigid workflows that have a serious impact on your development velocity. Whenever you have non-critical logic and data (e.g. analytics, caching) you are better off developing it in a traditional fashion.
E.g. to access Ethereum nodes, you can find plenty of libraries that act as a bridge between the web3 and web2 worlds. Just check on Ethereum docs.
I wrote a two-part series on web3 engineering. You can check it out below 👇
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. 1400+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
First read here!
Interesting thoughts, wrote a detailed post on engineering culture, might be interesting for your readers: https://www.junaideffendi.com/p/engineering-culture?r=cqjft&utm_campaign=post&utm_medium=web