Having been a newbie software developer (and I’m still fairly “new”), I did not understood why software developers in our company are quitting. Having been a fresh graduate, I was, then, still amazed by the fact that there are people out there in the real world that will pay me real world money just to write code – a hobby that I will do for free. I was puzzled. We are working in an environment that fosters creativity and innovation, a company that strictly subscribes to the “programmers’ bill of rights”, and a company that scores high in the Joel Test (11/12).  Those, plus the fact that we can surf Facebook anytime and drink all the brewed coffee in the pantry, made me believe that this is the best company to work for locally; it made me believe that anyone leaving our company is insane.

Just a few months after starting my job (I had my internship there for 6 months), one of the bestest programmer I know (he’s actually a “software architect”, but hates being called one), my mentor when I was still an intern, filed his letter of resignation. This guy is one of the most passionate programmer I know. He gets it. Paul Graham classifies him as a hacker and he actually worked for Microsoft (in Redmond, not the local whatever-they-are-doing-there branch).

For some, asking people why they quit their job is taboo; I actually enjoy having those type of conversation. Gives me insight. So I asked the fallen hacker, “Why did you quit?”. He pointed to the picture of his new born baby (his desktop wallpaper) and said with an enthusiastic smile “He is my new priority”. He then explained to me, in a fashion that I would understand, why working overseas means “better opportunity” for his family. Being a bit unconvinced with his explanation, I asked him “Is that all? Better opportunity?” and he replied back with a playful smile, “In my new job, I will be able to code again. I will no longer be a ‘Word Programmer’”. He has always joked about being a Word Programmer – programming in Microsoft Word using narrative texts (use cases, scenarios, etc) and UML diagrams; programming by story telling. He was indeed a hacker.

Having spent a year and a half on this job, I can say that I now have a vague idea on why programmers (or I.T people, in general) quit. Even though I’m only a year-and-half year old in corporate servitude, I had been handled by four managers and had been transferred to four teams and that gave me great insights on the crucial dynamics that affects employee turnovers. In my year-and-half stay, I have seen three managers, a project manager, two architects, four senior developers and a handful of intermediate developers go. Just a few months ago, four of my teammates left. The statistics above is a little off; it is more than 20%.

So why do programmers quit?

There are a lot of models that scientifically explains turnover, but most of them does not really cover the programmers psyche because most of them are written three decades ago. These models are not exactly wrong; they just don’t capture how programmers think and react.

So let me present to you my model. Let’s call it the Programmer Turnover Model. There are only two controlling variables on this model: Opportunities and Grievances. When these two factors achieve “equilibrium” (fancy word eh?), the employee will finally pull the trigger and call it quits. Seldom do I see or hear that a programmer quits just by one of these controlling variables; it is usually a combination of both. But it is not unheard of that an employee quits just because of opportunities or grievances: If you’re boss is verbally abusing (Grievances) you everyday, that is enough reason to quit.

Opportunities

Opportunities are the voice inside us that always yells “The grass is greener on the other side”. It is the greedy side of the human emotion. It is the human emotion that seeks larger paychecks and better benefits.

Programmers have all the incentives in the world to quit. In fact, if you want to suddenly increase your salary, all you have to do is quit your job and find another one. A 25% increase in salary between job hops is typical. In fact, most local programmers do it. You don’t even need to be highly competent to do this; you just need to impress the interviewers and pass the interview. In an industry that caters to outsourced work (typically boring business systems) and software maintenance jobs, the bar that is being set is not that high (not “Google high”). Fact of the matter is, most grown-ups (including my mom) advice I.T. workers to just “get a few years of experience and switch jobs”.

Local industry culture believes that the sooner you get overseas, the better it is for you. Those programmers that work or have worked overseas are perceived to be “successful”. And what better way to increase your chance working abroad than to beef-up your resume with “experiences”? Not only that you get larger paychecks and better benefits when hopping jobs, you also get a set of fresh credentials to put into your resume. When you work for a single company, you’re stuck with their technology. And in an industry where your skills are obsolete within five years (max), being stuck in a technology is a really really bad thing for you.

It seems that the game is rigged for the employers. Employers are nearly powerless in stopping the greedy side of human emotion. Aside for paying large sums of cash to these spoiled programmers, they incur the risk of losing expensive human capital. All hope is not lost, the human emotion provides some form of protection against job hoppers. The loving side of the human emotion.

