Seven Habits of Highly Effective Programmers

This advice by Philip Chu is highly influenced from Steven Covey in his best-selling book, The 7 Habits of Highly Effective People, but is really a high quality read - peppered with illustrative real world programmer tales. I am just putting bullets points and brief description in the blog here; however you must read the complete article at http://drupal.technicat.com/writing/programming.html. Also other articles at Philip’s site is certainly worth a read.

1.     Understand Your Requirements

The first step in becoming an effective programmer is to ensure that you are spending your time wisely. And there is no greater waste of time than in working on something that is not useful or never shipped. 

Gets a demonstrable system working as early as possible? 

Once you have something working, don't just leave it as a "proof of concept". Let people play with it, see their reactions, and let this guide and prioritize your development.

2.     Keep It Real

Keep your software running in as close to a shipping state as possible. You never know when you'll have to demo the system, send out an evaluation copy, or even deliver ("OK, time to wrap things up!") 

If you just test with sample data, that big iceberg of real data out there is going to sink your program, hence use real data.

The development build on your machine is not the real build, hence use real build machine.

Don't procrastinate on merging your code with the main code base - the longer you wait, the harder it gets

3.     Understand Your Code

Life is full of wonderful mysteries, but your code is not the place for them. You don't have to know how your car works - if the engine starts making strange noises, you drop it off the mechanic. When it comes to your code, if you don't understand how it works, or doesn't work, no one will. 

The best writers and coders have an esthetic and their work features structure and style that can often be identified with the author. 

You should periodically inspect your code, sweep up accumulated hard-coded numbers, outdated comments, misleading function names, or you'll inevitably end up with uninhabitable code that's embarrassing to show anyone else. 

Document your code as if someone else might have to take it over at any moment and know what to do with it. 

Ignore compiler and runtime warnings at your own peril. They are called "warnings" for a reason.

4.     Optimal Programming

On the other extreme from cut-and-pasters are those who change code just to make it look prettier (at least to them). While it's laudable to have a programming esthetic, it's a waste of time (and a useless risk) to change code just so it looks better to you.

"Refactoring" is all the rage, now, but programmers often take it to mean any code cleanup or redesign. The trick is in reorganizing code for the better without breaking anything. 

If you do need to optimize for speed or space in you application, attacking anything other than the bottleneck is a waste of time.

5.     Manage Thyself

You probably have a lot of complaints about your boss being a lousy manager, and you're probably right. So you have to be your own manager. Even if you have a decent boss, he's not going to stand behind you telling you what to type and how fast

Programmers are notoriously inadequate at providing useful schedule estimates. I think this is a bad rap, since management, left to their own devices, often make even worse predictions, and unwelcome news from engineers is often ignored. (A common theme in any engineering disaster). But still, awareness of the schedule is critical to actually getting the project done on time. 

You wouldn't just hop into your car before deciding where you want to go, right? And probably you have a route in mind before you start driving, too. Similarly, before you sit down at our computer, you should know what you want to accomplish that day and have some idea how.

6.     Continuous Education

A corporate soccer team member once asked me, as we were lacing up our cleats, "what's the secret to C programming?" If there was such a secret, I'd be hawking it on late night TV along with ab machines and how to get rich in real estate. Sorry, there's no shortcut - you have to learn and practice and make some mistakes. And you don't necessarily have to rely on corporate training or going back to school - there are plenty of (inter)national and local professional groups, books, and of course, the Internet. 

It's called "computer science" for a reason. It's easy (maybe too easy) for anyone to to start programming, without a formal computer science education. In particular, those from other engineering and science disciplines can pick up programming quickly and make a good living. But to effectively tackle non-trivial tasks, you need to know the inherent capabilities and limitations of software and recognize prior work, so you don't waste time reinventing the wheel, badly. You don't have to know everything under the sun, but you should have at least a cursory familiarity with many areas and be prepared to do some additional research as necessary.

7.     R-E-S-P-E-C-T

One requirement for being an effective software engineer is to be taken seriously. You need to have the respect of your peers and managers, at least for your technical capabilities, to have control over your own work and influence over others. 

Engineers sometimes communicate more to show off their own knowledge rather than to inform (although, if you can do both, kudos to you). This is often inflicted in employment interviews, under the guise of "finding out how you think" the candidate is asked inane puzzle questions. This can backfire, though, if the candidate has any self-respect.