In my experience, the meaning of quality depends quite a bit on the situation, too. If you're the only person who touches your part of the system, then it's better to have documentation that will allow you to pick up where you left off rather than "good documentation", which implies something that anyone else can read and get a good understanding of what's going on. If your code is only seen through a web interface, then usability and exception reporting are more important than flexibility and clean architecture. The list goes on and on... prototypes or production code? Small team where everyone is involved with everyone else's code or large team with lots of specialization? Core system or tool? Are your coworkers novices or experts? Will your code be viewed by 3rd parties (partners? investors?) Short or insanely short timelines?

Not that having "good documentation" is ever bad, but the relative weightings of different attributes is heavily situation-dependent.

"Perfect" code, not that there is such a thing, is probably immune from all these considerations. But a "perfect" developer would not be -- you have to juggle things to fit your particular situation, or you're optimizing the wrong things.

I find that the opinions of the people around me are the most reliable gauge -- the users, the QA folks, the developers I work with, and the production people who suffer with the problems (both in my code and in reality, but reported to them via my code). I know people who quickly write large bodies of code that effectively and efficiently solve the problem at hand -- but they drive me crazy because they assume that everything will be perfectly configured and nothing will ever unexpectedly go wrong. And when it does, and I bring them the problem, they brush me off with a test case demonstrating that it works just fine. Clearly I misconfigured something or something about my environment "isn't what it's supposed to be" (== matches their assumptions).

In short, I think it's about whether you make the people around you happy, and whether you can keep them happy.

Come to think of it, that's a lot like another profession. One with a somewhat different dress code.

---

---

• 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.