How Do I Get Good At What I Do?

November 26, 2008 7:56 AM

How can I gain in-depth knowledge and experience in technical fields?

My question is specifically related to computer science but could broadly be applied to just about any field, so I welcome input from all.

I've been in academia all my life, and my primary method for obtaining information is reading from technical manuals, papers, etc. However, this is often very slow; there is a lot of written work and some of it is pretty dense. I have often found when working in fields that I don't really gain a proper feel for the problems, tradeoffs, etc until I do some actual work on them -- it's all a little abstract till I'm writing code, or hacking on it etc.

My interaction with industry shows me that there are a lot of engineers who have very very deep knowledge of aspects of computer science and/or engineering; how do they (you!) achieve this? Do you just learn more as problems come up that need solving or do you go away and read about the theory or as much as you can of the subject? How do you develop yourself and push yourself further? Is it a case of interaction with people or just doing more and more?

I ask this question because I literally am at a point where I find myself living, breathing and eating my work. I spend all day and all evening on it but I can't seem to make good, proper progress. Life isn't meant to be like this and I certainly don't see the same thing with other people I interact. So either I can't hack it/am not good at it, or I'm doing something wrong. I'd like to find out which so that I can take forward steps to fix this.

posted by gadha to grab bag (9 comments total)

Through the course of problem solving you learn about some of the more esoteric aspects of whatever industry you are working in. I think that's the only way to really get a deep understanding of whatever it is you're interested in. Studying books and the like can only take you so far.

I probably learned more group theory doing assignments than I did in class, for example.
posted by chunking express at 8:14 AM on November 26, 2008

My interaction with industry shows me that there are a lot of engineers who have very very deep knowledge of aspects of computer science and/or engineering; how do they (you!) achieve this?

Through a very long time spent programming, learning from your mistakes, interacting with others about programming, and working on projects. See the Open Source Movement for many of the brightest minds. In the closed source arena, you'll probably find the best and brightest working at the big closed source companies (Microsoft, Oracle, etc.). They are pushed by their careers.

If you are living, eating, and breathing your work, you are on the right track. The next thing you have to do is to start leveraging communication to your advantage. You can make it on your own, but you will do it much more slowly (although you may come up with more novel ideas). Join an open source project that has some relation to whatever you are doing, and bounce your ideas off the other people there, once you have established yourself as a productive member of the team.

In the end, no one loses in this field who works hard. In many ways, computer science is becoming the closest to a meritocracy as you can get in a field, because of the emergence of Open Source Software. I have a friend who got shitty grades in a shitty school, who landed a job telecommuting with a startup in the Netherlands, and is now moving there. He did this through working with open source and proving to a large community of people that he had the skills and drive to hold his own. There are many instances of people being recruited out of projects like that.
posted by zhivota at 8:25 AM on November 26, 2008

This varies wildly according to person.

First, I locate the dry theory. Read up on "how it is supposed to work," the barebones basics, without the frills and kinks. Mix with research on how people view whatever technical subject; what's the chat you can discover on Google? Locate people who have a clue and find out what they have to say.

Pour through this dry mixture the water of experience. Solve problems. Tackle little ones, then bigger ones, and so forth. You are kneading the subject now. You know that, as implemented, the dry theory isn't always what you encounter in reality.

Take a break. Reflect. How would you do things differently? What lessons have you learned? How do you rate this technical subject as compared to other things? What are its connections to things with which you are more familiar?

Go back to basics ... write a manual on how you would have someone who is literate and just knows enough about the subject to actually accomplish a task, in a step-by-step manner that might include things like "Click the 'Next' button." "Fill out the following fields: ..." Include in that reasons why you do one thing over another. Include what will happen if certain critical steps which you yourself left off when you first learned are left off by the user.

Every time I go through this process for a few related tasks, I end up as the local expert on it, not just because I know how it is supposed to work, but because I know how it actually works, and can explain it to someone else. I find the process often painful and frustrating, because I hate to feel dumb and I like to accomplish goals. Nevertheless, that's what gets me to where I feel reasonably competent.

That may work for you, that may not.
posted by adipocere at 8:33 AM on November 26, 2008

1. Learn by doing. Try to find a project that's right on the edge of your comfort zone and will gradually drag you out of it.
2. Make sure you've got a diverse, interesting range of sites in your feed reader (you are following feeds, right?)
posted by malevolent at 8:51 AM on November 26, 2008

As an industry type, every last bit of useful information I know has come from trying to solve immediate practical problems. My CS education provides a nice orientation to what sort of theoretical work I can draw on, but I'd have to say that I've never truly understood a theory until I tried to put it to work.

CS theory by its nature posits ideal worlds. To really understand theories you need to put them into a hostile environment and see what breaks.

For me the quintessential example is how quickly shortest path algorithms fall apart on computer networks -- what do you mean that no two nodes agree on the topology or cost of their comnected paths? And how can vertices randomly appear and disappear? Oh, and why did Floyd never mention that every time I use a particular path its cost goes up by one for a period of time directly related to link speed...?

