Advanced Personal Branding

This February I wrote three articles on personal branding for software developers. I discussed creating and strengthening your brand step by step: branding all your accounts and defining your motto, sharing and promoting yourself and maintaining a technical blog. I sorted these activities by difficulty into a kind of personal branding ladder, which will vary for different people depending on their personality. This is the final article covering advanced, that are more difficult and more time consuming branding activities.

Go Out!
Personal branding is - well - personal. So you need to meet people in person, interact with them. Find your local user groups or technology related meetups and attend regularly. Join the discussion and talk about the topics you are interested in. You do not need to present anything formally. Regular listeners who ask questions now and then are vital for the existence of any community. There is no way you can fail here. As long as you are authentic, people who share your enthusiasm will want to meet you and discuss your topics. You are interesting to like-minded developers, you just need to allow them to find you.

Present at a User Group
After attending the user group meetings regularly, it is time to take the next step and present something yourself. It it true that some people would rather face death than talk in front of a crowd, but the usual audience at community meetings is forgiving. Remember, most people in the audience are like you and already know you in person. They gave similar beginner talks or know that they should. First time speakers cannot be expected to give flawless talks, and that is the beauty of user groups, full of natural human beings, delivering refreshing and idiosyncratic presentations. Some communities are so successful in encouraging their members to talk, that they continuously breed world class speakers.

Nevertheless I am not saying that your talk does not need rigorous preparation and practice up front. There are several basic things that you can screw up in presentations in general, like giving a wall of text or death by power point. Do your research and read some articles on preparing content, creating slides, presentation techniques and such. There is also much content available on technical presentations in particular. In fact there is only one rule you need to keep in mind: Your presentation is not about you. It is not about you becoming a rock star speaker, it is about serving the audience. For example if you want the audience to read your code samples, make them easy to understand and write them in a large enough font. If the font is too small you are actually conveying the message that you do not care if people read it.

I gave my first presentation at the local Java user group five years ago. It worked out well and today, many presentations later, I still like to talk to smaller groups because these presentations often become conversations and large crowds make me nervous. If you have an extrovert character and like talking to people, giving regular presentations could be less cumbersome than maintaining a technical blog. Here you might change the order of steps. Anyway you need to do both!

Organise a User Group
Organising a local community is hard work. Meetings have to be scheduled, speakers contacted and so on. Usually the group leaders' work is not seen but vital for a thriving community. Step up and help the organisers, your help will be appreciated. Or maybe there is no local community for your favourite topic, then it is high time to create one. Creating new communities is easy using tools like Meetup or social media platforms. For example Aaron Cruz is a "community factory". Be created a new meetup for a topic that clearly has been missing, Clojure Vienna and organised a few meetups, which were a great success. Then he transferred the ownership of the group to the most enthusiastic member and went on to create another meetup.

Your group does not have to be local, there are good examples of virtual communities as well. For example Jonny Andersson runs a remote reading group, a small group of people sharing the interest to learn from books. Another, quite different example is the vJUG, the on-line Java User Group, which brings well known speakers on-line every month.

As I said above, being a community leader can be a lot of work. For example Peter Brachwitz of Clojure Vienna told me that he prepares a presentation if nobody else volunteers to do so. Now that is great leader spirit! Despite the effort, running an user group is a highly rewarding activity. You will be able to watch great presentations (if you organise them ;-) and have "exclusive" access to speakers and other community leaders. For example in the Java world there is an International JUG Leader's conference once a year.

Present at a Conference
Presenting at user groups is often informal, sometimes becoming a discussion rather than a polished presentation. The larger the audience gets, the more formal and professional your presentation needs to be. When submitting a talk to a large and well known conferences like Devoxx, you are competing with many other speakers to get accepted. Also your future talk needs much more practice. When facing 80 or 100 people for the first time, who are all looking at you in eager anticipation, your brain is likely to shut down, unless you are naturally gifted. At least mine did, and I did not even talk to really large crowds till now.

So your presentation needs more preparations, several dry runs, maybe even showing it to a colleague for feedback. This is much work, which keeps me from doing it too often, if at all. And I do not believe in talks with little or no preparation. Even if you do not mind making a fool of yourself, you are doing your audience a disservice. You are wasting their precious (and limited) learning time, when instead they could listen to great talks in parallel tracks.

