hen AT&T assessed the performance of their engineering teams, they discovered that their top-ranking software developers were as much as 10 times more productive than their colleagues. There are several reasons behind this astounding range in performance. Besides intelligence and aptitude, of course, basic work patterns make a huge difference. I've tried to distill these patterns down into seven basic techniques that you can apply daily.

Before I describe each individually, it's worth remembering why you are reading this. You want to become a more efficient developer. To succeed, you need to strive for three key objectives:

• Produce applications that better meet the needs of users
  
• Introduce fewer defects
  
• Spend more time enjoying your job

That last element may surprise you, but in a creative discipline like software development, there is no room for disgruntled drudges.

And now...the seven techniques to help improve your day-to-day development efficiency.

1. Understand your users and their needs.
It's unlikely that you pay yourself to develop software for your own use, so the ultimate purpose of your efforts is to serve others. As developers, we seem to have difficulty projecting ourselves in the role of our users. Yet it is important for us to do so.

The first stage in any project ought to be to understand and document your end users' requirements. Although you may already do this routinely, especially if you're part of a larger team, there are always ways to study your documentation results further or to get to know your users better.

Being in tune with your users' needs should help you determine what to build and, perhaps more importantly, what not to build. Whether you call these needs "requirements" or "specifications," they should be the guiding light for all development.

2. Understand your whole code base.
Few projects have the luxury of starting from scratch. Chances are, you're usually scouting about for scads of existing code. That means spending too much time chasing back and forth between code modules. You can reduce the need for such code hopping by familiarizing yourself with both the logical and file-oriented structure of the code tree. Get one of the old hands on the team to give you a guided tour of the code and explain how it is structured. That'll help you find material faster later—especially since you'll have picked up some of the anecdotal history of the development work along the way.

3. Work well with others.
Most likely, you often work with other people on the same project. To achieve high productivity levels, it is important to develop team pride and communal ownership of your work. Try to build a sense of community, so that the entire code base belongs to the whole team; no area is private property. This cuts down on rework and duplication.

Group pride and peer pressure work to ensure consistently high quality. I mean, no one wants to be targeted as the joker who checked low-quality change into the master source tree, right? Group pride can also mean better adherence to coding standards because everyone has bought into them.

Don't get me wrong. Uniformity of coding is good, but uniformity of thought is not. Perhaps the most difficult aspect of being a true team is that you must welcome bad news as well as good. If a team member thinks something is wrong and points it out, the rest of the team must listen. Pointing out problems is all too often dubbed as being a "poor team player," when exactly the opposite is true.