Knowledge- and career development as a perk

Recently, The Muse published an infographic comparing some awesome "perks" employees at Facebook and Google are offered. Apparently, you are offered free food, free gym and healthcare, colourful and inspiring offices and events that promote a friendly culture within the company.

However, I did not find anything related to competence- or knowledge development, or career coaching.

We can assume that most careers are likely to span several employments. For employers, this means we get to hire experienced professionals as they move on to new challenges. As employees, this means that we need to keep our knowledge updated to sustain market value when time comes for a change.

Some organisations may have observed that employees with high market value are over-represented in turnover. On the other hand, brilliant people seem to attract other of the same kind.

I believe that maximizing the market value of each employee in an organization would actually attract even more high-end people rather than making everybody leave for other companies.

A company with this belief among its core values would proudly offer their employees knowledge- and career enhancing perks:

• Recurring workshops and company conferences for exploring new technology and idéas in the field.
• A generous budget for courses and conferences.
• Trend-spotting and hype evaluation.
• Encouraged public speaking and writing.
• Celebration of gained insights and improved skills.

The consultancy I'm currently involved in is built this way. Basically, we want the company to work for its employees, not the other way around. We are about 200 employees which of about 130 are stockholders in the company.

So, besides getting free lunch and a ping pong table, I think you should expect your employer to care about (and coach you in) keeping your skills sharp, knowledge updated and maximizing your market value.

Silence and shortcomings

People will fail too

In agile, we acknowledge that mistakes and misunderstandings are going to happen, so we progress in small chunks and introduce safety constructions to fall back upon when things go wrong. Throughout the team we assume total transparency and constant feedback between individuals to be able to direct efforts in the right directions at all times.

Everyone is invited to share progress and setbacks as they occur. As all participants are jointly responsible for (and driven by) making the project a success, impediments must be brought to the surface as soon as possible so that we can act upon it.

But what happens when it becomes personal and the impediment is you? I found myself in this situation some time ago.

The ”Silence is the sound of risk piling up” quote is from Kent Beck's ”Extreme Programming Explained”. It basically means that elaboration and problem-solving should be performed by more than one person at a time, and that if a team room is not filled with chatter, the members are either trying to solve problems on their own or not solving problems at all. A silent team room is then a sure sign of problems (aka. ”risk”) being handled by individual developers, not communicated properly.

At the point of this tweet we had been regularly pair-programming on almost everything for a long time, but for some reason I hogged a story where I was supposed to be "The Expert". It became personal right at the sprint planning and as the days went by, I remember how ”my” story just kept hanging on the board. In stand-ups, I would line up a few task-sized notes on what went down, reassuring everybody that there were some unforeseen stuff in the way but that everything is going to be resolved, given that I got to work on in undisturbed for a few more days. But in reality, no substantial progress was being made.

As more days passed by the team started to be suspicious and finally they convinced me to allow them to help. With fresh eyes we established that the problem could be scoped down and we could soon show working software for the team and the customer.

Why was it so hard for me to ask for help? It was human weakness of course. Because if I told them the truth then, they would find out that I had not been honest before. It would be obvious that I wanted to look awesome in the first place!

As much as I would like to think that this would never happen again, I'm almost sure it will.

We, as agile practitioners, need to understand that members of our team, from time to time, will find themselves in trouble that they will find very hard to admit due to perceived personal shortcomings. They need to be offered a safe way out of this situation without having to loose face. This is how we rebuild trust within the team.

Trust is imperative for honesty, and honesty is what makes agile work. Watch out for the signs of fellow team members not feeling trustworthy anymore and save them from of a downward spiral of non-transparency and bad conscience.

The insidious SRP

SRP - the Single Responsibility Principle - says that a class should have one and only one responsiblity, and hence only one reason to change. While both the mechanics and rationale for this principle is really easy to understand it is very often violated, even by very skilled programmers.

The StringCalculator kata is a famous coding kata designed by Roy Osherove. The goal is basically to calculate the sum of a series of numbers delimited according to certain rules. By doing the kata you will practice test-first programming and refactoring.

Right on the instructions page are links to screencasts done by people implementing StringCalculator in realtime. As you would expect, the videos show fluent, test-driven implementations of the problem in different languages.

Lets assume we are working with step 1 and 2 of the kata. We should be able to add zero or more numbers in a string, delimited by a comma. A typical nicely recursive implementation looks like this:


While this code is probably a lot more simple than you would see in your day job, it is not immediately obvious what it does. And the reason for that is that it violates SRP!

The add() method have two responsibilities:

1. Adding numbers
2. Locating and parsing numbers in a String

It is really a bit hard to tell what code takes responsibility for which concept, and that is the whole problem.

Lets refactor the responsibilities of this problem into two parts.

1. StringCalculator: Adding numbers, as before
2. NumberArray: Locating and parsing numbers in a String

The same code, only possible to understand in a glance. The second responsibility is explicitly taken care of by another class. The API of NumberArray feels familiar and straightforward, so for the calculation business there is no need to get involved in that code.

When the kata continues with more parsing rules, all changes will go into the NumberArray class. The logic of adding numbers does not change.

