Is l33tness acquirable?

June 3, 2009 4:45 PM

Doing intellectual tasks. Does it ever become second nature? When do the insights begin to appear?

I'm going to ask this question in my context, but I'm happy to receive input from anyone in any context.

I "do" computer science. This means I end up doing a lot of coding. I love what I do, and I would say (perhaps with bias) that I am better than average at it. But I'm not great. By great I mean it doesn't come as naturally as I think it should.

I'll illustrate with a couple of examples.
- Supposing I had to write a search routine, and I chose quicksort. I need to go lookup the algorithm and write it, it's not at the top of my head.
- Supposing I was writing a sort routine using brute force. I'd need to carefully check my boundary conditions made sense.
- Supposing I am setting a certain bit-pattern in memory. I need to visualise it paper (110110) and convert it to the hex equivalent.

I feel the difference between being good and being really good at what you do is to have these things naturally (empirical evidence noted from studying better people around me). Does this ever come? Can I make it come?

A second related question is, do I need this level of "quickness" for the clever insights to appear? While I can do very simple optimisations the more complex optimisations or clever tricks elude me. Overall I feel the basics should be things I don't have to think about if I'm to make any bigger contributions.

I suppose you could reword this question as "how do I become sharper/more skilled at what I do?"

posted by gadha to grab bag (13 comments total)

I have heard that it takes 10,000 hours or so of practice to become expert at something.
posted by dfriedman at 5:03 PM on June 3

The same way you get better with any other skill. Lots of practice.

Nobody is born able to play effortless scales on an instrument, roll out a perfectly even pie crust, or write a search routine without reference materials. There is some degree of innate talent that makes these skills easier for some to pick up quickly, to be sure; but sufficient diligence toward practice is much more significant over the long run.

Write a lot of code. You'll get better and better. :)
posted by Andrhia at 5:04 PM on June 3

It doesn't come naturally for anyone. Practice makes perfect. See Malcolm Gladwell's book Blink or Flow (by a guy whose name I couldn't spell from memory if I tried).
posted by B-squared at 5:05 PM on June 3

Teach someone. One of the best ways to get better and *really* understand something is to teach someone else it. It definitely helped me when I taught an intro CS course one summer, though it works for anything, really.
posted by losvedir at 5:43 PM on June 3

I write software for a living and I don't think I could do any of the things you've described without looking at reference materials or checking myself. The thing is, the things you've described are the sort of incredibly trivial, low-level tasks that you have to do dozens (if not hundreds) of times per day when writing software that does anything useful. Once you done these sorts of things enough times, they become nothing but implementation details that need to be hammered out in service of the overall bigger picture.

I think the hard part of CS is having the mental clarity to know how everything is going to come together. I don't think "quickness" comes from being savant-like in your abilities, but rather in having a clear plan before you start writing code, so that once you start coding, all you have to do is write code that follows the path that you've decided upon. I don't mean that you have to have all your interfaces/prototypes/whatever fully defined, but that there are no philosophical design decisions left to make; the only remaining decisions should be regarding the inner minutiae of the functional component you happen to be working on at any given time (ie: exactly the sorts of things you describe in your examples).
posted by strangecargo at 5:56 PM on June 3 [2 favorites]

do I need this level of "quickness" for the clever insights to appear?

To overstate things, yes. When you are able to effortlessly do simple tasks, you free up cognitive processing capacity to think about other things like optimizing the procedure or making connections between different concepts.

For some things you mention, like common algorithms, it probably would behoove you to actively memorize them. Eventually you will learn many of these things, but some deliberate practice (which is what you really need 10,000 hours of) is more efficient since infrequent practice is a much slower way to learn.

Be strategic in what you try to memorize and when. I find that being an expert is not as much about knowing, but about knowing where to look.
posted by parkerjackson at 6:02 PM on June 3

Young man, in mathematics you don't understand things. You just get used to them.
posted by Kinbote at 7:08 PM on June 3

I think the 10,000 hour thing has some validity. The idea is expounded at length in Gladwell's Outliers and the value of practice is discussed by Bill Bradley in John McPhee's A Sense of Where You Are.

You need to cross train. Make sure all the regions of your brain are getting some exercise. So reading some mathematics and physics will sound like obvious recommendations, but nonobvious things like history, philosophy, and literature will help you too.

And more important than all of the above is sleep. You'll never reach your potential without adequate sleep. If you're over 20, assume you need 8 hours per night. Under 20, assume 10 hours. Sleep debt accumulates approximately linearly: getting 7/8 of your required sleep each night for a week is the same as missing a night of sleep once a week.
posted by neuron at 8:37 PM on June 3

Supposing I had to write a search routine, and I chose quicksort. I need to go lookup the algorithm and write it, it's not at the top of my head.

You've glossed over the most important step for becoming an expert programmer! The most important step isn't knowing how to write things, it's knowing what to write. In this example, you chose quicksort. Why? Did you think about all the sorting algorithms you know, compare their memory and time and other tradeoffs, and decide quicksort was the best? Or did you just pick quicksort because it's the only algorithm you know about?

The way to become good at programming is to learn a lot about what's out there -- learn a lot of different languages, learn a lot of different algorithms, learn a lot of different ways to think about and model and do things -- and, when you find a problem, go over what you know and decide what specific thing you should look up in your algorithms book or on wikipedia or whatever.

If you have to write quicksort a lot, sure, you'll eventually get it memorized (but if you're writing it a lot, then you've missed the fact that a bunch of standard implementations already exist, so you're wasting your time). But memorizing quicksort isn't the end goal, so don't focus on it.
posted by inkyz at 10:05 PM on June 3 [1 favorite]

