May 19, 2014 at 7:12 am
My biggest flaw was expecting that others had the same ideals as I had. For example, wanting to do a job correctly. Even today I am amazed at all the people I encounter who just want to collect a check but not do anything. Even if I didn't like who I worked for, I still gave it my best, and I have worked for some pretty bad people over the years. (Note that I have also had the pleasure of working for a lot of outstanding people as well!)
Today I just bring those issues to my manager, and if he ignores them, it isn't my issue. If someone is affecting my ability to get my job done, and it is ignored, then management made the decision, not me. Fortunately I currently work for good people, who understand that it is important to address substandard workers, and who still balance that against the fact that none of us are perfect. What this means is that people who have temporary issues are allowed to work through them, but people who simply shouldn't work on our team are replaced.
All of us come up against toxic coworkers, and it is one of the most difficult tasks we face. How we deal with that not only affects our performance, it affects our health, our family life, pretty much every part of us.
Like all of us, I also make mistakes. I make my share, but prevent this from becoming an issue by owning up to them. In most cases my manager has heard from me before my mistake came to light - allowing them to prepare and respond appropriately before someone approaches them about any issue.
Dave
May 19, 2014 at 7:20 am
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
May 19, 2014 at 8:08 am
djackson 22568 (5/19/2014)
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.
Oh, certainly! I should clarify; it wasn't so much that I tested it to the limits of the edge cases I was thinking of, I was instead simply testing it to where I thought it shouldn't break. That, of course, didn't include fun edge cases where the users would try things that I hadn't thought of, but really should have :-). Then, once it broke, I felt personally offended, with the ever-so-terrible mindset of "they shouldn't have done that anyhow! It wasn't in the intended use cases!"
Now that I've stopped thinking in such limited terms, though, I instead test as far as I can, then throw in some random nonsense to make sure the process won't break, and on top of that, I try to plan for any weird-yet-possible cases that could happen, like a user totally ignoring that an import process actually needs something to import, or trying to import an image instead of a text file. Add in the appropriate messaging on those errors, and plan for a few more strange cases, and brace for any failures, and deploy! 😀
- 😀
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply