Hosting Public Coderetreats

I described the needs and benefits of inhouse Coderetreats in the previous article. (In case you did not read it - a Coderetreat is a full day hands-on coding workshop focused on the fundamentals of software development and software design. It is a day full of fun and excitement.) In this second part about Coderetreats I will say more about the opposite of (buying) an inhouse event, which is (hosting) a public one.

Hosting a public Coderetreat is obviously more work for the organiser, adding promotion of the event and handling registration. There are several reasons why companies host a Coderetreat. I ran a public Coderetreat in Venice sponsored by Interlogica. The people of Interlogica were passionate about our craft and wanted to connect with like minded individuals. Three out of four attendees were not connected with Interlogica at all and the exchange of ideas and networking was great.

Sponsoring a Coderetreat is Awesome!
The hosting company is usually also the Coderetreat's main sponsor. Sponsoring a public Coderetreat is a marketing activity. Interlogica wanted to increase its visibility. While we cannot expect a huge impact from a single event, it definitely was a good start. I supported them because a Coderetreat is real value provided to participants and the Craftsmanship community. As the event was free for the participants, someone had to pay for the room, lunch, time spent on organisation, my (facilitator) travel expenses and so on.

The sponsor deserves our gratitude and at least some "link love". The host and facilitator may create more buzz on Twitter and other channels, depending on the free time the host has during the sessions. I post at least some images of the sessions and retrospectives, drawing some attention to the sponsor as well. As sponsored event, this is part of the deal.

Finding Local Talent
Many companies have trouble finding developers to hire. Hosting a public Coderetreat is a great way to present the company. Sometimes a representative of the sponsor will open the Coderetreat and make participants aware of open positions. I recommend distributing handouts of vacancies in the room and on the tables.

Public Coderetreats are run on Saturdays to allow people to participate. Starting Saturday morning attracts only the most passionate developers, who want to learn and engage in deliberate practice. These are exactly the kind of developers companies want to hire. A lady from Interlogica's marketing department told me that "people who understand (the idea of Coderetreat) and come are the people we want to hire."

Community and Networking
The Software Craftsmanship community is growing and a Coderetreat is also a networking event. After a few Coderetreats the participants get to know one another. For me a Coderetreat is like a class reunion, I usually know at least half of the participants and some of them are dear friends whom I would like to meet more often. For beginners or people new in the city it is a great way to get in touch with local craftsmen.

A Coderetreat ends with drinking beer in a local pub in the evening. This is another opportunity to talk to fellow software professionals. At the Coderetreat in Venice, the sponsor set up a small reception including cheese, wine and finger food for all participants. (Did I mention that they rock ;-) Interlogica's CEO was amazed by the number of different people he met and talked to during that time.

Free for Participants
According to Corey Haines, one early proponent of the Coderetreat format, the event must be free of charge for participants. Many organisers ask people only for a safety deposit of ten to 15 Euro. The deposit is refunded as soon as the person shows up and is used to pay beer in the evening if the person does not. I strongly recommend using such a safety deposit to make sure that people show up. Most organisers use Eventbrite for handling the registration, because it does not take any fee when a ticket is refunded. An Eventbrite registration page might look like the one I used for GDCR14.

Promoting the Event
After setting up Eventbrite, every public Coderetreat should be registered at coderetreat.org and promoted through Twitter, Facebook and other channels. Coderetreats in large cities, e.g. Berlin or London are sold out in under a week. In smaller communities we need to allow enough time for people to get spread the word that a Coderetreat is coming up. I recommend having the registration ready at least one month in advance to have enough time for sharing and advertising the event.

Whenever I run a Coderetreat, I talk directly to local programming language user group leaders and ask for their support to promote it. Even if I do not know these group leaders, their members might be interested in coding activities. As a Coderetreat is open to any programming language, it is much more fun to have participants from various programming backgrounds. Collaborating with user groups ensures that there are participants offering more interesting languages like Go, Elexir, Haskell, Dart and so on.

The same is true for women in technology. For a Coderetreat in Berlin last year, one facilitators got in touch with several local women-only programming groups, like Rails Girls or PyLadies, told them about the event and opened private registration for them. He waited for a week before making the registration public. After public registration started, the event was sold out in a week.

Being Awesome!
So if your company wants to be seen to care for craftsmanship, dedication and quality, you are looking for great developers to hire or you just want to work in an awesome company, hosting a Coderetreat is the right things to do. Even when you are not able to host a full Coderetreat, buying food for participants or covering expenses is appreciated.

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.