Employers should also remember that good programming style is not something that’s easily taught. Any competent programmer can learn mechanics of language syntax and function calls; however, someone who understands little about artistry of structured programming or proper object orientation is unlikely to master these things on job. I’ve seen this happen (or rather, fail to happen) time and again. This, despite abundance of books and journals which discuss this matter at great length.

I also think that companies should pay greater attention to prospective employee’s technical writing skills; after all, external documentation (e.g. user manuals, design documentation) can be critical to 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 sake of dubious short-term gains.