In 1974, in his influential book of essays The Mythical Man Month, Fred Brooks talks about a small minority of programmers who are 10 times more efficient than the average programmer. He refers to these programmers as gurus. Subsequent research and studies back up the existence of these gurus and their amazing relative productivity. The ability to be a guru seems to be both a product of nature and nurture. That is a programmer needs to have some sort of innate ability to become a guru, but they need to learn how to put it to best use.

In his book, Brooks talks about organizing programming teams to allow gurus to make the best use of his or her skills and there is a wealth of literature for managers on how to find and keep exceptional programmers. The fact is, however, that just like every other field the vast majority of programmers are average.

I, myself, am no guru. I have however had the blessing to have worked with several. From them I have learned a number of work habits that help me make the best of my skills. This hasn't turned me into a guru but it has helped me to be a significantly better worker and enjoy my work better.

1) Take time off
All the gurus I know have had other interests besides work and been sure to make time for them. This can vary from a weekend hobby to regularly planning and scheduling large chunks of time off to do something else they enjoy. In most cases, relaxing time off seems to lead to greater productivity.

Similarly, gurus don't continue to push against problems when they are stuck, they take a break and do or think about something else. You can't force a breakthrough, but taking unstructured time not thinking about the problem often helps.

2) Share your skills and knowledge generously.
Teaching helps cement your skills, if you don't really understand something, you can't teach it to someone else. As a side effect, if you are always willing to help others, you know what other people on your project are working on at early stages and may be able to come to new ideas regarding your own work. Additionally, if you are always willing to help others, they will be more than happy to help you when you need help with their area of expertise. Finally, just talking about programming problems can make them better. By building an environment where asking for help is encouraged, you help build an environment where people talk about their work and their problems.

As a corollary, I've learned to ask questions early and often, not just about how to do things but about what to do. Often specifications and directions are not as clear as the writer may think, or my (my team's) interpretation of them is very different from the writer, customer, or our boss. Asking questions early makes sure that we are all on the same page.

3) Learn broadly
In an era when professional sub-specialization is becoming more common and more desirable to most employers, gurus have taught me the value of having a broad background. Working in different areas of the CS/IT field makes me better at all of them. One of the lessons from working in different specializations and areas of IT is to use your current tool - be it an operating system, programming language, or database system - as a tool, not as the only possible tool. Sometimes things are only impossible or difficult because you are using the wrong tool, not because they are impossible in and of themselves. There is no best tool, only the best tool for the job.

I hope these lessons from the gurus can help you have a more productive and enjoyable career as much as they have helped me.