Developer Melange Episode 3

Yesterday the third episode of the Developer Melange podcast was published. Developer Melange is a monthly podcast which brings you regular discussions about software engineering topics. All of them, in one way or another, related to building great software products. It is recorded by my friends and fellow software crafters Paul Rohorzka, David Leitner and Christian Haas and they release around an hour of high quality discussion every month.

I am supporting them since the very beginning. In fact I was playing with the idea of recording a monthly podcast already for some time. After my summer project I finally found the time to visit them during recording: We discussed the essence of Behaviour Driven Development, starting with Dan North's introductory article from 2006. It seems that we could not agree what the essence or core of BDD might be. In the second part we tried to answer the question if it is better to be a specialist or generalist in the field of software delivery. Of course the time was too short for such deep topics. ;-)

Get it here
Listen to this episode here. All previous (and future) episodes can be found on the Developer Melange home page and Developer Melange SoundCloud page. If you need an RSS feed for an old-fashioned podcast app, use Get RSS feeds from SoundCloud URLs, which is this RSS.

Feedback
The team and I are curious what you think about Developer Melange. You can reach us on Twitter or leave comments on SoundCloud. Tell us what you think! Any suggestions, e.g. topics you would like to hear about, and also criticism are highly welcomed. Stay tuned!

33 Days of Education

IT is a fast moving industry. Heinz Kabutz says that "we are in an industry with a knowledge half-life of at most 18 months. [...] Half of what you knew 18 months ago is worthless today, so you need to keep learning new things." We need to learn a lot, fast and continuously. Today even traditional companies recognise the need for professional development, also - or especially - for senior and expert level employees. (I could argue that senior tech people need more training than junior ones, because their time of dedicated learning in school or university has been longer ago, but I am digressing.) All companies I have seen, offered five days of professional training by year. (Unfortunately, not all employees take the opportunity to use this training budget, but that is another story.) A few companies have a stronger focus on self-development. For example the Swiss Zühlke Engineering offers ten days of professional training. (At least they did in the past, as confirmed by several Zühlke employees I met.)

Obviously ten days are twice as much as five, but I believe we need more. A few companies allow Research or Lab Fridays from time to time, following the idea of 20% time, made famous by Google Friday. While slack at work is focusing on innovation, the time is also available to learn. In the end, exploring new ideas is related to both. One of my clients runs a "Basteldonnerstag" once a month, which adds another ten days. sipgate runs Open Fridays every second week. So we are up to 20 or even 30 days for your professional development each year, I like that.

My Personal Development
As Code Cop I am working with my clients on different things. Some clients use technologies I have never seen before. Still my goal is to help them to improve. It could be as simple as writing unit tests with a xUnit styled testing framework - or as alien as modularising a legacy application written in an old, purely procedural language.

I learn a lot and need to learn more. I am conscious of the time I spend on learning. I think about learning methods and try different approaches, e.g. flash cards. I am still performing code katas, on my own and together with others.

2016
When reflecting about last year, I think that I could have done better. I had interesting work and got a lot of new experience, but I did not attend all training that seemed necessary and I did not visit as many conferences as I needed to visit. I worked full time and had to squeeze in the occasional learning. Out of curiosity I counted the days spent on learning last year. I was very surprised when I found 33 full days spent on professional training:

• 9 days of conference presentations. Last year I attended 5 traditional conferences, e.g. GeeCON, full of great talks and coding demos.
• 6 days of classic training like training courses or workshop days before conferences.
• 2 days of unconference sessions. Unconferences like SoCraTes are less structured than traditional conferences and enable discussion and deliberate discovery of new ideas. Usually I am hooked up with a new topic after attending.
• 9 days of personal workshops. These include Journeyman Visits, Code Camps and meeting with other people to work on a research topic for a whole day.
• 2 Coderetreats. While some unconferences include Saturdays, Coderetreat happens on Saturday by design. I am attending them rarely because usually I am facilitating them.
• approximately 5 days of pair programming practise. I remember 18 sessions either remote pair programming or attending Coding Dojos. Usual sessions last 2 to 2.5 hours.

This list does not include books I read, user group meetups, side projects or writing blog posts - all these activities are an essential part of learning, too.

After seeing these numbers, I am impressed with myself. ;-) 33 days are a lot, and one third of them was spent on evenings and weekends.

Previous Years
So 2016 was a good year for my personal learning. How about the previous years?


