I understand the desire of non-programmers to want to tie 'quality' or even 'kwalitee' to hard numbers. I think this is a futile quest. Or kwest.

As a programmer (I like to call it "software engineer", la-de-dah), I have certain ideas about how to measure someone's quality. You'd probably want to look at the following:

• How many smart questions they ask when they're given some programming job to do;
• How quickly they produce some bare-bones functionality;
• How good their code looks;
• How well they back up their code with tests and documentation;
• How easily they are able to answer questions about how their code works, and whether or not it can be updated to a change or a new feature
• How many bugs their code has;
• How easily they are able to locate the bugs and fix them;
• How well they know what's going on in their code;
• How open they are to a code review; and
• How proud they are of their work.

A lot of these items are what you wrote in your list, but without the hard numbers. The thing is, if programmer A has six bugs in their code and programmer B only has two, what does that mean?

• A is three times worse than B?
• A's bugs are shallower?
• B's bugs haven't all been found yet?
• A's code is used more?

It's way too vague -- and we haven't even talked about the severtiy of the bugs -- A's bugs could be simple little tweaks, and B's bugs could be show-stoppers, huge gaping holes in the design.

I hope I meet a lot (if not all) of the criteria in the first list -- I'm proud of my code, and I believe it's high quality stuff -- one of my scripts has been in Production as version 1.4 (the third revision) for over two years -- it's a little over 100 lines, but it does exactly what it needs to do, and well.

Conversely, a programmer who hoards information, whose code looks horrible, who cannot fix any of their own code, who refuses requests to do a code review -- that's someone I'd stay away from. These are more qualitative measurements, but I think they're just as valid.

Oh, and one more thing -- programmers need to be able to communicate well, because without communication, nothing's going to get done on time.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.