Telling the difference between good quality and bad quality is sometimes hard. Having worked a few years now in the software industry, I can tell who the good guys are and who the bad guys are. I can tell because I’m in all of their code and I’m thinking “this is a well-engineered module” or I’m thinking “what a pile.”
But my skill in software doesn’t necessarily translate into other areas. I still can’t tell what makes a great painting, or a great film. I can tell a good book or article from a lousy one, but only because I have spent considerable time both reading and writing.
In general, you can discern quality when you experience it and only when you yourself have enough competency to tell the difference. (We’re going to assume you’re familiar with this study which discusses the problems with self-assessing competency).
For example, when I bought my most recent home, I couldn’t tell a good home from a bad one. So I asked my cousin (who has built many custom homes) for some advice, and he explained to me that you can’t easily tell a good home from a bad home, because when the finish work is applied, most of structural quality is covered up.
Of course you can look for a few signs of things you can see, and there will sometimes be obvious signs of poor quality (creaky floors and walls, cracks in the drywall, gaps in finish work), but in general, you can’t tell much about the home if the finish work was even marginally competent. In addition, it may just be poor finish work, which can be redone. So you can’t judge a home by the paint.
To tell a good home from a bad one, you have to watch the construction process itself: how well the foundation was dug and prepared, the quality of building materials used, how many roofing nails per foot, the squareness of the framing, the care with which the plumbing was done, and so forth.
In the end, it’s all hidden by paint and siding; if you weren’t around to watch the house being built (assuming you had the skill to tell the difference) only time will tell whether the quality was good or poor. With my previous home, I learned that nearly all of the plumbing was sub-standard and had to replace many pieces of it after only a few years.
It’s the same with software: in the end, it’s all hidden by an API. Those using it may notice certain irregularities, efficiency problems, or what have you, but when things work most of the time, managers and customers are happy. All software has bugs. It’s only months or years later when someone needs to dig in and make a change that you’ll know whether it was done right.
Soon Hui wonders why good programmers aren’t paid 10 times as much as bad ones are (comparing them to soccer stars). He says [sic]:
I think it has to do with the nature of software development. It’s not that good developers can churn out 10 times as many features as the bad ones. It’s rather that good developers write code that have less bugs, more extensible and more maintainable. These are the things that you can’t measure by statistics or figures. But those who are able to command a high salary premium are those who can positively prove their worth, not those whose work can save the boss trouble later.
The productivity of good developers come from less rework, less debugging and less bugs.
original link (itscommonsensestupid.blogspot.com)
I don’t come to the same conclusion that he does: namely, you can’t tell a good programmer from a bad one. I can tell, and I think most good programmers can tell, but you have to dig into the code. The real problem is that many managers can’t tell the difference, and they’re the ones doing the hiring.
Which brings me to the final point. Software management is one critical area where the industry has not made great strides. As a group, I think most of us agree that there is a wide range of competency among programmers, but we haven’t figured out what to do with managers yet.
Having done some time managing groups of people in various capacities, as well as having been managed (including under- and over-managed), I think I can tell the difference between a good manager and a poor one.
The best managers I’ve known are nearly all have experience doing what the people they now manage are now doing, and doing it well. They themselves are quality individuals and understand and care about not only the end product, but the pathway to that end.
In software, the great managers are all former quality programmers. They cared about what they did and it showed in their programming work and now shows in their work as a manager. When you find a quality manager, you will find quality people working for them.
Software shops with great variance in skill and caring is often an indication of uneven management at best; high turnover is also an indication of someone not doing a great job at recognizing or keeping talented workers.
In the Paul Graham spirit, I think the only way to ensure you get a great manager is to start your own company. Then you’ve got no one to blame but yourself.