Monday 3-2-1 – good monoliths, career tracks, web3 failures💡
Edition #26
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) 🔨 Good microservices start with good monoliths
Consider the Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Paraphrasing it, good microservices designs are invariably found to have evolved from good monolithic designs.
Likewise, if your monolith looks like spaghetti, moving to microservices will not magically fix it. Rather, it will turn it into distributed spaghetti, making problems worse.
More ideas on monoliths and microservices 👇
2) 🎒 Career tracks are useful in hiring
A clear definition of roles and levels is immediately useful in hiring. Joel Chippindale, CTO and executive coach, reports 👇
In smaller companies I have found that much of the work to define roles and levels has been driven by the need to hire. For example if we are going to work together to hire a "Senior Engineer" then we need to have a shared understanding of what we expect from a "Senior Engineer".
Then it is only a short step to start using these definitions to help have conversations about professional development.
Starting in this way enables the team to start small i.e. think about one role/level and practice using these expectations in real conversations about hiring and professional development before building up a wider framework.
The career framework also makes for good hiring material. Candidates may ask hiring managers to have a look at it to assess where they would stand in the wider org, and their own opportunities for growth.
As a candidate, this is a smart move, and you should consider it a red flag 🚩🚩🚩 if the hiring manager refuses to make you see it, or if the company is above a certain size and doesn’t have one.
More on career frameworks 👇
3) 👾 In Web3, you need to prepare for failure
One of the biggest differences between web2 and web3 development, is that in web3 the cost of failure can be very high. This radically changes how software is developed.
ConsenSys, a leading development firm in this space, that is behind projects like MetaMask and Truffle, maintains a list of best practices around software engineering.
As they say:
It is not enough to protect yourself against the known attacks. Since the cost of failure on a blockchain can be very high, you must also adapt the way you write software, to account for that risk.
The approach we advocate is to prepare for failure. It is impossible to know in advance whether your code is secure. However, you can architect your contracts in a way that allows them to fail gracefully, and with minimal damage.
You can find the full document here:
It includes patterns to make contracts upgradeable and techniques to make them fail-proof, like circuit breakers, speed bumps, and rate limiting.
More on Web3 engineering 👇
And that’s it for today! If you liked the article, 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