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.
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.
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.
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.
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.
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.
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.