In any case if you want deep knowledge, think -- and more importantly, do -- practical projects.
posted by tkolar at 9:27 AM on November 26, 2008

Also -- coming from an academic family I can tell you that once again the family holidays will bring out the snark between those of us who can, and those of us who teach. (whoops, started already)

Seriously, neither industry nor academia is for everyone. If you're frustrated in one, perhaps it's time to try the other for a bit?
posted by tkolar at 9:35 AM on November 26, 2008

People in industry also have the benefit of being able to consult more experienced coworkers who may have seen similar problems before.
posted by electroboy at 10:25 AM on November 26, 2008

1. redundancy via a different points-of-view is your friend. By which I mean don't read one book on C++, read three -- by three different authors. Actually, three books by three different authors is just okay. A book, a video and a class is better. What you want is for the info to enter your head via as many different senses as possible. So if you watch a video and read a book, the book will reinforce the video and vice versa.

I have an unconfirmed theory that -- being social animals -- our brains assign greater importance to info we hear from multiples sources. If you hear something from just one person (e.g. the author of one book or one teacher), your brain will label it as gossip. If you hear the same thing from three different people (e.g. three different books), your brain will label it as fact.

Of course, the most important person is you. Which is why you'll best learn from experience. But even first-hand experienced can be strengthened via multiple, redundant points of view.

You also learn well by explaining things to someone else. Again, your brain thinks it must be important if you use it in a social situation.

2. make sure your external memory is efficient. Since it's impossible to remember everything in most tech fields, you'll have to rely on reference materials. I can't remember the entire API of many systems I work with, but that doesn't matter. I have good overall knowledge coupled with the ability to quickly find specific info that I need. I'm continually looking for ways to refine the way I can access info. Will googling work? What if I'm offline? Do I need two copies of a key reference book, one for home and one for work? Etc.

3. It's very hard to learn by doing stuff you don't enjoy. If you find banking boring, you probably won't learn much C++ from a book that uses financial examples. Luckily, most technical tools can be employed to many ends and the lessons you learn can be universally applied. So learn C++ by coding something that is fun for you. Make a game or whatever floats your boat.

4. Decide to become a guru. This means actively seek out info everywhere. Find out the best blogs on your subject and read them every day. Never pass a book store without checking to see if they have any good books. Start trading info with friends (email: "hey, did you guys know about this great algorithm that..."). Go to user groups. Etc. Nowadays, almost every tech subject has a community associated. Remember, you're a social animal. Use that to your advantage.

Note: I've joined O'Reilly's Safari site, so that I can read their books online. They have a rough-cuts program, where you can read drafts of tech books AS they are being written. I'm enough of a geek that I do that (so I can get the info RIGHT AWAY) and then I buy the finished book and read it again.

5. Don't cram. Cramming does not work. Sip info in small doses. Try small experiments. TAKE BREAKS. Five minutes does not count as a break. A break is when you get completely immersed in something else (e.g. sleep) for a length of time between studying sessions.

Re small experiments: I code big Flash applications for a living. So I'm often living inside projects that contain dozens of classes and many thousands of lines of code. But I also always keep Flash open with an empty code window linked to a new file. If I need to figure something out, I divorce it from my big project. I do it in a separate file -- just whatever I'm trying to figure out. In other languages, you can do the same thing via command-line scripting.

6. In any tech subjects, force yourself to be organized beyond an anal-retentive level. For instance, every programming book tells you that a function should do one thing. Make that sort of stuff your religion. Don't say, "I know, I know, a function should do one thing, but I'm in a hurry..." Or if you MUST say that, develop such an aesthetic for organization that you can't live with yourself until you go back, later when you have time, and organize the code.

(If you haven't read "Code Complete," read it. If you've read it, read it again.)

In a similar vein, eliminate ANY issues (that can be eliminated) that make tech work difficult. I'm talking down to the level of making sure you have a good keyboard, enough coffee, working markers for your dry-erase board, etc.
posted by grumblebee at 11:56 AM on November 26, 2008

Everyone learns differently. I tend to be more of an "osmosis" learner, hearing about a concept, letting my subconscious churn through it for a while, then being able to apply it weakly, and later being able to apply it well. I've found a lot of good skills by experiential learning - trying things out. Theory's never been a big help to me but I think a lot of the reason for that is that it requires more knowledge of mathematics than I was ever gifted with, though finally now as I head into my thirties, i'm able to understand more of it mostly due to dogged stubbornness. I learned everything I know about UNIX (and like) operating systems by use of the 'man' command while logged in to a system; of course this was pre-web and gopher was all you had in terms of hypertext documentation. I learned much of what I know about networking in a very similar way, although i've spent more time on theory there.

The only other suggestion I have for you is learn with objectives in mind. Don't just pick up a book on dry theory and churn through it. Decide you're going to learn about the following x things today. Increase or decrease the number of x things until your concepts are very well understood. Intent (e.g. setting objectives), and following through on it, marked a huge improvement in the way I learned.
posted by arimathea at 11:59 AM on November 26, 2008