What I learned at Kensho this summer

I joined Kensho as a software engineering intern this summer and learned quite a bit. I thought it’d be nice to write about what helped me along the way. Instead of a laundry list of software I built, though, I’d rather go in depth about a few observations I made this summer.

Gotta go fast

A bit of context: this was my first time working at a tech company that had more employees than I can count on one hand. Up until this summer, nearly my whole understanding of software engineering in such an environment came from articles on the Internet and blogposts with unknown authors. I supplemented this with the occasional rumor from older students whispering about a top-secret something, codename “office snacks.”

So, when I heard things moved fast at Kensho, I had some vague notion in my head about a hamster wheel powered by the sound of typing on a keyboard, spinning round and round. The reality was a bit different from what I originally had in mind.

Kensho reminds me of what I’m told the original Skunk Works by Lockheed Martin was like (incidentally, it was at Kensho that I’d first learned the Skunk Works — if you have any interest in small groups of people doing really cool things, check this out). It wasn’t overcaffeinated hacking or super-long hours that got us to the speed things move here. Rather, it strips away a great deal of bureaucracy to allow people to build cool things quickly.

What the Skunk Works can do: Lockheed SR-71 Blackbird. It’s the fastest air-breathing manned aircraft of all time!¹

It might be hard to convey this effect to a student, whose preferred unit of time is days until homework due date or an employee in a large company whose work needs to go through fifteen layers of approval over the course of months. Let’s go with a small example of a larger pattern: my onboarding meeting on the first day lasted half an hour. Half an hour, and then I was ready to meet the team I’d be working with!

I’ve heard stories of orientation lasting well over a week before new hires even get to touch their own computer. Meanwhile they get paperwork tossed at them like confetti. One particular story I’ve heard involves software engineers being told specifically not to pick up any objects over 70 pounds in the course of their work. They even had to sign a waiver asserting that they would not, under any circumstances, for anyone, for any reason, at any time, anywhere, to lift more than 70 pounds for work. I wondered why a software engineer might want to pick up 70 pounds so often to the point that there was an explicit rule against it.

Why 70 in particular, anyways?

Meanwhile at Kensho, instead of quibbling about the finer points of lifting odd objects, I made a meaningful commit (for my nontechnical readers: translate “commit” to “contribution to the code”) several hours into my very first day. Organizations that have grown too large and heavy can’t match this speed — they’d collapse under their own weight. Kind of like the way certain rule-makers seem to think software engineers do when they try to lift 70 pounds or more.

Meetings in general were kept short and to the point for the most part. Time gets treated as a valuable asset. Dilbert might be a successful cartoon because so many people have experienced meeting hell in other organizations, but luckily at Kensho it’s just a comic strip and not a documentary.

A helpful piece of advice I received on my first day was to avoid being blocked. Being blocked is a term borrowed from computing to describe a process that’s unable to progress because it’s waiting for something else. When applied to me, that meant to not spend too much time stuck on any particular issue and always have several things that I could be doing at any given time. If I was stuck on something, and no one was available right that second to help out, at least I could still make progress elsewhere rather than shutting down and going into hibernation until someone who could help became free. It seems remarkably simple and obvious now that I describe it, but I can certainly see how someone might accept that needing to wait on people and twiddle their thumbs is just the way things are. I’ve been there before, and it can be quite frustrating when all you can do is wait.

The Mage from Macedonia

If I had to point to a single factor that made my internship go as well as it did, it would have to be my relationship with the team lead, Predrag, who hails from Macedonia. He’s the kind of guy who digs several levels deeper than most other people when he comes across something unusual, and it really adds up over time. Combine that with a strong ability to communicate and suddenly you have a potent mix.

“Let’s not mutate arguments passed to a function if we can avoid it.” (Side note: Predrag is not this old yet, but his ability to reason about software seems downright magical sometimes)²

Aside: for my readers who are engineering students, speaking and writing well are really hard but worth learning. Most engineers underestimate its value. Yes, if you’re a computer science student reading this, you’re probably underestimating it, even when you take your underestimation into account. How’s that for some gnarly recursion?

