For a while, now, I’ve been trying to explain to people what makes someone effective — productive and efficient to do programming and/or science research. Until very recently, I was working in a genetics research lab, and I was asked by coworkers about what it takes for someone to be productive. Whether it was in terms of programming productivity or ability to intuit scientifically, I had been on both sides of the non-/productive divide. I distilled the differences to being resourceful and resolved.
Immediately prior to my 3 years at the genetics lab, I spent 2 years in grad school ostensibly doing the theoretical, CS side of computational biology, a.k.a. bioinformatics. In reality, I was just spinning my wheels in grad school in a constant state of cluelessness and dependence. I felt like I got the reputation as the Garfield of the lab — someone who was best known for sleeping and eating. My time in the research lab was a different story. I came in with the attitude to do things differently than before. Fortunately, my analysis tasks were in my grasp since they were more practical, applied, feasible tasks than the problem statements in the world of computational science research. I told myself that I would work a solid 8 hrs / day, and if I didn’t know something, I’d find out and get it done — regardless of what it is, it should be feasible, after all. I ended up surprising myself, repeatedly, in finding out that the boundaries of what I was capable of were larger than I previously realized.
With both recent experiences to drawn on, I offered my opinion to my coworkers in the lab knowing that I have some insight into the question. But saying that someone needs to be resourceful in what they do, or determined to work hard, doesn’t give an easy quick-fix solution to follow, so it probably wasn’t as satisfying to hear. But I felt that the difference was indeed a sort of mentality more than a particular skill. And it was a mentality that was necessary not just for programming or doing sysadmin work, but for research itself. In a sense, the idea is the same, whether you are looking at natural phenomenon in science research or troubleshooting software/hardware. There is some system with a set of understood principles at work, and we have to isolate the variables — whether interpreting results/diagnosing experimental design, or determining bottlenecks/isolating network chain breakages/locating a programming error.
I read a couple of articles today that speak to those same thoughts that I had. On the topic of being resourceful, Paul Graham’s latest essay, A Word to the Resourceful, succinctly exemplifies the core idea I was trying to get across. One key point from that is,
The unsuccessful founders weren’t stupid. Intellectually they were as capable as the successful founders of following all the implications of what one said to them. They just weren’t eager to.
So being hard to talk to was not what was killing the unsuccessful startups. It was a sign of an underlying lack of resourcefulness. That’s what was killing them.
Unlike many other lines of work, programming does not require you to memorize a million things, or repeatedly do the same thing over and over again; instead, programming requires intense self motivation and determination.
Even the best programmers typically have no idea what they’re doing when they start a new project. If I could summarize one thing I do more than anything else as a programmer, it would be research. Programmers must know how to lookup information, and how to process and use that information in a useful manner.
These writings hit upon a general truth of productivity, and I was especially happy about the PG essay. That essay describes well that hard-to-pin-down quality that is yet so real and so important, and even more satisfyingly than the previous essay about schlepping. I’d think that sending the PG essay to the friends that need to read it most might make a difference, but I’m not sure if they would think through what I say enough to get the message. It’s almost the same as the conundrum that PG ends with on the topic of the least successful startups,
But the most immediate evidence I had that something was amiss was that I couldn’t talk to them.