What do the top 1% of software engineers do that the other 99% do not?

Ref: https://www.quora.com/What-do-the-top-1-of-software-engineers-do-that-the-other-99-do-not

1. 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.
2. 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.
3. 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."
4. 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%.

Selecting the Project Leader and Manager

The above graph shows how/why/what type of Leader and Manager to be selected for better Project results.

Strong Leadership and Strong Management :
  When team/resources required to have more demonstration of work and Motivate(i.e empowerment)... then that team need Strong Leadership and Management.


Strong Leadership and Weak Management :
  When team/resources are well known about what to do and when to deliver things, but does not  have required skills or motivation then the team need Strong Leadership and Weak Management.

Weak Leadership and Strong Management :
  When team/resources are well motivated and highly skilled, but does not  have good planning skills then the team need Weak Leadership and Strong Management.


Weak Leadership and Weak Management :
  When team/resources are well motivated with highly skilled, and also the deliverables are well planned, then the team need Weak Leadership and Weak Management.


Great Project Leader would have following skills: