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.

Silvester Party XSLT

After finishing my Code Cop Journeyman Tour last month I am free for new adventures. My backlog of insights I want to share is huge, but today I will celebrate the turn of the year. In Austria we usually celebrate the New Year's Eve with a party so let's see the results of my Silvester "party".

Last Global Day of Coderetreat, one participant used MSBuild to implement the rules of Conway's Game of Life. Maybe it did not improve his grasp of object orientation but surely trained his skills of writing build scripts and besides all it looked like a lot of fun. I have worked on the Game of Life in many mainstream programming languages, e.g. Java, JavaScript, Ruby and Scala as well some as less common languages like Dart, Pascal or even good old BASIC. MSBuild seemed like a perfect change from the usual and made me think about unfamiliar or even bizarre approaches, e.g. using Apache Ant or even XSLT (XSL transformations).

Over the years I have implemented the Prime Factors kata and the FizzBuzz kata in XSLT but never anything more elaborate. Although XSLT is a Turing complete language, I was not sure it would work out. On the other hand, the representation of the universe, i.e. the cells and their neighbours, might be some basic XML structure removing the need to implement any complex data structures. I even chose an HTML table to make visualization trivial.

<table>
  <tr><td>_</td><td>X</td><td>_</td></tr>
  <tr><td>_</td><td>X</td><td>_</td></tr>
  <tr><td>_</td><td>X</td><td>_</td></tr>
</table>

Based on this data structure I started writing XSLTunit test cases for evolving a 3x3 grid:

• dead cells should stay dead
• a single living cell in the middle should die
• the 2x2 block in the upper left should stay alive
• the 2x2 block in the lower right should stay alive
• two single cells in the upper left should die

By triangulating the fake implementations I approached a solution, at least that was what I thought. It turned out that I did not nearly know enough about XPath and most of my selectors using parent, preceding-sibling or following-sibling were wrong but happened to return an expected result in my test cases. When I thought I had finished the code nothing worked as expected. Now how would I debug my XSLT code? No, I hate debugging and took a step back to write some tests to verify the selection of the living neighbours alone:

<xsl:template match="td" mode="countLiveNeighbours">
  <xsl:variable name="currentX"
                select="count(preceding-sibling::td) + 1" />
  <xsl:variable name="precedingRow"
                select="parent::tr/preceding-sibling::tr[1]" />
  <xsl:variable name="followingRow"
                select="parent::tr/following-sibling::tr[1]" />

  <xsl:variable name="neighbours"
                select="$precedingRow/td[$currentX - 1] |
                        $precedingRow/td[$currentX] |
                        $precedingRow/td[$currentX + 1] |
                        preceding-sibling::td[1] |
                        following-sibling::td[1] |
                        $followingRow/td[$currentX - 1] |
                        $followingRow/td[$currentX] |
                        $followingRow/td[$currentX + 1]" />

  <xsl:value-of select="count($neighbours[text() = 'X'])" />
</xsl:template>

As soon as I finished the countLiveNeighbours template, my previously created solution worked as expected.

<xsl:template match="td">
  <xsl:variable name="liveNeighbours">
    <xsl:apply-templates select="current()" mode="countLiveNeighbours" />
  </xsl:variable>

  <xsl:choose>
    <xsl:when test="(current() = 'X' and $liveNeighbours = 2) or
                    $liveNeighbours = 3">
      <xsl:call-template name="live" />
    </xsl:when>
    <xsl:otherwise>
      <xsl:call-template name="die" />
    </xsl:otherwise>
  </xsl:choose>
</xsl:template>

I had chosen XSLT as bizarre approach on purpose, so I guess it is ok that it took me eight hours of Silvester to figure out the above solution ;-)

The 13th and Final Week

The 13th week of my Pair Programming tour started a bit uncertain. I had not been able to finish the arrangement with the company I had planned to visit. I had got positive replies from my contact there that his team was interested and that he would ask the HR department for final approval. And then there was only silence ;-) Additionally winter came to Austria and the temperature fell by ten degrees just over night. I was exhausted and thought about quitting the tour prematurely.

But then, in the beginning of the week, the first FirefoxOS DevTreff meetup in Austria took place and I met some really enthusiastic hackers who immediately agreed to host me. So I went on with my tour for another week. First I visited a development team to run some in-house training. Besides the usual Coding Dojo we wanted to try something different this time. We started refactoring some nasty piece of production code Randori-style. It was really interesting to see the whole team communicating, e.g. the architect was surprised to see certain patterns in the class we worked on. Everybody was engaged and I wanted to encourage everybody to contribute so I abandoned the Randori-dojo protocol and the session turned into Mob Programming. It was fascinating. In the end the team agreed to use this style of working for our next session as well.

Déjà vu
Then I visited Jürgen Cito in his office at the University of Technology, Vienna. I had a strong sensation of Déjà vu because many years ago, I had roamed these very same rooms in the beginning of my own studies. Jürgen told me about his master thesis about Statistical Methods in Managing Web Performance. It looked great and I am looking forward to the finished work. He had finished his research and was just wrapping things up so there was little we could work on. Instead Jürgen told me about an idea he had for some time and so we created Sinatramania. Sinatramania compares (or rather will compare) the different frameworks based on the Ruby Framework Sinatra by implementing the same simple REST API in the different programming languages and frameworks. We created a Cucumber test suite and started with the Sinatra reference implementation. It was much fun and I will definitely send him some pull requests as soon as things settle down. If you use one framework inspired by Sinatra, e.g. Flask, Laravel, Ratpack or Scalatra, then I encourage you to add your implementation to Sinatramania.

Tying up loose ends
I started my tour visiting the Vienna Ruby Community, presenting them my idea of Journeyman Tour. Back then the leaders of the group had invited me to run a Coding Dojo but it had taken almost three months to find a suitable date while I was busy on tour. Finally I came back to deliver the promised Ruby Coding Dojo. We worked on the String Calculator Kata, a perfect exercise for a first time Dojo. We had excellent discussions and I particularly liked Ben's question if three powerful Ruby functions like split, map and reduce might be too much to squeeze into a single line of code. Yes, with great power comes great responsibility ;-)


Friday I visited an old friend. His line manager had agreed to my visit but he had not bothered to ask for full, official approval up the hierarchy. So I cannot name him nor his employer. Nevertheless it was a great day. In the morning we discussed TDD and integration tests. Then we created a new Maven plugin, test first of course. I proposed to create a guiding test, which we built using the Maven Invoker Plugin. It took us half of a day to get the guiding test ready, because asserting the proper behaviour of our plugin under test was tricky. I learned a lot and Maven Invoker looked like a good alternative for the Maven Plugin Testing Tools, especially when considering the problems I had with them. Using the guiding test, further development was smooth and we would have finished the plugin on the second day. I was really sad that we only had one day to work on it.

This is the end my only friend, the end
As the title of this blog post implied, this was the last week of my tour and it ends my diary. You ask me why? You say that my tour sounds like some serious fun and I should go on forever. Actually I cannot. First I need a break. Second I ran out of companies. I wrote earlier that it took me roughly a man-month (160 hours) to find the 16 companies that hosted me and during my tour I did not have time to look for new hosts. Further I had planned my tour to last for three months and it had been exactly three months. Finally I need to go back to work and earn some money again. Although lunch was free, I spent a lot of money on commuting. Although my tour has ended, I still have many things I want to share. I will discuss what I have learned in upcoming posts, so stay tuned.