Knowing how exceptionally nerd snipable I am, a colleague recently posed a challenge to me:
Suppose I have a union of five literal strings, like
'A' | 'B' | 'C' | 'D' | 'E'. How would I design a type that represents an array of exactly three of these with no duplicates?That is, how do I allow
['A', 'B', 'C']while disallowing['A', 'B', 'A']?
This is certainly a tricky one, so let’s begin by getting some of the easy pieces out of the way.
Early in my career, a new puzzle entered the software engineering zeitgeist: FizzBuzz.
First popularized by Imran Ghory’s (now defunct) blog, this was initially proposed as an interview question that could be used to screen out completely unqualified software engineering candidates :
After a fair bit of trial and error I’ve come to discover that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a[n] implementation of a linked list). They struggle with tiny problems1.
So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call “FizzBuzz Questions” named after a game children often play (or are made to play) in schools in the UK.
While Imran’s point was that a solid engineer should be able to effortlessly write a straightforward solution to this problem, many of his readers took the idea in an entirely different direction, filling message boards with increasingly obscure, clever, and absurd solutions, simply for the joy of it. I recall being particularly amused by one that used C++ template metaprogramming to get the compiler itself to print the solution in its diagnostic messages…
…And perhaps you can see where this is going.
A while ago, having seen all of the control flow structures that have been added to Typescript’s type system, I began to wonder if it would be possible to induce the Typescript compiler to compute the result of FizzBuzz as a type.
One of the hats that I wore at a former employer was being the “dean” of the internship program. I was responsible for recruiting efforts, offers, and mentor training for the 12–20 interns that joined us each summer during my tenure. In doing so, I gained a lot of appreciation for how difficult it can be to avoid the Curse of Knowledge 1.
A huge part of ensuring a great experience for interns is setting clear expectations—especially when it comes to performance related questions like, “What do I need to do in order to get a full-time offer at the end of the summer?”
This led to an directive that I repeated often enough that I’m sure all of the mentors got sick of hearing it:
No intern should be surprised by whether you recommend them for a full-time offer at the end of the summer.
This might seem like an easy, obvious goal, but that’s where The Curse comes in: while a mentor may clearly understand their expectations for their intern, how can they know whether they’ve conveyed that understanding clearly?
It’s tricky.
While variations of the phrase “Disagree and Commit” have been floating around the tech industry for decades, it took on a life of its own after being invoked in Jeff Bezos’ 2016 Letter to Amazon Shareholders . Since then, many companies have enshrined this as an explicit value in their recruiting literature and employee handbooks.
This is a powerful value! When applied judiciously, it can enable teams to move swiftly while building trust and empowering one another. At the same time, misapplication can destroy a team’s effectiveness through distrust and disempowerment.
In this post, I’ll explore both the positive aspects of this value and some of its most common pitfalls.
Although I never watched much of the original series, I was a huge fan of Star Trek: the Next Generation when I was a kid. The series has a lot of memorable moments, but one of my favorites is from “Relics” (Season 6, Episode 4).
In the episode, James Doohan reprises his role as the Original Series’ Chief Engineer Scotty—but now older, retired, and barely relevant. Predictably, the writers use every opportunity to contrast him with Next Generation’s chief engineer, Geordi. After an exchange in which Geordi tries to shake off Scotty’s “help”—saying that he doesn’t have enough time to get Scotty up to speed—Scotty chooses to reveal the secret behind his reputation . (43 second YouTube clip; you should absolutely watch it)
Scotty: Do you mind a little advice? Starfleet captains are like children! They want everything right now and they want it their way. But the secret is to give them only what they need—not what they want.
Geordi: Yeah, well, I told the captain I’d have this analysis done in an hour.
Scotty: How long will it really take?
Geordi: An hour!
Scotty: Oh, you didn’t tell him how long it would really take, did you?
Geordi: Well, of course I did!
Scotty: Oh, laddie, you’ve got a lot to learn if you want people to think of you as a miracle worker!
Despite the humor of this scene, it can be tempting to dismiss Scotty’s advice: his smug air and conspiratorial delivery make him appear contemptuous and dishonest towards his colleagues. However, underneath these attitudes is an important organizational principle:
Any well-designed system needs some slack.
In my years of mentoring other engineers, I’ve noticed a pattern that often arises as they reach the cusp of “Senior Engineer” status. In general, these are folks that…
Make regular contributions to their respective teams
Aren’t receiving any clear, negative feedback from their direct manager
Achieve good (or great!) ratings in their formal performance review cycles
And yet…