Plans before coding
A great developer takes the time to plan an approach before
designing or coding. A great developer knows that the time required to
do so will be more than paid back by the time saved by getting it more
right the first time. A great developer plans all scales of work, from
envisioning multiple versions of a product to writing or modifying a
Always knows why
A great developer always knows exactly why they wrote a particular
line of code, and why they wrote it the way they did. A great
developer writes code because that code is the best choice for a
particular situation, not just because it is the canonical
implementation. A great developer codes consciously.
Writes situation-appropriate code
Any developer can write code. A good developer writes solid code.
A very good developer writes elegant code. A great developer writes
code that is both solid (compact, well constructed) and elegant
(precise, simple, graceful, polished). More importantly, a great
developer can tell when elegance is not worth the effort.
Deviates where and when necessary
A great developer not only knows the canonical implementation but
understands it is the canonical implementation. A great developer can
tell when the canonical implementation is not the best answer for a
Knows when not to change code
A great developer knows that changing code is sometimes worse than
fixing it. Fixing a bug may cause too much instability elsewhere in
the product, for example. Messy code whose function is not well
understood shouldn’t be rewritten until there is sufficient time to
ensure its function is well understood. A great developer understands
the tradeoffs involved between changing code versus leaving it as is.
Approaches debugging scientifically
A great developer knows that debugging is a science not an art and
approaches it as such. A great developer formulates a theory as to the
cause of the problem, determines a method for proving the theory wrong,
performs the experiment, and observes the result. A great developer
records this information and uses this data to guide further work.
Walks through their code
A great developer knows that they don’t really know their code until
they’ve stepped through it. A great developer sets breakpoints on
every line of code as it’s written so they know which lines haven’t
Knows the language and platform intimately
A great developer knows the programming language (and platform) in
use inside and out. A great developer knows why each construct (API)
was included in the language (platform) and why other constructs (APIs)
were left out. A great developer disagrees with certain aspects of the
language (platform) but understands why those aspects work the way they
do. A great developer knows what the language (platform) can do, what
it can’t, and how to achieve the same effect through other means.
Groks the tools
A great developer knows what the available tools are and how to use
each of them. A great developer knows that not every tool is
appropriate for any particular task. A great developer knows how to
abuse the tools to produce results hard or impossible to accomplish via
Improves the tools
A great developer knows that their tools can always be improved. A
great developer prefers to get these improvements from elsewhere so
they can concentrate on solving the customer’s problem. A great
developer recognizes when it is simply faster or more efficient to
write a tool themselves. A great developer constantly looks for
opportunities for increasing their productivity.
Knows when to ask for help
A great developer takes pleasure in a challenge. A great developer,
then, enjoys banging up against a brick wall and slowly breaking
through it. Some walls are thicker than others, however, and sometimes
the wall has a developer-size hole that the developer continually
manages to miss. A great developer realizes when it’s time to ask for
help and does so. A great developer knows who to ask for help. A
great developer knows there isn’t any shame in asking for help.
Always has a side project going
A great developer is never completely satisfied by the current
project. A great developer is always also working on a (probably many)
side project meant to investigate an idea, understand a language or
library feature, automate a process, or otherwise itch a scratch the
primary project isn’t satisfying.
Doesn’t make assumptions
A great developer actually does make assumptions, but a great
developer doesn’t stop there. A great developer inspects the
assumption, then researches that assumption into knowledge. A great
developer does this not just for their own assumptions but for
assumptions other people make as well.
A great developer documents everything. A great developer strives
for self-documenting code but knows that some amount of documentation
is always required. A great developer knows that documentation need
satisfy only two goals: educate the current audience, and preserve
enough knowledge about the topic that the current audience can expand
the documentation as necessary for any future audience.
Follows coding standards
A great developer has internalized and continuously uses a set of
coding standards. A great developer may not be able to recite the
standards word for word, but when asked about any particular point the
correct answer is immediately forthcoming. A great developer writes
conformant code without the aid of verification tools, but always runs
those tools as a backstop.
Uses version control
A great developer knows that version control is as important for
personal projects as for enterprise projects. A great developer
version controls everything.
Makes lots of small checkins
A great developer knows that version control is most useful when
code is modified via small checkins that each contain a single logical
change. A great developer strives to check each change in
independently from each other change.
Tests their own code
A great developer is embarrassed when someone else finds a bug in
their code. A great developer thoroughly tests their code before
checking it in. A great developer doesn’t pretend to be a great tester
but does strive to be considered a good tester.
Has passion for their customer
A great developer understands what the customer needs to do and how
the customer wants to use the product. A great developer looks beyond
the customer’s needs to see how the product can revolutionize the
customer’s tasks. A great developer promotes the customer’s point of
view throughout the product cycle, from the first nascent product
vision through specifying and implementing features to cutting features
and triaging bugs to product release and ongoing maintenance. A great
developer helps the rest of the product team understand the customer as
well as they do.
Has great judgement
A great developer understands the business case for the code he is
writing. A great developer uses this as a basis for judging what code
to write and what code should not be written. A great developer uses
this as a basis for deciding when to write code and when writing code
is not the right thing to do. A great developer uses this to balance
designing for the future against the need to get something done in a
Has no ego
A great developer values the praise of their customer over the
praise of their peers. A great developer wants to do the right thing
but doesn’t much care about being right. A great developer brings
their reasoned opinion to design and coding discussions but listens
carefully when alternatives are offered, searching out and examining
the details of these other options. A great developer appreciates
suggestions for improving their code or design. A great developer
knows they will write bugs and appreciates it when bugs are brought to
their attention. A great developer follows a process because the
process protects them from themselves.
Makes time for training
A great developer knows that the only way to continue to be a great
developer is to never stop learning. A great developer doesn’t limit
this education to programming-related topics, either, but also
researches testing, program management, marketing, and anything else
that is remotely related to the process of creating software.