The Lie

<fiction>
Let's start with a little story about an enthusiastic software developer called Bruno. The story begins with an interesting job offer: A well known company is searching for an experienced developers to enlarge an existing team due to an increased business demand. The company does software since more than 40 years and scores reasonable at the Joel Test.

The Interview
The company is looking for top developers, a difficult coding exam during the interview is making sure to weed out the less skilled ones. The exam contains of a full range of Java traps: Beginner mistakes, try-finally idioms, generics and even some Java Puzzlers.

Bruno is one of the best. He finishes the exam in no time and scores well. Two small mistakes he makes just manage to curb his enthusiasm. The interview goes on with questions about common Java frameworks, ORMs etc. For the first time since long he feels challenged and invigorated by the exam's questions and the interview. He asks his usual questions any serious developer should ask about a future workplace, e.g.: How complete is the build? How does the code look like? Are there many singletons? (Because he just hates singletons. They are pure evil.) He gets some reasonable answers and accepts the offer in the end. The world seems like a happy place.

A Happy Place?
What look's like the beginning of a happy story is in fact its end. As soon as he starts working for the company he discovers that the interviewers had been lying about some things. Maybe they didn't know (but ThreadLocals are still singletons, aren't they). Maybe they were in some state of wishful thinking, confusing planned things with reality. Maybe there were other reasons nevertheless Bruno is disappointed.

Even worse Bruno's work does not reflect the skill level suggested by the interview: Java 4, JDBC statement driven persistence, no challenges, no problems to solve. All he has to do is to make already deeply nested ifs a bit deeper to find a place for more business logic. Bigger changes are discouraged due to the fear of breaking anything. (This might be the case for most modern business applications based on legacy code. Their business logic winds itself in endless, cascading ifs through all layers of the code. Or when did you need to come up with a more complex algorithm than iteration the last time?)

Bruno doesn't want to quit. Running away just doesn't just feel right. He has high expectations. But as the relation with his boss gets worse he gives up and quits. Everybody including himself agree that he wasn't the proper guy for the job in the first place. Hmm. How could that happen?
</fiction>

The Essence of the Lie
It has been two years since I first realised "the lie" as what it is. There were times when it really bothered me, but most likely it's just another thing to consider when looking for a job. It's well known that there are at least two kinds of software people. Some call them developers vs. programmers, smart vs. non smart, craftsmen vs. hackers, experts vs. journey men, professionals vs. duct tape programmers, coders vs. "code monkeys", etc. The essence of "the lie" is that some companies looking for the first kind are in fact in need of the second.

This is not a rant against these second kind of programmers. There's nothing wrong with them. (Note: There is a negative undercurrent in duct tape programmer or code monkey but that's most likely due to the arrogance of us craftsmen. So I will stick with the term plain programmer.) For certain problems in certain environments the plain programmer is simply the better choice.

Anatomy of a Plain Programmer
Now I'll try to list some virtues of a plain programmer :-)

• There is no need for a plain programmer to know his or her IDE well, he just has to know the debugger, because that's the tool he will use most of the time to poke in the legacy code.
• And he doesn't need to know any advanced language features and God forbid he must not use them. (His peers will be confused, so he should better stay with the stuff everybody knows.) So for example there is no need to know concurrency. (Note: I'm not joking, I witnessed my boss questioning the usefulness of an internal training about Java concurrency features.)
• It's desirable that he doesn't think too much about his work, better cascade another if and change existing code as little as possible then mess with the underlying design. (Refactorings and design changes almost always spoil dead lines, esp. when they were ridiculous in the first place.)
• He has no ambitions and does not feel the need to change already messed up processes.
• And last but not least he has to have a high capacity for suffering. He will need it.

In my experience it's more about the environment enforcing or at least encouraging these behaviours than someone just wanting to be like that. Less aspiring people with a high tolerance to discouragement just happen to endure it longer.

