11–14 of 14 posts
If your next question is "How do you know if someone writes bad code?" then it is fairly simple for an experienced programmer to see if a piece of code is bad, good or somewhere in between.
The worst ones are those that know just enough to be dangerous, and who think they know everything. Instead of asking, they make assumptions, and produce code that almost works. Meaning, it will pass most of the obvious test cases, but breaks as soon as it hits production.
Example: One guy had to add a meta tag to a web page, with the page's publish date in ISO format. Instead of using the source data, which had the date as a DateTime object, he parsed the date from the formatted page output. This worked for US pages, and European pages where the day of the month was <= 12 (because of the different order of day and month), but broke as soon as the displayed string was impossible to parse. Ugh. Any half-decent programmer would wonder, "there must a better way to do this?"
Applies generally in all walks of life, in most situations. I've seen it in programming, and I've seen the mess that's left when people ignore that problem for too long.
If a programmer week after week on project after project says he will do x, y and z and next week he did G then it ruins the team because nobody knows what to believe and what to count on.