I speak software.NET

First of all, is this even a question worth thinking about? Why should you care if one software developer is better than another? The answer depends on your perspective. Are you a software developer yourself? No? Are you in a position of hiring software developers? No? Well perhaps this article isn’t so important to you, for the rest of you read on!

If you’re a software developer, you should be VERY interested. The answer as to why a peer is better than you can impact you not only professionally but also personally. Professionally it will certainly impact you in terms of monetary reward. In addition, it can impact your own daily state of mind. Consider that the better developer is often receiving positive feedback from many different levels. Their peers, their leadership, clients perhaps. That can make the difference in whether you drive home feeling like you had a good day vs. a bad day. It’s a tangible impact to your daily existance.

If you’re in a position of hiring developers but are not a developer yourself, it should be obvious to you as to why this is important. Your management or perhaps clients are looking for the best developers they can get their hands on for the lowest possible cost. Being able to differentiate a good developer from bad can lead you to being placed on the sacred “preferred vendor list” or if you’re working internally a raise if your finding them consistently. The rest of this article will focus on the developer perspective but read on so you know what to look for.

So what exactly does distinguish the good developer? The enumeration of these traits is coming from my own empirical observations. It’s from someone with 20 years experience. Let’s see if you agree or what you can pony up.

Attributes of great software developers:

• Fundamentals/Core Values
• Perspective 
• Command/Understanding of the development language
• Command/Understanding of the problem domain
• Emotional Maturity
• Habits
• Constant Re-evaluation and Course Correction

Fundamentals/Core Values

The fundamentals? When did we start talkin football? I thought we were talking about software development? Simply put, the same principals apply. Vince Lombardi was famous for constantly preaching the fundamentals to his players. The military puts each and every soldier through basic. Now why is that exactly? It’s because the fundamentals are the foundation for which the rest of our ability relies.

You say, you learned C++ in college so you’re good to go? Perhaps, but your good to go only if you’re also … on-time, listen and follow directions, are reliable, conscencius, courteous, polite and exhibit some level of empathy.

These are core values. The person who exhibits these traits can blend into most any environment. The person that doesn’t, will often find themselves …. well … “they just were not a good fit for the company”.

Having been in a leadership position for quite a while, what I’ve often found is that the person that doesn’t possess these traits often can not overcome the deficiencies it causes.

Let’s consider the guy that always comes into work at 10:30am on a good day. Yes, sadly they also happen to have the shortest drive to work. They will profess of course that they put in their 8hrs. However, this person must work until 7:30pm at a minimum just to get in their 8hrs - factoring for a 1hr lunch. I’ve found from experience that what actually happens is that they leave at oh … perhaps 7:10pm. It’s late you know. In addition, they spent from 6:25 to 7:10pm talking to the people that were there late that came in at 8am or 9am.

This person also often doesn’t follow their leadership’s direction either. They’re so good they don’t have to you see. Unfortunately more often than not, the person’s perception of themselves is artifically elevated. They think they deserve to come in late and not put in 8hrs because they think they are more productive than their peers. They have already handicaped themselves because they are working less hrs … so now they MUST ALWAYS BE SUPER-PRODUCTIVE just to break even with their peers. This is possible in the short run but hard to sustain over time. So overall, that developer is likely to not be as productive as their peers and that’s assuming it’s even possible for that developer to be super-productive. Often it’s not.

When they do work into the night, let’s say they worked until 8:30pm. Pretty late depending on where you hail. For them, that’s only a SINGLE ADDITIONAL HOUR. They will look for someone to notice they worked the extra one hour, when in fact other person’s are coming in early or working through their lunches to produce the extra hour and still leaving much earlier than they do. Ah, but they wouldn’t know this.

Ah wait, your thinking … 8:30pm THAT’S NOTHING!. Uh yeah, I’m impressed. I’ve yet to find ANYONE that has made that type of comment that actually has performed FOCUSED, PRODUCTIVE ACTIVITY day in day out.  Yes, we have all had days/weeks like this for short bursts but not day in day out.

The arrogance that leads this type of developer to have this behavior is also the same cause of some of the other breakdowns in core values. No matter how good the rest of this person’s skills are, the overall perspective from management will not normally be very positive overall.

I have also found that the core values are very hard to correct. Very hard. These are character issues and are often formed from early childhood. At best, corrections are usually made temporarily. I’d rather have a person with good core values because they can be coached over time and they will be worth the investment.

Perspective

