Wise advise for programming, from a comment on /.

• Don't get attached to your code. Your code sucks as a newbie. Your code will suck a little less with experience. Even the master coders sometimes write a section of code that sucks. Much of the difference between a newbie and a master coder is that the master coder recognizes his own mistakes when he comes back to them and rips his old code apart to be replaced by new code. The quality of the application as a whole is where to take pride if you're going to be proud of something. Being overly proud of a line, a function, a class, or a library will often get in the way of the quality of the application. Your users don't care about the code you write or how clever/inspired/tight/beautiful/special it is. If rewriting part of the code improves the application, then that's what matters.
• Bugs happen. Fix them without blaming or arguing. Don't place blame on the people who wrote them. If blame must be placed, place it only on the code in which they were found. Your job is to make the code work, not to piss people off by pointing fingers. You'll write bugs into code, too, anyway, and you don't want every one of them thrown back in your face.
• Make a habit of promising less and delivering more. It's much better than the other way around.
• If you're doubting how to design or code a section of a program, ask two people whose programming styles differ. Take as much of the advice of both as will fit into one solution. Try to change which two people you ask from one task to another, even if some of them are not the absolute best programmers on the team. You'll learn more this way than attaching yourself to one mentor unless your mentor happens to be a world-class wizard. You'll also keep allegations of cronyism and team splitting down.
• Use source control of some sort. Even if your team doesn't use it overall, use it for your portions. Even if it's something really basic like tarring up your project directory at the end of every work day and keeping the tar files, do it. Try to subtly hint at its benefits for the whole group if they're not already using it.
• Learn a programming language completely different from what you use at work in your spare time. The perspective it gives you can be very helpful. Lisp, Scheme, Haskell, Erlang, and Forth are good candidates for most people to pick up. If you're not exposed to one of Python, Perl, or Ruby at work, pick one and study it at home, too. Any one of those will do, although my personal preference is Perl (after all, it's just a personal preference). JavaScript's object model is interesting, so that wouldn't be a bad choice either.
• Don't read /. and other sites too much when you need to be coding. It's great to take a break and come back to a problem, but don't overdo the break part when a deadline looms. Cramming and hurrying when coding isn't as easy as hurrying up many other kinds of work.
• Get plenty of sleep and drink plenty of fluids. I know it's old advice and it sounds corny. All those tales of lone hackers coding all week on coffee, Jolt cola, cold pizza, pot stickers, and hot and sour soup are romantic and inspiring. They're stories about great people getting stuff done against the odds, though. You need to think clearly to code well. If you can think clearly on 3 hours sleep and cold pizza night after night, then good for you. If not, take care of your body so you can concentrate.
• Set reasonable short-term goals on projects and cross them off one after the other. You don't have to knock the whole project out as one commit two days into the schedule. If you can schedule kind of conservatively and get ahead of schedule, then use that time to improve your code or save it for troubleshooting later in the project. Don't get cocky when one module gets implemented smoothly and tell your boss to shorten the whole schedule. It'll just come back to bite you in the ass if you do.