How To Learn a New Programming Topic

(Note: this article is really long, but every word of it is important. Follow along and learn the topic with me.)

I had an interesting conversation with another programmer the other day about how to learn a new programming skill. He's a very smart guy, but he was having trouble getting started learning new topics. Programming topics are built up in layers, and you can't understand high-level things until you understand their lower layers. Many programming books, articles, and even our development software is fighting this idea and trying to make high-level processes accessible without the low-level knowledge. This is because many people reject what I consider a basic property of programming itself: programming is hard work. Part of the reason for that is because you are constantly learning the minutiae of many new topics simply to keep up with your job. This can be boring at times, and requires hard work and dedication. Programmers who lack this dedication can survive for a while, but they almost always either become glorified data entry clerks, or they become doctors, preachers, and pizza drivers (true stories).

One of my major pet peeves on internet forums is the "How do I do this" question, when the person hasn't even tried yet. Programming is a topic which often presents the student with so many problems right up front, that they throw up their hands in disbelief and have no idea what to do. So they go begging to experts for some tidbit of arcane majick that will make it all make sense. The experts will often come back with a flame of epic proportions, which I have been guilty of on numerous occasions, telling people "why don't you try to learn it before you come in here with your stupid questions?!" At some point, it occurred to me that for some people it's not as simple as "go and learn it." This can be true of people with good learning skills and high intelligence. However, it is possible to learn this skill. That is, learn to learn.

Learning a new programming skill is an organic process and will not be the same every time, but there are some basic processes you can apply in all cases. This example will show you what those are in as much detail as possible. Research skills are important, but so is experience. In many places in this adventure, I rely on my experience to figure things out. In the cases where I have no experience with something, I go get some. I chose a topic which I have no experience with: Visual Studio Add-ins. Here goes...

Defining your goals
At first, I want to think about what my ultimate purpose is, but I have to mentally accept that I probably won't get there right away. I need to carefully define this because I don't want to confuse myself and waste my time by exploring topics that don't apply to my situation. What I want is a VS Add-in that would allow me to highlight a section of variable declarations (such as the long sections generated by the Forms Designer), and sort them by type and alphabetically. Ideally I would like this to be a context menu that comes up when you highlight some code. I need to think about some of the possible issues with this right up front, but I don't dwell on them. Some things that come to mind right away are: how to get a context menu to come up in the first place, how to read the code from the editor window, how to automatically modify that code, how to make sure I don't introduce errors in the code, and how to reject bad user input if they highlight a section of code that doesn't include variable declarations. Overall, I know this is going to be a pretty hard project, so I want to start with something simple. At first I want to create a simple Add-in that puts up a context menu item whenever I right-click in the editor window. Without any research, I'm assuming that's going to be easier that testing to see if any code is highlighted and if it's proper code for my routine and so on. This initial context menu item will not do anything, it will just be there to let me know it's working.

Searching for information
In the old days, I would be on my bike headed to the library, but these days we have Google, and it should be the first place you go for any information. Using Google to search for programming information works fairly well, but you need to know how to use Google. Coming up with the right search terms is very important, and in this case I have a good idea what I need. I know what my topic is called, which is a good start, and I know what language I want to program in. Including the language in programming queries is one of the best things you can do to help Google find what you want. So I go to Google, and say "Visual Studio Add-in C#", and start looking at the results. I'll usually read the first few results of a Google search, checking which sites they come from and the preview text to see if the article applies to my situation... only then, do I click a link. If I don't get good results, I don't waste my time clicking anything, I change my search terms, or if I'm positive I have good words, I check other search engines like Ask.com. I also check programming sites and forums like Codeproject and specialized programming documentation search engines like MSDN. I prefer tutorials when I'm just getting started, so I do avoid MSDN and the Visual Studio "F1" function until I've gotten an intro to the topic, but I will eventually be consulting the technical documentation for something. This will probably be time-consuming and painful - I know this and accept this right up front.

Anyway, back to my Google results. The first result is from Codeproject, and I know that's a good site, but it says some kind of error, so I look at some of the others. There's some good things there, and I might go back to the Codeproject one, but I like the second one, so I click it and start to read the article.

Reading and processing information
At first, I don't read the whole article, I skim over it. Skimming is a skill you should have learned in school, and if you don't have this skill, you should learn it. It comes in handy when looking through long code files too, so it's a good skill for any programmer. The article looks good overall, so I start reading it word-for-word. No, I am not going to skip any words... this is super-important with a topic you know nothing about, and I shouldn't have to say it, but don't skip over anything. I am eventually going to read this whole article, but there's going to be interruptions along the way, so I use tricks to keep track of where I am, such as highlighting sections in my web browser as I read. I want to make sure I don't miss anything important, but this is a tutorial, so I need to follow along. In this case, I'm not going to read the whole article before I try the process. I know that c-sharp corner is a good site and I'm fairly confident that the article will lead me somewhere interesting. This is where the organic process begins, and I'm going to alternate between learning and doing, and possibly also between various levels of information within my topic. In the first paragraph of the article, it makes it clear that this tutorial is a more complicated project than I initially wanted to do, but it's still pretty simple: it adds a comment to your code file. I decide this is cool, so I open up Visual Studio and start to follow along.

Trying it out
At this point, it's worth mentioning that having a good machine will really help you. Make sure you have enough memory to run Visual Studio and a few web browsers and if you have multiple monitors or other bells and whistles, use them. I'm actually reading the tutorial, running several web browsers and Visual Studio, and writing this blog, all at the same time. If I was short on memory or something, that would simply not be possible. If you are reading this and you want to follow along, you should have the same applications open. If you don't have my type of ADD, you will simply have to learn to multi-task... it's a programmers greatest time-saver (caffeine helps).

