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.
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?
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:
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