Some people that are software developers today – and perhaps this has always been true - don’t understand what’s really required to write good software. They may have the ability to draw a screen using the designer used for that language. Perhaps it even edit checks and saves the data to the persistence target. But they may not have considered, development standards, error handling, monitoring, security, reusability, short-term maintenance cost, long-term maintenance cost. Being able to understand these concepts is what differentiates the professional developer from the rest. Which side are you on? If you read this and didn’t understand all the words, that’s a good indicator of what side your on right now. This doesn’t preclude you of course from bridging the gap later on. No developer ever started off ”great”.

Command of the language

A developer’s command of the language is certainly a component of why some developers are better than others. If this weren’t true, anyone off the street to come in and become effective developing software immediately. But how can I prove this? Consider that today when a new developer starts working for you, for the most part NO ONE EXPECTS MUCH FROM THE NEW GUY AND THIS IS AFTER THE INTERVIEWS AND BIG SALARY DISCUSSION. Today, most software that does anything really useful takes a while to understand. The most experienced well trained top-guns still need time to get to know where is the code in source control, how do we manage versions, what are the coding standards, what design patterns are being utilized, what security measures are being used, what level of re-factoring is expected and so on. If the newly hired developer has a command of the language, after a fairly short period of time, they will begin to make bigger and bigger contributions until they start owning more and more of the code base.

If the new hire doesn’t have a good command of the language, this period of time can be lengthy … they may never really “own” many use cases. If your new hire isn’t acheiving bascially the same level of productivity that your getting from the rest of your folks, it could be because they never really had the command of the language you thought they had. Perhaps they just know how to take tests.

Command/Understanding of the problem domain

This is often the most crucial but often overlooked reason why one developer is better than another. The better the developer understands the problem domain, i.e. the subject for which the software is being developed … under normal circumstances … the more productivity you will receive. Why is this? Isn’t all software the same? I mean, it’s just screens and data being saved right?

 If your asking questions even remotely resembling these … you do not understand software development. If your telling yourself right now that I’m wrong … you’re fooling yourself. But don’t worry … you probably weren’t trained as a software developer or perhaps you let your skills atrophy. Of course all is forgiven. These circumstances can be rectified if you’re willing. If your not being honest with yourself right now, then it’s on you.

Another cause for not knowing the problem domain is bad specifications or lack or specifications. This unfortuately is all to common. I have recently relearned a lesson about this. Business analysts are most often not trained software developers. Ok, none of them are! However, they do of course command skills that software developers don’t. The issue that is often it’s hard for them to know where “analysis” stops and “design” starts. I drew up a mock screen for you and an ERA diagram what more do you need! Well, in some cases that might be enough. In most cases it’s not. The recently learned lesson is that it pays to discuss this as a team. Otherwise,  you may end up thinking analysis is complete when it’s not. The dev team will pay for that. Or conversely, you” underestimate the time required for design. That will also hurt the dev team. More often than not, the dev team is held accountable for all software mishaps.

Emotional Maturity

A software developers emotional maturity can have a huge impact on their performance. In fact, emotional maturity has an impact on everyone’s performance no matter what the profession. We’re all seen this … the young attractive person running the register who rang us out us out at the grocery store on the way home … if you hail from Redmond or San Francisco … change that to Starbucks. The person got you through the line but never made eye contact with you. In fact they never looked up to even see what you looked like. They didn’t say thank you .. in fact due to the odd silence … you thanked them! Ah yes, this is due to emotional maturity.

Consider how much work you’d be willing to do for the boss that thanks you for your efforts and coaches you vs. only berates you when your work in not done on time. Consider the client that doesn’t call for updates on that software you did for them. Did you thank them for the fact that they even hired you? Did you apologize when you were late delivering the software and explain what changes you think can be made in order to avoid a repeat? If not, perhaps you are not yet emotionally mature. Of course you’re emotionally mature you say. Your 48 years old! I’m sorry but it just doesn’t work that way.

The buzzword for this used to be called “EQ”, your ”emotional intelligence quotient”. There were many books on this in the late 1990’s. You were busy reading Japanese management books? You’re a decade behind then! Suffice it to say, it’s often the person with a high “EQ” that out-performs the person with the high “IQ”. Who would you rather work with?

In addition, many if not all software projects reach a point where you have to just pluggin away. Your recent deadline slipped. In facts perhaps all deadlines slipped. No matter what, you must stay positive. Keep moving adjusting and delivering the best software you can. You will get into the endzone. This requires emotional intelligence. Some developers are just not “closers”. There’s a certain maturity required to polish off every last one of those bugs.

