A geek programmer acquires technologies like shiny tools in a utility belt. But every technology is simply a collection of patterns expressed in a language, and most patterns are not new; if we understand the patterns, we can readily understand any technology that embodies them.

At various times in my life, I’ve geeked out on programming, but I don’t think that’s the hallmark of a good developer. What could be wrong with a talented developer who gives 110% creating clear, accurate maintainable code from 9 to 5, enjoys lunch while talking about anything but work, and goes home to a life unleashed from a keyboard?

Here are what I think are the five key competencies of a developer. To see why they are important, think about what software is: it’s not an endless series of statements, nor a collection of arbitrary calls to an API, nor is it only cut-and-paste. Instead, it’s a network of hierarchies of code—highly structured, with little copied code—mainly replicated patterns (not necessarily the GOF patterns but ones like “lazy initialization,” “model-driven code generation,” or “scripting in XML”). It’s also only useful if it meets business requirements and is of adequate quality. So, we need to assess the skills that enable a developer to meet these goals.

Enough preamble; let’s go.

1. Analytical: Structured, Clear, Critical Thinker, and Problem Solver

The problem is that a lot of people mistake poise, confidence, or rapid continuous speech for intelligence. So, we need to be very clear about the hallmarks of intelligence for a developer.

Software is all about functional and structural decomposition, so I think the key aspect of intelligence is to be analytical by nature, nurture, or force of will. An analytical person will consider a question or problem from multiple angles, choosing the best general approach and then breaking the problem down into sub-problems.

You can detect this competency in an interview quite easily because the candidate will naturally seek to clarify an ambiguous question or list the parts and relationships of a solution or “top and tail” a problem to identify its scope before going into details.

To detect this competency, you don’t have to give them a new problem, just ask them to describe almost anything: a software product they worked on, object orientation, the roles or process of software development, the internet, web, or equally the layout of a real, or ideal city, the nature of democracy, the definition and operation of evolution, etc.

When the description is complete, ask yourself if you have heard an enumeration of the pieces or if the candidate has described the heart of the matter; that’s analytical.

2. Abstract: Capable of Identifying and Understanding Abstractions and Patterns

Software is complex; you cannot understand it by simply reading every line of code. You understood it by looking for structure, building a theory of how the code is modeled, and then verifying and changing that model as you read.

Developing new software is a lot like understanding an existing program, except that the model does not yet exist, only the “theory” of that software in your mind. Your program expresses the theory in the model of code.

If you think in terms of abstractions, writing a functional or technical specification is not that different from coding, except that the language is a human one, and the interpreter will be one or more human minds. A specification is abstract because no program can run it, but if it is accurate, complete, clear, and well-structured (all qualities we seek in code), then a developer can implement it.

3. Precise: The Ability To Express Something Concisely and Accurately

Some developers manage to be somewhat successful by only replicating examples; they look for something close to what they want to implement and then tweak it. This is like sculpting, except when it is done with code, the result is usually not very clear, not very concise, and probably not entirely accurate.

Similarly, some developers can only explain things by example, not by naming the underlying concepts or patterns. This is acceptable but will be a stumbling block because they are less likely to recognize, understand, and apply patterns at the micro or macro level in code.

A developer who can be precise (but not necessarily rapid or impressive) in speech will develop more precise code and more easily explain a technique or a requirement to another developer.

4. Prioritized and Pragmatic: The Skill of Recognizing What Must Be Done Versus What Could Be Done

The agile approach naturally favors writing today’s code today. Even in companies that do waterfall development, it is still a vital skill to be able to distinguish between the essential and the possible.

Products are often only entirely successful by being delivered on time. A pragmatic developer does what’s needed, creating a few hooks and writing the comments that lay the groundwork for tomorrow.

Pragmatism is also demonstrated by the desire to achieve, complete, and finish; this drives and encourages us to define what is success, helps us prioritize the way to get there, and focuses on the completion of tasks rather than on gold-plating.

5. Idealistic: The Desire To Do Things Right

A developer who is only pragmatic can sometimes be lazy; not only do they only develop today’s functionality, but they only code for today, not for the developer who has to maintain that code tomorrow.

An idealistic developer actually cares about all the qualities of what they deliver:

• They ensure they understand the requirements.
• They consider and possibly even document the test cases before they write a line of code.
• They write code that is clear and adequately commented; they continuously refactor, so that common code moves into shared methods and then into base or helper classes.
• They write unit test cases to protect other developers and testers from bugs.
• They consistently do manual testing where an automated test is impractical.

Idealism and pragmatism are necessary counterparts, balancing and informing the decisions a developer makes all day long.

Other Competencies

Naturally, there are other competencies:

• Concentration: writing software is a complex task of transcribing a model of the mind into code.
• The ability to understand and use technologies.
• The desire to learn and improve all the skills they need to be effective individually and as part of a software delivery organization.
• The recognition that their skills are often meaningless unless they mesh with the other roles on their team and other teams.

Conclusion

One final competency; however, is one that we all need; the ability to recognize that there is no uniquely valuable set of skills or behaviors. In any organization, there are multiple ways to be successful, many roles to fill, and an individual’s work is just part of a larger process, all of which needs to work to be successful.

Smart people sometimes overlook other kinds of intelligence; it helps if we maintain the desire to achieve mutual respect and offer our views as an opinion, even if we believe we are correcting an error—you’d be surprised how often we confuse opinions and perspectives as facts.

However, a developer would do well to have the competencies above; then they are well placed to advance in their career on the technical track to become a senior developer, then a development lead and later an architect, or on the management track where integrity, a passion for respect, and the desire to inspire and help others to achieve are even more key.