My three pieces of advice to developers aren't specifically about code, but they will eventually lead to better code: First, slow down. Slow, slow, slow, slow

My three pieces of advice to developers aren't specifically about code, but they will eventually lead to better code: First, slow down. Slow, slow, slow, slow down. Take the time to test and to write tests. Take the time to think about your code. Do it as right as you can the first time. Don't let anyone tell you you don't have time to do it -- you always have time to do it. Your boss might say "deadline is 5pm", but push back if you can't do it right. It's always, always worth it to slow down. Build testing into your timeline estimates. (My rule of thumb: double the estimate. 1x for writing code, 1x for testing). Second, don't overwork yourself for no reason. I used to be the support engineer for a startup. Half of my job entailed fixing all the bug reports that came in each day. I would reproduce the bug, add a test, and push a fix as quickly as possible. I used to come in at 9 and stay until 7 or 8pm. One day I cleared out the queue. No more bugs in the list. The next day I came in and had 10 more items. Realization #1 happened there. I sent an email to a colleague at one point, and he didn't respond until 11am the next day, but I barely noticed. And realization #2 happend then. The realizations were simple: 1) there will always be more work tomorrow, and 2) nobody realistically expects a response within minutes. In fact, if you send an email after 4pm, you probably don't expect a response until the following morning. Both of those realizations caused an attitude shift: I leave work at 5, 5:30 every day. I spend more time at home with my fiancee and friends. When I come in, if I have a few more emails than I did the day before, that's fine. They're not expecting instantaneous responses -- and if they are, that's their problem, not mine. Each support ticket got resolved in 24 hours or less -- far exceeding our customers' expectations -- but I went from working 60 hour weeks to 40 hour weeks. Much happier, much more productive, much less stressed out, and our customers will still exceedingly happy. A friend of mine works 60+ hour weeks and checks his email constantly, even when he's not at the office. I told him to just wait until morning and email them then. He says, "If I do that, I'll never get anything done, because I'll have 100 emails from my boss in the morning." Well, that's not his problem -- that's his boss's problem. He should go back to his boss and say "If you want me to get X, Y, and Z done, then you need to either email me much less frequently, or get more headcount on the project." Don't overwork yourself. Don't work more than 40 hours a week without extra compensation. Don't stress out about work -- I guarantee they're not stressing out about you. Finally, eliminate the phrase "it works for me" from your vocabulary. When someone sends you a bug report, whether it's a customer, a manager, or a fellow developer, your first action should be to confirm that it is, indeed, broken. They would not send you a bug report if there wasn't something wrong. It might be your code, or it might be them, but you owe it to yourself to make sure you have bug-free code, and you owe it to that person to give them the benefit of the doubt. And one thing you do NOT want to do is go back to someone and tell them THEY were wrong, and then have it turn out that it actually was a bug. Do your due diligence and rule out a bug. If you can't recreate it, go back and say "Hey, I'm having trouble recreating this. Can you give me more information?" Only when you have ruled out a bug by reproducing the behavior, do you go back to your customer and explain that they made a mistake or something. Those are the three biggest mistakes I see with new developers (and even people that aren't developers). Slow down, don't work too hard, and start off with the assumption that the customer is right. My two cents.