Technical Background

A team needs members with a technical background. These guys are the ones that ensure everything works. They can write the hard bits of code, keep everything performing and make sure the code is maintainable. Without these guys, you will have problems. On the other hand, sometimes those with a technical background view problems solving as a puzzle, where the solution is the end in itself.
In my experience, team members with a less technical background are more empathic toward the user community. They view problem solving as a means to a goal. A customer focus is what makes a project successful. Software can be successful despite technical problems, but it cannot be successful if doesn’t meet the customer’s needs. Having some non-technical people helps prevent your resident technocrats from building a system that will service 10,000 concurrent users, but doesn’t meet the needs of the 329 users you have today.
Perhaps at the extreme end of this spectrum is the extreme programming practice of including a customer on the development team.

Experience

In expert versus novice programmers, I make the distinction between skill level and experience. Age, skill and experience often correlate, but not always. Your young apprentice programmers are important to have on a team. They can react faster. Sometimes not knowing better is a bonus. They’ll do things more senior team members don’t want to do. They do things they’re not supposed to do, sometimes for the benefit of the team.
I think people underestimate how long it takes to actually become an expert, as I mention in my previous post. But, then they also underestimate how similar all software projects are. They also overestimate the impact of their toolset. Generally the technologies in the laundry lists that form most job listings are not the critical success factors for that project.
People want a programmer with who can hit the ground running, who is familiar with all of the teams tools, languages and libraries. But, this is a monoculture as well. Sometimes you need people who aren’t from your toolset culture to point out where you have swallowed the hook too deeply or to introduce new tools and techniques from their alternate background. Sometimes their learning process can teach you something.
While some experience is valued in programmers, age sometimes isn’t. However, you need the older, more stable people as well. They keep the young ones from repeating the mistakes of the past. They keep the project on an even keel. It helps to have an older perspective on the team. I think they help keep attention focused on what matters. The tension between the older and younger team members helps keep the team on track.

Traditional Diversity Factors

I have no opinion on the impact of race. I have an opinion about women on software teams. I wish there were more of them. I have worked on software development teams with diverse nationalities. I regard that experience as positive. Different cultures have different tolerances for risk, different respect for authority or tradition. I think cultural diversity on a team is a good thing.

Managing Diversity

Over the years, there have been many methods proposed of matching people with the jobs they are best at. The solution that works best is to ask them. People gravitate toward the tasks that require their special skill sets. Good team management means hiring diversely and allowing that migration. On a well managed, diverse team, people will self select the jobs they are best at. As a result, the diverse team is more resilient and I believe potentially more successful.

Cognitive science research on problem solving tries to examine the difference between experts and novices in a domain. Rather than distinguish between developers and architects, I think it is better to distinguish between experts and novices at programming. The Dreyfus model of skill acquisition details five skill levels to help in this task. Here is a summary from Coding Horror:

Level 1: Beginner

• Little or no previous experience
• Doesn’t want to learn: wants to accomplish a goal
• No discretionary judgement
• Rigid adherence to rules

Level 2: Advanced Beginner

• Starts trying tasks on their own
• Has difficulty troubleshooting
• Wants information fast
• Can place some advice in context required
• Uses guidelines, but without holisitic understanding

Level 3: Competent

• Develops conceptual models
• Troubleshoots on their own
• Seeks out expert advice
• Sees actions at least partially in terms of long-term plans and goals

Level 4: Proficient

• Guided by maxims applied to the current situation
• Sees situations holistically
• Will self-correct based on previous performance
• Learns from the experience of others
• Frustrated by oversimplified information

Level 5: Expert

• No longer relies on rules, guidelines, or maxims
• Works primarily from intuition
• Analytic approaches only used in novel situations or when problems occur
• When forced to follow set rules, performance is degraded

The Java World article laments about companies that advertise for experts, but don’t interview for it. I have to say this struck a nerve with me. Multiple choice tests like the Zend Certification disappoint me. Tests like this don’t measure skill on this scale at all, they measure exposure.

In the past, I’ve used a coding sample as an interview question. The code, about 250 lines, was distilled from an existing system and is horribly bad in so very many ways, but functional. By showing the code to an interviewee and asking them what they would do to improve it, I found I could get a good idea of their skill level. Novices simply had no idea what to do with it and would just move code around. Sometimes they would insert comments, trying to make the code “better.” Some candidates only found and fixed one problem (there were several major ones.) No one fixed all the problems. The one person that I interviewed and didn’t have look at the code (for time reasons), we had to let go. He simply fooled us at his interview about his skill level. The thing is that I am certain he could have passed a Delphi certification test. (like the one I took at Brain Bench.)

Moving from novice to expert programmer takes a very long time. From Teach Yourself Programming in Ten Years:

Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967. Samuel Johnson thought it took longer than ten years: “Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price.” And Chaucer complained “the lyf so short, the craft so long to lerne.”

So you can’t become an expert without experience. However, you can have experience without becoming an expert. Some people just put in their time and never develop themselves. So these people may have the answers to the certification trivia question for their specific environment and be able to get past the HR resume screeners with their buzzword detectors, but they will not have the impact that a true expert would have in the same situation. Just like our Delphi Dud.