Software Development optimize

10 traits to look for when you're hiring a programmer

Programmers come with a wide range of skill sets, hail from many countries and cultures, and can have differing backgrounds and experiences. Nevertheless, certain qualities can mean the difference between a great programmer and someone who's not so great. Here are 10 things to look for when you're hiring a programmer.

Programmers come with a wide range of skill sets, hail from many countries and cultures, and can have differing backgrounds and experiences. Nevertheless, certain qualities can mean the difference between a great programmer and someone who's not so great. Here are 10 things to look for when you're hiring a programmer.

Note: This information is also available as a PDF download.

#1: Curiosity

Great programmers never accept things "as is"; they need to poke deep inside something, even when it appears to be working fine, to learn more. This is how many problems are solved before they are problems, and it's usually the quickest way to fix acute issues. A programmer without this mentality will usually end up lacking the knowledge underlying why they are doing what they are doing, which means they're working with blinders on. Unless candidates are very shy, their curiosity, if they have it, will show strongly during interviews.

#2: Clear thinking skills

It may sound obvious, but programming is an exercise in logic. People who can add 2 and 2 to get 4 are common, but people who can take "2 + x = 4" and figure out that "x" is equal to 2 are much less common. This is why I have always preferred programmers with strong math or science backgrounds. It makes them a bit better at programming, but more important, it generally indicates good logic skills. When I discuss the job, I sometimes leave blanks in what I'm saying to see if the candidate can fill them in. In addition, if your hiring process includes formal testing, that's a good time to test logic skills.

#3: Top flight reading speed and comprehension

Another "duh" when it comes to programmer productivity is that most of their work is not the typing of the code. A significant portion of a programmer's day is spent reading, whether it be other people's code, Web sites with examples, documentation, or project specs. Programmers who read slowly, or worse, don't understand what they're reading, will be inefficient at best, and dangerous at worst. You probably don't want someone on staff who misreads the spec and spends three weeks doing the wrong thing; that's just embarrassing when you need to explain the delay to the project sponsors. It's really hard to gauge reading skills during the hiring process unless you use a formal testing process.

#4: Attention to detail

Attention to detail is a close cousin to curiosity. A programmer who pays attention to detail will be significantly more productive than one who doesn't, all else being equal. It is, unfortunately, extremely difficult to measure this quality during the hiring process. Still, sometimes things happen during the hiring process that show that a candidate has this trait. Maybe it's a casual remark or just a minor incident that occurs during the interview.

For example, I once had an interviewee casually compliment me on my shirt and mention that he was a fan of that designer; that spoke volumes about his attention to detail (as well as his fashion sense). And of course, a severe lack of attention to detail can sometimes be obvious too; the candidate who walks in with pants unbuttoned or toilet paper stuck to a shoe clearly is not paying attention to detail!

#5: Quick learner outside of programming

Unless your company develops programming tools, like compilers and IDEs, your programmers are working with projects outside the realm of programming. Just as journalists need to understand a little bit about the subjects of their stories and good teachers need a working knowledge of the field they're teaching, good programmers are able to learn about the environment their software will work within. Of course, you don't need a CPA with a computer science degree to work on your accounting software, but a programmer who can't understand the basics of the math and business rules involved is going to be a liability.

I take candidates I'm seriously considering on a tour of the facility and provide a brief, simple, jargon-free overview of the company and how it works. Candidates who ask pointed questions that show they understand what I'm talking about, or who otherwise show comprehension, get extra credit in the overall hiring decision.

#6: Self-learning skills

It's extremely rare for a programming shop to have the budget and time to provide training to its programmers. This is unfortunate, but it's a current business reality. The result is that most programmers self-teach their skill sets (ideally with a mentor handy) once their formal schooling is over. Programmers who are good at self-learning are going to be better at programming.

During the interview process, I like to ask questions such as, "How did you learn to do that?" when the candidate talks about something difficult, or, "How do you get new skills?" and "Do you read any programming-related books, magazines, Web sites, blogs, etc?". Candidates who aren't just capable but who are eager to teach themselves new programming skills are much better to have on staff than those who don't like to learn outside a formal training program.

#7: Passion

