Thursday, July 7, 2011

Having what it takes

There is only one trait you need in order to be a computer scientist: persistence. And I mean dogged persistence. Like you spend 10 hours on a problem persistent.

This is actually a learning exercise. After some time, you start to discern patterns in how things tend to break, and you see them in multiple places. Even as operating systems, programming languages, and applications change, you see these patterns of how to fix broken things, because you have experience under your belt.

The truth is, if you have no patience for such things, or if you want to quit after an hour of working on something, chances are you won't last long in this field.

I can tell you, though, that persistence pays off. After awhile, the mystery of machines begins to go away, you begin to see patterns, and your frustration dissipates.  And best of all, when you do have that breakthrough and fix the damned thing, you feel an overwhelming sense of accomplishment.

It feels like this is difficult to communicate to "kids today". I think it's hard for them to see the point of the struggle, when there are so many other fields that don't require nearly so much frustration. (A friend once described it as constantly banging your head against the wall and then feeling really good when you stop doing it, which perhaps is apt.)

Often people ask me why I became a computer scientist, and I always reply honestly - it never occurred to me to do anything else. (And I'm as stubborn as a mule, which helps. :-))


  1. To be fair, I suspect persistence is the most important trait to doing well in most fields. This might be a bit glib, but it seems to me that computer science actually has a conjecture to which that is a corollary: P != NP suggests that most things worth doing require persistence!

  2. I think I disagree. Persistence is something I've struggled with because it's easy to feel like an abject failure well before solving a problem. I'm not in CS but do tons of programming for my research, and when I was starting out, it was brutal. I had no idea how to debug anything. And there's a big difference between getting abort traps and seg faults for hours/days on end (again, at the beginning, I didn't know how to handle this sort of thing) --which is the experience of being COMPLETELY wrong and having an effectively useless product--and being able to get "partial" answers, which are possible in more qualitative work. One can feel kind of soul-destroying without the tools to handle it.

    The persistence I face more often now is staying excited about a project that's 90% my work, i.e., when I have few people to talk to about it who really get it, and when the methods aren't working or I'm not sure I believe my answers. It's always a little scary to think that there might still be a mistake somewhere in it.

  3. I agree with Anon 2:41--persistence is one of the keys to success in most fields I have been exposed to. In experimental science, there are certainly long periods where the experiments don't work/aren't conclusive/can't be interpreted/don't show what you need to know. Troubleshooting the experiment (even for well established protocols) is a key skill, and can take days. Tweaking the design can take longer.

  4. How do you balance persistence and pressure to publish?