November 17, 2011

Too smart, doesn't get quite so many things done?

We care about our craft. We're totally smart and get things done. No question.

But "smart and gets things done" has to have some kind of spectrum associated with it, right? There's at least a "smart" dimension and a "gets things done" dimension.

An easy question to ask is, "Am I overthinking?" (This is especially easy to ask if you're overthinking.)

We often quibble about how to get things done better [*] in terms of practicalities, but it often feels like people who ignore the long tail of practicalities achieve greatness with the least effort.

If you had to pick one, would it be better to over-think or to over-do?

(My advice: don't think about it too much.)



In some asymptotic sense of better.

Collaboration and concentration

Latest in the, "People problems are hard, I'm glad I just program computers," set of thought processes. If you have thought-provoking anecdotal data points, your comments are welcome!

There's a confounding and contentious dynamic in programming between collaboration and concentration. This goes beyond just individual and team efficiency — it's also about finding a balance that lets you enjoy and grow your craft.

There are certainly times that you want to hunker down in an LCD-monitor-adorned sensory deprivation chamber and do some badass debugging, find all the corner cases in that nasty algorithm, or suss out all the invariants in a complicated system.

But, on the other hand, there are certainly times that you need to write code during a flurry of peer interaction. If you're ramping up on a new system, the thirty seconds it takes you to ask another human being a question and receive a solid, well-informed answer usually trumps the hours you'd spend reaching the "same" conclusion. With less certainty. Oh, and you actually missed the trap everybody else already knows about, so you actually figured it out wrong.

The extent of the dichotomy is clearly not limited to these examples. It's easy to think of times you've had to pepper somebody with questions as well as times you wanted to hole up in a cave to get some code done. For my systems programming experience I'd hazard a guess that it's around an 80/20 split between concentration and collaboration.

So, it's interesting to ponder: if you were building a team, how would you structure the work space or work activities to enable collaboration when it was necessary, but enable concentration in the common case?

I suppose it's doubly difficult because you also want your team to feel empowered — capable of seeking out collaborative help when they need it in order to get things done and make progress, but also empowered to cordon themselves off and have at it.

I can pretty easily find research that involves hospital workers in the early 1990s, but I have to imagine that a team of brilliant systems programmers is a different beast altogether.

The peril of the new shiny

I'm a little bit behind in my movie watching. About 35 years behind.

Yesterday I saw the movie "Network" (1976) for the first time. Humorous, cynical, and meta is totally my hook, so I had a ball with this one. However, it reminded me of a pretty solemn pattern that I wanted to write about.

I call this pattern the "new shiny", in the same sense that a house cat only sits in your lap in the absence of a shiny thing dangling just out of its reach. In the movie, an older man leaves his wife, with whom he previously shared a 25-year committed relationship, for a younger woman, with whom he's become infatuated.

Now, in this movie's allegory, that younger woman is a metaphor for television and stuff, but that's besides the point for this discussion.

The story presents an instance of the "new shiny" pattern. You happen upon a new opportunity, incompatible with an opportunity you're currently pursuing, and you're tacitly forced to make a choice: pursue the new opportunity, or, through inaction, continue with pursuit of the current opportunity.

As the movie points out, it's easy to become infatuated, even obsessed, with the new shiny, if only because striking out on a new path is exciting and optimistically promising in its "honeymoon phase". In this light, the situation becomes even more difficult: passivity results in an outright denial of something intriguing, leaving you wondering, classically, "what could have been".

Inevitably, evaluating the new shiny with sound reasoning and peace of mind becomes very difficult. The irrationality of attachment — whether to existing things or to things that might be — blurs rational evaluation, if there was really any to be had to begin with. Often, no matter which you choose, you will quickly begin to wonder how much better things would have been on the other path.

...lovers, technologies, jobs, subjects of interest, projects...

Some categories don't have the same existential scarcity that makes the new shiny perilous. Take food: there's little cost to returning after venturing off to sample another cuisine. You don't feel the same kind of remorse choosing soup over salad. Other categories are far less forgiving.

There's also ample reason to fear the new shiny. Every time you make a commitment you disavow the temptation of the new shiny and its hold over you. And, typically, unless you take steps to strategically isolate yourself, you have little control over new shiny encounters — these things are just stumbled upon in the course of everyday life.

There are very few tools at our disposal to deal with the new shiny properly. Human prescience is quite limited to begin with. I suppose that the new shiny is just the classic problem of man versus raw choice taken to its passionate, emotionally-involved and foresight-crippled extreme.

Simple formula for instilling unease in a person you've just met

A: Nice to meet you, I've heard a lot about you!
B: All good things, I hope!
A: Oh yeah, definitely. You know, except for that one thing.
B: Oh? What thing is that?
A: Haha, you know I'm just kidding.
B: Right, right...

My programming job evaluation criterion

I love making lists with no title or context and then hiding them somewhere in my room. At least, that's the inevitable conclusion of my paper-purging weekend.

I actually found one fun list (under my bed) that I've rematerialized the context for: what criterion do I use, as a candidate, to evaluate a programming position in the valley?

I came up with this short list when I was interviewing at Mozilla. It's a personal list, inextricable from my personality, experiences, and my current lot in life, but some of the thoughts may apply generally and help future candidates to brainstorm.


If you're into the whole consequentialism thing.

What's the outcome you're achieving by doing this job? Particularist (i.e. feed your family, put your kid through college) and universalist (i.e. bring education to undeveloped nations, make navigation systems that don't fail) concerns are both important to consider. [*]


Who are the people you're going to be working with? Community in my mind is roughly, "Humans you will be interacting with as a part of your job." Do you have reason to believe this will be a beneficial community for you? Maybe you work best interacting with a particular disposition of person: driven, explanatory, idealistic, encouraging, expert, iconic, pub-dwelling, sky-diving?

As my friend eloquently put it, "Fuck staying in a job where people suck."


How much do you already know about the subject of your work? How much do you want to know? They say, "God is in the details." I buy it, but if the job expects and encourages you to learn new things in topics that you're passionate about on a regular basis, it sure makes this part easier.

I've also heard, "Lots of folks just try to do the same exact thing they did at their last job over again, but slightly better." Maybe you'd like to avoid that. [†]

Artistic direction

How much control do you have over the direction of the project that you'll be working on? It's quite frustrating to pour your heart and soul into your work if all your projects get cancelled or you're being metaprogrammed.

This brings up related questions of status: How valued will your input be? Is this place a meritocracy in the ways that drive excellent products and good decision making? What capability do you have to devote resources to things that you think are important? (This could be a use-20%-time-to-prove-its-worth-pursuing kind of deal.)

Or, maybe there is no meritocracy, and there's politics. That'd be important to know.

Artistic fidelity

How much craftsmanship is expected? Mandated? Tolerated?

Posed another way: how hacky will your work need to be to meet deadlines, output requirements, expectations, and so forth? How hacky do you anticipate the work of others will be? Is there some mitigating circumstance (like an important product deadline) that makes a lower level of craftsmanship acceptable?

Another consideration: does this job expect you to show appropriate respect for the product being delivered, or is it overly focused on the purity of their development methodology?


What percentage of your time will be spent doing mundane tasks (that you have little hope of learning from)? Do you have a good strategy for coping-with/minimizing expected sources of tedium?


How much state-that-already-exists will you have to deal with? Sometimes this is to your advantage (i.e. already-established big/important customers) and sometimes it's to your disadvantage (i.e. original code base believed the MS Visual Basic was the language of the future and wrote their application using solely the corner cases of the language semantics).

(Compensation and career advancement weren't on the list. I'm sure that everyone has a price where they'd sacrifice any one of these things, but it's a much more meaningful exercise to evaluate them on their own.)

The categories are supposed to be largely orthogonal, but the idea is simply to provoke thought for meaningful/tough questions during the interview process — if you value your time and attention, the employer should be giving you sufficiently satisfying answers!

No place is perfect, but thinking about what you're getting yourself into and why should put you squarely ahead of the game as a job candidate.



Programming jobs that work towards solving severe third-world problems that also let you work with interesting technology are not abundant. My current strategy is to work in the interesting tech position of my choosing and donate a pre-set percentage of my salary towards effective charities working in those areas.


A similar quote that a friend gave me: "Some people don't have ten years of experience so much as the same year of experience ten times."