Your contribution as a developer is defined not by the abstraction of how smart you are or how much you know. It’s not defined by the technology acronyms on your resume, the companies you’ve worked at or which college you went to. They hint at what you’re capable of but who you are is defined by what you do and how that changes the project and the people around you.

If you want to be good, apply yourself.

How to be a great software developer

Lots of good practical info:

  • Write clear, maintainable code. As in his examples, you should be able to use the variable names and methods to describe the logic in concise English sentences. Comments are usually a crutch that can easily not reflect what the code is doing after many developers have made changes over time.
  • Go deep on your chosen technology before branching out. Often a mature platform will have a solution to your problem that uses much fewer lines of code, is better tested, and has better performance. It’s a matter of surfacing these features and sharing them amongst your fellow programmers so you all benefit.
  • Understand the cost of technical debt. When you’re starting a brand new project different from what you’ve done before, it will be quick and dirty, with all sorts of problems that you’d never want to ship to production. When you’ve settled on your feature set and know you’re going to be attached to the code for the long haul, then you can begin to get your architecture in line and fix the things you’d never want to see the light of day.
  • Make your team better. Devote Real Actual Hours™ to getting stuff done, and regularly document what you’ve learned to save others time and effort.

Questions you should ask yourself:

Does your presence make your team better or worse? Does the quality of your code, your documentation and your technical skills help and improve those around you? Do you inspire and encourage your team-mates to become better developers? Or are you the one that causes the bugs, argues during stand-ups and who wastes hours of time discussing irrelevant architectural nuances because it helps cover the fact that you’ve done no actual work?