- Invest in learning and building tools. I've yet to meet a top engineer who didn't acquire mastery of their editor (EMACS, vi, etc), source control system, debuggers (though that's sadly going away), and programming environment. By contrast, mediocre programmers can (for example) edit code in EMACS but don't treat it like a development environment either to speed up the edit/compile/debug cycle or to reduce memory load (by off-loading knowledge of where a function is by using TAGS or some meta-search tool). Top engineers not only understand all the basic features, but usually make heavy use of the extension languages and customizability of their environment.
- Give credit where credit is due. Again, if you're a top engineer, you don't need to hoard credit and can happily acknowledge other people's work. This makes other great people want to work with you, and it's a self-fulfilling cycle.
- Impatience. Rather than wanting to spend time in meetings, top engineers write code, and spend time writing code rather than talking about it. Jeff Dean, Pengtoh, and Amit Singh have done major code changes to Google infrastructure without hesitancy. As Bill Coughran once said, "You come in one morning and discover that the universe has changed."
- Total stack comprehension. Great software engineers don't stop at an abstraction or module boundaries. They penetrate those boundaries and attack problems or bugs until they solve them. I was once sitting down next to Pengtoh while he dug down into misbehaving code and discovered a bug in the assembly the compiler was generating. He then figured out a stable workaround for that bug. If you're intimidated by abstractions or have too much respect for module boundaries, you wouldn't have found that bug.
If you do all of those 4, there's zero chance you won't be one of the top 1%.