2015, shown in the orange bars, is pretty similar to last year (blue bars). Surprisingly I spent 33 days on professional development, too: one workshop less and no Coderetreats, instead more remote pairing sessions. In 2014, shown in yellow bars, I fell a little short. I did not attend any training or unconferences and did fewer workshops. Becoming independent enabled me to visit (paid) training and I just discovered the opportunity of unconferences and workshops back then. Still I had more than twice as many pairing sessions, summing up to 27 days of professional development.

Conclusion
While I felt bad about my personal learning earlier, these numbers satisfy me. 33 days sounds much and I am starting to pride myself on them. I have no way to compare, I know people who attend at least one conference each month, which already sums up to 24 days at least. So maybe 33 days are not that many after all. So I might/ should/ could do more (MOAR PROFESSIONAL DEVELOPMENT!!1!), but I am pretty sure that I will not. I did not aim for 33 days in the past and I will not do so now. I am very busy, both with my work and my major ongoing side project. On the other hand, this year was full of opportunities and I already spent 12 days professional training in the first quarter.

Interview Sebastian Göttschkes

Following up on my previous post on meaningful work I want to further dive into the topic started there. As most of our time is spent on regular work, i.e. in our day job, I am especially curious about the impact we could have there. For me as software developer my day job is to sit in a chair and press keys on my keyboard in weird sequences almost all day. And by doing that, what can I do about the important issues of preserving the environment or cruelty to animals to name just two examples? Is it possible for my work to help these issues? Is it possible to make a difference by just working on the "right" things? What are these "right" things?

To get some answers, I decided to use a more structured approach. This topic is complicated, probably highly philosophical, and I do not expect to get good answers by analysis alone. I think we need to start a dialogue with one another to discuss and define what our responsibilities might be. I created a list of questions and started asking some of my peers, i.e. developers with solid experience of working in our industry. I have collected their answers and will mark their ideas and opinions either by quoting or typing in italics to separate from my own interpretations and errors.

Introducing Sebastian
Sebastian Göttschkes was the first to accept my invitation. Sebastian is a developer living in Vienna. He is interested in programming since he was a kid and started coding when he volunteered for programming classes in school. After finishing his studies at university he has been working as professional software developer for ten years. He likes to build stuff. Read his blog or find him on Twitter to get in touch with him.

Being Vegan
I noticed that Sebastian was vegan and asked him about it. Some time ago he had started to eat less meat due to health problems. Being concerned about what to eat and what to avoid, he thought more about food in general which led him becoming vegan for ethical reasons. He said that being vegan is important to him because as developed being he does not want to treat other beings badly. Cruelty and killing is not necessary for his survival. It is disappointing how we, human beings treat other beings. We should be able to do better.

Other Topics of Concern
Sebastian is also very concerned how we treat one another as individuals and as society on the whole. The current refugee crisis in Europe is a perfect example. If people are starving we have to help them. We have to help first, there will be enough time for discussion later. Currently there are many discussions in the European Union regarding refugee quotas and refugees are forced to wait. Surely they need to be registered and their claims have to be verified, but that could come later. These people should not be treated like numbers on some form. Sebastian believes this to be the result of our capitalist ways. There are more and more areas where people and whole systems are reduced to numbers.

Challenges for Humanity
When I asked Sebastian about what he considered to be the biggest challenges for humanity he laughed. There are plenty. The environment is obviously very important. We need to fight climate change and forest deaths. We must not destroy our planet. Further politicians and governments need to work together smoothly to avoid wars and all the unrest caused on a global scale.

How to engage in these topics?
Sebastian likes to talk about being vegan but he makes sure not to have a reproachful attitude. People are open for the discussion when they are not attacked or forced a bad conscience. Even a single meal without meat each week makes a difference. In the current refugee crisis in Vienna he keeps donating goods and actively supports the NGOs helping refugees around Westbahnhof where he lives. He has also organised charity concerts in the past.

My first questions were just introducing Sebastian and setting the stage. The really interesting question was about the impact of our regular work. I asked him several questions regarding impact, choice of work, choice of project, customer or industry and so on.