Some programmers are "daycoders" -- people who write code 9 to 5, Monday through Friday, and do not think about it in the slightest outside of those times. That's perfectly fine; not everyone can be a super geek who lives and breathes code. I have hired people like this in the past to fill a gap or to work on the sections of a project that are routine. But when I need to hire a top programming candidate (regardless of skill or experience level), I need to be hiring someone with a passion for the work.

Passion is a "make or break" during crunch time or on a project that requires tricky techniques, rare skills, and so on. After all, daycoders won't be motivated to learn the best way of doing things and will instead just do what they've always done, which may not be the best way of doing things. Daycoders are also difficult to retain without a steady stream of raises and a high level of perks, since they are there for the money, not for the work. Passion will be fairly obvious during the interview. Candidates who get excited when you talk about your project or who are talking about their past projects have it for sure.

#8: Adaptability

Have you ever worked on a programming project that ended with the same specs it started with? Neither have I, and I am including short projects that lasted less than a day! Programmers who do not handle change well will probably not be very successful, except on long-term, Waterfall-type projects that last years, usually under government contract. That is not to denigrate those kinds of projects or programmers, of course. But most projects are simply incompatible with a lack of adaptability.

It's pretty obvious during interviews when candidates are not adaptable or handle change poorly, particularly if you ask questions like, "Did the requirements change often?" Candidates who say something like, "Sure, but that happens on all projects and it's a fact of life" are winners. Those who roll their eyes and respond with, "Yeah, that's why I could never get anything done!" probably will not be a good fit for most environments.

#9: Good communication skills

"Communication skills" doesn't mean the same thing as "Speaks perfect English." It means, "able to convey an idea accurately and effectively." Pictures, sounds, and hand motions are all part of communication skills. Programmers who have a hard time getting their point across or understanding what others are trying to tell them will not be effective in the long run. This is a difficult ability to properly measure in a phone interview, but when candidates have difficulty communicating even in a face-to-face interview, you can be sure that they'll have a hard time on the job as well.

#10: Who's the boss?

Programmers are a notoriously independent group of people. Indeed, I believe that's one of their strengths, and it's great not having to micromanage people working on technical projects. However, a good portion of programmers struggle with the idea of "I am the boss and you are not." I know, it sounds tyrannical. In a way, it is. Managers often need to make decisions for nontechnical reasons, and they may not be able to explain those reasons to their team (secrecy, politics, not enough time, etc.).

A little bit of pushback, particularly on bad decisions, is something I encourage and fully support, especially if the boss doesn't realize that it is a bad decision and if the feedback is delivered correctly. But when the boss says, "I know from the technical perspective this is a bad idea, but this is how we need to do it," it's final. All too often, certain "rogue coders" will ignore their marching orders and go do their own thing. Even worse, they have a tendency to run their mouth to anyone and everyone about how stupid the boss is, and how he or she obviously does not understand programming -- which may or may not be true. This sinks projects and does nothing but cause animosity and hurt team morale.

This mentality can often be seen during the interview process, especially when you're asking about past work experiences. Rogue coders love to talk about their "evil, idiot, pointy-haired slave driver" former managers, even when it is wholly inappropriate to do so, like in a job interview. Well-adjusted programmers will say things such as, "I disagreed with some of my manager's decisions at a technical level, but I know that those decisions had to have nontechnical issues factored into them."

About

Justin James is the Lead Architect for Conigent.

130 comments
ukikM
ukikM

Ugh... I am an experienced programmer and what I have just read sounds like a teenage girl looking for a dreamed-of prince on a white horse. Ok, there is a promile of them who do find one but majority do not. Why? I have worked for guys like you and companies with such a attitude (Ok, maybe You just sound like but.. others..). In 99% they suckkk... they are like "You are great, ingenious" and they mean "but you are my mouse extention who can think when I say so". What they retrun for it is just a laugh because of which a motivation for doing the job is just going down. I have recently quit the job of programming because of such attitudes. Now I do completely different thing and I do programming but.. only with serious people with a brain on its place. 

Ok I understand the reality of the business.. I know clients are like but.. we are not automates whom you stick a joystick or a pad in a**, next you put some coins and.. off you go. And this above looks like a recipe for a one. It is just a wringing of a sponge out of whatever is valuable in it to get a new one and it again. That's how I see the business from a distance having quite reach experience, seeing other fellow programmers and being quite good in the job. 

Now you wonder why is it a tough task to find a good programmer? Most of them I know are fed up with it.

I just wanted to share it with you.

joycehays
joycehays

