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.