Linked by MOS6510 on Sun 5th May 2013 22:43 UTC
General Development "In order to be an effective programmer, you need to possess a combination of traits that allow your skill, experience, and knowledge to produce working code. There are some technically skilled developers who will never be effective because they lack the other traits needed. Here are seven traits that are necessary to become a great programmer."
Permalink for comment 560634
To read all comments associated with this story, please click here.
Trait Zero
by hhas on Mon 6th May 2013 12:14 UTC
Member since:

I am disappointed but not remotely surprised the article failed to mention the most important trait of all:

0. Willingness and ability to learn, understand and think about your users' problem domains firsthand.

I am no great technical programmer, but one thing I do make a point of doing is to sit down with users and learn about them and their jobs: what they do, what they know, how they think, and what their duties, liabilities, concerns and desires are. While I could never do their work anywhere near as well or fast as they could, I consider it my basic responsibility to know enough about their work that I could muddle by at least at intern level and communicate with them in their own language. "Stepping into their shoes and walking around in them," as a wise, if fictional, commentator once put it.

Once I can think about users' problems as if they were my own, I can apply my own analytical and coding skills to creating solutions that they couldn't produce themselves. But just because that's my own area of expertize doesn't make theirs any less important or less deserving of attention or respect. If anything, it's the opposite: they are the ones who actually make things and do things; my job is merely to facilitate that.

So it shocks me how many professional developers seem content to sit at their desks all day every day, churning out code with no personal understanding of how that code will integrate into users' lives. I appreciate that management cultures obssessed with internal politicking and buck-passing tend to create isolationist silos that confound such communication and collaboration, but a lot of developers seem to embrace the arrangement. These professional "problem solvers" and "solution builders" would rather live their whole life in some self-imposed Skinner Box, never touching the world outside. Sitting with users ("lusers") is often seen as a menial, dirty task and quite beneath them: the responsibility of BAs, QAs, managers; anyone but themselves.

These same programmers get upset and angry when end-users complain that their provided 'solutions' fail to address the problems they actually have. Yet they are as much the architects of their own failure as anyone. A coder who only knows how to code is about as much use as a manager who only knows how to manage. The former [rightly] aren't shy about criticizing the failings of the latter when they are the ones on the receiving end, but perhaps they should perform the same analysis on themselves sometime.

Reply Score: 5