You just can’t be Googling ‘Select’

I’ve been extremely fortunate over the course of my career, and I’ve been able to learn from some truly incredible people working in software. It truly does “take a village,” and some of the best general career advice I can give to anyone starting out is to find a really good mentor.

And so it was that years ago I was peer programming a C# application with a more senior engineer. We needed to iterate through a list and transform its elements. The codebase was written in a semi-functional style with lots of chained Enumerable method calls, and I wanted to be consistent with the pre-existing code. Rolling my own for loop was out of the question.

The only problem was I didn’t know what method to use. In JavaScript I’d use Array.prototype.map, but I was a C# novice who—up to that point—had only lightly used it for a couple of high school IT assignments.

Naturally, I decided to Google the information. The Internet quickly informed me that the Select method was what I was after. Nice and easy.

var nums = new List<int> { 1, 2, 3 };var numsDoubled = nums.Select(it => 2 * it);

I was pretty happy with how things had went, but my pair was disappointed. After we wrapped up working on our ticket, he gave me some feedback that went something like this:

Sophia, you can‘t be Googling things like Select. List methods are really important and get used all the time, so you should have them all memorized.

You know what? He was totally right. Me not understanding the core building blocks of the programming language was—and is—unacceptable.

Great engineers aren’t wasting time looking up fundamentals, because they have these things deeply internalized. The best engineers in the world are the ones who’ve dived deep into their tools to understand how they work, and have a strong mental model to work from. These engineers are better than everyone else because they have more free brain cycles to focus on high-leverage tasks that seriously move the needle.

That small piece of radical candor had a profound impact on the rest of my engineering career. One of the reasons why I have an article dedicated to discussing ID formats is because of the path this advice set me down. I have strong opinions about things because this feedback inspired me to dig deeper and really try my best to understand things deeply.

Shortly afterwards I read the entirety of the Enumerable documentation. I played around with all of the exotic methods—GroupJoin is a fun one—and I tried to reason about how I would implement each one from first principles. I used and misused these methods multiple times, and extended this way of thinking to most other elements of my programming.

For a while I only ever used the array methods, because AirBnB’s ESLint preset complained whenever you used a for-of loop. I dug into why, and found that Babel’s transpilation of for-of loops was unbelievably bloated. Not great if you care about web performance, and something I would have never known if I’d never developed that drive to understand my tools deeply.

Years later I was pairing with a junior engineer and we needed to key an array of objects by their ID. Array.prototype.reduce is a fantastic tool for a problem like this, but my pair wasn’t familiar with that method. In a fantastic real-world example of oral tradition in software engineering I was able to pass on the exact same piece of feedback I’d received earlier on in my career.