At first, I make a note that this article mentions "Visual Studio .Net" - I'm not sure what version he means by this, but I have version 2005 so if I notice anything weird, I might have to abandon this tutorial and find one that is specifically for Visual Studio 2005. I start to create project as described and everything is going well. I see that there is a lot more stuff in the screenshots than what I see in my Visual Studio, but I have the options I need, so I press on. I choose a good name for my project (JazzysCodeSifter), and I check the options one more time before I click the Open button. I am presented with a Wizard that looks a little different than the one in the article, but again, the option I need is there ("Create an Add-in using Visual C#"), so I select it and click Next. The next few screens in the wizard are covered in the tutorial, so I click through and finish the wizard part. I take note of the options along the way, because I'll eventually go back and learn more about them, but for now I just select what the tutorial says. When I get to the finish screen, I see that things are a little different than the tutorial says, so I go back and read some more and I twiddle the options in the wizard until it's exactly right. THEN I click finish in the wizard to create my project. I make sure everything is exactly right, because I don't want to confuse myself by accidentally going down a different path from the tutorial. This has burned me before, so now I make sure I do it exactly right.

Exploration
Now, there's some things I'll do here regardless of what the tutorial says. This is just from experience, so I depart from the tutorial for a minute and I do two things: compile the project and read through the code. The project compiles fine, and when it was created, it automatically opened a file called "Connect.cs", so I take a look at that. I don't like wizards very much, so I scrutinize the code that it created in my project, and I may eventually go back and create an Add-in from an empty project, writing all the code myself. For some project types that generate a lot of code, this is not practical, but if possible I like to know what those wizards do and the best way to find out is to do it yourself by hand. For now I see a lot of confusing stuff in the code and I have no idea what most of it is, but I make note of some key things, like what libraries are used (the using directives tell me this), how my object is created (it has an empty constructor), what some of its events are (I see OnConnect, OnDisconnect, etc.) I consider looking up the Visual Studio "F1" help on some of the object type names, but I want to finish the tutorial first, I'll do that later. The tutorial will tell me some of what I need to know, so I go back to it...

When I go back to the tutorial, I notice that the next thing in the process is a very cryptic operation and I don't fully understand what they are saying here:

To build the setup project (CopyrRightAddInSetup in this case), youll need to go into the Configuration Manager in the Build menu and check the build, because by default it is unchecked.

This comes along with a screenshot that doesn't help very much. Now, I happen to know what a setup project is (it's the installer that you will distribute), so I go to create one for this Add-in using the wizard. I know from experience that it's best to add the setup project to my existing solution, so I do that. I also know the basic steps to create a setup project, so I do those and I end up with something like the screenshot in the tutorial. If I didn't know about setup projects, that one sentence in the tutorial would have sent me off on a tangent to find out the basics of setup projects, and my learning process would become recursive. I would be back to Google and probably another tutorial. I feel confident at this point that I haven't messed anything up too bad yet, so I continue in the tutorial.

The tutorial says to "Run the project in debug mode," and I know how to do this, so I click the little arrow and it runs. I see it open up a new instance of Visual Studio, and I go to the "Tools" menu to see if my Add-in is available, and it is. Again, lots of memory and a good computer is handy here: I'm now using 1771MB of RAM, for two instances of Visual Studio (one running a program in debug mode), 4 web browser windows, and a paint program for this screenshot of my Add-in.

If I was using virtual memory for this, my hard drive would be thrashed and I would be staring at the hourglass. Anyway, I have reasonable proof that my basic Visual Studio Add-in works, and at this point, I have created The Null Program, so I have a choice. I can go ahead and stop reading the tutorial and go off on my own, or I can finish the tutorial and learn what it has to offer. I choose the first option.

Finishing the first try
I usually like to create a very basic project at first and then dive into the technical documentation, but this tutorial is worth finishing, so I'll do the idea in the tutorial: an Add-in that puts a comment in your code files. This isn't a big departure from the code-modification tool that I eventually want to do. In some cases, I will abandon the tutorial at this point and go off on my own tangent if I think it's necessary. Sometimes, that works, but sometimes I end up going back to the tutorials. This is completely unfamiliar ground, so I want to see where I end up with this example, so I finish the tutorial. I make note of a lot of things along the way, which I will have to read up on from other sources. Tutorials don't explain everything, and I want to understand some things in detail. Experience tells me the things I need to investigate further and those I can safely ignore. For example, this Add-in is invoked in a different way from what I want and the tutorial doesn't explain it fully, so I will investigate the interface between Visual Studio and my program a little more, but for my purpose, I don't particularly care about the Toolbar it created so I won't investigate that any more. Not right now anyway.

Remember the idea here was just to get an introduction to the subject, because I had no idea how to get started. It took a lot of work to get to that point, but it wasn't impossible. I think an organized approach to this task can make it seem less overwhelming, and if you use this example to develop your own learning techniques, you should be able to adopt new programming topics a little easier. This will only get you started though. If you want to become an expert on Visual Studio Add-ins, it will take years of experience, because this topic is built on so many others. If you don't know C#, for example, you can never be an expert on anything that uses C#. Learning topics like this can be very time-consuming, but I think it is the only way if you want to be any good. Learning programming can require some special techniques, but this is essentially the same process you would use to learn anything else: an iterative process of study, practice, reflection on what you have done, and refinement of your skill. Tiger Woods practices every day, studies the golf swings of other people and himself, and sometimes even takes golf lessons, and he's Tiger Woods! You need that kind of dedication to truly understand any subject, and programming is no different. Good luck!