Taking Responsability for your Code
A co-worker (Kyle Olson) came up with a list of items about how to take responsability for your code that I thought was quite useful. I am reposting the article here.
I would like to add that one thing you should always be thinking about when writing code is how someone else is going to be able to read/maintain it. Code spends 80-90% of it's time in maintence mode, so the code has to be understandable to someone else can fix it and keep it working. If you don't comment or don't document then people will have no idea how to get it to work.
Relationship with testers:
If you can't reproduce a bug on your system, do you send the bug immediately back to the tester, or do you go to the tester for a repro? If you have trouble understanding a bug, do you punt the bug without a thought, or do you simply punt the bug away?
The testers are almost always willing to show you exactly what the problem is, and doing so will greatly reduce the time it takes to fix a bug. Spending just a few minutes debugging a tester's machine will allow you to uncover a myriad of problems. Your priority should not be to get bugs off of your plate, your priority should be to fix your bugs and make our product work properly.
Relationship with other developers:
If you create components and interfaces for other developers to consume, is there a strict contract that the code follows? Can the developer be certain how the code will behave? Does the other developer know what error codes will be returned? If the code fails, how will the consuming developers know that it has failed?
If another developer has a problem with your code, do you engage the other developer in an attempt to fix the problem, or do you attempt to force all the responsibility onto your coworker? Is your response to the developer to tell them the things that they did wrong, either in code or in the handling of the issue? Is your first response to keep bugs away from you by demanding the other developer perform a work around? Do you refuse to help the other developer unless they show you absolute proof of a problem in order to avoid the burden of testing your own code? Are you willing to investigate an issue even if it might not be your issue? When you do pass an issue onto another developer, do you help them get up to speed or do you push the bug on without comment?
Other developers are relying on you to help them accomplish their goals. If you fight other developers to keep work away from yourself, you create more work for everyone. Your goal is not to keep problems out of your territory. Treat other developers well, and our team will flourish. Treat others with arrogance, and our team will fade away.
Personal responsibility:
When an error occurs inside of your code, does the error become visible or is your only goal to appear to be running correctly? Do you trace out information which will help determine the source or your bugs, information such as error codes? Does your code contain useful Asserts?
It can be ok for our code to crash if that crash exposes an issue. Programming “defensively” can get you into trouble. Our programming conventions tell us not to use catch-all exception handlers. When we “catch (Exception)” we're hiding bugs. Only catch exceptions that you understand and expect. Any exceptions you don’t understand are cases we haven’t planned for or bugs we need to fix. If a function returns an HR, trap this value and act upon it appropriately. As with exceptions, don’t attempt to run correctly if you don’t understand the error that was returned. A failing product that appears to operate correctly is harder to fix than a product that fails loudly.
We all been reminded to buddy build before checking in, but we need to go further. When you finish writing your code, how much testing have you done? Have you only used one system, or have you worked to consider a variety of environments? Have you attempted to make your code fail? Are you ignoring some failure conditions, hoping that they never occur in testing?
Is your code complete when you check it in? Do you do only the minimum required to complete your work items? Do you demonstrate honesty, or do you say you've completed your work knowing there are many holes left, placing the responsibility on the testers to solve your problems? Have you written unit tests to ensure the code behaves as you expect, and to ensure that if that if the coding begins behaving incorrectly you will know?
Conclusion
Take responsibility for your code. Find ways to fix problems, rather than finding ways to make your problem someone else’s problem. By doing so, you show respect for your coworkers, your product, and ultimately your customers.