Hey, Luca here, welcome to a weekly edition of the💡Monday Ideas💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
I am a strong believer in hiring many (mostly?!) junior engineers.
This is one of the things we got the most right at my previous startup — even though, I admit, kind of by chance. One of my co-founders and myself were ex PhD students and we always kept good ties with our alma mater, so we would often run internships and hire people straight from their M.Sc or B.Sc. It was the easiest and cheapest way to hire for us, especially in Italy where the tech ecosystem was (and still is) kinda small, and there were few engineers working on our stack (Ruby on Rails).
However, having fresh engineers on our team brought a ton of benefits that were not always obvious at the beginning:
🔄 Process — Senior dev teams may neglect documentation and procedures, relying on tribal knowledge. Onboarding juniors instead forces teams to organize and explain everything clearly, improving processes for everyone.
💸 Cost — Junior developers are cheaper and faster to hire, coming from predictable channels like universities and bootcamps that provide a steady pipeline of candidates.
↔️ Fit — New hires can grow into your specific needs, which is often more effective than searching for unicorns who perfectly match your weird technical corners.
🪴 Growth — Making people grow drives happiness, productivity, and retention. Mixed-level teams allow matching work to experience, creating a healthy cycle where juniors rise through the ranks while everyone stays challenged and learning.
We covered hiring principles earlier this year in this article below 👇
CodeRabbit CLI brings instant code reviews directly to your terminal, seamlessly integrating with Claude Code, Cursor CLI, and other AI coding agents.
While they generate code, CodeRabbit ensures it's production-ready - catching bugs, security issues, and AI hallucinations before they hit your codebase.
I don’t write a lot of purely technical pieces at Refactoring, favoring timeless engineering and management ideas instead.
I made an exception for web scraping, which is at once 1) one of the things I did the most in my professional life, and 2) one of the spaces that grew the most in the AI era.
The problem with scraping (or web data collection 🧐🎩) is that there are just so many ways of doing that, leading to some of the biggest it depends in engineering.
So I tried to design a quick cheatsheet to point people to the right solutions, based on their needs. As always, it is about asking the right questions:
Scale 📈
Is the collection real-time or batch? If batch, how often do you need data to be refreshed?
Is the collection high-load? Do you need thousands of requests / second?
Importance 🏆
How core to your product is this?
How different is your use case from that of other companies?
How important is it that you build IP and skills around this?
Type of data 🎨
Are the websites famous?
Are the websites many?
Team skills 🎓
Is your team experienced in web scraping or not?
Budget 🏦
How much are you willing to spend on this?
Based on these questions, we can sketch a high-level decision graph:
Of course there is much more to it, and if you are interested in learning more you can check out the full guide I wrote! 👇
A couple of months ago I had the incredible privilege of interviewing Rands on the podcast. As a writer myself, Rands is one of my heroes — author of countless amazing blog posts, plus one of my favorite books of all time, Managing Humans.
When I asked him about how writing has changed his career, he answered in expected and unexpected ways.
First, Rands hasn't needed a traditional resume in over a decade because his writing has built what he calls "nerd fame" — industry recognition that constantly opens doors for him.
But beyond career benefits, writing provides also therapeutic value and serves as a grounding mechanism for processing complex thoughts and emotions about work and leadership challenges.
"Writing makes me smarter about the topic that I'm writing about because... it takes opinions that I have or feelings that I have and turns them into ideas."
He also added a few ideas that stuck with me:
📖 Finishing matters — while casual writing (100 words daily) builds habits, completing books provides unique lessons about persistence and achievement.
🔄 Iterative learning — his perspective on topics like whether managers should code has evolved over 15+ years thanks to writing and reflection. He isn’t sure he would have come to the same conclusions otherwise. And that’s because of 👇
🎯 Long consideration — writing allows for deep, multi-year exploration of ideas rather than surface-level opinions. And you can go back to your own (written) thoughts many times, ponder them, and update your thinking.
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 👇
Thanks for sharing, very interesting insights on writing.