I've been coding for many years and look stuff up every day. There's no way I can or should try to store all of the mundane details of the numerous technologies I encounter, and if I ever reached a point where I could rattle absolutely everything off continuously it'd be a sign that I've finally stagnated and am stuck in a rut.

You'll remember things you do regularly, look the rest up, and hopefully accumulate valuable higher-level knowledge over time. True expertise can't be googled.
posted by malevolent at 12:07 AM on June 4

I'd need to carefully check my boundary conditions made sense.

You're there already. As inkyz said, it isn't knowing the details of quicksort, it's knowing that it's quicksort you need. It isn't knowing how and which boundary conditions to check, it's knowing that you have to check them in the first place. Most immature and/or inefficient programmers never check their boundaries, and never realize their omission.

There's no shame in looking up the correct implementation of quicksort - in fact, even if you had the thing memorized, it'd make send to look it up anyway to make sure you're not overlooking some subtlety.

And recognizing you're not perfect is helpful as well. You'll get there, grasshopper!
posted by DreamerFi at 1:57 AM on June 4

Being able to rewrite standard libraries from memory is not terribly useful. Even if you have done so as part of a language implementation (I have), you will end up consulting the work of other people who have more time and expertise invested into a subject. The alternative is subjecting your users to your bouts of "brilliance", which even for qualified geniuses is not something to be relied on.

Ideas like the quicksort algorithm don't pop out of thin air in computer science- you need both a firm understanding of what is already out there, what you want to improve on, and how such a work relates to existing approaches. The speed at which your idea develops is of course a function of your skill, your existing background, and other factors.

Like others have said, it doesn't come overnight (or in a week, year, 5 years, ...). Always be expanding your experience and knowledge and slowly you become experienced and knowledgeable.
posted by mezamashii at 2:01 AM on June 4

Richard Hamming says do 10% more: "Knowledge and productivity are like compound interest. Given two people of approximately the same ability and one person who works ten percent more than the other, the latter will more than twice outproduce the former.

http://www.google.com/search?q=hamming+you+and+your+research
posted by at at 7:40 AM on June 4