By V. Berba Velasco Jr., Ph.D.
As published on goarticles.com
and www.articlecity.com. Copying of contents, in whole or in
part, is permitted provided that the author by-line is kept intact and
unchanged. Hyperlinks and/or URLs provided by the author must remain active.
Over the years, I’ve paid a lot of attention to how companies
recruit computer programmers. During
that time, I’ve noticed how managers frequently make hiring decisions that seem
to make sense in the short term, but which result in long-term chaos.
I’ve seen the kind of havoc that this can wreak, and how devastating it can be to the company’s future.
I’d like to say a few words about that today.
The companies that I’ve observed typically pay attention
matters such as industry backgrounds, years of experience, and so forth. They
want to know what types of projects the applicants have worked on, which
compilers and operating systems they’re familiar with, which communication
protocols and software packages they’ve used, and so forth.
Many also want to know about the employee’s work ethic and personality, but in the end, the hiring decisions
frequently boil down to the employee’s work experience and how much training
that person would require.
All of those are important, sensible considerations.
As I observed these companies though, I noticed that most of them—about 80% or more—paid little or no attention to
whether the applicant had a clean, readable programming style. They
were deeply concerned about whether the applicant could get the job done, and
didn’t seem to care much about whether their software could be easily
understood and modified by others, years down the road.
To some extent, this is understandable.
After all, the immediate goal of
most companies is to develop working products that they can sell. What
many forget, however, is that they are supposed to be marathoners, not
sprinters. They need to think more
in terms of finishing the entire race, and less in terms of achieving
short-term victories.
It also betrays a certain naivete about the immediate damage
that can result from poor programming style.
After all, even the best software is rarely bug-free. A programmer who
writes clean, legible software will be able to debug his own work more reliably
than someone who writes patchwork code.
The latter may arguably provide fixes more quickly (and even that’s debatable!), but the results will be
unreliable—and when time is short, that’s a luxury which companies cannot
afford.
Employers should also remember that good programming style is
not something that’s easily taught. Any
competent programmer can learn the mechanics of language syntax and function
calls; however, someone who understands little about the artistry of structured
programming or proper object orientation is unlikely to master these things on
the job. I’ve seen this happen (or
rather, fail to happen) time and again. This,
despite the abundance of books and journals which discuss this matter at great
length.
I also think that companies should pay greater attention to
the prospective employee’s technical writing skills; after all, external
documentation (e.g. user manuals, design documentation) can be critical to the
software’s maintainability. Besides,
in my experience, programmers who write well in English are more likely to
write software too. And why not? Programming
languages are ultimately just that—languages. Someone
who can express himself well in English is more likely to communicate clearly
and effectively in his source code as well.
For these reasons, I urge any company that’s hiring a
programmer to ask incisive questions about an applicant’s coding style. How
does he name his variables? How
many lines of code should a function occupy? Does
he use global variables, and if so, when? What
kinds of books has he read on programming style? Ideally,
companies should also ask for samples of an applicant’s source code and
technical documentation, to verify that these lessons are put into practice.
This takes a little extra effort, but it can help a company avoid sacrificing long-term success for the sake of
dubious short-term gains.
About the Author:
V. Berba Velasco Jr., Ph.D. is a senior electrical and
software engineer at Cellular Technology Ltd (http://www.immunospot.com,
http://www.elispot-analyzers.de,
http://www.elispot.cn) where he serves with great pride. He has seen
how proper attention to software usability, maintainability and elegance can
spell the difference between mediocre products and great ones.
