Kino
If we have spent an extended amount of time together, we have probably talked about Murakami. (Sorry.) And if we have talked about Murakami, and you haven’t read Murakami, I have probably recommended that you start off with Kino, one of his short stories.
Kino is one of my favorite pieces of Murakami’s work, but that’s almost beside the point. More important than its quality is its metonymy — it is rare, I think, for a single short story to encapsulate an author’s entire oeuvre, but Kino does so admirably, single-handedly winning Murakami bingo.
It’s something like a bouillon cube of Murakami’s entire shtick, drained of any excess weight or water and condensed into its most pure form. If you like it, great! You should read some of his books (The Wind-Up Bird Chronicle if you love the surrealism, or maybe Colorless Tsukuru Tazaki if you love the alienation and ennui — though, come on, they’re all about alienation and ennui.). And if you don’t, well, you figured out that Murakami isn’t your author in the most efficient way possible.
How long did it take you to fully spin up at your current job?
A rule of thumb that I picked up from a computer science professor right before graduation was that it’ll take you six months right out of college until you’re actually a productive employee, and then three months or so thereafter.
Those six months are important, for you and for your organization — you’ve got to learn how to be a full-time employee, you’ve got to learn how programming in industry works, you’ve got to learn mountains and canyons worth of business logic and business context and organizational values and all of the things that aren’t covered in the first week’s paltry onboarding sessions.
I scoffed at this number at the time — I’m a fast learner, there’s no way I’m going to be a drag on my team for half a year! — but I remember it turning out to be pretty accurate!
It’s not that I spent those six months twiddling my thumbs, but I was definitely a net drag on my team; for every ten minutes of productivity I contributed, I probably used fifteen minutes from others. It wasn’t until around the six-month mark where I was truly self-sufficient — where I could review and write code confidently, where I could carry a pager without pestering everyone for every little thing, where I could be a bonafide point of contact.
And, the obvious caveat: dwelling in the trough of inexperience (whether its local or global) is something everyone goes through! It’s certainly not a bad thing, but I think it is a worthy goal to try and minimize the amount of trough-time spent by every new hire in your organization.
One metric that a lot of organizations try and solve for, in service of this, is: how long does it take for a new engineer in your organization to deliver their first non-trivial code change?
This is a good question, and a worthy one. But it’s not quite the entire thing. Writing code is easy. Delivering code is slightly more difficult, but it’s still pretty easy. The hard things are the ones that you can’t search for on Stack Overflow (or, insert-bespoke-internal-version-of-Stack-Overflow-here):
- What happens when you get paged for something that isn’t in your runbook and isn’t clearly attributable to a service you own?
- What’s the proper way of getting input and feedback from stakeholders for projects bigger than your little chunk of the codebase?
- Hell, what’s the proper way of finding out who those stakeholders are?
- How do you distinguish between trivial and important requests from dependencies?
And so on. The meta-questions; the things that come less from experience as a developer and more from experience within an organization.
This is where canonicalization is important: documents as institutions, transformation of the implicit into the explicit, that kind of thing. And time helps, of course, too — as much as we might pretend otherwise, you can’t capture everything in docs, and the only thing that will let you distinguish the signal from the noise is letting your eyes adjust over the span of six months.
But the most powerful force, I think, is a team filled with folks who are willing and able to help: to show you the right way to request a new fleet, to show you the right dev-tools person to talk to when you want to change some internal abstractions, to show you what a good incident report looks like. To show you which short stories are worth reading.
Happy Sunday.
I hope you enjoy the weekend (whether you’re in a place where it’s three days or not.)