No, seriously. If you still read text directly off your slides in a presentation, or if the last time you thought about “show, don’t tell” was in English class in middle school, you’re throwing away a huge fraction of your brain power because no one else understands your thinking. You gotta have both the show and the go. If you don’t believe me, work with Predrag for a week or two and you’ll see how effective being able to do both is.

Predrag might seem like just a regular guy (the opposite of the socially inept nerd stereotype) when you first meet him. Later on, when he only needs five minutes to devise an elegant solution to a problem that took you a while to even articulate precisely, you start to realize that this whole software engineering power ladder goes quite a bit higher than school would have you think. It doesn’t peak at straight-A students. The interesting thing here is that you can actually understand his solutions after you hear them… but you look back and wonder how he came up with the idea in the first place. It turns out it’s not random flashes of genius, but rather the result of a systematic way of thinking (I’ll discuss this later on).

I found it was quite helpful to prepare for our weekly one-on-one meetings with specific questions. It’s easy to ask for help without thinking it over first, but reminding myself to get detailed helped my own understanding. It’s amazing how easy to understand the answers are when I ask good questions. It feels really good to be able to point to what I tried so far and my guess as to why it didn’t work, rather than going with the classic computer science student staple, “my PROGRAM doesn’t WORK.”

A few other things he’s said that I found helpful, in no particular order:

• Intelligence is cached thinking: This is the big one. This is the reason why he seems to always be able to come up with a solid answer right away. You don’t need to think faster than someone else to figure something rapidly, you just need to think about the problem before you start writing code. Then when you come across difficulties, you’ve done most of the hard brain work already and the fruit of your efforts are already sitting somewhere in your brain’s cache. Then everyone you work with calls you a genius.
• If you can predict what will happen, then you truly get it: It’s easy to just run a program, see the output, and go, “Yep. That sounds about right,” whereas in reality, you don’t really get it. Writing my prediction out on paper first and only running the code afterwards made me get very specific with my thoughts. It’s saved me countless hours of debugging time.
• You can learn to write code with fewer bugs: If you find that your program doesn’t do what you expected it to do, then when you fix it, you should look back and see if you could have done some sort of thought experiment to predict this in advance. Don’t just give up on writing less buggy code! That’s like resigning yourself to getting bit by mosquitoes when bug spray exists. Bug bites might still happen, but your attitude affects how easy it is to deal with the programming equivalent of standing water. Maybe the bug metaphor is starting to break down a little here…
• Take notes: Especially to give yourself some context, which is helpful when you’re returning to something you haven’t thought about for a while.
• Don’t worry about where you are, think about where you’re headed: I’d just run into my first major roadblock and my self-confidence was a bit shaken, so Predrag pointed this out to have me evaluate my situation with a bit of a clearer head. It’s a good reminder to come across periodically.

Closing thoughts

I’ve mentioned many things I liked about working with Predrag, but I also learned from many others at Kensho. On Tuesdays we had Tuesday Tutors, where we’d watch and have discussions about a selected engineering talk, with topics ranging from software deployment to computer science education to designing aircraft that fly faster than bullets do. On Fridays we had Kensho Finance Seminars, covering topics from financial systems to cryptocurrency to personal investing to monetary policy³. On Wednesdays we wore pink⁴.

Kensho is full of folks that actually care about your learning. These are long-term people who play positive-sum games. It really is a breath of fresh air compared to the curve system that university frequently impose on their students, or the zero-sum mindset that the system invites. That attitude made my experience that much more enjoyable, and it’s really amazing to see it in action.

Oh, also: Kensho has a nice weight room in which it is perfectly ok to lift over 70 pounds.

Especially if you’re a software engineer.

1. This image or file is a work of a U.S. Air Force Airman or employee, taken or made as part of that person’s official duties. As a work of the U.S. federal government, the image or file is in the public domain in the United States. Source
2. This image is in the public domain. Source
3. By the way, these seminars are made possible in large part because Kensho employs folks with a substantial amount of finance industry experience and knowledge. That includes someone who’s taught finance at Harvard!
4. I really need to watch Mean Girls again (I promise the other activities actually happen though and I didn’t write that entire paragraph just to make a joke about a movie from 2004).