At international events you might meet new people and grow your network beyond your local area. While this is already true for all attendees, the "magic" speaker badge lets you stand out. Other speakers will talk to you and regular attendees will stalk you to ask questions ;-) And speaking at international conferences can make you famous, really world-famous if you work hard. Working hard means attending at least one conference each month, all around the globe, besides your regular work. This is really tough, as veteran speakers like Dan North or Thomas Sundberg have assured me.

Organise a Conference
Did you spot the pattern? Find some event, attend, contribute and finally organise one yourself. What is true for local events is even more true for conferences. Again you can start small with local one-day conferences embedded in larger communities like Eclipse DemoCamp, Google DevFest or Code Retreat. Your event is likely relying on the infrastructure and help of a well running user group, because you cannot do everything by yourself. For example when we started Eclipse DemoCamp in Vienna five years ago, we did so with the help of the Java User Group Austria.

A much better example is GeeCON, my favourite Java conference which I attend every year. I believe its story is the following: Some guys of the Polish JUG met and complained about the lack of a great conference in Poland. They decided to create one. Already the first version of GeeCON was a huge success and over the years the conference became one of most awesome events I have ever attended. But GeeCON is also a perfect example of the hard work needed to run such an event. If the organisers are not in a hurry, e.g. to buy more wireless routers or fix some other problem, they are walking around the venue slowly, with tired, dark circled eyes. Lukasz Stachowiak, member of the GeeCON organisers, once told me that preparations for the next version of GeeCON start on the very next day after the previous one has ended. I am sure this is also true for Devoxx and all community-driven conferences.

Write a Technical Book
Finally we reach the top of the food chain. Writing a book is probably the most time consuming activity. Tomek Kaczanowski told me that it took him two years to get his Practical Unit Testing book delivered. But the time was well spent. His book is getting more and more popular, which is nice in case of the little revenue each book gives, but much more important is the widespread reception of his book.

As I did not write any books myself, I can only refer to articles about doing so. For example Jack Shirazi's discussion if writing a technical book is worthwhile covers income vs. non-direct income vs. time spent of writing a book. It says "People are impressed by authors. If you have had a book published in a certain area, even if that book did not do particularly well, people are impressed." Since 2007 when he wrote the article, things have changed in publishing if you decide to self publish, as Tomek did. Jurgen Appelo recommends to read at least three books about self publishing before starting with it. And if you think about writing a book you should read Rand's excellent explanation how to write a book first.

It seems that writing a book is sort of making addicted. Many authors I know did write more than one book or at least think about writing another one, even if it would make their wives unhappy (again). Tomek decided to give his third book away for free. Bad Tests, Good Tests is a short book, nevertheless it took him some time to write it. Sure, giving the book away for free removes its direct income aspect, but increases its non-direct income, as more people will get it. Anyway, free or not, it is a great book and you should read it!

Thanks to all the people I used in this blog post as examples for successful branding activities, especially as I did not ask for their permission to do so.

Teaching using Mob Programming

Since some time I am training young developers. I meet with different teams and we discuss topics like Pair Programming or I run hands-on workshops in the Coding Dojo format. Occasionally I pair program with single team members on difficult tasks as mentoring on steroids.

The first session
Last November one team I work with grew tired of Coding Dojo examples and wanted to work on real code while keeping the good atmosphere of our sessions. I envisioned sort-of a dojo in Randori style with everybody of the team pairing with me one after another. It ended with me being busy driving and all others navigating in different directions at the same time. Additionally, as teacher, I had to think about the proper action for the code and discuss the different proposals of navigators. It was difficult and showed many opportunities for improvement.

Enter Mob Programming
At the same time I learned about Mob Programming. Mob Programming is defined as all the brilliant people working at the same time, in the same space, at the same computer, on the same thing. That means that most of the mob's work is done sitting together in a group work area. All the necessary skills are present together in the same room, so there is no waiting time. If you have never heard of it, I recommend watching this presentation by Woody Zuill about Mob Programming, presented at the Oredev conference last year. Woody's team is using this technique since some time for all production work.

My Sessions
Inspired by Mob Programming I applied some of its concepts to my sessions. For example I never drive and I also do not navigate. Instead I try to meta-navigate the team of navigators. (Or sometimes I simply dominate everybody and tell the driver exactly which keyboard short-cuts to type. ;-) In the following sessions we refactored some code and created unit tests. All these sessions worked out well. Now, after running more than ten Mob Programming sessions with various teams during the last year, here are some things I noticed:

