Wednesday, March 12, 2008

Tech Republic: traits of good programmers (what hiring managers should look for)


Tech Republic has a “ten things” page hosted by Jody Gilbert, and today their blog has a column by Justin James in the category “Career Development”: “10 Traits to look for when hiring a programmer.” The blog link is here and there are plenty of message board responses. You may need to be a registered user of Tech Republic to see the content.

Most of the tips are rather obvious. Good “academic” skills are how I would summarize some of it. This is the stuff the “tests” in schools look for (and the awful “teach the test” problem for public school teachers). That is, basic “problem solving ability” in math, represented by those notorious “word problems” or “story problems” in Algebra I. (Isn’t that what a program solves? When you click on a buy link on Amazon, doesn’t the script have to work a “word problem” to compute your invoice?)

Another skill is reading speed and comprehension, out of programming areas. That sounds like it’s right out of grade school, doesn’t it.

Some more of the traits, like passion and “attention to detail” are rather obvious. Back at my first major mainframe job in financial applications back in the middle 1970s at NBC, my office mate used to mutter to himself “attention to detail” as we realized how critical every accounting closing would be.

Obedience (I use my own term here) is an issue, because programmers do tend to be “libertarian individualists” who believe their own ways of doing things follow the principle of Reason Magazine. But you have to obey policies rules (especially security rules regarding elevations and update access to production databases, and now, physical security of consumer data). Even libertarian think tanks like Cato have to have their internal “rules.”

The first trait, I discuss last, in “curiosity.” Back in 1999, when I came back to Arlington and went to work in a local office briefly during a family emergency, a “new soul” but longterm office mate said, “Bill, you have an astonishing lack of curiosity.” It was as if his idea of enterprising character was to download every widget and try it. Well, of course, that can be dangerous, and that can break company rules. (It could even then; only approved software could be downloaded onto personal desktops.) But this person had taught himself to run a Unix or Apache web serve off of a 386 in his own home back around 1993. You see his concept of “curiosity”? Where “curiosity” really comes in handy is in support jobs, where one has to research customer (internal or external) problem tickets, and delve into systems that one did not write and does not know a lot about; often it is difficult to “motivate” an approach based on the documentation that an organization provides. It sounds a bit like “motivating” a proof in a graduate school math course, or even figuring out how to integrate a bizarre function (partial fractions, perhaps) in second year calculus. Some programming training courses emphasize "curiosity", such as a PowerBuilder course where on the first day students were sent into Help in order to figure out how to do things even for the first time.

Perhaps we need a concept like "constructive curiosity" which aligns with "creative business thinking" which goes beyond code and into analysis and understanding of deeper business needs. For example, how to integrate new, market-driven methods of ad delivery in a shared-hosting computing environment.

No comments: