Mentoring a programmer
As I was writing in my journal this morning, I started thinking about the many events in my life that led me to my current career. I’ll spare you the gory details of the typical “college grad meets the real world” story, but there is one factor that cannot be underrated in my journey to become a software developer: mentoring.
Coming from a nontraditional background, I never learned programming in any kind of academic environment. I picked it up while working customer service at a small software company, and played around for months before I tried writing some demo apps and then later started working on some of the internal applications that were used by only a few people. I found programming syntax to come pretty easily since it is just applied logic. However, it was the application architecture that started to get the best of me when I realized that I was running into common problems that had to have simpler solutions than the ones from which I was approaching them.
At this point there were several key people who I turned to when I got really stuck, but one in particular really took the time to actually mentor me and began to patiently sharpen my programming mind by teaching me about design patterns (or more importantly, how to use them to solve real life problems), showing me examples of code that he had written, and describing lessons that he had learned. I am not sure that I understood how important this was at the time, but looking back it is clear to say that I would not be where I am today were it not for his involvement at this pivotal point in my life.
This brings me to my reflection in my journal from this morning (and maybe a little call to action). I am no expert and most certainly have a long way to go still. However, I have learned a few lessons and am beginning to wonder if I may may be able to also play an important part in an upcoming programmers life. The most important thing about mentoring is not knowing every little detail, but rather, encouraging someone to stick with it and to either develop their love for it, or to realize that there is something better on the horizon. As such, I think there are a few key characteristics of successful mentoring in the world of software:
- Take risks - there is no reason to protect a new programmer from your code (that is what version control is for), assign real tasks that will stretch his or her abilities. It is this kind of real world trust that builds confidence.
- Don’t give too much preemptive advice - Allow him or her to take a stab at a problem and then help when asked.
- Frequent code reviews - Once the code is working, walk through it and spend time identifying patterns, pointing out optimizations, and talking about alternative approaches. This helps to frame all of the explanations in relation to problems that have been recently addressed by the programmer
- Warn against pre-optimization - Teach that the first priority is to get something that works, second to that you figure out if there are any bottlenecks that need to be optimized. This one took me a long time to learn, as it was made apparent to me that I spent way too much time analyzing problems because I was so worried that I would slow down the application. I became much more efficient when I learned this simple lesson.
I am sure that this list is not complete - so please add on in the comments if you have any other suggestions. In the meantime - get out there and see who you can encourage someone in their quest to become a good programmer!
I’ve found many times when I’ve learned something, but it wasn’t entirely clear as to where it would apply, until later you stumble across a situation and all of a sudden it just clicks. Hey… I can you such and such to solve this… so that actually really wasn’t a waste of my time!
I can’t agree more about premature optimization. So many times I see people stressing about minute details of “what is faster, a or b?”, or writing code that is very difficult to read and understand because it should be faster. Then when you ask is there even a speed bottleneck, a lot of times the answer is “I don’t know” or “I haven’t tested”. Knowing the fastest way to add rows to a listbox is not a concern when you are talking about lists that will have 100 or even 1000 rows. The differences are so small that obfuscating your code for the sake of a fraction of a second just isn’t worth it.
You mentioned to allow the person to take stabs at the problems and then come to you to ask for advice when they need it. I like this approach, but there was this one guy I was helping out once who was just a little stubborn and I think he felt like it would be a bother to ask so he’d keep plugging away and only came as a last resort. Sometimes I wonder if I was mean or scary, but I tried to make it known that I was there as a resource. He did always get the stuff done and well, so it worked out either way.