Netflix Culture Slides

I just ran across these very impressive slides about Netflix culture, even though they’ve been out for a while.


I especially like how they go against many of the old saws I’ve seen in management books, and then give reasons (but not evidence) to back up their principles. The argument against loyalty, both from company to employee and vice versa, is food for thought.

The most interesting point in the slides to me is their analysis of why companies become more bureaucratic as they grow. Their hypothesis is that small startups have high talent levels, that top talent is self-motivating and requires less supervision overhead, and that the typical company growth pattern results in talent dilution. The end result is that more supervisory bureaucracy is needed to manage the diluted talent. Netflix’s answer is to strive hard to maintain the talent density, which enables a much flatter organizational hierarchy and thus less bureaucratic process. It’s a nice argument, though I’d really like to see if there is any research backing this up.

If I ever decide to become a manager or join a startup, I’ll definitely keep these principles in mind. Unlikely, however, as I enjoy coding too much to give that up.

What’s in a Name?

I participated in a code review yesterday, and while there were many things I wanted to say, I only think of the right thing to say an hour after it’s all over. What I wanted to say was

The most important thing you can do to improve the quality of your code is to choose good names.

At least, that’s the way I feel right now. I reserve the right to change my mind tomorrow.

It’s really important to remember that naming is not just an action you apply to passive code. The goal of good naming should drive your design and your coding in much the way that Test-Driven Development’s goal of writing tests first is supposed to drive your code design.1 In fact, this practice of active naming so important, I think that it deserves a name — Name-Driven Development. Anyway, here are some advice on naming methods.

Continue reading

The Borg Container Assumptions

“You will be assimilated. Resistance is futile”
Hugh of the BorgĀ 

In my current assignment, I’ve been looking at browser widget frameworks such as OpenSocial and Google Gadget. It seems to me that something is broken in the conceptual paradigms used by these frameworks, as least when applied to the web. They all seem to be based on the idea of a “container” and “apps” (I’ll use app and widget interchangeably) where the container is responsible for loading and configuring apps/widgets. However, in their implementations of containers and apps, these frameworks fall into a set of erroneous implicit assumptions which I call the Borg Container Assumptions1:

  1. The container encompasses the entire page
  2. The container is a singleton
  3. A container is not a widget
  4. A widget cannot exist without a container

Continue reading

Dojo AMD incorporating third party scripts

So, you’ve started using RequireJS or you’ve upgraded to the latest version of Dojo and have converted your web application over to Asynchronous Module Definition (AMD) loading. However, your code still depend on some third party non-AMD scripts. Can and should these scripts be incorporated as AMD dependencies? By “non-AMD” I mean the third party scripts which are not wrapped in a define() or require().

define([ /* ... */], function(){
   //... body of third party script

The most important question to answer is: Can you modify the code?

Continue reading