When Hiring
So next time you need a programmer make sure you know what kind you need. Don't lie to yourself. Don't give in to wishful thinking. It might not be comfortable for you but your project/organisation might be a mess. If you are in such a situation that you need a plain programmer, hiring an expert developer is just a mistake. You don't need a rock star programmer to churn out another business rule. Don't ruin another craftsman's life by sending him into a battle he can't win.

Public Relations

It seems that I am particularly unlucky in finding support for my interest in code quality. I can't help ranting so I will tell you this little story.

Some years ago, shortly after my "career" as code cop began, I wrote a series of articles about code quality and daily build techniques for a Java magazine (which I enjoy to do from time to time). My boss knew about it, but was not interested in it and I wrote the articles in my free time. (As you might have noticed I am not a gifted writer and filling all the gaps between facts and source code took the best part of most weekends during that year.) The first part was published soon after that.

After some time the second part of the series was published. This time the head of the IT department (the boss of my boss) learned about it and was impressed. He thought I had done it during work hours, or at least should have. I was happy and thankful for his appreciation and of course did not object to being paid for the time already spent. But my boss did not like the idea. He kept saying that we (the company I was with back then) were not an IT providing company and did not need to show any technical expertise or qualification to the outside world. However as he was forced to pay me for those hours, a rather difficult time began. In the end I regretted having shown the article to anyone.

In fact the whole story depressed me a lot and made me accept an offer from another company half a year later. There, during my interview I was promised support for writing technical articles. Later when a new article was due I wanted to call on that. It turned out that neither a budget nor a process was available for such activities so the support melted down to being allowed to write in my free time. I was pissed but in the end couldn't blame my boss. It was entirely my fault. Due to my lack of bargaining skills I hadn't pinned down the promised support to something concrete. (Technically my boss had not lied to me.) So from this time on I did neither ask nor expect any support. If they didn't want it, they should have said it straight at the first place.

But that was not the end...
Several months later I attended a department meeting on improving internal education, knowledge transfer and being more professional in general. It turned out that the head of the department (the boss of my boss) wanted more activities seen by the general public and that they had problems fulfilling the request of upper management to place an article in internal journals from time to time. Imagine my confusion when I heard that.

Yesterday a colleague brought a small, local conference on software quality to my attention (shame on me I hadn't known it before) and proposed that I should try to submit a talk. Again I tried to get some support for it. I am able to prepare stuff at home (at the weekends) but I can't afford taking days off for giving a talk. This time I contacted the boss of my boss directly because I remembered his (feigned?) interest in public relations. Unfortunately he delegated the decision back to my boss. As we already know, she does not deem public actions necessary. :-( My colleague was surprised, too. We remembered the things being discussed during the departmental meeting and both had thought that management wanted more public relations. (Otherwise I would have started questioning my senses.)


What is going on here? Are they all dreamers, talking about things they would like to have knowing they can never afford them? Or is it just another form of the suppressing code quality because we don't have any-syndrom? (In full name I call this the suppressing code quality topics because we know that we do not have any quality and I will write about it later.) I don't know. But I do know that it was the last time they tricked me. (They've already tricked me twice, shame on me.)

Soft Skills

In our department there was a small team of three people, organising internal training, maintaining the library etc. One of them left and later in a departmental meeting a discussion took place about replacing the missing member. The remaining two guys said that they already have difficulties managing and synchronising themselves and a third person would not help and is therefore not needed. Well, it sounds reasonable so far.

Some days later I was asked by my boss if I would like to join the team, which I denied, because as I had earlier understood, they did not want a third person, even if management thought they needed. (Well maybe it's from the management "idea" that having even two employees working on some topic is risky, because both might decide to leave the company - but three might as well...)

Afterwards I talked to the head of this "education" team. I had denied not of disrespect for their work but because I knew that they didn't want a third person. I was surprised to learn that they had already found a suitable replacement for the missing third member. They were so happy that someone they liked had volunteered. Huh?

Did I get something wrong in the first place, or did they talk unclear, on purpose, so they could choose their third member themselves? The whole story is just strange. Obviously I lack some soft skills in communication...