Is it possible to have impact on your day job?
There is the social entrepreneurship movement which has similar goals. Today almost every product or service needs supporting technology so we developers have many options. As our technology is everywhere we should be able to find jobs with more impact in general. But the problem is to find suitable companies and keep the standard of living at the same time. Also it is more difficult for people with a high degree of specialisation. Sebastian looks for companies who help people in some way. Even regular companies can do that, it is not necessary to work for NGOs exclusively. But it is difficult to recognise such companies. You have to check each project you work on individually. Sometimes you cannot tell up front at all.

Choice of Industry
While software development is an industry on its own, most of us work to support another industry, e.g. finance, insurance or energy, although often we do not take this choice deliberately. Sebastian does not believe that the choice of industry matters. It is more important which company you work for and even more so which project you actually work on. While the finance sector has a bad reputation, supporting micro loans to help poor people is a good thing, unless the project's goal is to rip off everybody and just make more money. In general Sebastian recommends to stay away from finance and overly capitalist industries, because of their problems discussed earlier.

Choice Based on Values
On the other hand it is not easy to find a company according to one's values. We cannot be too particular because we need the money. As we are part of the system, i.e. our society, our current way of life, our capitalist world, we have to live by its rules. All I can do is to decide according my values inside my possibilities and choose from the options I have. But the system is complex and hard to understand. There is much indirection and it keeps getting more and more indirect. For example some things we consume are not made locally. And even if we know where something was made, we do not know where its raw materials came from. It is not unusual for raw materials to travel halfway around the world. It is impossible to think about all the problems and implications so they are usually ignored.

Choice of Companies
I was not satisfied by Sebastian's answers and continued asking because I wanted to explore his values and decision process more. For example I asked him if he would work for a butcher? He denied, but he would work for a company working for a butcher. In fact he has worked on some platform of local advertisements where butchers would be able to advertise their goods as well. I kept asking and asking, but Sebastian did not have a list of undesired customers. Sebastian prefers small companies. In general small companies are less "evil" than larger ones because they have less power and cannot ignore laws. Small companies have other goals and there are still people in charge who have a conscience.

Projects are especially interesting to Sebastian when they try to change people's way of thinking without blaming. For example he mentioned TREEDAY, a gamification of checking CO2 footprints, or WienRadeltZurArbeit where you win prices by collecting miles of going to work by bike. These initiatives are great because by making people think they have more impact than by just supporting people who already care for the topic.

Conclusion
I enjoyed talking to Sebastian and it took us around 90 minutes to cover all questions. The conclusion is that there is neither black nor white. What should we do if we write software that - in the end - destroys 100, 1000 or 10000 jobs? Maybe there is no way we can do the "right" thing - either we do not know all its implications or we have no choice. But to ignore the situation is definitely wrong. We need to address the issues, preferably in a positive, improving manner.

Credits
Thank you Sebastian for sharing your values and ideas with us. I am glad you took the time and I appreciate the interesting discussions we had. Thank you very much.

Thoughts on Mastery

During summer time I was on vacation in Tyrol which is an excellent place for hiking. A local magazine told a story about Josef Frauenschuh and his business of hand-crafted rakes. Josef is a true master craftsman: He is of old age, many years past official retirement. He creates large wooden rakes of highest quality using different kinds of wood for each part of the rake. His rakes are balanced and lightweight. He uses the best tools he can get, all of them are self-made and after 45 years he is still improving his tools and process. Obviously he does not accept any compromise. Once, when he needed more space to create the shafts, he simply made a hole in the wall of his workshop.

I liked the story a lot. It made me think about our craft and the concept of mastery.

I believe that one major aspect of mastery is age. It is not necessary by itself but rather is a side effect of the time needed to master a subject. Masters are aged because they have been practising their craft for 30 years or more and still try to improve. Following this definition it is obvious that there can not be many masters of software development, because our industry is still young. Only a few like Uncle Bob are working in the industry long enough, whereas most of us have less than ten years of experience. The so-called senior developers with five years of experience are just young journeyman, if at all.

Josef is working hard. Although he could retire any time, he is working five days a week because the demand for his rakes is high. He is a master and his rakes are masterpieces, but does he get rich? I do not think so. Following the story I assume he has to put considerable effort into each rake, and sometimes the wood splinters and he has to start over. Being curious I compared the prices and his rakes sell for around 70 Euro, whereas eBay has some for ten to 20 Euro, although no wooden ones. So yes, the masterpiece is up to five times more expensive than a regular one.