Habits

My smoking doesn’t affect my ability to produce good software you say. If that’s what you were thinking when you read this, your not even in the ballpark. The habits I’m referring to are often but not limited to the little things. There are dozens, hundreds or perhaps thousands of actions that occur when developing software. The great developer has made automated unit testing a habit for example. They don’t need to be told to do this. In fact, they may even start with unit tests. The great developer, may be using tools that expand the capability of the language’s IDE. The great developer may have incorporated code generation or a subject specific language or other meta-data based productivity builder. (all these were relavent at the time of this writing). Though, it could even come down to the fact that the great developer knows 20 hot keys that make the IDE perform tasks that take longer otherwise. Why do habits matter that much? They matter because they all add up.

A great developer always looks for the next “thing” to incorporate as a habit. It’s similar to how athletes study and practice techniques that are turned into muscle memory. It happens with less and less thought. The great developer creates their own version of the athletes muscle memory. Did you ever notice that some developers use almost all keyboard short cuts. They seem to fly using the IDE .. while the rest of us search for the build button?

After going through the re-evaluation process the great developer will pick a reasonable number of techniques they want to add to their habitual toolbox. You’re already doing this you say? Be honest with yourself now. Only count those things you’ve read and/or observed that you actually now practice frequently and without much thought. That’s what differentiates a habit from something you WILL SOON FORGET.

Constant Re-evaluation and Course Correction

The great developer is constantly re-evaluating themself. What am I doing right? What am I doing wrong? What must I do to affect change? This is the process that over time allows the developer that wants to improve to actually do it. Eventually perhaps entering the elusive TOP ONE PERCENT in their field. The people that are performing this process HONESTLY can achieve this … if they want to and are willing to sacrifice. Both are required.

We’ve all heard this type of advice tossed around the office.

“All we have to do is roll up our sleeves”

“All you have to do is hold them accountable”

“We just need to execute”

… um thanks for the advice. How about this. SAVE THE PLATITUDES! What people really need is to know is exactly what steps do they need to take. If you can’t offer up more than ambiguous advice - then respectfully – don’t say anything. Your probably about to venture into saying things that you don’t know much about.

The people that want to be better and that are going to get better want to know tangible, exacting actions they can take.

For example! Let’s pretend your the project manager and you have someone on your team, “Ted”, that’s not performing to expectation …

1. Explain what you expect. In a professional environment don’t yell. At least apologize profously if you do loose it.

2. Get their assessment

3. Repond honestly with your assessment and specific things they can do differently

4. Next time around with same individual.

5. Set the expectation again

6. Get them to agree to what they can deliver

7. Monitor them more frequently than you did before so they don’t get off to a bad start and so you can affect the situation sooner if you have to.

8. If they still are not reaching the performance level that they themselves told you they could …

9. Have the same individual perform self-assessment again.

10. This time, when you respond with your evaluation, you must help Ted understand how to cope with the factors that they said affected the slippage. Let’s pretend Ted is late because Ted was helping Bob finish his work. You can let Ted know that Bob made an agreement with you on those items and that Ted is still responsible for his tasks. So that in the future if Ted help’s a team member again, Ted must put his own work first. Tell Ted that next time Bob is late that Bob should discuss it with you. After all, if Bob is in trouble, it’s Bob’s responsibility to talk to you about it. It’s not up to Ted to perform a rescue mission unless you direct him to. This keeps the dynamics of the team simple. Although Ted is obviously conscienous … it relieves Ted of responsibility for the outcome of Bob’s work. The outcomes afterall are your responsibility.

These are specific actions that can be learned. And this process invoked over time will produce better and better results … again … only if the individuals involved are willing to make adjustments. The sooner this type of process starts .. the better the outcome. If your in a leadership position and your not doing this … your not leading.

 This was just an example of one item. There are so many technical and non-technical things to learn … and that’s not the focus of this article.

Conclusion …

Have I convinced you? Yes? No?

Well certainly there is much more that could be discussed here. This article is merely a couple hours of off the top-of-my-head meanderings. I’m venturing a guess here though that those folks with experience can smell the truth of it. The people that have been through many many projects end to end and yes actually delivered some good software. 

Certainly all these factors can at least differentiate developers from each other. If that’s true, then why is it that in 2007, corporations seem to manage developers like they are interchangable parts? Perhaps you already belong to the corporate “developer pool”. Sounds glorious! I’d love to be in the pool you say. This will be the topic of my next article.

Scott Christian Pulver 

January 2007