Advice to myself, I wish I had had starting out

I thought I would write the advice I would give myself if I were starting out as a professional developer all over again.

There is no such thing as magic

• If you don't even believe your own description of how a bug was fixed, it hasn't been fixed.
• Take the time to understand how your code is being called. Walk the call stack.
  

Time is too precious to waste

• Spend the right amount of time making your tools work correctly. If you have manual steps to build or setup, that's time spent not writing the good stuff (code)!
• Avoid participation in coding-style-flame-wars. At the end of the day it doesn't matter if the brackets are on the same line or the next. Challenge yourself to read different styles. If the practice has caused an actual bug and/or problems with a tool, gather consensus about what to do to fix it.
• When a class of bug crops up over and over again, consider if there is a way to re-architect the code so the issue is no longer possible.
• Make sure you're not re-inventing the wheel - has the function you're about to write already been written somewhere else?
• Get the right amount of sleep. Don't lose time on mistakes you otherwise wouldn't have made!
  

Become a debugging whiz

• Learn how to use the debugger for your platform, don't survive on printf if you don't have to.
• Learn how to hook up symbols so you can see how outside code influences your code.
• Talk to others about how they debug things; ask for good spots to put breakpoints.
• Talk to others about your tough bugs, but understand the problem description first. Note down details so you can explain without getting flustered.

Create maintainable code

• Name things what they mean, not just what they are. "htmlFile" means very little, "reportHtmlFile" goes a lot further to describe it. If you can't name your variable with meaning, it's a red flag to step back and revisit the problem.
• Be your own code-quality-compiler, write every single line as if it were shipping. It will.
• Start out with the right level of abstraction: if the function you're writing is useful in other situations, start with it factored correctly. In the end, it will save you time.
• Write code that can easily be debugged. e.g. Consider setting your variables in a centralized location so only one breakpoint should need to be set, or leaving in trace code that could be turned on for commonly debugged areas.

Become an asset to the whole team

• Take the time to learn how other areas of your product work. If you want to write more than one area of code, understanding is critical.

Dealing with difficult situations

• Try not to confront others with problems; work with them instead. You will likely need to work with them again.
• If, when solving a problem, everyone is talking past one another - take the time to make a diagram of people's ideas. Re-iterate in your own words what you think they are saying.
• Know what you want from a person before you send email or chat with them.
• Write your email as if it were going to be skimmed, because it will.

Learning and growing with your team

• Find a mentor on your team to learn from; find a peer on your team to learn with.
• Hassle others the right amount: not too much, but definitely not too little. Consider writing down questions you can check off a list instead of going back and forth to ask questions one at a time.
• (RTFP) Read The Fine Print! e.g. the remarks section of MSDN always has juicy details that should rarely be ignored.
• Become part of the community you're developing in - read blogs, forums, learn from others. Share with your team.
• Read books! There are lots of good books out there on software engineering and debugging, and probably the language/technology you're coding in.
• Write stuff down. Don't let process be folklore or leave undocumented that which would be useful to your fellow developers.
  

Giving advice

• Never give too much advice at once. ( Ooops! I guess I'm still learning! =) )
  

What's your advice?
- JFo