Question: What/where is the best source to find these top programmers?

joycehays
joycehays

Excellent article. Question: What/where is the best source to find these top programmers?

batya
batya

I won't hire the one who says they developed 7 systems in 2 years - they didn't stick around long enough to see if the systems worked.

me
me

The passion thing -- I'm passionate about code, but still live 9 to 5 coding life, except in emergencies. Just balancing life and work. But if I have only a few things to do, I'm sure I'll code well beyond my work hours.

darren_1065
darren_1065

That new management position is looking pretty good right now. :)

mick
mick

As someone who tried Engineering, then did Politics and Philosophy before turning to Accounting and Computer Science, I think you're restricting your pool of talent by preferring Maths and Science graduates. Of all my studies, it was Philosophy that taught me most about how to think critically, how to analyse and look at a problem in different ways. I've seen the same skills in other Arts graduates too. These are often people who have gone to university to study something they are curious about, something they have a passion for and something that gets them thinking in different ways. They (like I did) will probably find it hard to find someone willing to pay them to sit and think all day, so the next best thing is to be a programmer.

ramdhavepreetam
ramdhavepreetam

hii i really liked u r post but i have little dought abt Attention cause some geek programmer are never care how the look or toilet paper is attaching to there buut . but in programming they are really good .

emmetor
emmetor

Interesting, but you failed to quantify or qualify the visual thinking skills necessary to be a great programmer. Those were masked somewhere under the slightly more boring life skills bit. It takes someone with significant visual intelligence to create the best solutions. The auditory intelligence is for the detail. Great Programmers need imagination. Engineers, not so much. Architects vs Engineers, I suppose. You got the 'auditory' and logic skills nailed down, but I expected you would. And you underestimated the visual skills, but I knew you'd do that too, because the auditory is stronger with you, therefore you value it more, I'm guessing. Obviously most people are mixed dominant, - a mix of different types of thinking, BUT, probably you haven't considered that the dominance piechart of different parts of the brain would change depending on the task at hand, or the "granularity". Some highly logical people just cannot cope with a computer, and get extremely stressed. Similarly, some spaced out visual thinkers are unable to run their lives at a high level, but are born to write code, because they have the ability to apply deep logic, but don't like using it in real life, where it becomes a hindrance. So, often, that (proper) logic is skipped in favour of more goal-oriented logic. Anyway, I shouldn't really be typing this, please don't analyse this post for structure, because it doesn't have any, unlike my software! Hope my rants help.

chasAFD
chasAFD

It's very important for a programmer to take personal pride in their work . Any craftsman knows that true quality work oozes pride, whether you're building cabinets or code. I believe this is more important than passion, and they are distinctly different things. And pride is easily detected during the interview process.

Dr Dij
Dr Dij

in addition to attention to detail, attention to testing. We've had programmers who whip something together, shove it out for end users without much of any testing and assume that 'they wrote it, it must work correctly'. Doesn't matter how smart you are, you need to test it. Also an ability to simplify user interfaces. the easiest / clearest way possible. Look stuff up from files if you can to avoid some inputs. Validate some of the inputs against database tables before you commit to updating or running that report or process. AUTOMATE repetitive tasks; e.g. if your program processes lots of files, have it write a database table to show it was run at the end. and don't show that file next time. Move stuff to archive automatically. If you can delete files older than X # of days automatically do so. Email people with notification that stuff ran if it doesn't have a log / monitoring console. Don't give end users what they want: give them what they need - e.g. writing a report or data extract, you know that in the second round they'd ask for xx field also. add stuff they'll need unless it is something where exactly that data is needed for another system. Know the databases you are working with and what's available (in general and for the above reason). Cross check all data extracts another way, e.g. browse the tables with winsql or access, or in the ERP system your company is running to make sure things add up. put in traps for values you shouldn't have, while testing. data is often modified by flags in dift fields, i.e. it means something else or is not wanted on the report if a flag is a certain value.

Justin James
Justin James

Thanks, glad you liked it! For me, I've found that the best developers come from referrals. Most recruiters pull from the same pool (Monster, Dice, CareerBuilder, etc.), the big difference is how good they are at pre-screening the candidates, and how good they are at the "people skills" part of it (do they call back quickly, do they annoy the candidates, etc.). If you are looking for inexperienced programmers, I'd suggest that you make connections in the CS department of a high quality college and have them feed you the best students. J.Ja

