A group blog from members of the VB team
I’ve always enjoyed writing. Putting pen to paper (or, these days, fingers to keyboard) is something that brings a lot of joy into my life, even more than music or any other hobby that I have. I’ve been writing stories since earlier than I can remember, have faithfully kept a daily diary for many years, and have published countless journals, conference papers, and other articles on this or that technology.
So, when I was in my early twenties, it seemed the most obvious thing to try start writing professionally. I wrote out a number of stories (mostly science fiction), which I sent in to various magazines. All of them were rejected. This was a source of frustration to me for quite some time, and as I personally found my stories to be engaging and eloquent (why not?), I couldn’t understand why these obvious “gems” were being overlooked.
I could have given up, and I was tempted to. But I instead decided to get into it from another angle; why not practice? There was this new thing called “USENET” which leveraged the still-nascent Internet, which was read by people with very similar backgrounds to mine. I started out by writing short parodies, figuring out what worked and what didn’t. (Some of my Star Trek and Black Adder parodies are still lurking out there on the ‘Net, much to my embarrassment. If you come across them, have mercy on me. J)
I got a lot of healthy feedback from friends and ‘Net acquaintances on these attempts. Gradually I came to realize that there was a lot of difference between having a good idea and describing it well. There’s a fine line between too much description and not enough description, and I tended to err on the side of “too much.” It’s a problem I still have to some degree even now – for the technical writing that makes up much of my authoring, it’s not a big deal, but it’s deadly for any writer who’s trying to keep the action moving. This was a good thing to learn, I’ve gone on to publish one piece of fiction, and I do plan (if I ever get enough time) to try my hand at fiction again – and in the meantime, I have learned many things that have helped me in the writing that I do daily.
So, what has this got to do with programming? Well, this is going to be a slightly odd column – not my usual coding example, but more getting into how we learn and improve our skills. It’s motivated by a comment from “jerry” (which you can find here), in which he asks:
“[…]I've been trying and trying, searching endlessly on the internet, but i can't find anything on the internet that really teaches me more. It's either easy stuff, or articles like these *gulp* that are way too far beyond me. And just experimenting takes forever, and usually doesn't show much results, because i don't know what to look for. How can i learn?”
This is a great question; one that I wanted to spend some time on, rather than just ad-lib a few reassuring sentences in a comments section. How exactly do we learn to be good programmers?
Before I get into “ways of learning,” there are some basics I should touch on first. There are a few talents that I believe all good programmers share, the benefits of which extend beyond programming. Three of these include:
· Pattern matching: A good programmer sees patterns in how work gets done. These patterns can be used to generate the spec for a program (i.e., tailoring usability to match a cultural meme), or to generate the basic architecture for their code (i.e., boilerplate). A truly great programmer, however, will intuitively know when to ignore these patterns and move forward to something new so as not get trapped in an obsolete way of doing things – this is referred to as “thinking outside of the box.”
· Efficiency: A good programmer is capable of reducing a complex problem to a simpler one. (Some skill at pattern matching is a prerequisite for this talent.) This talent is exposed through the crafting and reuse of good code. A truly great programmer will be reevaluating plans and code even after they are complete, and for as long as they are relevant, and have the desire to accept honest feedback on the work to make sure that it’s as efficient as possible.
· People skills: Really? In a programmer? Well, yes. Without this, you can’t accurately gauge what the customer needs, or communicate your ideas, or…well, do anything that involves people. There are people who can write good code and have good ideas but you’ll never know it. A great programmer can sell new ideas to their team because they know how to explain the ideas in such a way that people immediately understand them.
Given these talents, my opinion is that you should be in a good position to grow your skills as a programmer, no matter your current expertise is. (Not coincidentally, interviews at Microsoft are set up to gauge these three talents, as well as general know-how.) So now, let’s take a look at some learning opportunities.
Back in the early 80’s, there were a lot of magazines that one could purchase that had lengthy programs written in them, all ready for you to type into your C-64 or TRS-80. (I personally read Compute! magazine myself, being a C-64 user.) The programs were fully printed out due to necessity – 5.25” floppies disks were still a new thing then (many people, like me, were still using tape drives), and publishers didn’t bundle disks with magazines until later in the decade – too expensive!
The side-effect of this was that the user was essentially forced to *be* a programmer by virtue of typing in the program, unless they bought pre-packaged code (of which there wasn’t much). Anyone paying attention to what they were typing – if they had the talent – would be recognizing the patterns and thinking “Hmm, what if I changed this? How about if I do that instead?” In fact, I’d be willing to bet that that’s how 90% of programmers in my generation got their start – they began with someone else’s example (even if they didn’t understand it), and started tweaking the code, little by little (as well as coding around typos inadvertently introduced into the article). Gradually, they’d recognize patterns, and start applying them to their own code.
This sort of example-based learning is something that I still do today. When I became the lead of the VB Compiler Team back in 2003, I knew nothing about compilers beyond what I’d learned in college nearly 16 years prior, so I grabbed the compiler code, wrote a simple program, and stepped through the compiler line-by-line to learn what it was exactly that my new team owned. In more recent days, when I’m working on “hobby” (i.e., non-Microsoft) code, I’ll sometimes stop at open source sites, download the code, and do pretty much the same thing I always did – step through the code, tweak it, and see what happens so that I can learn the basics. (Edit and Continue makes this pretty simple to do.)
The epitome of example-based programming is to take code written in one programming language and porting it to a different language. You can learn a lot that way, especially if you’re currently weak in one of the languages. I’ve done this a lot in the past to get past the learning curve – for example, the very first code I posted in my VB blogs was a VB port I’d done in 2000 from some C++ code I’d written in 1998. It was the first full program I’d ever written in Visual Basic! I learned a lot about the differences between the languages, their strengths, and their weaknesses.
Oddly enough, these blog entries of mine are a sort of homage to the old Compute! magazine, with code interspersed with discussion – like other authors on this blog, I’m motivated to both present the code and talk about it as well, so that it becomes a good learning experience. Our own MSDN Code Gallery is good place to find code samples, and there are still magazines out there which publish code for you to try as well. And if you run across a programming concept that seems too hard – ask the author! You can’t expect the author to write your programs for you, but he or she will likely be very flattered to get questions from you and happy to clarify issues that might be too vague. At the very least, it gives the author something to write about for his or her next article!
Occasionally, you get the opportunity to build on someone else’s code, and that’s a great learning experience as well. A gentleman by the name of Ken Mattern has done this with the MIDI code sample app that I posted a few weeks ago (here and here). You can find his extensions to my code here. Basically, he’s taken my code and added a keyboard and other controls to the form, which makes it a lot easier to enter the notes (you can even hear the notes as you press them) and is a big improvement on the interface that I had created. He was gracious enough to point me towards his extension, and he and I have exchanged mail on ways that the keyboard code could be made even more efficient. Win-win!
Visual Basic in particular has always had a great community from which to learn, and one sure way to learn more about coding is to join a VB User Group. There are many of these around the globe, and you can search the ‘Net to see if there’s one in your area. I’ve visited with some of them, and I’ve always been really impressed with them – the members are really helpful to each other with respect to learning new concepts. You can also get involved with “group projects” at these meetings – collaboration is a sure means of getting feedback on your skills and learning new tricks, as I’ve discovered at Microsoft.
And sometimes, you just need to take lessons. For example, I’d gotten back into golf recently after an injury got me out of the game a few years back, but was doing really poorly. Despite helpful advice from friends who are good golfers, and despite watching them play, my game didn’t turn around until I got lessons from a pro (and boy, did that help!). The same thing works for programming – sometimes you just need to study with a master.
This doesn’t necessarily mean taking classes (although there is certainly something motivational about getting graded on your programming, having an instructor at hand, etc.). It can be as simple as buying a book at your local bookstore. There are literally hundreds of books which can teach you to be a better programmer, and buying 2-3 of them is definitely a good investment for anyone seeking to improve their programming skills. (My shelves at work regularly contain books on COM, .NET, international programming, security, and so on.) If you go this route, here are a few things to consider when shopping for a book:
- Does the book provide clear descriptive text for the code?
- If a true textbook, does it provide a solution for the problems it sets you to work on?
- Does it explore different aspects of coding – data, forms, web use, etc?
- What level of programmer is it aimed at?
Read through the first chapter at the bookstore before buying the book – that should give you a good idea of where the author is going.
Community colleges and night schools also often have inexpensive courses in programming. Sometimes these are tilted in a particular direction (web development, rich client apps, coding in C#, and so on). You want to make sure that the course is about programming applications instead of using applications, of course!
At this point, I’m going to throw it open to everyone else to comment. Have I missed some obvious learning mechanisms? What else could a person wanting to improve their programming skills do? I’m looking forward to hearing back from everyone on what’s worked for them!
‘Til next time,
P.S. I’ve uploaded yet another version of the VBScreenSaver code to fix a bug I found last weekend. It turned out that, in the unlikely event that the same random number is chosen twice in a row, the code was attempting to access the same picture before it released it, leading to a resource contention exception. I’ve fixed this by simply returning from DrawPicture() without doing anything if the random number is the same , keeping the current picture up until the next time event. It’s not a frequent enough occurrence to warrant anything more complicated than that, such as releasing the picture (which would cause a flicker) or generating new random numbers until we get a unique one.
Private Sub DrawPicture()
' Which picture? Get a new random number
Dim index As Integer = Me.m_Random.Next(m_fileCount)
If m_files(index) = m_currentFile Then
' We are already looking at this file and will get an exception
' if we try to open it before we close it.
' We could call for another random number, but why bother?
You can find the updated code at my Temple of VB site.
PingBack from http://microsoft-sharepoint.simplynetdev.com/how-do-we-learn-to-be-good-programmers-matt-gertz/
Honestly, you have to be the nicest person i've met! I'll try what you've said, and get back to you!
Thank you for submitting this cool story - Trackback from DotNetShoutout
Thank you Matt for such a post,I'd like to add that Programmers/Developers have to balance there ego and accept other people input on what they have written (Code) and be open to discuss solutions that they came up with, with other developers because they might have a better way to solving that issue. I would like to point you to A Forward in Book titled "Coder to Developer" by Mark Gunderloy Forward by Joel Spolsky its :
Great article, Matt...
...and you're scaring me.
I started programming when I was 11 years old and my first PC was a VIC-20.
Personally, I was a Compute!'s Gazette hog myself. And yes, I typed in EVERY program...even the machine language with pages and pages of columned numbers. :-)
It's always good to see a fellow Commodore user.
Again, Great job!
What a wonderful article! the beauty of programming is when you can reduce any piece of code, to what can be done with paper and pen. Thanks for the wonderful advice.
@Jerry: Glad I could help -- let us know how it goes!
@DotNet Shoutout: You're welcome (although, like I imply above, I find getting this into print to be cathartic :-))
@Jonathan Danylko: Heh, do you remember trying to debug those programs when you entered one of the PEEKs or POKEs wrong? I had my little brother standing next to me, reading the addresses and data out loud so I could figure out which one I got wrong after typing in the entire "EMPIRE" game.
@Ahmed Ibrahim: Thanks for the forward. You are absolutely correct; the best programmers leave their egos behind, and can always learn from a variety of sources. It's always a pleasure for me when we hire someone out of college who can give us the scoop on the latest-n-greatest practices coming out of the universities!
@Sara: Thanks for the kind words. It's funny; what you said reminds of how, in my college days, I used to write out my programs long-hand before even typing them in -- this is because we had a fixed amount of computer time on the Ahdahl 6000 that U-M had, and so I also used to debug them mentally before entering them, which really helped with the robustness. I'm not saying that people should do that nowadays -- the tools are much better now! -- but it definitely made you think hard about the code when every bug ate into your time budget!
It's the first time I comment in a blog, and I just can say it was the best post I ever read... A lot of times I felt this way... and can't discribe like you did.
I want to tell you, that I share this post whit all my software factory partners at work... In Argentina!!!
Sorry for my english.
Argentina, eh? Very cool, Ezequiel! I'm glad that you enjoyed it -- I'm pleased that the post seems to have hit the right wavelength with a lot of people.
P.S. Your English is fine. :-)
Nice article. Glad to see you mentioned Example-based learning. This is exactly what I have been doing to teach my self VB.Net. I will tweak some one else's code to see what happens. Sometimes it is difficult when you don't know what the code is doing. Good work!
I even type in that "code checker" so every line was entered properly.
(Ironically, the problem was typing in the code checker perfectly to run to check the other code.)
<starting to twitch>
@Haroun: Yep, I've always leaned pretty heavily on EBL myself -- there's just no replacement for "doing" in my case, though it can be a pretty iterative process. (I've always admired people who can simply read up on a subject and hit the ground running with no prior experience -- lucky folks!)
@Jonathan: Time to drag you off to the Rest Home for Aging C-64 users. :-) "Please don't mention 'Gateway to Asphai' around Mr. Danylko -- he'll start scratching himself and muttering about slaying mamba snakes."
Some of the better ways I've learned new code and pattern recognition:
- Reading single threaded code that does multithreaded tasks, such as, asychronous event handling driver code.
- Reading code in from distinctly different systems helps one learn how to code and detect patterns. VB.NET versus C# versus win32 is not different enough.
- Reading code at different distances from the bare hardware (e.g., device driver code, gabage collected code, report writer code, scripting language code)
- Reading code from different decades (1970s structured versus 1990s OO versus 2000s GC environments)
- Reading code from resource constrained systems.
- Reading code from asychronous systems such as communication protocol handlers
- Reading non-sequential language code and rule based systems
Those are good ones, Greg, and I think a lot of them have a lot of applicability for moving from an intermediate to an expert level. I particularly agree with the point about different languages (applicable on all levels) -- porting between unmanaged languages like C++ and managed languages like VB has a lot of back for the buck -- even better if you can dig up some Pascal or Fortram routines. I once had to port something from LISP to C++, and it made my brain hurt, but boy did I learn a lot about structured code.
I am a hobbyist vb.net programmer looking to build my VB.net skills. I typically get small chunks of time to (less than 30 min) tinker and play. Has anyone seen a site with small ~15 min exercises that I can use to create a queue of exercises that I can tinker with on my spare time.