hisakimatama (5/16/2014)
Hrm. Well, it's still rather early in my career (just under four years of being a DBA/Database programmer so far), but I'd say I've definitely failed so far, on several occasions :-P. The core failure in every case to date has simply been that I've failed at failing.I'd imagine it's not too different for most new programmers, but I could certainly be wrong. When I first started, I had a few screwups and mistakes, and the response I had was one of puzzlement. "How did that go so wrong? I tested it plenty! It shouldn't have done that!" and so on. Eventually, in my puzzlement, I'd stumble upon the answer.
There is nothing at all wrong with that, assuming you did indeed test it. Asking how something went wrong is not an issue, it is correct behavior. Expecting our code to work correctly before releasing it to end users is also correct.
Those who accept that their code will have issues frequently have far more issues because their standards are too low.
When I write something, say to extract data for someone, I test it until I believe it is correct. At that point, I then tell the end user to expect it to fail. I ask them to prove me wrong. Most of the time they can't do that. But their attempts to break it, or to find my mistakes, generally leads to better QA than I can do myself.
The key to what I am saying is that we should code until we believe we have it right, but we should encourage others to find our flaws that we may have missed. We should not accept our limitations and expect others to deal with it. The line between doing good work or shoddy work is hard to find, but I think most good programmers really believe their output is correct before releasing it. Shoddy programmers believe it is good enough.
Dave