Programming Is an Endeavor, Not a Race

It seems obvious that the field of programming is an endeavor and not a destination to be reached. The technology and best practices are always changing, sometimes at an alarming pace, and keeping up with that rate of advancement requires a constant commitment to personal development. That means that good programmers are always learning, yet I read internet discussions all the time that attempt to separate novice programmers from experienced ones and argue in favor of one or the other.

The advocates for the novice programmer appeal to the need for training, mentoring, and standards to help the novice programmer become productive, protect the team from mistakes the novice would make, and generally expedite the process of getting the novice to an expert level. The advocates for the experienced programmer argue that such measures waste the expert programmer's time with endless distractions and stifle their creativity with rigid coding guidelines. The novice programmers complain that the experts are aloof and won't give them the time of day, while the experienced programmers claim that the novices don't care about learning the best way of doing things or are incapable of comprehending their advanced code. Therefore, teams should be made up of only the best programmers to be successful.

Certainly, I'm oversimplifying the ongoing argument here, but this is the general form that I see it take, time and again. I see a lot of validity to both sides of this argument, especially when considering that everyone has their own perspective coming into the debate, and their points are certainly true for their own experience. It seems to me that they are all right, and at the same time they are all wrong, because the framework of the argument is wrong.

The major flaw comes from assuming that programmers can be categorized as either novice or experienced and that there should be any tension between them. In reality, programmer skill is a continuum, and there is no definite point when someone transitions from a novice to an expert or to any intermediate skill levels that you could come up with. We all started out as novice programmers at one time, and now we are all at different points on our learning path.

New programmers are entering the field every year as people take their first programming class or discover a book or online tutorial that introduces them to programming. That will still be true in 10, 20, or 30 years from now, and we need these new programmers because at least some of them will become tomorrow's great programmers. They won't be able to write great code to begin with, and some of them never will. But unless they write a lot of code, they will never learn how to write good code. Some of that code will likely make it into your code base, and yes, you will have to maintain it. That is part of your job as a more experienced programmer.

Another part of your job is to help teach other programmers. You may not feel like an expert programmer capable of bestowing your knowledge on others, but unless you are a beginner, you likely know some aspect of programming fairly well. If you are an expert, it is likely in specific areas, and you know of other areas that you'd like to work on. You're an expert and a novice at the same time. You should do what you can to spread the knowledge you have so that others can benefit from your expertise, and hopefully, you will benefit from others with expertise in areas where you are weak.

There is an additional benefit to teaching, and that is that while you are teaching, you are also learning. Having to explain something so that another programmer understands it will deepen your own understanding of the subject in a way that reading about it or having it explained to you or even doing it yourself will not achieve. Teaching something forces you to organize the topic in your own mind more fully and solidify concepts that you may have only superficially learned before.

Take a simple example, like how to choose when to use a for loop or a while loop. You may have been choosing one or the other in different coding contexts for years without thinking much about it. You know how they both work, and you can use them fluently. As soon as you have to explain to someone else why you would use each of them in different contexts, I guarantee that you will learn something new because you are forced to examine their pros and cons, their structure, and their idioms in ways that you probably haven't thought about before.

Earlier I mentioned standards, and I think standards are a big point of contention for a lot of programmers. Some think they are necessary because standards will protect the code base from novice programmers that don't know what they're doing, and maybe those programmers will learn something about good programming by following standards, assuming they actually read and internalize them. Others hate standards because they feel that coding standards are draconian. They feel that standards condone coding without thinking and stifle the creativity of more experienced programmers so that they can't write the best code as the situation warrants. Do you see the inconsistency here? How can standards promote good programming but at the same time prevent good programming?

The problem is that most coding standards are created under the assumption that a few experienced programmers can codify their knowledge, impose it on novice programmers, and expect good code as a result. There's that false dichotomy of novice and expert programmers again. It is true that new programmers need to learn and understand good programming practices before potentially abusing more complex language features. Basically, we need to learn the rules before we can break them. How can we encourage that practice without prohibiting experienced programmers from using complex features in elegant ways because they are potentially dangerous in the wrong hands?

Then there is the related concern that novice programmers won't be able to understand code that uses more complex language features, so they should be restricted for that reason as well. That line of thinking ignores the fact that programmers can and likely will learn these features with time, and the more they are exposed to them, the faster that learning is likely to happen. A better way of implementing coding standards would be to make them as lightweight as possible with the emphasis on things like good naming conventions and unit testing. Then encourage a culture of asking questions and mentoring through practices like code reviews to help speed up the process of disseminating knowledge and improving everyone's programming skills.

For every programmer, there is a beginning, but there shouldn't be an end. There is no point you can reach where you know everything you need to know. Programming is a dynamic field, and there is always something new to learn. We are all at different points on that endless endeavor. We have the responsibility to learning when our skills are lacking and to teach others when the opportunity arises. The next time you're working with novices and their code, remember that you were a novice once, too. You could learn something - by teaching them.