A major reason we cannot define what makes a programmer "good" is that we have thus far been unable to define the practice of creating software as a proper engineering discipline [1]. It is difficult to even enumerate the necessary expertise of a "good programmer" in a general way that transfers everywhere- it is a combination of computer science principles, knowledge of specific tools / languages / frameworks, programming idioms, domain knowledge, certain communication and interpersonal skills, etc. Further complicating things, certain types expertise is useful in some problem domains, and useless in others (i.e. COBOL programmers or kernel hackers will have to gain a different sort of expertise to become effective web developers).

This means that one type of programmer can be "good" at rapidly gaining new forms of expertise. Another may be crazy good at a problem domain he/she's been hacking at for years, and have irreplaceable knowledge. Yet another maybe can do both well, but be stuck at a cushy job for 30 years and never realize their full potential at jumping around and building other great things (like some of my old coworkers).

This lack of clarity in the definition of a "job well done" for software teams is a huge source of pain and lost productivity in companies, especially when the stakeholders and the developers themselves are unable to interpret the signals of failure from their teams. There's no real silver bullet [2] to immediately improve the situation, but there is certainly lots of data that can inform one about a dire situation in a team before it's too late to fix it.

- Code itself has lots of empirical data [3] that can predict team performance in projects with enough of a track record.

- Analysis of team composition and practices [4] can uncover deficiencies and lack of confidence in a team, pointing at other underlying project risks.

Currently (as the article described), all of this information is synthesized and estimated in an ad hoc manner by managers and stakeholders. What really needs to happen is for this data to be routinely collected and delivered to managers, stakeholders, and team members.

Here at Mindsight (http://www.mindsight.io), we are trying to tackle such issues. We're building technology that collects all this data and empowers a manager and his/her team to synthesize reports to stakeholders as frequently as their CI system publishes builds.

We may still have a ways to go in evaluating programmers in the general sense. However, there is still much that can be done to help individual teams understand their true progress in a project. Keep an eye on a future Show HN from us!

[1] http://repository.cmu.edu/cgi/viewcontent.cgi?article=2967&c... [2] http://worrydream.com/refs/Brooks-NoSilverBullet.pdf [3] https://www.microsoft.com/en-us/research/wp-content/uploads/... [4] https://wweb.uta.edu/management/Dr.Casper/Fall10/BSAD6314/BS...