* A bug is not a property of the code; a bug is a property of the programmer. If you have a bug, that means that the model of the problem in your head differs from either the actual state of the code or the actual state of the problem. Fix your mental model of both and then 'fixing' the bug becomes simple.
* Every language and programming paradigm is a tool. Every 'best practice' is a tool. Yes, even your favorite. Use tools when they are useful, and don't use them when they get in the way. Once you start a project, you are all but locked into the tools you chose -- so, choose the tools that, at the end of the project when the code is two maintenance cycles away from being thrown away and rewritten, you would have wanted to use in the first place. This means using object orientation only when the best way to represent what you're trying to do is objects, and using functional programming only when your code benefits from a functional style. Ideology only gets in the way.
* Temporary programs aren't. Particularly if you are in industry, assume that you will still be maintaining any piece of code that goes into revision control or becomes part of a process for the next ten years, unless you rewrite it first. Write code that you will still understand in ten years, and use technologies that you used ten years ago and that you expect you will still want to use in ten years.
* Every language you learn adds to your toolbox. Every concept you learn adds to your toolbox. Some tools are less widely applicable than others, but having exactly the right tool is what separates very skilled programmers from your average CS graduate (who has, over the course of the curriculum, been taught some large subset of what academics i...