I speak software.NET

<intro> 

Are you working for one of those recently “enlightened” organizations that has put you in the developer pool? If you don’t know what I’m talking about then you have somehow managed to avoid this. Good for you! If not, someone most likely pushed you in the pool. Not many practicing developers want to swim in that particular pool. But don’t dispair because I predict the developer pool will eventually spring a leak. They’re going to have to pay a lot to repair the pool too. If someone actually did a multi-year accounting. The numbers prove was not the fiscal treasure chest they though it was. Later on, many developers will later on find themelves out of the pool completely even though your managers won’t admit it.

What happened to cause all this in the first place?

I’m not going to name names here but in the passed couple of years, I’ve been hearing more and more about the reorganization of developers into “developer pools”. You know. It’s just like the secretarial pool from the 1930’s except it’s for software developers. No, I’m not kidding. Read on.

You’re working for a very large corporation. Your one of the senior VP’s, let’s say for a company around 52 thousand employee’s or more. The business folks are so tired of waiting for their projects to be started, they begin threatening you. They’re going to go to the outside for help and they don’t care what development standards you’ve got. You don’t want that – what do you do? Well, you do what all good Sr. VP’s do. You call in a management consultanting firm. This well established consulting firm, recommends you form a “developer pool”. They have a another customer that just implemented this and they’re recording huge improvement in customer satisfaction for very low additional cost.

You have misgivings at first but you have to change something because all good managers know if you don’t change something then things will stay the same and you’ll find yourself out of a job cause you didnt change something. So, no problem you say. Your ready to setup the developer pool.

The notices to managers go out. It’s something like this. We’re not doing this right now. But I need you to inventory your software developers. Have them fill out this skills assessment form. We’re not doing anything with it right now though. So here ya go. You start filling out the sheet. The sheet only has 20 skills on it. You also realize they could have sent you a sharepoint link and that some poor fool will be data entering this. Not my problem you think and move on. Your feel frustrated because you’ve developed alot of specialized skills that not on the form! Help! You mention this to your manager. She tells you not to worry about it cause there not going to do anything with it. Just fill it out.

Back to Senior VP. Took longer than you thought to get the info you needed. Now you send the word out to the business units. We’ve been listening. We’re set to double our capacity to process our current pending projects queue. Yadda, yadda, yadda … we’ve got a lot of great developers with great attitudes that we’re relaxing in business units that we’re using them to capacity. Well some of that was true …. kinda.

Sounds pretty good to the business person. Well it should since their going to get some attention now. Is it good for the company? Is it the most efficient use of software developers ….no and here’s why. Software development is not assembly work. It takes brains and one or the most important factors in the productivity is understanding the problem domain. The develop pool oddly enough doesn’t address that dynamic. It more or less treats developers as if they were all equal interchangable commodities. Why if that were true, we might as well have our development work done in India or China! Whoops, can I get a mulligan on that? Crap too late. Ok, now you know my topic for my next article, “Why you should insist on learning Hindy or Chinese as a second language and not Spanish in high school”. If you reading this and the year is beyond 2015, please replace Hindy with African County and Chinese with South American country.

Ok. Why does the corporate developer pool nonesense… and don’t worry guys the same business folks that more or less prompted the change will be the same people lobbying IT senior management to change it back. So hang in there. The senior IT executive that actually inacted the high priced consultants recommendation, will eventually realize that she was duped by that consultanting firm whose data was empirical and short lived.

The concept does make sense.

<fill in>

The concept actually only works for a while. Pretty much because the initial perception is that the business areas waiting for resourses are getting some attention  now. Which is true.

It’s working for us, what are you talking about! Address that for some large organizations, the pool concept will work at first. In fact it may still be working in some places. Some big corporation are measuring the real costs and discovering cracks in the theory. Over time, the concept will breaks down. Especially as the organization develops larger and larger inventories of software.

<fill in>

Why doesn’t the concept hold over time …

Initially seemed to work. Perception was much of it, but when IT starts to measure the cost of maintenance, retention has declined and the influx of replacement talent cost more and is harded to get (crap the word is out) and overall your tired of hearing complaints from developers and now also from the business people because the cost of maintenance has sky rocketed and is very slow. You also know that code consistency and quality is declined. Your getting bad reports from your architecture team. They can’t control it. Worst case, some code assests were misplaced. You were able to recover them from your offsite storage provider but it scared you. It never happened before.

<fill in>

We thought SOA would prevent the degradation of the developer pool momentum my consultant told me about. Why didn’t it? Because SOA is an altogether different technology and solves different problems.

<fill in>

What adjustments or variants might work and why …

Developers that stay generally speaking in the same problem domain will produce more software or higher quality for less over time.

The pool concept still exists, but it’s filled primarily with contracted labor. You work HARD on your interviewing process and now through word of mouth things are improving at the Corporation X your getting and better candidates.

<fill in>

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