Most of this advice boils down to this: Be Considerate. To your other devs, your project manager(s), your testers, your analysts, your DBAs, your sysadmins and your users.
For your fellow devs:
- Don't break the build! Test in your local environment that is as close to identical to production as possible.
- Follow coding guidelines! They are there for a reason.
- Don't use libraries not already in the code base without checking with others first! Everyone has their favorites but don't litter the codebase.
- Follow source control standards for your company! They have them. Find out what they are and follow them to the letter.
- Don't step on other's toes! Someone else working on a problem? Don't try to usurp them without a damned good reason.
- Follow the Principle of Least Surprise. Don't hide or obfuscate functionality. Ever.
For your your project manager(s):
- Keep a text file where you write a time and a little blurb about what you are going to work on. Every time you switch tasks do that. Run into a problem? Write it down in a sentence or two. If it is taking more than that you've waited too long. Use these for your standups and status reports. It will make both a hell of a lot more pleasant.
- Be extra special nice to your PMs...they have a thankless job.
For your testers:
- Be clear what you have coded and what bugs/improvements, specifically, that code is meant to address.DO NOT go above and beyond the call of duty if you can help it. YAGNI. If you absolutely think you are being asked to do the wrong thing, talk to your analysts about it and hammer out a solution.
- Suggest possible corner cases
- Be extra special nice to them too.
For your analysts:
- DO NOT go beyond their specifications without talking to them about it. They know what they are doing most of the time. Even if not, you must make that assumption.
- If you notice a problem with their specs, let them know as early as possible. But only after thinking about it first. Ask yourself "Why would they want this?" or "Why would they want it done this way?" If there is any possible answer to this question, you are probably just going to annoy them.
For your DBAs:
- Don't ask for access to a production database. Just don't.
- Don't ask them to "Just apply an index" or any other database 'fix' for poorly written SQL or haywire ORMs.
- Don't push code onto them in the form of stored procedures.
- Don't ask for views for any one-off uses.
- Don't blindly blame slow performance on "Something going on with the database."
- Don't pull a bunch of records from the DB only to filter them down in code.
- Don't access a database without permission.
- Don't make any 'improvements' on the database configuration what-so-ever.
For your sysadmins:
- You'll be given a machine and users/passwords (or have keys set up, more likely) for access to what you need. Everything else you do through them (which will likely not be much). They'll walk you through it. I'm sure it will be relatively friction free.
- Just try not to create work for them.
- For your users:
- Don't tolerate slow code
- As important as the Principle of Least Surprise is for your fellow co-workers, it is doubly important for your users.
- For the most part, if your users think it is a bug, it is a bug. If your users think the way something works is wrong, it is wrong. This boils down to Don't Blame the User...
I'm sure I left plenty out. Feel free to add to this list in the comments!