Tony Hopkinson
Tony Hopkinson

is going to happen to IT in five years time, shouldn't program anything. They have future with those tea leaf readers at Gartner, though. Cover 100% of all cases in a protocol stack... Well now we are back in this galaxy, here you go Try DoSomething() Catch Console.WriteLine("Unknown OLE Error (5)"); End; You can't argue with success.... If you mean getting the guards in your conditions right well, yes. The rest, well those guys already have jobs, they listen to prayers and move mountains and stuff.

jmgarvin
jmgarvin

Too true. I think my favorite is when you are asked why your API doesn't have hooks for every product under the sun. Ya, I'll get right on that...

SObaldrick
SObaldrick

How necessary is it today for programmers to understand 2's complement arithmetic? When I was programming it was essential. We did most of our code in assembler. I remember my first interaction with a contractor in the workplace. I had to sit with him and teach him how to add and subtract using 2's complement arithmetic. It was at that time that I discovered that contractors get paid more than full-time employees. A little demoralising, Les.

Tony Hopkinson
Tony Hopkinson

that took ten minutes. I'd be looking for the catch. :p Course in OO it's easy anyway FizzBuzz fb = new FizzBuzz(0,100); fb.Execute(); Snigger. Or even new FizzBuzz(0,100).Execute(); Or to JJ's horror a static class FizzBuzz.Execute(0,100); Good test though.

dougbrong
dougbrong

1. a member of a band of irregular soldiers that uses guerrilla warfare, harassing the enemy by surprise raids, sabotaging communication and supply lines, etc. [Origin: 1800?10; < Sp, dim. of guerra war (< Gmc; cf. war1); orig. in reference to the Spanish resistance against Napoleon; the name for the struggle erroneously taken as a personal n.]

Justin James
Justin James

Plus, few of the systems were big projects, few companies specialize in projects that last 2 months or less. Although, one employer I had specialized in "short order programming", I had quite a number of projects that went through a full lifecycle in less than 1 business day, and the longest project was 3 weeks from beginning of definition to delivery into production, with 3 months of maintenance after that. And the projects tended to involve juggling tens of thousands (if not more) dollars, so accuracy was quite important. I learned a LOT at that job. J.Ja

Justin James
Justin James

I agree that there are a lot of courses outside of math and sciences that teach good logic skills. I also agree that Philosophy is one one them. I certainly don't restrict the candidate pool to math/science people, but I do give them extra points. The general rule of thumb for me is that studying (formally or informally) something that requires logic skills (math, science, philosophy, music, etc.) as opposed to other skills (phys. ed, MBA, communications, painting) is going to not be a deal maker/breaker, but be a bit of a bonus to someone in the final decision. J.Ja

Tony Hopkinson
Tony Hopkinson

with what you are thinking about. I'm not sure that philosophy and politics are inherrently logical though. Both tend to operate off unstable foundational assumptions. Maths and engineering do not obscure the assumptions they make and purport them to be facts. Any assumption is explicitly identified. In programming it's assumptions that will kill your ass.

Tony Hopkinson
Tony Hopkinson

support them. They are very good in areas where the problem is clearly defined and the scope set in stone. Given that in the main neither of those things are true in business coding, they turn out to more costly than a less skillful coder who realises he's coding the wrong thing.

Justin James
Justin James

It is odd, I learn quite well via both audio and visual means, but I am fairly poor at expressing myself visually (I always wanted to learn to draw or paint, but I could never get past stick figures) but verbal/written I am (I think!) quite good. So you are right, I probably do have a built-in bias to the audio skills over the visual skills. J.Ja

Tony Hopkinson
Tony Hopkinson

That's like saying only people who use yourdon are great programmers. I rarely think visually, mind you I don't describe myself as a great programmer either. I 'forget' true false as much as any other c**t. Any model of a problem is an abstraction, how it's visualised is neither here nor there. Some techniques lend them selves better to particular problem domains, but to say one beats all the others, is to become some mumbling academic who endorsed the next piece of shelfware.

TheGooch1
TheGooch1

