He lists humility, love of learning, detail-orientedness, adaptability, and passion as the most important traits that a developer can have in order to be effective at their job and provides some well written insight into what he believes each of the different traits really means. For example, he has this to say about humility:
…humility isn’t pretending to be worse than you are and it’s not timidity. So what is it?
Simply put, humility is an understanding that the world doesn’t begin and end with you. It’s accepting that you don’t know everything there is to know about WPF, or Perl, or Linux. It’s an acknowledgment of the fact that, even if you’re an expert in some particular area, there is still much to learn. In fact, there is far more to learn than you could possibly do in a lifetime, and that’s ok.
Once you start assuming you’re the expert and final word on something, you’ve stopped growing, stopped learning, and stopped progressing. Pride can make you obsolete faster than you can say “Java”.
His thoughts inspired me to come up with a few corollaries of my own. I refer to them as corollaries because some of them are related to humility and passion, which are Ben’s attributes.
Ensure the Right Problems are being Solved
One of the fastest and most talented developers I’ve ever worked with also turned out to be the least productive member of the team because he continually had to rewrite his code since it never matched what the stakeholders envisioned. I’ll be the first to admit that stakeholders are a fickle bunch, but other developers on the team, who were not nearly as fast or smart, turned out to be much more effective in the long run simply because they constantly asked clarifying questions and sought regular feedback on their work. That led me to one of my most important maxims: It’s not how fast you can churn out code that matters, but how long it takes you to get an acceptable product to your stakeholders.
Creatively Reformulate Problems
Some of the most productive moments I’ve had in my career have resulted from taking a step back from a difficult problem and critically thinking about each of the problem’s underlying assumptions. Many times the assumptions proved to be erroneous or incomplete, thus making way for a much simpler solution. I can think of a few instances where I was able to get around the problem by creatively tweaking the user interface or workflow.
Other times I’ve been able to eliminate the problem entirely by honestly communicating the cost of the feature to the stakeholders, who then removed it from the project list because it didn’t provide enough value to justify the cost. There are definitely times when the brute force technical approach will be required, but I think a developer who is willing to try finessing a complicated problem first will almost always come out ahead.
Use Questioning As a Learning Tool
Sometimes it is not a matter of knowing what question to ask, but rather knowing when to ask it. I recently caught myself squandering perfect learning opportunities because I was afraid that asking my questions would make me look stupid. Conversely, I routinely witness developers pass up similar learning opportunities because they view another person’s skills or platform as vastly inferior to their own and thus erroneously assume that there are no valuable lessons to be gleaned.
On the opposite end of the extreme, it is common to waste learning opportunities by too quickly asking to be spoon-fed an answer without first applying any effort to solving the problem. It is justifiable to occasionally take shortcuts when the project is under a tight deadline or you are in a true collaborative mode (i.e. pair programming), but I think that truly effective programmers value the research and problem solving skills more than one single answer and will thus tend to discipline themselves to be a little self-reliant whenever possible in this area.
Temper Passion with Pragmatism
I agree with Ben that passion is a key trait to look for in a developer, but I’ve also seen otherwise brilliant developers reduced to utter ineffectiveness because they expressed their passion in negative ways one too many times and consequently alienated their co-workers and destroyed their own credibility. Unless you’re spiking the workplace coffee with mind control drugs, you’re likely to only have a limited amount of persuasive currency to spend on convincing your co-workers to switch to the latest and greatest language, tool, framework, or process. Truly effective developers are good at prioritizing the changes they want to help bring about and will consequently let the little things go (without so much as even a snide comments).
The other thing I notice in effective developers is that their passion is grounded in some form of objective criteria so that they are able to calmly provide both pros and cons of a technology that are situational based. That means that they can immediately identify situations where their favorite technology would be inappropriate. Passionate developers who are ineffective don’t often make such a distinction, which usually leads me to conclude that what they are really need is a religious cult or social club to fulfill whatever void that their current language, framework, or platform of choice is filling for them.
In conclusion, it takes more than raw mensa level brain power and passion to be effective at your job. If you want to be or find someone who is both Smart AND Get Things Done, then you have to focus on a few non-intellectual qualities like emotional IQ and self-awareness as well.