How do they know they got it right? Testing is the simple answer.

If their code has been tested thoroughly by a good QA team and it passes, then I would say they got it right.

Writing quick and dirty code is not something that should be done as a habit but at the same time there are occasions when you can spend 20 mins writing code that may be classed as dirty or 4 hours refactoring a lot of code to do it right. In the business world sometimes 20mins is all that is available to do the job and when you face deadlines quick and dirty may be the only option.

I have myself been on both ends of this, I have had to fix the dirty code and have had to write my own in order to work around the limitations of a system I was developing in. I would say I had confidence in the code I wrote because although it was dirty and a bit of a hack sometimes I did make sure it was thoroughly tested and had a lot of built in error handling so if something did go wrong it wouldnt destroy the rest of the system.

When we look down on these quick and dirty programmers we do need to remember one thing, a customer generally doesnt pay till they have the product, if it ships and they go into UAT testing and find the bugs from quick and dirty code it is a lot less likely they will pull out when they have an almost working product infront of them, yet if they have nothing and you are telling them "you will have it soon we are just fixing x" or "it was delayed because we had to get y working just perfectly" they are more likely to give up and go with a competitor.

Of course as this image demonstrates no one should underestimate the danger of quick and dirty code!