Bad perks, connoisseurs, and good onboarding 💡
Monday Ideas — Edition #154
1) 🗃️ The fastest open source analytics DB — fully managed
This idea is brought to you by today’s sponsor, Aiven!
ClickHouse is built for speed – processing analytical queries 100-1000x faster than traditional row-oriented systems. So how do you make a fast database even better?
Enter Aiven.
Aiven for ClickHouse lets you set up a fully managed cloud data warehouse in less than 10 minutes. Spin up your clusters, scale, fork and migrate – all from a single dashboard – and stop worrying about the infrastructure.
Check it out and let Aiven do the heavy lifting!
2) 🎁 I hate perks
Most perks on engineering job posts are bad, and companies should just get rid of them.
In my book, a good perk checks at least one of two boxes:
✨ It is meaningful — it should be relevant to your culture, reinforcing / encouraging substantially some of your values. For example, for a remote and async culture, it is meaningful to give a generous budget for a home workstation.
🏦 It is really valuable — famously, Whole Foods gives 20-30% in-store discount to all their employees.
Bad perks are the opposite of meaningful and valuable — they are arbitrary and cheap.
They make candidates suspect you are using them to compensate for a position that is not interesting enough, or well-paid enough.
Bad perks are free snacks, gift cards, or paid birthdays off.
In this case, no perks is way better than bad perks. Plenty of great companies do not advertise them in job posts, and it's fine!
The focus here is on "advertise". It can be great to have paid birthdays off. You just don't need to write it in the job post.
2) 🔬 The Connoisseur Engineer
Last week we talked about how AI rewards good taste, and many reached out asking for clarification.
Well, I think the best way to elaborate is through an example.
Last month I tried Ghostty — a native terminal emulator for Mac and Linux. It is a delightful product, incredibly fast, and thoughtful in a thousand different ways. It has also been developed mostly by one person, Mitchell Hashimoto. Mitchell says Ghostty has plenty of contributors, but honestly, looking at Github, Mitchel made 5000+ commits; and the second in line ~200.
This is the type of work that can be done by a single person in 2025, but it is—and I believe it will stay—extremely rare.
Why aren’t there more examples like this? What stops developers from working like this?
To me, that’s taste.
Taste for good products, for good UI/UX, for good system design, for good tradeoffs.
In a way, it is what Rick Rubin said in his infamous interview last year 👇 which became an instant meme.
Fast forward one year, it doesn’t sound silly anymore.
So, what does the engineer of the future look like? A 2022 survey found that developers code on average 52 minutes per day — which is about 10% of their time.
This seems shockingly low, but I spoke with many others (Henry, Farhan) who reported similar figures, always between 10% and 15%.
So, even if you are able to eliminate coding completely, as of today, that’s at most a 15% improvement. What goes into the remaining 85%? It’s requirements, design back & forth, meetings, and coordination. To go after that 85%, you need to reduce the cost of coordination — and to do that, you need people to do more things they didn’t do before, not just more of that they already did.
This comes in many shapes and forms: merge backend and frontend engineering, have engineers own QA, or even own features from top to bottom.
In other words, you won’t unlock everything AI has to offer just by staying in your lane and pedaling faster. You will do so by learning to do the work of different people, so that we can eliminate more meetings and overhead.
This doesn’t mean we will need fewer people overall — it just means teams can get smaller and people can focus on great creative work, instead of passing the ball around.
If you ask me, this is a promising future, which I very much look forward to.
I wrote my AI-optimistic take on the future of software engineers early this year, and I still stand by it 👇
3) 🎒 Good onboarding == self-serve + buddy system
Everyone has impostor syndrome when they start a new job — it doesn’t matter if they are an intern or a Principal Engineer, or if they work in an office or 100% from remote.
The first week should set the tempo of the engineering team, and you should aim for your new team member to make an impact immediately. The best way I found to approach onboarding is through a one-two punch: self-serve + buddy system
👯 Buddy System
This should be a human, yes not an AI bot, that your new engineer is partnered up with to help them onboard and to introduce them to the company and team.
This is not a passive role and you should design a clear system of check-ins and pairing so that your new hire feels supported and your existing employee can learn more about the onboarding experience for continued improvement.
The buddy system is a procedure in which two individuals, the "buddies", operate together as a single unit so that they are able to monitor and help each other' Webster goes on to define the buddy system as "an arrangement in which two individuals are paired (as for mutual safety in a hazardous situation)." — **Buddy System* (Wikipedia)*
🗃️ Self-serve
Curate a self-serve, learn-as-you-go checklist for the common things and the company/team processes that will be continually reviewed, like career levels, company glossary, and other handbooky stuff.
Handbooks come in many forms, the most popular of which are digital docs (wikis, Notion, Confluence, …), and code repositories — i.e. markdown files that live together with code, like GitLab's public handbook.
In some companies handbooks get also printed as physical books, and given to new employees. This is less common but still pretty much in use, like at Valve.
As developers, we spend a lot of time optimizing user flows: onboarding experiences should be no exception. If you said in your interview process that you curate productivity and inspire creativity, and then the first week is a clunky experience, this will harm the new hire's energy.
We published a full piece on engineering onboarding written together with the one and only Dana Lawson, CTO at Netlify and ex-VP of Engineering at Github — she knows a thing or two about hiring engineers. You can find it below 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full version — if you aren’t already, consider becoming a paid subscriber. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca