The key to being a good programmer
One blog topic that never seems to get old is what makes a good
programmer, or how to be a good programmer, or what you can do to be a
better programmer. The same activities are often listed as being the
path to successful codesmithing, when really it is just the method by
which the true magic happens. With programming, like many things, it
isn’t what you do, it’s what you learn from it and the only key
ingredient to being a good programmer (besides practice) is exposure to
programming. Exposure comes in many forms, whether it is through
hands-on practice or looking at someone elses code. Here’s a few of
typical examples given and how it exposes us to programming.
Work on projects outside of the office
Working on your own projects outside of work lets you practice
programming and exposes yourself to your own code. It also lets you
practice problem solving and gives you the opportunity to experiment
with alternative solutions. Also, a number of times I’ve gone back and
re-read something I wrote and found better ways of doing it. However, it
needs to be mixed with exposure to outside code so you don’t just keep
yourself in your own rut and writing the same code with the same
Works on Open Source projects
Not only does this give you more practice but also the ability to
work on other people’s source and see how they code their way around
certain problems. It also gives you exposure to the build and testing
processes which are tools than that help improve your skills. Usually,
in the case of libraries, you don’t even need to work on the project,
you can be exposed to some of their ideas just by using the API.
Knows multiple languages
Working with multiple languages does give you exposure to different
ideas and ways of doing things, but in itself, doesn’t make a better
programmer and can even be detrimental. A native English speaker may
improve their vocabulary and be exposed to different phrases by knowing
French or German, but it doesn’t make them a much better English speaker
or writer. Flip that around and a native French speaker is going to
give a better speech than an English speaker who picked up a bit of
French. Similarly, a hardcore Java/c#/C++/Delphi guy is going to be
better than someone who dabbles in it.
It could be argued that it is obvious that getting more experience leads to being a better programmer, but not so. Solitary practice and accumulation of personal experience may get you so far, even gets some people very far, but for most, external exposure is required to drive new experiences and learning whether it be writing code, drawing pictures or playing the guitar.
Joel Spolsky wrote that good programmers are smart and get things done which also happens to be what makes good lawyers, doctors, accountants and applies to just about every other profession. Obviously being smart is a good thing, but that will only take you to the point where you have to sit down and write some code.
Passion is often stated as a requirement for being a good programmer,
but it is just a means to an end. In itself, it doesn’t make a good
programmer but can be the fuel that drives the activities that do
improve your game. I’ve known a number of capable (not great)
programmers who have little passion for it, they enjoy it, but it is
purely a 9-5 job for them. The lack of passion shows in that they are
content to just use existing skills without spending any time learning
new ones or exploring the technical ecosystem available to them.
Try and expose yourself to as much code as possible, even bad code can be good for you as long as you aren’t copying it. Identify design patterns and more importantly, think about why those patterns were used over other patterns and what possible consequences are there of using that pattern. Learning the thinking behind other architectures will help when the time comes to make your own decisions. After all, when we get stuck as developers the first thing we do is Google it to see what someone else has done. This is just pre-emptive research!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)