This Q&A is part of a biweekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 80+ Q&A sites.
Robert Harvey asks:
Occasionally I see questions about edge cases on Stack Overflow that are easily answered by the likes of Jon Skeet or Eric Lippert—experts who demonstrate a deep knowledge of a particular language and its many intricacies. Here's an example of this from Lippert's MSDN blog:
You might think that in order to use a foreach loop, the collection you are iterating over must implement IEnumerable or IEnumerable. But as it turns out, that is not actually a requirement. What is required is that the type of the collection must have a public method called GetEnumerator, and that must return some type that has a public property getter called Current and a public method MoveNext that returns a bool. If the compiler can determine that all of those requirements are met then the code is generated to use those methods. Only if those requirements are not met do we check to see if the object implements IEnumerable or IEnumerable.
This is cool stuff to know. I can understand why Eric knows this; he's on the compiler team, so it's explicitly in his job description to know.
But how do mere mortals, those of us on the outside, find out about stuff like this?
Eric Lippert replies:
First off, thanks for the kind words.
If you want to get a deep knowledge of C# it is undoubtedly an advantage to have the language specification, ten years of design notes, the source code, the bug database, and Anders, Mads, Scott and Peter just down the hall. I'm certainly fortunate, no question about it.
However, even without those advantages it is still possible to get a deep knowledge of the subject.
Back when I started at Microsoft I was working on the JScript interpreter that shipped with Internet Explorer 3. My manager at the time told me something that was some of the best advice I've ever gotten. He said that he wanted me to become the recognized expert at Microsoft on the syntax and semantics of the JScript language, and that I should go about this by seeking out questions on those aspects of JScript and answering them. Particularly answering the questions I didn't know the answers to, because those are the ones I would learn from.
Obviously Stack Overflow and other public Q&A forums are like drinking from a firehose for that sort of thing. Back then, I read comp.lang.javascript and our internal Microsoft "JS User" forums religiously and followed my manager's advice: when I saw a question that was about the language semantics that I didn't know the answer to, I made it my business to find out.
If you want to do a "deep dive" like that, you've got to choose carefully. To this day, I am remarkably ignorant of how the browser object model works. Since I have been concentrating on becoming the C# language expert these last years, I am remarkably ignorant of how the various classes in the base class libraries work. I am fortunate in that I have a job that prizes specific deep knowledge; if your job or your talents are more in line with being a generalist, going deep might not work for you.
Writing a blog is also tremendously helpful; by requiring me to explain complex topics to other people, I am forced to confront my own inadequate understanding of various topics all the time.
Karl Bielefeldt replies:
Having been on the "guru" side of the conversation once or twice, I can tell you that a lot of times what you perceive as "deep knowledge" is often the result of the "guru" recently struggling for a month to solve the problem you're trying to solve yourself. That's especially true on a forum where people can choose which questions they will answer. Even the likes of Jon Skeet and Eric Lippert had to learn "hello world" at one point. They pick up their knowledge one concept at a time, same as anyone else.
Maglob replies:
Remixing the wise words of Yogi Bhajan:
"If you want to learn something, read about it; if you want to understand something, write about it; if you want to master something, program it."
Programming is like the ultimate teaching challenge. Teaching a computer to do something requires that you know your stuff really well. By teaching/programming, you will learn to become a master.
For example, if you want to learn physics, write a physics engine. If you want to learn chess, program a chess game. If you want to learn deep C# knowledge, write a C# compiler (or some other tool).
HLGEM replies:
I would say do the following:
After learning a relatively useful stack of languages (the ones you need for a real job) at the level where you can do most common tasks, stop learning more languages until you have studied at least one in depth. Part of the problem in our industry right now, in my opinion, is that people only learn the first 5-10% of the language before moving on to some other language. Once you have the capability to do most common tasks in a job, then start looking at one thing in depth. (You can go back to getting breadth after you get some depth, then go back and forth between the two.)
Volunteer for the more complex, harder tasks, the ones that make you go in-depth to solve the problems. If there are none where you work, look for open source tasks or start working on a personal project that will make go in-depth. If your job has no interesting problems, consider looking for a more challenging job.
Read the advanced books on one language (for SQl Server for instance this would include reading about performance tuning and database internals) instead of the "How to Learn X in 30 Days" type of books.
Read interesting questions where they are asked and try to solve some yourself. If you want to learn, try to solve some without reading the other answers first. Even if the question has already been answered, you will learn more if you find the answer yourself. You might even find a better answer than the one the question had.
Ask a few of the harder questions. Evaluate the answers you are given, don't just use them. Make sure to understand why the answer would or would not work. Use those answers as a starting place to research.
Find some good technical blogs from known experts in the field and read them.
Stop throwing away your knowledge after you are finished with it. Learn to retain. Most experts don't have to look up the common syntax. They don't have to reinvent the wheel every time they face a problem because they remember how they approached a simliar problem before. They can connect the dots and see how problem X that they did two years ago is similar to problem Y that they have right now (it amazes me how few people seem able to make connections like that).
Bart:
Get Reflector or any other decompiler (since Reflector's fee-based now), and start opening up some of the most used .NET libraries to learn how the internals work. Combined with a book like CLR via C# you'll get quite deep (deeper than most of us will go on their regular job).
Think you know the best way to develop deep programming knowledge or disagree with the opinions expressed above? Bring your wisdom to the original post at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, scientific skepticism, and almost everything in between.
Posts
