What Makes a Good Software Developer?
Software developers often like to think of themselves as elite artists, and appreciate being treated that way- they like to be left alone to do things their way, to roll into and out of work when they want, and don't always like their conclusions and methods to be questions. How can you tell the true geniuses from the lazy people who are just hiding their ineptitude?
As illustrated in the picture attached to this post, what a developer actually does can get a different description depending on who you ask. Because programming is so specialized, it's often difficult for a programmer to tell someone who's never written code what he or she is doing or why one way is better than another, and that includes interaction with management. Software development is one of a few lines of work where people don't often progress up the company ladder, both due to the business value of what they do and because they're often not personally inclined to move into management. Salespersons progress into managing and helping other salesmen, hospital administrators come from the ranks of the doctors, and police chiefs almost exclusively go through being an officer and a detective first. The managers of those occupations know when their employees are doing a good job and when they're not because they did the job themselves- the terms and technology may change, but the basic tenents don't.
Software is distictive among lines of work because of the specialization of the skill and the person- it's difficult to cross train software developers with other careers, because the skillset is so different, and people who are good at development often aren't very good at managing time, talking to customers, reporting to stakeholders, and many of the skills that good management requires, so often a developer's manager has never developed him or herself. It often takes months or years for a manager to really trust the team underneath him or her, proven only after many deliveries and trying times.
The issue is even more difficult when customers try to determine which software vendor to choose for a project. Often having never even spoken to a software project manager, much less a developer, customers have very little idea why one software house might charge three times what another one does, nor which one will satisfy their needs. Customers often have little interest in understanding the issues at hand- they would have gotten into software design if they wanted to learn it. However, muich like choosing a contractor, it's important that customers understand the implications of their decisions and verify that not only can the vendor meet their needs but has the vendor done something in the past. Being the vehicle by which a programmer learns how to develop an app is not the way to ensure success to a project.
DevTopics has an excellent article on just how impactful a good developer can be and how to group developers into categories that may illustrate how to property build a team, but it's targeted mainly at managers. We tell customers that we set out to differentiate ourselves by delivering first and showing problems rather than explaining them- it's a lot easier to show how a rushed decision or needless configuration option can damage the long term prospects of your project rather than to explain it.