How do you traverse a really large library like .NET?

July 12, 2009 7:30 PM

I'm working a project that requires some custom programming. This is outside of my usual domain, I'm feeling overwhelmed by the amount of objects and libraries available to me. I find most of my time is spent looking up what to include and how to do simple things that are easy once I find what I'm looking for. What's the best way to go about learning the libraries? Should I just sit down with a big reference book?

I find myself actually comfortable with the programming and grasped the object oriented programming concepts fairly quickly (it was sort of an a-ha moment).

However, the .NET library is so big and has so many different things to use, I often spend a lot of time dicking around trying to figure out the best way to accomplish what I want. MSDN and other documentation is abundant, but sort of obtuse. I spend a lot of time googling to find what I need. I'm thinking of sitting down and going through the entire library methodically and try to memorize or familiarize myself with as much as possible. Is this a crazy thing to do or a good way to go about it?

Are there any good guides besides MSDN that sort of distill things down in a more accessible way? Any advice?

posted by geoff. to computers & internet (8 answers total)

Most distillations are going to be domain-specific. What kind of programming are you doing? A web application? A server/client pair? A regular Windows user application?
posted by jedicus at 7:52 PM on July 12, 2009

Don't memorize. You memorize by doing; when you've used a particular function enough times, it becomes second nature. (OTOH, Other things, no matter how many times you use them, will refuse to stick.) The sheer amount of content available is too much for any one person to try to grasp, especially without some sort of context. For example, in the languages I eat/sleep/dream in, I'm pretty sure I only am familiar with about 50% of the libraries available to me. The rest I haven't had a need for. When the need does arise, I'll look it up.

A good reference book will help, good online documentation is golden (think searching!) Google for examples of what you're trying to do. In other words, you're doing it right. It will become easier, eventually. It's always slow in the beginning. It's like anything else -- you get better and faster at it the more you do it.
posted by cgg at 8:35 PM on July 12, 2009

Books or sites that work through frameworks using practical examples can sometimes be quite helpful. In these cases, you can see what methods, classes, etc. that professionals use to solve specific problems. These examples can expose you the dark corners of the frameworks, to classes that you've never heard of or will never hear of again; that are only useful in specific situations, but incredibly useful in those situations. Searching through the framework help and/or object browser in Visual Studio for generic words related to what you're trying to accomplish can helpful (ie, search for "sort"). Last, the msdn magazine has some really cool, detailed examples you can follow along with.
posted by kurmbox at 9:09 PM on July 12, 2009

I've been in the industry for 12 years. No one memorize libraries. Leafing through to get the general organmization and feel is a good idea.

The trick is to get familiar enough with a library or group(s) of libraries to be able to correctly guess what a library will have and what it will name that, so that you can quickly narrow down where, and if, that something exists.

Code completion tools can make this somewhat easy than it was when I was stating out with a simple editor, but it's really a matter of guessing accurately, by being able to think, "knowing what I already know of Library X, that library would probably name a function to do Y something like 'int doYex( Hhandle, lptrCh)'...."
posted by orthogonality at 9:11 PM on July 12, 2009

I wouldn't even say that I memorize by doing. I usually do the process you describe geoff of doing the intensive Googling to find the optimum way to solve a problem once.

Then I forget everything I just learned and all I remember is that I've solved the problem before at some point in time. I try to either post the solutions I've found publicly on web sites or forums, or add them to a big archive of snippets from past projects I've done. So when I encounter the same problem again I just track down the code where I solved it before and copy that.

If it's been, say, two or three years since the last time I encountered it maybe I'll re-Google to see if a more optimal solution or library has come out in the mean time.
posted by XMLicious at 9:17 PM on July 12, 2009

I find the easiest way is to just write a series of toy programs of increasing complexity (aiming towards whatever domain I'll be doing the real work in). At first, the goal is just to get something that works at all; later, as I dig through the documentation to figure out how to do something more complex, I'll realize how using such-and-such a class or pattern would make the last program I wrote simpler or better. But it's really hard for me to learn a library's usefulness without doing any actual coding. When I find myself doing something that seems like it should be easier than it is, then I might also search for other peoples' code (perhaps here) to see how they've approached it.

Once I feel generally competent with an API, then it's helpful to just read all the docs straight through and to read other peoples' code.
posted by hattifattener at 9:35 PM on July 12, 2009 [1 favorite]

By the way, MSDN becomes a lot more usable when you use the lo-band version.
posted by lunchbox at 9:46 PM on July 12, 2009

Hmmm, I think maybe writing a bunch of simple programs might be a good idea. Perhaps I'm taking the idea of decomposition too far and trying to do too much at once. I think creating a series of programs that do what I want and work right out of the box might be more satisfying and allow me to get more practice in. Perhaps I was being too hard on myself, I assumed that relying on Google and MSDN was sort of like cheating and if I relied too much on examples I wouldn't actually know what I was doing, if that makes sense?

I also kind of have a nagging fear that if I spend 6-12 mos. learning something it'll be obsolete in two years. I can't imagine learning French only to find out that France stopped speaking it a year ago, but I guess that is the nature of the industry.

Thanks for the advice!
posted by geoff. at 8:05 AM on July 13, 2009