A couple weeks ago, I came across a good post, lessons for software industry novices, and it inspired me to add a few more just for the heck of it...
1. Don't check in code right before you go home
It's 6:00, the [wife|kid|girlfriend|dog] is expecting you home in 30 minutes, and you just finished a really simple change. There's no harm in just checking this code in now before you go, right? DON'T DO IT! I swear I have been burnt by this too many times to count. If the build breaks or some bug pops up, you won't be there to resolve it...and every minute it goes unresolved you'll be losing good will with your fellow developers and testers. Obviously I always run a local build before checking in, but now I go a step further and try to hold off on any check-in if it's within an hour of me going home - better safe than sorry!
2. Batch your questions
As a new developer (or developer new to a team), you'll have loads of questions. This is good. Don't keep these to yourself, however don't ask them one-by-one as they pop into your brain. Write them down on a list, and only when you can go no further, then ask the tech lead/analyst/business owner all of your questions in one batch. People are almost always happy to help, but if you can limit the interruptions, it's always appreciated.
3. Stop complaining!
Yes, the system you work on is insanely complex/convoluted, the business owners are totally irrational, and the development team dysfunctional. Still...don't complain. If enterprise software development was easy, businesses could (and would!) hire people a lot less smart than you, and pay a lot less money. The fact that things are frustrating just means that talented developers are needed, and that we make a good living. If things are so bad, then quit - there's always a market for good developers. Otherwise, do what you were paid to do: make things better!
4. Keep it Simple - Format Matters
We all know the virtues of writing clean, readable code, but we don't always apply this rule to the artifacts we produce: emails, documents, models, etc. Spending time tuning/formatting these other products not only makes our ideas easily digestable by others, but it makes our ideas more persuasive as well. The minute it takes to tune an email for the people reading it is well worth it.
5. Be Nice!
I'm not talking about "nice" in the traditional sense, but rather in a game-theoretic sense. Many development activities can be boiled down to simple prisoner's dilemma situations: e.g. if we all comment our code we're better off, but individually it's more rational to be a free-rider and just take advantage of everyone else's comments (which is why it's sometimes irrational to comment code. It's been found that many people naturally play a tit-for-tat strategy, meaning if everyone else is "nice", they'll be nice too, but when someone free rides, they'll follow suit. Given this, it's always good to play the nice strategy and help others (review code, unit test, etc.). As soon as you don't, others won't either, and your development team can quickly turn to an every-man-for-themselves.
