By czth in Op-Ed
Fri Feb 01, 2002 at 11:37:53 AM EST
Tags: Software (all tags)
What makes a developer great?
What's the difference between the developer that can write crisp, clean,
bloat-free - perhaps even, gasp, well-documented, tested, and robust -
code and a klutz who couldn't implement bogo-sort
without six wizards and a walkthrough?
No, don't give me the "I'm an MIS and while I may suck at developing, I can
kick your ass at brown-nosing and preparing insipid PowerPoint™
presentations, so there" line. I don't care. That's not what this article is
about, although despite the sarcasm I recognize that there's far more to
software development than coding (consider, for example, the description of the
Enabler in this
article). But here I want to focus on development, from design to
implementation but mostly implementation.
There's a great deal of difference between the bad (take a look at the hall of shame and
yes, this is from production code), the average, and the great. I've tried to
pinpoint these differences: what the bad lack and the great perfect and do
I'm a bit of a minimalization freak. Small code is good code, because
there's less to take in when it comes time to maintain it. As well as
compactness, this also means making things modular; like Unix tools, a function
should do one thing and do it well and do nothing else. If a function gets big
and complicated, break it into more functions, perhaps even its own class if
data needs to be shared between otherwise clearly distinct subproblems. Divide
and conquer. I've seen functions that were over 7000 lines long, and there was
no need for it. It's a maintenance nightmare, especially when the function is
"pure" C and all the variables are waaaaay back at the top of the
function (or globals). In my own code, I sometimes take "small" over "readable
to Joe Coder" but in shared production code, wizardry should be toned down a
little - or at least well commented.
Larry Wall (creator of perl, for which I will be forever grateful)
lists three virtues
of a programmer, which are dead on, and motivate many of the suggestions
in this article.
Traits of a good programmer
I don't claim this list is complete. I don't claim it's true for all good
programmers nor that all good programmers have all these traits. I do
believe these points outline what makes a good programmer, and I'm not just
theorizing, I've worked at a few different shops with a lot of different
people. But you may disagree, or think I missed the absolute greatest ever
trait of a good programmer: if so, I'm open to learn about it.
Despite ideas like pair programming,
most of one's time writing software is going to be spent alone. A good
developer needs to be one that can find things out for himself and is
self-managing to the point that he can work at a problem until it is complete.
No, you don't work in a vacuum; feedback is good, but developer's shouldn't
need babysitting. RTFM, STFW, ask co-workers; be self-guiding. If
a problem does come up, take initiative to seek out a solution rather than
to wait to be asked. Take responsibility and handle it well and you'll
be trusted with more (just be careful not to become
How? For the first area, write code. That's all. Pick a project -
address book, IRC client, rogue knockoff, draw a rotating cube, even if it's
been done a million times the creation of it can still help you learn.
Theory is good but there's no substitute for doing. For the second, make sure
when you say something is done, it is done, tested and handles anything
the user can throw at it. Reliability engenders trust, trust responsibility,
and so on.
Fitting closely with the previous point, the ability to learn new material
quickly is a must. I think the main difference between university and college
is that university is more of a place to stand while you learn to learn, rather
than passively been taught the latest soon-to-be-obsolete whizzbang technology.
Not that a programmer has to be a university grad, of course. The ability
to read and comprehend technical documents (such as RFCs) is a must. I picked up XS and
MakeMaker (the Perl C extension interface and build tool) in about an hour a
few days ago, by reading docs and tweaking examples. You should be able to
pick up a standard like ISO C++ and answer the issue at hand "according to the
scriptures" as it were.
How? Read. Learn by doing - although you may be able to mentally
go through example code, sometimes it's better to cut and paste it and give it
a run. Don't skip terms you don't understand; stop and look them up -
use google or try something like FOLDOC.
Doctors do it; lawyers do it; so do engineers. Pick something you're
good at and like, and become the local expert in it. This helps to set you
apart from the rest, which might aid in gaining (or keeping!) a job. Don't
just specialize in code; diverse external interests (for example, one of mine
is photography) also
mark you as someone with an interest in spending time to learn and to grow.
How? Just pick something you like and learn about it: search the web,
subscribe to periodicals, read news sites, talk to gurus, follow mailing lists
Equip yourself with a good set of reference books, from favourites like
Knuth, CLR (Introduction
to Algorithms, Second Edition, by Cormen, Leiserson,
Rivest, and Stein), and selections from the O'Reilly stable, to more esoteric
aids that you find helpful. Keep a good list of links, too, like this
invaluable C++ library
reference. I like to maintain my links on a local wiki; it's far more orderly than a long menu
of bookmarks, and easier to organize. As well, if you choose your terms
carefully you can find almost any algorithm described on the web.
As well as books, keep a library of code
snippets you use often. I just added template classes to return all
n-combinations or permutations of a vector<T> to mine.
When you write code, think with reuse in mind (see next point), and copy it to
a snippets directory or a wiki page. But don't reinvent the wheel... a Jedi's
power comes from the force that is already present within all life, that
is, the standard libraries present on every system. For C, libc; for C++, the
STL and the rest of the standard library; perl has CPAN, etc. If you're hand-carving square
wheels, you'd better have a good reason for it. Even before you learn the
library, learn the language - don't let me catch you doing something redundant
like if(pointer) delete pointer;!
Next, arm yourselves with good tools. Find yourself an editor you like;
if you like pico, I won't flame you (much); I use mainly vim and (at work) the Visual Studio editor, but I
also know my way around emacs. I
use perl a whole lot for code changes (usually as a filter through vim when
vim's own search and replace can't hack it), it's truly the "Swiss-army
chainsaw." Make is also good to know; I wish I could convert this VC++ project
at work to use it; most of the time, Studio is fine, but when you need power,
it fails utterly. I also find cygwin a lifesaver on NT.
Finally, your co-workers can be your greatest asset. If they've "been
there done that", and are willing to mentor you (and you do your part by
reading and experimenting for yourself and not pestering them with every little
problem you have), you can save a lot of time. These are the people you
spend about a third of your life with; it behooves you to get along with them,
to recognize their knowledge and when the time comes, be willing to give them
a hand too; even if you don't have much experience, sometimes a bug (like
writing if(i = 0) instead of if(i == 0)) just needs another
pair of eyes.
How? Experiment with various editors and other tools. Teach yourself
perl; it's structured so you can learn a bit as a time as you need it. When
you notice yourself repeating something, especially a mundane task, ask
yourself if it can be efficiently automated (the fundamental question of
computer science). And talk to your co-workers, go out for lunch with them, tell jokes; it may not come as naturally to you as some, but work at it; as this article reminds us, life is about people, not machines.
It's amazing how much duplication bad and average coders do in code.
coding becomes a maintenance nightmare when you need to make a change.
Refactoring is key. Cut out
whatever is reduplicated and make it a function, inline if you're
worried about efficiency. This point is critical. I have had to work
with 20,000 line files that could probably be refactored to less than a quarter
of that. Design for reuse - although, as XP (see next) mandates, don't
write code you don't need.
How? Reading code helps, although perhaps this is one of those
"either you have it or you don't" skills (just like, I am told, there are
people that don't "get" pointers; which is sad). Those with a strong
mathematical background should be good at it too. And make sure to get hold of
Patterns, one of the canonical works on the subject.
Software development, in general, scales poorly (Brooks, The Mythical
Man-Month). Even recent open-source developments have hit
By being familiar with using and implementing an arsenal of development
"meta-methods" such as these, time can be saved, errors reduced, and efficiency
Source control is required. CVS is probably the most common. Having a
central repository makes code-sharing easier, allows easy viewing of changes
and project history, extraction of previous versions, and acts as a backup (but
the CVS server itself should still be backed up). Such a repository also aids
in doing automated daily builds of a project; it's quite easy to write a perl
script (or find a tool on freshmeat) to
check out the files to a build server, and have it report errors to a web page
or even email them to the last person to check in the file. The next step is
automated testing. Two good sources for software methods and ideas are Extreme Programming (XP), and Joel on software. Don't throw the
baby out with the bathwater, however! Rather than "XP says to do pair
programming, and we can't do that so forget it", pick and choose the parts of
it that will help your individual situation.
Another important point is to know and keep in contact with the client
(user). If you ask your boss, "How is this going to be used" and they don't
know, find out. A programmer is often the worst person to make
usability decisions about their software - we like solutions that are
"interesting" to code, elegant, and tunable to the nth degree; the real world
isn't always like that.
How? You may have to just go at it yourself: if there isn't a build
server or source control, install it on your machine or scrounge an older
unused machine, and convince your co-workers and boss of the advantages;
it will become an integral part of the process on its own merits. Be
eloquent, if people want studies give them studies. Make it convenient
for people to use (e.g. daily build results on a web page, or set up a CVS
client for them).
I don't care (much) what your coding style is. Just be consistent. If you
want to prefix your globals with g_ and members with m_, be
my guest; if you want to use Allman or the one true brace style, take your pick,
just keep on doing it. But, if you have the liberty, try to get some
minimal naming and formatting conventions - nothing draconian - established for
a project. Where these don't exist, my rule of thumb is that a module's style
is dictated by whoever wrote the most code for it (usually the creator).
If you're counting sheep, call it sheep_count or num_sheep
or uiNumSheep or NumSheep or numSheep or even, if
you must, NUM_SHEEP, just make sure you enumerate cows the same way.
Be able to defend your choices.
Document whatever you think the average programmer working on a
project won't understand. If you comment to the level of the bad programmer
your code will end up completely encrusted with comments, and assuming the next
person to work on the code (yes, I know it's absolutely perfect in every way,
but hypothetically) is a wizard is a good way to get your code thrown out (and
you with it, no matter how clever it is. I'm trying to wean myself off this
practice, by sporadically showing people code and asking them about it).
Separating code and documentation (except for higher level overviews and
algorithm descriptions) is a bad idea; for the same reason cutting and pasting
code is bad: I probably won't remember to update in both places. Make it easy
How? Develop good habits, and use them. Write a description of your
coding style - naming conventions, indentations, when and where you comment, to
get it clear in your mind. For example, I write a comment at the top of a file
to describe what it does (but I use CVS to store the change log), at the top of
a function to describe inputs, outputs, and, in high level terms, what it does,
and at the top of a block of code if it is at all complicated. Pretend you've
been given the code and told to fix a segment fault when the user clicks the
Whizbang button, and ask yourself how easy it would be to find the code.
A good command of language - the human variety - is essential if you want to
be more than a code grinder. Unfortuantely, we developers aren't renowned for
our powers of expression. And we do have to write: clear code, descriptive yet
succinct comments, and, at least in my experience, most of my bosses want
documents on whatever part of the system we're modifying - how it works now and
proposals for how to effect the changes we want. With (horrors) real sentences
and paragraphs, not just strung together haphazard but with some sort of
coherency (how dare they?!)
I was fortunate in that I grew up without a TV (since we would only have
been able to get four channels, I wasn't missing much), so I read a lot; to
that I attribute a fairly good command of the language (E&OE). I also got
involved with my school paper and
have done a lot of writing on my site.
If don't think your writing or presentation skills are up to par, take
some English courses - as electives if you're in school or enroll in a
night course at a local college otherwise. They'll be valuable to you and make
you more valuable. I used to be shy, I wouldn't say I am any more, but
when I'm nervous I stutter. The key for me in presenting to people is knowing
my material cold: no more nervousness, and everything goes smoothly. And you
have to present things to people all the time, formally or informally: a problem
with code to a co-worker, a idea to improve the project to your boss, even
telling a joke. And remember that you have to know the rules to break them :).
Some consider grammar and spelling, especially online, to be irrelevant: if
you can understand it, hu karez how its speld (and note I'm differentiating
between typos and not knowing how to spell or form sentences)? To me, a
spelling or grammar error is like a bad taste in the mouth. It says that the
writer doesn't know or care enough to even ensure that the materials that
compose their argument are sound, and, sometimes not even intentionally, I
place less value in the argument. The medium is the message - trite, true.
And if I reject bad writing, how much more, then, are those who
professionally deal with documents daily?
In the same presentation vein, to communicate you want to understand your
audience. I joke about managers being lion food, but I talk with my manager and
understand his deadlines and requirements, and what his superiors
need from him: a programmer that is interested in and respects his
superiors (and co-workers)' goals is a valuable asset, because they're focused
on a bigger picture than writing "fun" code and trying to convert the company
If this is the biggest section, it's because people and communication are
the biggest neglected area for programmers. Give and ask for frequent
feedback (don't wait for reviews). Be the exception.
How? I sense a theme in these "How?" sections, and it's go and
do. Same here: practice. Talk to your mirror if you like. Write a
proposal for redesigning your home page. Whatever. And get as much feedback
Your code will have bugs. Being able to quickly hone in on the
location, fix the bug, and then write code to ensure it won't happen
again is a mark of a great developer. Assert liberally, it costs nothing
in a release build. Can't happens do and will. Know how to use the
debugger for your platform (Visual's integrated debugger, gdb, DDD, dbx, etc.).
In some cases you may have to resort to more primitive means, such as
"comment-jitsu", commenting out portions until the code works, especially for
(internal) compiler errors, or sprinkling debugging print(f)s in the code
(however, even debug statements can throw off the timing of something sensitive
like an OS, leading to nasty Heisenbugs).
How? It's an art form developed by practice. What, you expected me
to put something different this time? There is no magic pill. Read
your debugger's man page or look at the VC++ menus; learn how to watch and
examine variables, set (conditional) breakpoints, examine the call stack.
I don't mean jump-up-and-down pep-rally type. Just that if you want to be a
good programmer it'll take time. Your own time, usually, because it won't
often be the direct result of doing the letter of school assignments or the
sort of quantifiable self-improvement that you can count as "work." You have to
keep current in your field, just like any other, whether it's by subscribing to
magazines (like C++ Users Journal or Dr. Dobbs) or reading news
sites. You have to have the kind of attention to detail that can debate and
defend what operator+() should return, when to use const, and
design choices (yours and others'). The sort of thing they say introverts
(INTJ or INTP on the Meyer-Briggs
personality test) are good at, if you're into personality tests.
In short, it won't work if it's just work.
Now, I'm not advocating you abandon humanity and sleep in favour of coding,
although a short period of that - often referred to as larval
stage - is reputed to be beneficial (no comment). As I've already said,
diverse interests make you a better person, never mind a better developer. But
I can talk shop all day, if people let me, and my non-coder friends know that I
like to do 16 push-ups during commercials because "it's a nice round number in
binary." My most recent project is to set up a site for helping me organize and show
to friends photos taken with my digital camera, using a short custom PHP
How? Wait for inspiration to strike then code like a demon (daemon?)
Seriously, though, you need to develop (no pun intended) an interest in
how computers work and "what can be efficiently automated" and hone your
skills through practice.
Despite all that has been mentioned, is there still a "je ne sais quois"
that "hackers" have? Unquantifiable, it cannot be found, but rather finds you,
an innate wizardliness? Or can anyone, if they want to, become a wizard? Me,
I like to think the latter, but fear that the former is true.
So what's my point? Just elitism? I hope not, since there's already enough
of that going around. I think the first point is: there is a difference, a
big difference between the bad, the good, and the great. If you're a
programmer, you can use this list as an informal self-test. If you're hiring
programmers, this gives you some idea of what to look for, rather than
asking questions about what sort of tree I'd be if I was a tree, which I
patently am not. (You might be surprised at how few employers actually get
prospective hires to write code; I've been through hundreds of interviews for
co-op and not many did. Sure, it's
good to get an idea of how people think and solve problems, but it's nice to
have some concrete examples of what the employee will be spending most of their
time doing too.)
May you be a worthy representative of your profession, whatever it is you do.
 I'm going to use the male pronoun. Deal.
 I'm sick of all these disclaimers. But if I don't throw them in then
someone will tell me e.g. university isn't necessary to be a good developer,
and they know so and so who worked at McDonalds / attended DeVry / whatever and
then one day saw the light and overnight became the best developer in
the world and is now working for $BIGCO and making $BIGBUCKS. Maybe it
happens, but it's the exception, not the rule.
 Interestingly, practitioners of these professions are regarded as
"professionals" while developers are not. Why not? Well, in part because
Computer Science is a relatively young discipline, and also because a lack of
regulatory bodies (compare the P.Eng. designation for engineers). We need an
equivalent P.Dev. (Professional Developer) examination as part of our
discipline's maturing process.
 Kudos if you caught the irony.