A few moments ago, I made it sound that it is so easy to job hop. Well, it is for soulless programmers (and about half of programmers are). But programmers are human too and they possess some of that soft, caring, vulnerable human emotion. People just don’t quit their job out of greediness. They are attached to their officemates, they been used to the smell of that particular brand of brewed coffee in the morning, they love how their $5 dollar computer chair squeaks when they lean back while waiting for their programs to compile, they love those once-a-month company parties, they know their way into their programs and they’re quite competent in it, they love to see their crush on the opposite cubicle, they are considered the domain expert inside the department. Humans resist change because attachments are hard to break.

It is painful to leave a company and that is what stops most people to quit their job even if they know that there are better opportunities out there.

Grievances

Grievances are the devil’s advocate that whispers “Stop taking this sh*t and quit”. Opportunities provide all the incentives in the world to switch jobs and although the touchy human emotion tells us to stay because it is painful to leave, grievances makes it justifiable and easy to quit.

Grievances builds up over time that’s why it’s hard to avoid it. It stacks up high. Each person have a certain threshold on how high they can keep their grievances stack before it falls down and crumble (translation: Each person can only take so much bullshit).

There are many forms of grievances, but all of them contributes to the metaphorical grievances stack:

• My company is still coding in Cobol when there are better technologies available.
• We don’t have source control.
• My boss is a back-seat driver. His hobbies are micromanagement and micromanagement.
• The elevator takes forever.
• The air conditioner is too cold.
• The code base is so poorly written that it breaks in 27 different places when you add a single line of code. The previous developer maintaining the code base is a literal arts major.
• We are responsible for testing our own code.
• My teammates are bozos.
• I hate my project. It’s not fun and exciting. It’s grunt work.
• I have written just 150 lines of code in the last 2 years.

Grievances have many forms but grievances are simply things that gets listed down in the “I do not want” column of your employees checklist.

The good thing about grievances is that managers and employers can manage and control them. Unlike Opportunities where employers are powerless, Grievances can be managed and controlled. It’s not easy but it’s doable. And the first thing that needs to happen is communication.

If you’re an employer/manager working with programmers, understand that your programmers have all the incentives in the world to leave you for better opportunities. Do not make it easy for them by giving them reasons to quit.

The Price of Turnover in Software Development

In his influential book, “The Mythical Man-Month”, Fred Brooks emphasized the importance of Conceptual Integrity in software design and architecture:

Most European cathedrals show differences in plan or architectural style between parts built in different generations by different builders. The later builders were tempted to “improve” upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. So the peaceful Norman transept abuts and contradicts the soaring Gothic nave, and the result proclaims the pridefulness of the builders as much as the glory of God.

Against these, the architectural unity of Reims stands in glorious contrast. The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design. The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride.

Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

The conceptual integrity of software is a measure of how well software conforms to a single, simple set of design principles. When done properly, it provides the most functionality using the simplest idioms. It makes software easier to use by making it simple to create and learn.

Conceptual integrity is achieved when the software’s design proceeds from a small number of agreeing individuals. For software to maintain conceptual integrity, the design must be controlled by a single, small group.

When turnover is high, the conceptual integrity of your product is being sacrificed. And because conceptual integrity is the most important consideration in system design, having bad conceptual integrity will make your product hard to use. This in turn will affect your sales and eventually your bottom line.

Not only will the loss of conceptual integrity of your product negatively affects your sale, it will also affect the morale of your best programmers. High turnover rates induces the Software Peter Principle:

The software Peter principle is used in software engineering to describe a dying project which has little by little become too complex to be understood even by its own developers.

It is well known in the industry as a silent killer of projects, and by the time the symptoms arise it is often too late to do anything about it. Good managers can avoid this disaster by establishing clear coding practices where unnecessarily complicated code and design is avoided.

When your project becomes too complex to be understood by your best programmers, they will be naturally be forced to rewrite it. They will go into their manager’s office and ask for a re-write, the manager’s will then disagree because there are no “business reasons” to do so (and maybe they are right because “rewriting is probably the ‘single worst strategic mistake that any software company can make’”), so you’re best programmers go back to their cubicle grumpy and dives into the unmaintainable piece-of-crap that is your codebase. Soon, they quit (because there are better opportunities and you gave them enough reason to leave you).

The managers then instruct their H.R. people to hire a new software developer to maintain the unmaintainable codebase. But since the programmer is new, and inexperienced,  he makes implementation choices that work but have unintended negative consequences. Further degrading the conceptual integrity of your product; making it increasingly difficult to understand. It’s a death spiral.

If there is one thing that the best programmers hate other than maintaining crappy software, it is working with incompetent programmers. And because you have a crappy codebase and you need software “maintainers” to maintain your codebase, you hire cheap, incompetent programmers and that will send you down further in the death spiral. Paul Graham puts it nicely in his essay “What Happened to Yahoo!”:

