Every programmer has his or her techniques for being more productive and writing more code. Having been on a three month contract where I wrote and debugged 5,000 lines of code in two weeks, I thought I'd share some of mine.

Get Into the Zone

It's not always easy to get into the zone and it often takes about an hour to get there. Research suggests that after every interruption, it takes at least 30 minutes to get back into the zone. If your job requires meetings, try and schedule them close together so you have a longer non-meeting time for programming. Deal with email when you're not programming and keep instant messengers off. Headphones can also be helpful if your workplace allows them. For me, a familiar album playing works wonderfully at screening out background noises. If interruption from your telephone is a problem, turn down the volume and call them back later.

Design With a Designer's Hat On

Whether developing a game or designing an interface, I find that I get best results if I focus solely on the design from a designer's point of view, "wearing my designer's hat". That means ridding your mind of all those developer "buts...." Thinking too much about implementation will likely compromise your design. Like brainstorming, you have to learn to be nonjudgmental about how you'll make happen.

Debug Every Line You Write

I don't mean that you have to single step through each and every line, just make sure you've run the code in a debugger and called all of the methods. If you're doing testing, you want to aim for 100 percent coverage of your code. There's an old adage that fixing bugs in released code is much more expensive than fixing them during development, and it's true. Changing a line or two of code in development takes a minute or two. If it has to be built, tested, released, then deployed to the affected customers along with any fixes for data then it is going to take a lot longer. Plus, allowing a customer to find a bug because you didn’t test some code is pretty high on the list of sins to never commit.

Use Long Variable Names

As a teenager writing in Basic, I did all the wrong things. My friends and I only used variable names like a, b, or bj (yes, I did that). We didn't know better and some Tiny Basics only supported two-letter variable names. Nowadays, maintainability is a big issue so I'm happy to use long variable names like HasReadPacketTerminator or methods like PerformNuclearCountDowntoExplosion. Yes, maybe my C# code looks more like COBOL but at least it's easy to read. That said, some databases may have maximum length limits.

Use Case to Distinguish Database Objects

Relational databases contain multiple tables with multiple columns. A simple way to easily distinguish between them is to use lowercase names for databases and column names and uppercase for table names. select * from [payroll].EMPLOYEES where employee_id > 0 That way, anywhere you see an uppercase name you instantly know it's a table. ) Do you have any particular best practices that you'd like to share? Tell us about them in the comments below.