Communication
Mob Programming enables communication. In one of the first sessions, the architect of the team saw something in the source he did not like. He mentioned it to be an architecture violation but the other team members did not know this aspect of the architecture. It was amazing to see them talk. Although being on the same team they had not talked about it before. It is known that regular pair programming spreads the knowledge throughout the team and Mob Programming does even more so.

Participation
"Mob learning" differs from regular "mob work". Some people like learning sessions less than "the real thing" Also as in any team and any team activity some are more interested in the session than others. But usually participants are engaged, probably due the good communication. One major factor for active participation is the team size. Sessions with too many people do not work out well. Larger groups split into subgroups with their own agendas. I recommend group sizes of ten or less people.

The teams I work with are mixed teams with members of different experience and skill. It happens that some junior members cannot follow a high level discussion and zone out. I believe this is a symptom of the group needing more knowledge sharing and communication in general. I guess this does not happen to experienced "mobs" but I do not know. As moderator I try to get all people engaged and ask the seniors to explain the problem to the whole team because "the team needs to know". I also move forward very slowly so everyone is able to get along. This is even more important in the end of the session as people get tired and zone out more easily.

Exhaustion
Due to their active nature "mob sessions" are quite exhaustive. Ten minutes of break each 50 minutes of work help to keep people fresh. Also regular rooms run out of fresh air quickly, so I open windows as much as possible during these breaks. Most meeting rooms I have been to have the projector on the shorter side of the room, so almost all people have to sit with their heads turned. This is uncomfortable and tiring when sitting like that for several hours. While there are no dedicated work areas for mobs, internal training rooms are better because they are usually arranged like classrooms. But I have yet to find the perfect mob working area in the enterprise.

Topics
In my Mob Programming sessions I want to show the team certain techniques, e.g. splitting a large class. The session needs a defined, explicit goal and everybody needs to be clear about his or her expectations. The format works well for showing a work-flow from end to end. Also people like sessions with big structural changes, e.g. refactoring towards a pattern. On the other hand they do not like extracting small structures, discussing names and other clean code related activities. People do not feel progress there. This might be a drawback of working with real code, the urge to make progress is higher than in a dojo. Maybe these sessions are only appropriate after the participants have gained a certain level of competence by attending Coding Dojos. Even with successful mob sessions I mix in a Coding Dojo every third time at least. In the dojo people work on the details and practise the basics. In some way mob sessions are orthogonal to dojos and as such a great addition to our learning tools.

Driving
I rotate drivers every ten to 15 minutes, as proposed by the Mob Programming guide to keep people active. Usually there are participants who do not want to type. These include junior team members, who probably are afraid to get criticised in front of the team, and on many occasions female developers. If someone does not want to drive, I ask why, but till now did not get any clear answer. I guess some people do not want to type because they are slow. Once a senior guy refused but then did drive. He was horribly slow and used no short-cuts at all. He even did not find the rename refactoring in the Eclipse menu. It was embarrassing.

Moderation
These kind of work is more demanding for me than dojos or even theory sessions. I rehearse my theory presentations and experiment with the planned kata before a dojo, but it is impossible to prepare fully for such a mob session. I ask the team to send me the code we will work with a few days before and then work through it in detail. Knowing the code up front makes me feel more secure and saves time because I do not have to read the code during the session. Such a session is team work and I do not have a strict outline except the defined goal. In fact I can never be sure about the right thing to do because it is not my code. I have no idea about its requirements, history and constraints. This is stressful because as mentor I am asked for guidance which I might not be able to give. It happens that I have to say that I do not know, which is not a problem but still makes me feel that I failed.

Conclusion
I am facilitating Mob Programming sessions since almost a year with different teams in different companies. Some worked out great, some did not. Some were fun, some were just exhausting. Should you try it? Maybe, I do not know. Do I recommend it? No, I stick with Woody's style of "not recommending", No I do not recommend it, I am just sharing because people have been asking about it. But I am genuinely interested in this mode of working and will continue to experiment with it. Unfortunately I never participated in a real session, working on production code. That would be another kind of experience. (Hint, hint! All you mobs out there, I am open for your invitations ;-)

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.