Still it seems that Josef is not earning five times more per hour than other workers. Could it be that master craftsmen are relatively underpaid because they put in extra work to create magnificent things? Maybe his rakes are expensive to compensate for the small number he is able to produce. That does not compare well to our industry. We (developers) are greedy. We expect a good salary matching our experience and competence. The more experience we have, the more money we want, which seems only fair. The never ending demand for IT professionals spoils us and salaries rise during the first years of junior developers' careers. At least they rise up to a certain point, which might be 15 years of experience, when we become "too senior" for most employers. But this is another story.

I do not know Josef Frauenschuh but I believe him to be a true master craftsman. Instead of bragging about his achievements, he is modest and admits that sometimes he even has to listen to outsiders to improve his rakes. He does not need titles of seniority, nor is he proclaiming himself to be a master. I guess he considers himself still a simple carpenter. He is a great example. Some of his modesty would suite us software people well, and I will start with myself.

Personal Branding for Developers

Recently a friend mentioned that by creating the Code Cop I built a strong brand. I was surprised. Surly I spent a lot of energy on my personal branding, but I had not considered it a brand, probably because there was never any business involved. We talked about some interesting ideas that he will work on in the future and asked me how to build a brand. This article is mainly for him. It might be interesting for others as well so I decided to publish it rather than create a long email. I will describe what I did to create my brand together with some things that I picked up on the way.

You are a brand
My journey for personal branding started when I read an article by Jeff Atwood, Your Personal Brand. But even back then I already had my brand which I had been awarded by my co-workers. It was "revealed" to me, I did not look for it. This is the most important point regarding your personal brand: You do not have a brand but you are a brand. You are not Coca-Cola, probably you are not even a company, just a developer. Personal branding is not about creating a fake perception of yourself, choosing a fancy title or bragging about your deeds. It is about honesty and focusing on being a great person. It is the mental image people have about you. If you are not authentic whatever you do will be shit!

Understand Reputation
Your personal brand is supported by your reputation. Reputation is the opinion people have about you. For knowledge workers it is related to how much you know and how much you help others as well as general social "metrics" like how you behave or if people trust you. Everything you do gives a perception of your brand. Every small interaction in the real or digital world builds or breaks your reputation and therefore strengthens or weakens your brand. Be serious but do not be too serious.

Brand Your Accounts
Today most of our communication is digital. The first step is to show yourself. Choose a good portrait of you or maybe an unique avatar and put it on your GitHub account. You have a GitHub account, don't you ;-) Seriously, put it on all your accounts. Same goes for name and motto. If you are not sure about the motto, leave it blank for now, but you are sure about your name, right ;-) When registering new accounts try to use the same user name that fits you or your main idea of your brand. Obviously that is not always possible unless you are a very early adopter like Rands in his virtual land grab for his user name. Still I try my standard list of user names, e.g. codecop, codecopkofler or my name until I hit something that is still available. The user name is not that important while the display name shows your name in a similar way. Note that some services like Twitter allow changing the user name without problems. By branding all your accounts in a similar way people will recognize you across application and social media boundaries.

I am not sure how anonymous accounts fit in because they are not linked to you personally. But used consistently I assume using a pseudonym for your name consistently will have the same effect. When getting famous you might need to keep up the masquerade and actually dress up like your profile picture. There are people successfully working under an obviously fake name, talking in public and still staying anonymous.

Define Your Motto
I briefly touched the issue of your motto. Your brand needs a motto and there is plenty opportunity to show it as most accounts offer a biography or about-me field. For example Twitter offers you 140 characters to describe yourself. While this may seem way too little space to explain your passion, idea or project, it is an excellent opportunity to focus your brand, prune it to its essential core, the motto. This pruning may take some time and it is not easy to come up with a succinct, yet powerful description of yourself. I started with a long story about me, like the one you can read here, then pruned and compressed it further and further until I got something I liked. In the end my shortest bio was 142 characters long. As additional benefit I ended with a set of bios, different in size, and I am able to choose one depending on the space that is available in my profile.

Working on your motto should get you started. There is much more I want to explain, but writing about it took more time than I had initially expected. I will publish this first part now, so you can read it while I continue writing about how to gain reputation by sharing content.

My Buddy Check List