Microsoft (back in the day), Google, and Facebook have all been obsessed with hiring the best programmers. Yahoo wasn’t. They preferred good programmers to bad ones, but they didn’t have the kind of single-minded, almost obnoxiously elitist focus on hiring the smartest people that the big winners have had.

Why would great programmers want to work for a company that didn’t have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can’t attract good programmers to work in a suit-centric culture. And without good programmers you won’t get good software, no matter how many people you put on a task, or how many procedures you establish to ensure “quality.”

In technology, once you have bad programmers, you’re doomed. I can’t think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

Turnover reduces the conceptual integrity of your product. When there is no conceptual integrity, your product becomes hard to use and hard to maintain for programmers. The programmers maintaining the products hate the code so much that they quit. You hire new inexperienced programmers that further reduces the conceptual integrity of your product. You enter into a death spiral and you can no longer attract the best programmers because your code stinks. You enter another death spiral from which there is no recovery. That is the price of high turnover in software development: You lose your best talents then you lose your product and eventually your company.

How NOT to Retain your Best Software Developers and Programmers

One of the most popular form of “employee retention” is Training Bonds. Although it is not legally enforceable (or if it is but the company won’t really run after you because it is expensive to sue), most bright programmers will never sign a training bond. For most hackers, a training bond is a sign that a company is being ran by “suits”. Joel Spolsky attributes training bonds to “blind loyalty”:

I think that companies need to keep their employees loyal by treating them well, not by enforcing blind loyalty though a contract. I am not going to make the mistake of signing this clause again. Fortunately, with today’s shortage of qualified programmers, the balance of power today is sharply in your favor when you start a new job, and I think you have a very high chance of getting a job without signing restrictive employment clauses.

Another popular form of employee retention mechanism is counter-offer. Counter-offer is when your current employer gives you an offer (counter-offer) that is larger than the offer you received from the company you intend to jump to. Counter-offer is a big no-no because it sends the following message to your employee:

We have not really paid you the amount you deserve. But since we really need you to stay, we are willing to pay you more. We don’t think that you deserve this, but our hands are tied.

It is much worse when the news of a counter-offer leaks to your other employees. They will also feel that they are not being paid the amount they deserve, they will feel cheated and eventually quit. More turnovers, yay! Always remember the bribery never promotes loyalty.

If you think bribing your programmers when they accomplish something extraordinary will increase their loyalty: you are wrong. A lot of books have been written on the subject of incentive pay and why it is considered harmful:

… “incentives (or bribes) simply can’t work in the workplace”. DeMarco and Lister go further, stating unequivocally that any kind of workplace competition, any scheme of rewards and punishments, and even the old fashion trick of “catching people doing something right and rewarding them,” all do more harm than good. Giving somebody positive reinforcement (such as stupid company ceremonies where people get plaques) implies that they only did it for the lucite plaque; it implies that they are not independent enough to work unless they are going to get a cookie; and it’s insulting and demeaning.

I know that the title says “How to Retain your Best Software Developers and Programmers”, but I was only able to give the “How NOT to do it” guide. It took me a year-and-a-half to understand what motivates programmers to quit their job. It may take me another year-and-a-half to understand how to motivate them to NOT quit their jobs. You may wait for it, or you can just read Spolsky’s blog for a complete guide on how to manage and retain the best programmers that you will ever find.

Dummies can learn programming, too.

We, the nerds and the geeks, would like to believe that programming is a talent. That programming is… Something special. Something that cannot be learned fully. Something inherent — a gift from the gods. We would like to believe that programmers are born – not made.

These beliefs stems from the premise that programming is an ART. Like singing or painting.

Let me be the one to tell you that programming is NOT a talent. However, let me stress the fact that programming is an ART and as all matters concerning art, passion separates the good from the great.

Programming can be learned. Programming Languages can be learned. Algorithms can be learned. Software Engineering techniques can be learned. Everything concerning programming can be learned. So what separates great programmers from good or mediocre programmers? No, not talent. Passion.

Programming (or Software Development to be precise) is just building stuffs for people to use… It’s a modern form of craftsmanship. Even in the old times, craftsmanship is the vehicle for passion. Passionate people create great works, their magnum opus. Passion is what separates a $5 painting to a $10,000,000 dollar one. Passion is reflected in the end product… It’s as if the heart of the creator is passed on into the product.

I still believe that programmers are not born – they can be made. But hear this, Great Programmers are born. Not because great programmers are born with great intellect. Not because great programmers are born with superb logical and rational thinking skills. Not because great programmers are just geniuses…

But because GREAT programmers are born with passion. The passion to create great programs.

… and passion can never, ever be learned.