Clever names, peer reviews, and referral candiates 💡
Monday Ideas — Edition #74
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.
🐶 Datadog • built by engineers, for engineers
Datadog brings together end-to-end traces, metrics, and logs for full visibility into your applications, infrastructure, and third-party services.
Businesses can secure their systems, avoid downtime, and ensure customers are getting the best user experience. With Datadog, you can:
Break down inefficient silos between Dev, Ops, Security, and Business teams
Combine dashboarding, alerting, APM, infrastructure monitoring, UX monitoring, security monitoring, and log management in one platform—plus 600+ out-of-the-box integrations
Accelerate cloud migration, reduce MTTR, drive DevOps adoption, understand user behavior, and track key business metrics
Start your trial today and they’ll send you a free Datadog t-shirt!
Datadog is a sponsor of Refactoring 🙏 check out here how we run sponsorships transparently.
1) ⚖️ Clever vs descriptive names
About one month ago I published a full newsletter edition about naming things in software:
One of the ideas that generated the most discussion was the feud between clever and descriptive names:
💡 Clever names — names that are either wordplays, or character names, or else, that have some indirect relation (or not!) to what they refer to. E.g. Dropbox’s feature flag service is called Gandalf, because “thou shall not pass”.
✏️ Descriptive names — names that explicitly indicate what something is doing. E.g. replacing Gandalf with a more mundane FeatureFlagService.
Most advice out there tells you to avoid clever names and always us descriptive ones. I found this true for individual classes, components, and (of course) methods, but not necessarily for services.
Naming systems and services feels different from naming stuff inside code.
One reason might be that services are singletons: e.g. there is exactly one auth system at any given time, or one feature flag service.
When stuff is individual and doesn’t follow a pattern, there is no point in using conventions. Putting “Service” at the end of “FeatureFlagService” doesn’t tell me much about other services.
Also, descriptive names invariably reduce your design space. After naming your service FeatureFlagService, it becomes difficult to evolve it into anything else, such as running A/B tests for marketing or handling access control for features. Although technically possible, the original service would then feel misnamed.
Conversely, I will probably remember that Dropbox’s feature flags were handled by Gandalf until I die.
Now, the typical objection to this is: how does it scale when you have tens or hundreds of services? Which always reminds me of this awesome Krazam video 👇
Names in the video are funny, of course, but the real problem is the proliferation of services. No matter what you call this mess, it's not going to get prettier. You'll have to look up docs all the time anyway.
Now, I don't want this to feel like an endless ode to clever names. Descriptive ones are fine, of course, but to make them work, you need to cover more bases than you might think. They should be consistent with your domain language, describe the right scope, and not overload existing concepts. If you can meet this, that's perfect! Otherwise, calling your service “Bingo — because it knows everyone’s name-o” is fine, too!
2) 🏅 Peer / 360 Reviews
In many companies, performance reviews also include feedback from the subject’s co-workers.
Such reviews are often called 360, because individuals are meant to provide feedback in all directions: sideways to their peers, upwards to their manager, and downwards to their reports.
This has obvious upsides:
⚖️ More balanced perspective — it counters personal biases and surfaces more information than a single manager’s review.
⬆️ Creates room for upwards feedback — it gives people a structured way to provide feedback on their managers.
🤝 Creates more trust — research shows that people are more willing to trust and act on participated feedback, rather than on individual one.
When done well, 360 reviews are extremely powerful, to the point that some companies (e.g. Netflix, Valve) have scrapped the top-down, manager-driven process entirely, and only rely on those.
However, this is easier said than done. In my experience, good 360 reviews are tricky to pull off, for a variety of reasons:
🔍 Selecting the right people — for each individual, you should select a wide pool of people who will provide feedback.
✨ Creating the right culture — people might feel uneasy at giving feedback on others. Many companies reported starting 360 reviews in anonymous fashion, and only later (and not always) switched to signed feedback.
⏱️ Finding the time — 360 reviews are time-intensive: they require a lot of work from everybody, and create a lot more information for managers to digest and reflect on.
My advice, however, whatever your size and stage, is to incorporate 360 feedback, even in a small fashion.
You most likely don’t need extensive 360s that require people to comment on all the various skills of the company's career framework. You can start in a simple format, like the Stop/Start/Continue, used by Netflix. I covered it, together with other retrospective formats in a previous article:
Also, you can start running these anonymously, and only switch to signed feedback when you feel ready.
You can find more ideas, including templates for running such reviews, in a recent Refactoring article 👇
3) 📣 Referrals bring the best candidates
Referrals are the best way to bring high quality candidates. Full stop.
If you are a startup, they will naturally be your main hiring channel for a long time.
So you may want to encourage referrals by setting generous rewards for people who bring them in.
How generous? A head hunter usually takes 15-20% of the yearly gross salary. Within your team, you may settle around ~10% after the probation period, and make the formula simpler by defining fixed amounts based on the role of the candidate.
Pamela Gotti, CTO at Credimi, leverages referrals to make people participate actively in the hiring process:
We do encourage everyone in the engineering team to be owner of the hiring process too, meaning that referrals are really encouraged, and everybody is aware that the responsibility of growing the team is not HR's only :)
The [hiring] process for referrals is the same, except that the first [screening] step is not done by HR but by whoever reaches out to the candidate.
The flip side of referrals is that they may hurt diversity. By relying too much on them, you risk creating a workforce with too much of the same background. You should pair referrals with a good outbound strategy.
For more ideas on referrals, outbound, inbound, recruiters, and hiring process, check out this two-part series I wrote a while back 👇
💻 Typo • 10x your dev velocity (Sponsor)
Typo is an engineering intelligence platform that seamlessly integrates with your dev tool stack (Git, Issue tracker, CI/CD, Slack).
It connects the dots between engineering signals and developer well-being to enable teams to code better, deploy faster & stay aligned with business goals.
As a Refactoring reader, you can get 20% off + 30 days free on any Typo plan 👇
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
About naming: I think "clever" names for services are okay and often helpful, especially if you communicate them outside of your team. We gave our "domain" services clever names, and everyone knows that "Clever Name Service 1" does this and "Clever Name Service 2" does something else. All other - technical - services have technical names, e.g. "kafka-to-pubsub-service", "recalculation-scheduling-service" and so one.
About peer reviews: I wrote a blog post where I suggest to perform short, ad-hoc feedbacks from your peers, maybe you like it. (It's the pinned post on my stack, I choose not to post the link here as I wish to avoid any perception of shameless advertisement.)
Oh, and: may I ask what tool do you use to draw your graphs? Looks really nice.