5 Techniques to Increase Your Programming Productivity

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

Women working at computerIt’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.

7 Responses to “5 Techniques to Increase Your Programming Productivity”

  1. Instead of using

    select * from [payroll].EMPLOYEES where employee_id > 0

    Why not use

    SELECT * FROM [payroll].employees WHERE employee_id > 0

    That’s how I’ve been thought anyway (although I’m completely new to databases).

  2. One of the best practices I like to use is to oultine (with pen and paper – no tech I know, but it DOES help) my project BEFORE I start to code. Helps me flesh out what I’m doing so that I have a clear guide and I don’t stray from my original goal.

  3. These are good tips, but the last one is very specific to database programming. I would expect this type of article with the top 5 ( I assume top ) techniques to improve productivity would be more generally applied to all ( or most ) programming situations.

  4. Generally, the use of caps and lowercase letters in programming sense is to identify between local and public visibility. I like the idea of distinguishing between tables and columns, but you could add another layer of relevance; capitalize the database names, initial caps on table names and lower case for columns.

  5. Good article, however the level of granularity changed drastically with the last tip! You went from time management, environment control, and development efficiency practices to a code format convention!? How did you pick that minutiae over, say, using 4 tabs instead of spaces?! Or 2, or 3? Ha ha. As you can see from the comments here as well, you’ve set off a typical code formatting war, confirming that the last “tip” doesn’t fit with the rest.