Its great to be proud of your work, or at least to desire to create productions that you are proud of, however, unless you are in charge of everything, you may get cut down for taking the time to make things "too perfect" or do "too much testing" ( actual quotes from my management ). Most of what I do is for internal use, and my manager won't get credit for delivering ( notice that I am not in this picture ) until its delivered. Quality is not as important as delivery, and I have been criticized for making an application too stable, or too flexible, or too user friendly. Often I'll write an app, and then start designing a gui to make it easy to configure ( most of my apps use XML encoded config files ), but that is generally pre-empted by another project they have for me, and never gets done. Sigh, reality bites.

Justin James
Justin James

Mentally, I kind of roll that up under the "passion" header (hard to have pride when you don't care!), but it is great that you put it explicitly too. :) J.Ja

Tony Hopkinson
Tony Hopkinson

Once I've got past the interview process, I've had to swallow alot of it. Oh well, just putting the finishing touches on nasty kludge 35,452....

Justin James
Justin James

Those are all good! All of those items are higher order conceptual pieces ("how do I test this to check all of the edge cases?" in particular) that will never appear on a resume, but can definitely come out during an interview, and help separate the really good coders from the not so great coders. J.Ja

Tony Hopkinson
Tony Hopkinson

They rarely know what they want, and so we rarely know waht they need. If there's one place where design quality regularly goes straight down the pan it's UI. Quite often all the i's are dotted and t's crossed on that as the 'important' (read visible) bit, then some poor twat of a developer has to make it fit the need.

Justin James
Justin James

... but part of me has *always* wanted to work for a think tank or market research institute. It seems so awesome. You get paid big bucks to theorize, but if you are ever proven wrong, no one cares because they don't remember the prediction, and you'll just blame someone's implementation of your idea anyways. It's like being a weatherman who doesn't have to be right even some of the time. Or like being a blogger who has the comments turned off and somehow makes a killer living with an amazing bonus by just blogging. ;) J.Ja

jmgarvin
jmgarvin

I don't expect a programmer to know everything, but fizzbuzz is an excellent example of a coder knowing how to do a VERY simple task either as Tony pointed out above or by using a VERY simple loop with a simple conditional statement. What are we teaching CS majors if they don't know how to code?

jmgarvin
jmgarvin

The funny thing is that it's so simple it is amazing that more can't code it. What bothers me is how many people we're graduating, yet very few can actually code. That's a bit disturbing.

Justin James
Justin James

The static class thing is something I do all of the time too. You can take the Pascal away from the program, but you can't take the procedural code background away from the programmer... besides, forcing someone to populate a bunch of properties of a "worker class" and then calling .Execute() is just as lame, with the exception of it making multithreading much easier since you can make a Delegate to the Execute() method... I too would have been stuck looking for the catch. The last time I was asked a question like this in an interview, I made it clear that I was looking for the trick, which is why I was taking so long. Afterwards, we had a good discussion (myself and the interviewer) about this kind of thing in general. On the rare occassions that I ask questions like this, I always make it trick-free. After all, I am not testing for an applicant's ability to find trick sentences. J.Ja

SObaldrick
SObaldrick

A style of programming that harasses the enemy, sabotages communication and breaks supply lines. Maybe they meant a style of programming that is ham-fisted, without a great deal of thought and paid for with bananas. I've worked for that company. Les.

Justin James
Justin James

"Both tend to operate off unstable foundational assumptions." Only when used by people who don't know what they're talking about, which is the majority of people calling themselves "philosophers" or "politicians". :) As formal, academic subjects, they are both extraordinarily concerned with ensuring that the underlying premises are correct. Most philosophy, for example, spends the majority of the words trying to prove their premises, and then wrap up by drawing the conclusions. J.Ja

TheGooch1
TheGooch1

And management wonders when it will be done, setting unrealistic deadlines and not caring what the developers have for feedback. After all, the only thing this is important to them is pleasing their superiors, quality is not even a consideration.

SObaldrick
SObaldrick

That's why we have analysts. Les.

jmgarvin
jmgarvin

You have a point though...We're moving too far into the theoretical for CS majors and too far into the "practical" for the cookie cutters.

Tony Hopkinson
Tony Hopkinson

is inefficient. Cookie Cutters don't know what it is, and CS majors don't why it doesn;t matter anymore in practical terms. Progress... Way back when, when I was lad, you did need to know what it was and when you could get away with it.

TheGooch1
TheGooch1

I still work for that company, and I am still looking for the exit. Over the entrance to our building it says "Welcome to the Jungle"

Tony Hopkinson
Tony Hopkinson

