The meritocracy

Office politics – who hasn’t been exposed to them? Wouldn’t it be nice if all technical choices were based upon, oh I don’t know, whether they’re any good rather than who puts them forward?

Meritocracy… is a system of … administration (such as business administration) wherein appointments are made and responsibilities assigned to individuals based upon their "merits", namely intelligence, credentials, and education, determined through evaluations or examinations.

(Wikipedia, http://en.wikipedia.org/wiki/Meritocracy)

Talking compilers

I think that a lot of people that work in computer and software development are in it for the fantastic empathy machines have towards us. No matter how friendly or mad we are, that compiler will always tell us how it is. It does not judge or discriminate, it does not tell us off. The computer is, in this sense, a proper ‘meritocrat’. The better a programmer you are, the less it will complain about your missing brackets.

When we leave the world of (lone) programming and enter the world of (team) software development, we also enter a world of talk and talkback. Suddenly we are not alone in deciding what goes where, we actually have to talk about our decisions. Well, we don’t have to per se, but when we make decisions that affect other programmers without their explicit or implicit agreement we may end up upsetting others.

If there is anything destructive to a team of software developers it’s negative feelings. Negative feelings produce negative thoughts and negative thoughts replace constructive thoughts. Even if there is only some negative emotion popping up in you or one of your team mates, it is already costing your team efficiency and less efficiency means less money for the company and that means less money for you.

I also want to share that, personally, I care greatly about my time and I want to spend it as happy and as productive as I possibly can. If a team mate is feeling unhappy, if I am feeling unhappy, than that time is not spent in the way that I enjoy the most.

Talking people

So, in order to minimize unhappiness, we need to talk. To management, to clients and to each other. But just talking alone isn’t enough; we need to compile the words in a similar manner, so to speak. If one developer says “we need to alter the code so we achieve goal x” and the other developer hears “you screwed up” then the happiness curve will go into a steep decline.

When we developers discuss the decisions we have to make it may occur that we disagree about the best solution. How do you solve a disagreement?

Talking team members

To me, there is only one way that can work. That is the way of the meritocracy, or: defining your criteria for what a good solution entails and then applying these criteria to the solutions. There can be no personal stake attached to any solution. I realize that this is more easily said than done, but it is a very, very important step to take as a developer and person.

If you show your team members that you care about their thoughts, even more than you care about your own solution, they will end up applying the same values to your thoughts.

The meritocracy

In an environment where every developer can be confident that his or her thoughts are judged only by their merit he or she can truly shine. It is my firm belief that every single person out there can be a creative genius if they are allowed the opportunity or even encouragement to show it. I am on a daily basis amazed by the creative ideas that my co-workers and I have and that in itself brings enormous joy to what we do.

Principles

I’d like to share some of what we work with in order to determine if a given solution is better than another. Keep in mind that you don’t write code for yourself.

1. Workability
   Any solution that does not meet the criteria of the project, such as speed or platform, is not right. A solution that closes doors to future enhancements is worse than a solution that doesn’t.
2. Readability/Understandability
   The easier the solution is to read and understand the better it is. Less statements is better than more statements. Sufficient descriptive naming is better than too short or too long names.
3. Consistency
   The more the solution is consistent with the project and the existing code base the better it is.

What do you think?