As a programmer, you should always be looking for hidden and implicit concepts in your code. Just by extracting such a simple concept as finding numbers between the commas in a String, you can make yourself and the future you a huge favour!

Decoupling the individual from the problem

During the Daily Scrum meeting, it is very common to ask each person in the team the following questions:

1. What did you do yesterday?
2. What will you do today?
3. What is blocking progress?

This is standard procedure, as taught by Scrum trainers and Wikipedia. The first question gives the developer the possibility to shine a bit and get rewarded for being productive. The second question is used for putting focus on progressing further. The third question offers the developer to ask for help if something is getting out of hand.

But one team I worked with discovered that there are severe drawbacks with asking these questions.

To begin with, everyone wants to look good. So it was quite common for people to put up a handful of new notes on the board, explaining why they were important and then cashing in the reward by moving some of them to done. This took focus away from the existing notes so it was sometimes hard to detect if something did not progress as we visioned it earlier.

Secondly, people don't like giving promises that are not likely to hold. "So the work I plan for today is a few meetings, doing some critical support and maybe getting some work done on this story". It was useless.

Thirdly, and most importantly, it is really hard to ask for help. How do you know if something is really blocking or just being awry? And why do I have to ask for help every other morning when others seem to cope with their work just fine? Further, when someone asked for help, the rest of the team had already begun working on their stories in their heads and were not too willing to help out (courtesy of question 2).

One sprint, we tried talking about stories instead of people:

1. What work was done on this story yesterday?
2. What work will be done on this story today?
3. What is blocking progress on this story?

This made some dramatic change to how we worked as a team; it became natural to be two or more developers working on each story.

The first question still had the reward built into it, but without adding unplanned work items as we did earlier. The second question was answered more objective and realistic.

Finding impediments in the third question came to be a Q&A session on how the story could progress. Ideas were bounced and people offered themselves to help out.

Pair programming became normal procedure and with that the common understanding of how we developed software (aka. coding guidelines) became more widespread and agreed-upon.

To summarize, this was a game changer for us. All the benefits from the original questions were still there, but decoupling the individual from the problem enabled us to speak freely.

Tell them: It's a lifestyle

It's a well established fact that the world of software is changing crazy-fast. Computing capacity have generally doubled each year since anyone can remember and in 2013 we jealously try imagine how life as a programmer was in the nineties when IT was kind of experimental and not so much "we're all gonna die when the internet turns against us". And yeah, single-threaded!

If you are a successful (or at least employed) software developer today and plan to be that in say twenty years, history strongly suggests that you need to keep yourself updated with at least some of the trends in software.

That, or risk finding yourself hopelessly outdated and prematurely ready for retirement at an age where you would rather be working another decade or two.

The fact that you are reading this article suggests that you already understand all this, and actively seek ways to keep yourself up to date - which is great! Therefore, in this post I am not referring to You, dear reader, but rather your colleagues!

"The constrained colleague"

So many people in our business feel that it is just not possible to find the time it takes to read books, blogs or tweets, take courses or attend the local community meetups. The boss won't pay them for going to a conference or even surfing the net, for starters. And the family shows no sympathy for unpaid “work-related” stuff outside office hours.

So what can we tell them? Are they officially excused for not keeping themselves updated? Well, no!

Evolution will continue and even if Java is still around in 2030, who wants to be among the "Cobol guys" of their generation?

It's as simple as this: Software development is a lifestyle. Just like people in medicine, we have to monitor industry trends and research and adopt techniques continuously. Just like carpenters, we have to try new tools and become proficient with those that matches our personal style. Just like musicians, we have to practice practice practice on your craft to keep it solid and fluent.

Here is some advice I occasionally try to articulate:

• Our days contain many small chunks of time when you're not expected to have your focus elsewhere. Listen to a podcast when commuting or working out. Read a blog article when you're eating or, uhm... well. Replace that spy/thriller novel you’re reading at night with a book on functional programming, agile or design patterns.
• Go to the local community. Explain to your spouse how getting knowledgeable and networked pays off with a better job in a few years from now. 
• If your employer refuse to sponsor conferences or courses, find ways to pay for them yourself like bringing lunch instead of eating out to save money. Or you could always change company or become your own employer.

Software development is a lifestyle, and part of it is keeping up to date. Some employers will coach us in this, but we must take responsibility for our own careers in the long term.

TDD Kata: Batchrunner

(Do one task at a time, and try not to read ahead.)

Purpose: Practice on using fake objects for sensing.

Goal: Implement a transactional command batchrunner that ensures that a series of commands either all runs successfully, or the whole chain is rolled back.

Interface

public class TransactionalCommandRunner {
  public void addCommand(ICommand c);
  public void execute();
}

public interface ICommand {
  public void execute();
  public void undo();
}

1. Start simple:




1. TransactionalCommandRunner can execute zero commands.


2. TransactionalCommandRunner can execute one command.


3. TransactionalCommandRunner can execute many commands.




2. Implement rollback




1. If the first command fails (throws an Exception), the rest of the commands are not executed.


2. If the first command fails, it is not rolled back (undone).


3. If the second command fails, the first command is rolled back.


4. If a subsequent command fails, all preceding commands are rolled back.


5. The exception thrown by the failing command is rethrown from TransactionalCommandRunner.execute().