Last DemoCamp a fellow craftsman asked me how to find a proper employer to work for. How to find out if a team you are going to join is kicking ass? How to check if the future team mates are good people? (By our definition a good person cares about his or her work, doesn't rush, writes unit tests, keeps the code clean and does many other nice things. :-) So how to find out if you want to work with them? These are good questions.

Mindset
Applying for a job is symmetric which means it's a process working in both directions. Of course you try to prove yourself worthy of the new job. There are many resources on the internet that tell you how to write your CV and how to behave during interviews, so you would not screw up. There are even guidelines for managers which questions to ask including the famous FizzBuzz. All these guides are targeting your value as employee and how to present it properly.

On the other hand your future employer has to show to you that he is worthy, too. The interviewer is his first representative and must be prepared well and take the interview serious. Later he or she might tell you about the company's generous compensation scheme or the team or the development process to impress you. In the end of the interview you are usually asked if you have any questions. This is the time to ask and so I do. During the past years I have compiled a list of questions that I ask during interviews. Today I want to share some of them.

Process
I always start by asking the Joel Test. Although it failed me in the past, I still believe it gives a good overview of the used development process. Then I ask the interviewer to define quality. Quality is perceived different by different people and the manager's idea of quality has considerable influence. Usually this leads to an interesting discussion if the manager is really interested in you.

Team "Theory"
The team I'm going to work with is important to me and I start asking about it right away. "How large is it? How is it structured? When was it formed?" A team needs time to form and I like to join high performance teams. So is it a real team where each team member found its place or is it just a group of individuals sharing the same room? Starting a gig with setting up a new team is risky if you lack authority to influence future hiring decisions. The team might not end as you would like it to be.

Team Spirit
Next I try to figure out the team spirit. "When did the last person leave the team and why? Why is there an open position? Are there any contractors on the team?" A high percentage of contractors is a bad sign. First contractors do not fully participate in teams as their engagement feels more temporarily. Second most contractors I know either have no idea about coding or are extremely prolific but then their code looks like hell. (But I'm sure this is a coincidence.)

How Does it Feel?
If all things are going well you might be invited to meet the team, which in some cases has the final word in the hiring decision. And even if not, a tour of the office never hurts. I always try to meet my future team mates and spend at least half of a day with them. How does it feel spending time with those people? Are they in a good mood or is there a dark cloud of fatalism hanging above them? Are they friendly and open minded? How do they communicate? You will spend a lot of time with them, so you better like them.

What Do You Know?
During this time I "interview" my future colleagues. Well, it's not a real interview, more a chat to figure out what makes them special. My questions just guide me during these conversations. And I would also tell them things about myself. Most likely they know better than me if I fit into the open position and the team or not. To get started I'm looking for someone who knows more than me. In our technical domain it's very easy to know more in some area than most developers. "So what's your background? How long have you been developing software? What were your most exciting projects? Was it cool stuff? Were you excited about them?" (Did you care?)

As these people are developers, I get more technical and ask them about their favourite Java framework or library. I like language fundamentals so Apache Commons fit me perfectly, but that's just me. Everyone has his or her favourite toys. Think about them, discuss them. Are they esoteric, mainstream, fundamental, boring? On the other hand the similar question, which is the first library to add to a new project, has only one right answer. It's not Apache Commons and it's certainly not Spring or Hibernate, but it's JUnit. Even if you do not develop test driven, you will need it sooner or later. If we happen to talk about design I always ask "What's your favourite design pattern?" I hope it's not singleton, because singletons are evil, all other answers usually lead to a good discussion about object orientation. After talking for some about what he knows and what I know I sum it up with my last question of this section, "What will I learn from you?"

Do You Care?
Next I'm looking for individuals that love to code, that care for their craft and are burning with enthusiasm. Asking about hobbies and how one spends his or her personal time doesn't sound related at first, but it is. The real question is if he or she does code on personal time, maybe is even an open source contributor. For example, some time ago I met an older guy and he didn't seem very enthusiastic. The whole team had impressed me so far and I was sure that he would just be a nine to five employee. I started asking him about his duties on the project but quickly moved to the area of personal time. It turned out he was into wireless network topology and played around with wireless infrastructure at home. He wasn't coding but still fooling around with technology. I was impressed.

Further I want to know "Which blogs do you read?" If you are interested in your craft you have to stay in touch, play around with new stuff and read books. The pragmatic programmers recommend reading four technical books each year. So "What was the last technical book you read?" Talking of books, "Who is Donald E. Knuth?"

What About Quality?
Ultimately I'm looking for software craftsmen and I wouldn't be genuine without diving into code quality and clean code. Everybody with just a faint interest in code quality, object orientation or self improvement knows Robert C. Martin, so I always ask if they know Uncle Bob. Finally I try to determine if I will hate this person every time he or she commits some changes to the repository: "What is most important about code? What is the worst defect for code? What is clean code for you?"

Warning
Let's finish with a word of caution: These questions help me figuring out if a future job is good for me but it's not foolproof. It happened that everything looked great and still the real job experience was awful. Also be aware that these questions result from my personal experiences. They need not to be good for you. Don't blame me if you end up in a group of coders from hell.

Headhunter Fail

Recently I was called by a headhunter. I don't mind being contacted by them if they do their research properly and have interesting things to say. But it wasn't the case this time...

The Call
I don't know why these people (headhunters) always need to call. I personally would prefer an email. I will read it when it suits me. But being soft-skilled, they have to talk (i.e. call). Talk if you have to, but please research and find the proper phone number! This poor fool called the company's main number and my boss was the one to pick it up. This was quite an embarrassment.

She (the headhunter) told me about a position I might be interested in. Well, I don't have time to talk, but send me some details, would you. You know my email address? Yes, of course you do, in contrary to my mobile phone number. So what's the point in calling me anyway? Is there a checkbox on your form to make sure the candidate is able to cope with embarrassing phone calls? But I'm repeating myself. Just don't call me.

The E-mail
Finally I had some hard information in my mailbox.

• Who she was.
• Company she was working for. (I had not known it before.)
• Web page of the headhunting company. (I checked it out and it did not impress me at all.)
• and the offer.

The Job Offer
And the offer really made me laugh. Here is a rough translation (Google translate rules ;-):

Our client is a reputable company in the high-tech
industry and international leader in its niche.

Wow! It's a reputable and internationally known company. Who cares, but what's the niche? What is it doing? Is it producing stuff or just selling things? How big is it?

Your tasks:
* Analysis and development of existing systems
* Creation of software applications
* Testing of applications
* Implementation
* Fixing bugs in existing applications

Aha, my task is to develop software. That's expected from an offer for a Java software developer. Not much to see here. I would like to know what kind of applications, how the testing is done etc.

Your profile:
* Some kind of technical education
* Experience in software development in Java
* Experience with XML
* Understanding of development processes
* Dynamic personality
* Fluent in English

So one should have experience in developing software with Java. At least here is some information: The company which is hiring is using Java and XML (somehow). They have some kind of development processes. Or they want to have one. But what kind of process, e.g. waterfall or agile? Or do they just want people to be aware of documentation and testing. Is there any Java developer out from school that would not match this profile?

I'm not interested at all
The offer was poor and boring, I didn't even bother to answer it. But still I'm asking myself how the headhunter-researcher could think that this a position I might be interested in.

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.

backwater, in-house development

Maybe I am too strict, or my expectations are far too high for the average company (which is likely the case). However, while staying with Herold I reached the conclusion that "backwater, in-house development" does not provide footing for IT innovation. Obviously this is true but the ironic part is, that management pretends that it's there. Listen to this:

Two years ago they came up with the idea of science Fridays. Every Friday the development department would be locked, so no one would disturb us and all developers would try out new stuff or study books. Well, it never happened. Last year the idea was still around, we would just start after this particular next release. And there is always some pressing next release to work on. The WTF of this paragraph is that two months ago I was asked by the boss of my boss if I used the science Friday time for some project. I had to laugh out loud.

Another idea was born at the beginning of last year: every month a member of the team would prepare some topic, e.g. new features in .NET 3, and present an overview. There was not a single one of these presentations, the monthly meetings were always full with lists of features to be put into the next release. The proposed topics, already outdated, are still in my boss' drawer, waiting for their time.

How about professional training? "Sorry, there is no budget for that. Sales revenue just increased by 5 percent last year. The company is in critical condition. We all have to work harder."

So I experiment with new technologies at home and try to bring in something new from time to time. But I was told that we do not need it, because we are no IT company and there is no point in spending time to stay up to date because it is not our main business. And anyway I am not supposed to spend "so" much work time on education and research. But I have to, because as Heinz Kabutz once said, we're in an industry with a knowledge half-life of at most 18 months. Keep in mind that half of what you knew 18 months ago is worthless today, so you need to keep learning new things.

Do you work under similar conditions? Tell me how you overcome them to stay a top notch developer.