Me too. Or those who go for the 1000 monkeys = a Shakespeare scenario. They pay in peanuts.

Tony Hopkinson
Tony Hopkinson

watching politicians squirm is about the best fun you can have with your clothes on. Philosophy though, when someone can use an argument like anthropomorphism, to shore up what amounts to an opinion and call it logic, well that comes across as post justification of an opinion to me. Not saying there's no logic but my code starts if A then, you can't miss it or forget it.

SObaldrick
SObaldrick

is when I wrote my first code, using punch cards and a remote server that we accessed by sending the punch cards in the mail. 2 weeks later we'd receive a compiler error report. Checked out Yourdon on Amazon - he's still writing, but appears to have moved into project management instead of structured analysis. Les

Tony Hopkinson
Tony Hopkinson

I'm 44, I predate Yourdon by a good while though. My initial design aids were truth tables and Karnaugh maps, wrote my first code in 1976.

Tony Hopkinson
Tony Hopkinson

Nothing better than seeing the development manager getting right in someones face and shouting "You did WHAT?" Get ready for the IT version of the Keystone Cops. Someone else could have thought ahead though, or may be just thought.

Locrian_Lyric
Locrian_Lyric

If you need a product to do XYZ tomorrow, you can't be concerned with next week. Planning is great when you have that luxury, but often you do not. Yes, it costs to go back and re-do things, but you also have to take into account the value of having something, sometimes *anything,* in place and the value that creates. I worked on a project for a newspaper where the job *had* to get done by a certain date because the business had already sold advertising in the new format. We were faced with either delivering a bare-bones project and have to go back and re-code a whole lot of things (and it was a mess, believe me) or to miss the deadline and make the company look very very bad. Care to guess which we did?

TheGooch1
TheGooch1

So, a coworker of mine did a presentation on the state of his application. He started with why we bought it, then explained events such as audits,etc, the forced things to be done in a non-standard way, which forced another odd configuration, and then another, and another, until we see 3 different versions of the app in different environments, and the data in stored in different formats that cannot be ported between each other ( say, you try to get everything into MS SQL Server ) without paying for professional services to do so. So now there is a mess, which was created using the "just get it done as quickly as possible without spending more money than you have to" method. With enough money, this problem can be solved, but with enough planning and emphasis on quality, it could have been avoided altogether.

Tony Hopkinson
Tony Hopkinson

realising the problem. Quality is a very fuzzy identifier. As a programmer, I'd be talking about code quality. Standards, documentation, reviews.... A UI and or product specialist, will be talking features, usability. A salesman wouldn't give a toss about that, it is saleable. A marketeer, clear blue water from teh competion, buzzwords, gimmicks, 3rd party appraisals... A manager will accept it all but the goal is to make the deadline so the salesman can sell. Having to take development shortcuts to meet business goals is not the problem, not adding up the real cost of doing so, that's a different story altogther. Quality is a short term cost and a long term benefit. Attempting to defer the cost to version 2, means it will cost twice as much and benefit you half as much. Programming is a tool, cheap tools usually do one job, make the next one much harder and can't be reused with any success. But beancounters will always put off a cost until the next reporting period on the basis that if they close their eyes and wish really hard it might go away.

SObaldrick
SObaldrick

Almost nothing .. the intent is to have the requirements have as little constraint on the design as possible. I will provide hints in the requirements as to some good practices for implementation, but there is no reason why an designer needs to implement my suggestions. So long as they can prove that the deployed application satisfies the requirements, they can design it how they want. It is possible to write specific, unambiguous, testable requirements without getting into the details of how they will be implemented. It's a skill that has taken me decades to learn. Les.

Tony Hopkinson
Tony Hopkinson

in others it's sort of non tech so progress to management or may be PM. Next title up the ladder in my current place which has technical track, is architect. Here's a question for you as an analyst, how much does what you ask for constrain the developer in terms of how they implement it?

SObaldrick
SObaldrick

.. from being a programmer to an analyst, with delusions of grandeur. I guess that's why I think I get paid more as analyst. Les.

Tony Hopkinson
Tony Hopkinson

customers with delusions of grandeur. :D Most of time in my caraeer has been spent as an analyst and a programmer. Domain Specialists, well they are a different thing, and a very valuable one, if they know their stuff and can communicate to the non-technical. That being us lowly coders.