Links #1

Interview with Jeff Rothschild #︎

Transcript available.

Pulls #︎

Scaling #︎

That is the attribute of the product that creates the scalability challenges… Remember, you’re not looking at your own data… One of the earlier observations was is that you couldn’t pre-calculate what a user would find interesting at the moment… Of course, you take a step back you say, “Well, what if they didn’t come in?” Then you just expended the cost of building this context and then never had the opportunity to use it. Of course, the next time you do the scan, if you end up replacing it, that work served no value. Those were cycles, and time, and heat that were expended without a payback.

Code Review #︎

most engineering teams will find that code review is possibly the most valuable thing they can do, and I don’t think there is no contention around the notion that code review is valuable. However, if you truly believe in the value of code review, then you also should think about, “How do I make my code review more effective?”… I like to see code reviews that are preceded by the developer, the one who is submitting the code for review, writing down their assumptions. This is what I believe could go wrong with this code. Here are the things it could impact… Another list, let’s say parallel list to that, of here are the things – Here’s how I verify that it didn’t… if you’ve created a list of 10 things that this could impact and they think of an 11th, then that’s a red flag

Collateral or Incidental Knowledge #︎

as a software engineer 40 years ago… there was a book for everything. I mean, for the machines language of the system, the individual system calls, the language runtimes, the job control language. So many different aspects of what defines a system environment. If you needed to know something, there was only one way you could get it, which was a somewhat linear search through this documentation stack. You might get to the right book, but after that, your journey to the right answer involved a lot of stops… My observation is simply that highly targeted information retrieval obviously saves time, but there is a cost associated with it and we should simply be aware of that cost and choose sometimes to take the long route… so that we’re always developing a broader footprint of knowledge and a deeper understanding of the abstractions we use and the environments in which we program.

Management #︎

How do you make people happy in a job where there actually is going to be some constraint and some discipline when the thing that brought them into this actually was the freedom of being able to work on what interests you and being able to exercise this creative process? I believe this is where good management comes into play. I believe that recognition of this tension is what separates an effective manager from one who is simply stumbling through the job.

The real effective manager walks into the room and says, “Here’s the problem that we need to solve,” and then shuts up.” Even if they have a strong idea in their mind of how that problem should be solved, just keep quiet. Let somebody else put the ideas on the table. If you think that the idea being presented isn’t as good as what you would suggest – That’s what you were thinking, then the right way to bridge that gap is ask some questions. How will it deal with adding these features in a later release? How will it address integration with this other product?

Hiring #︎

You need to sometimes go out there, take an additional step, take some risk. I would contend that organizations that are of averse to hiring failures probably have the greatest challenges in having diversity in education, cultural diversity, gender diversity. Just, “No. This person hasn’t done it before.âR(ncm2_auto_trigger)X Well, there may be reasons they haven’t done it before because maybe the last manager said, “You hadn’t done it before.”

Not really making a comment about Facebook. Facebook did a really good job of recognizing that it’s easy to hire people who are like yourself. I’m guilty of this as well. I happen to have a background in file systems and I have noted that in a disproportionate number of interviews I asked people to trace an I/O through the file system. Why do I do it? Because it’s easy for me. I’m on solid footing to know whether they’re bluffing or whether they’re giving me a correct answer and in some other domains. I wouldn’t be as certain.