From Good To Great Developer – downloads and resources

Posted by Chris on March 26, 2009

I have now finished my little tour of presenting “From Good To Great Developer” at various Swedish conferences. I want to say a big “Thank you!” to everyone who joined me at any of those occasions. As promised, you can download the presentation and code from my web site on the resource page for the talk, where there are also links to various resources mentioned in the talk. For anyone who missed it or want to spread the word to your colleagues, I would be more than happy to come to your company for a session.

Finally, I also want to thank my friend Erik Emmerfors for drawing the great comic strip describing the story of the incompetent bank robber. For more information on what this story has to do with my talk, see the summary flyer on the resources page.



Posted by Chris on February 25, 2009

focus1I use Spaces and Quicksilver to increase my focus on the task that I am currently working on. By hiding focus-stealing applications from view in another desktop, and interacting with them through Quicksilver, I can stay focused on my task. Read on for more details.

For a couple of weeks now I have been deliberately trying to become more effective by improving focus during daily work. I have had a lot of inspiration from Staffan Nöteberg, whose book Pomodoro Technique Illustrated is a great read. I have tried using the Pomodoro Technique a bit, but for various reasons (one being synchronizing with my colleagues) I’m trying other similar techniques such as PCEO now. Regardless of which technique I have been using I have also tried using some technology to help me focus, and that is what I wanted to write a quick post about here. Specifically there are two applications, Spaces and Quicksilver, that I have been semi-using on my Mac for a long time, but not really been able to see or draw any real benefit from.

Focus on the task at hand

When I am working I want to be able to focus on the specific task that I am doing right now. For instance, if I am writing an article I want to have Textmate (or some other application for writing) running, perhaps a couple of browser windows/tabs with some information I need for the article, and perhaps a Finder window. Just things relevant to this task, and for those applications that can have multiple windows or tabs only the relevant windows.

What I do not want to see is iTunes, Mail, an IM application, lots of browser windows/tabs with “other stuff” not relevant for this task, a development environment, Finder windows for other things, my note-taking application or anything else that could steal my focus if I would look at them.

A simple solution is of course to simply quit all these other applications. But that means it will take a lot longer to switch context to other tasks, or catch up on mail and other communication during a quick break. And perhaps I do want iTunes running since music helps me focus, I just do not want to see it because I can easily get stuck navigating songs. Minimizing all these applications is not much better than closing them, since it still makes it difficult with context switching.


The solution for me has been Spaces, the built-in virtual desktop application in Mac OS X Leopard. Using Spaces, I have arranged my desktops according to tasks. The basic setup has three desktops that always exist:

  • My first desktop starts out blank. This is where I work.
  • The second desktop is my communication hub. Mail, IM, Twitter, RSS reader etc, all those kind of applications are normally always running here. I also have my calendar and todo’s open and showing here all the time.
  • My third desktop is my reading place. Articles, blog posts etc that I defer reading until later are dumped here.

At any given time, I normally have a couple of other desktops created. For instance, since I am interested in photography I normally have a number of browser windows open specifically for reading about photography, and also for following different communities that I take part in. I want to be able to quickly overview what is going on in that area, so I more or less always have a separate desktop dedicated for that. Other ongoing work such as sales usually have a dedicated desktop as well.

More importantly, when I am working on some task (on desktop #1) and decide to postpone it for later, I usually create a new desktop and dump everything there. That way I am ready to start a new task with an empty desktop, and I can easily get everything back when I decide to switch back to the previous task.

Finally, I really like having a communication and planning desktop. This is where I go when I come back from a quick break, to get an overview of any changes that might affect my planning.

Recovering gracefully from interruptions

When I am focused on something, possibly in a nice state of flow, I do not want to lose that focus to an interruption I did not plan for (breaks should be planned often to reflect and re-plan as necessary). However, interruptions cannot simply be ignored. The Pomodoro technique describes some good principles for handling internal and external interruptions. Usually it comes down to making a note of whatever was so important to interrupt you, and scheduling time for taking care of it later.

However, there might be some interruptions that I want to act on immediately. For instance, something as simple as iTunes switching to a song that I do not want to listen to right now. I could switch to iTunes, but that would carry the risk of ‘getting stuck’ navigating songs and thereby losing focus. Another example is sending a quick email (such as just a file that someone needs), or adding something to a todo list. The common theme for all of these are that I need to interact with some other program, but to avoid losing focus I do not want to interact with it directly.

Email a file

Email a file

This is where Quicksilver really shines. With just a couple of keystrokes I can email that file to my colleague, without even seeing the mail application. It is still ‘hidden’ in another desktop, and there is no risk of me seeing that super interesting but non-urgent email lying in my inbox. Quicksilver has tons of plugins that allow me to do these quick indirect interactions with applications, which means I can recover from an interruption without losing my focus.

Pen and paper rules!

With that said however, as a final note I want to warn you not to rely to heavily on technology. Pen and paper are the base components of whatever focus-helping technique I use. Daily planning of what activities I need to do today, simple follow-up on where my time was spent, and taking notes of things to reflect upon later is best done using just pen and paper.

From Good To Great Developer – Spring Tour 2009

Posted by Chris on January 30, 2009

Last year, after a user group meeting, me and Kim Gräsman were talking over a beer about how hard it was to get everyone else to care about code the way we do. For instance, there we where at a user group meeting, while ‘they’ were not. This got me thinking about what we usually do when we try to ‘help’ others see things our way. We try to teach them things such as refactoring, design patterns and TDD, with no other result than us becoming frustrated when people do not understand or want to use them.

Further thinking led to a presentation, titled Great Developers, that I gave at the SweNUG Code Camp last summer. There I talked about what I believe a great developer to be, and how they work with code to produce a great result. I had the opportunity to do this again a couple of times during the autumn, and I also submitted the presentation for a couple of conferences during this spring.

JFokus 2009I did however change the title, and also the abstract, since my main point in the presentation moved from ‘what is a great developer’ to ‘why are we having trouble helping good developers become great developers‘. This week I gave this presentation to 300-350 people at the JFokus 2009 conference in Stockholm, Sweden. I think it went really well, and I hope people liked it. At least one person commented afterwards:

Your presentation has been one of the most concrete, clear and to the point presentation I have heard since a long time ago, and I can mention that my motivation regarding what you have said has changed.

With the Java-people covered, I move my focus to the Microsoft TechDays conference in Västerås, Sweden on the 17th to 18th of March 2009. And if you happened to miss me on any of these occasions, there is a final chance at the Scandinavian Developers Conference in Göteborg, Sweden, on March 24th.

I hope to see you at some of these events! Take a look at the lineup of speakers for them, they promise to be great sources of inspiration and learning.

Notes on Designing Experiential Meetings

Posted by Chris on December 05, 2008

About a month ago at the AYE conference I participated in a full-day workshop on Designing Experiential Meetings, led by Jerry Weinberg (with support from Esther Derby). I really enjoyed it and learned a lot. A couple of days ago I was talking to Tobias Fors, telling him about the workshop, and he convinced me to post my notes in a blog post. So, here are my thoughts and notes from that workshop.

I must stress that these are my interpretations and notes of what was said, even when I refer to Jerry or anyone else.

What does experiential mean?

Wikipedia says:

Experiential learning is learning through reflection on doing [...]

In my own words, an experiential meeting (or workshop, training session etc) is a meeting that includes activities that allow you to experience something (through discussion, hands-on work, simulations or something similar) and then learn from that experience by reflecting on it. So in a sense it is about participation as opposed to just listening. But I would not describe a training session as experiential just because it includes an exercise. Without the reflection part a lot of potential for learning would be missed.

So, that brings me to the basic structure of an experiential meeting.

Exploration, Discovery, Application

Jerry described experiential meetings as having three basic components. First we Explore the topic we want to learn about, next we Discover something about it, and finally we try and find a way to Apply that knowledge. Sometimes these are used in cycles. For instance, while Applying something we learned we might move in to a new Exploration.

A style, or pattern, that I like is a session that starts with the participants exploring some concept, either individually or in small groups. They then get into larger groups (or the one group) to share their thoughts and discover patterns or key points. Next, a simulation is used where they will apply and reinforce these key points. The simulation helps the participants explore the concept further, and in the following debriefing they discover even more knowledge.

Whatever happens, happens

A basic principle of an experiential session is what Jerry described as “whatever happens, happens”. As the leader of a session, it is not your job to make sure that something specific happens, or to decide what knowledge the participants should get from it.

As a session leader you are not a trainer with knowledge to push to the participants. You are a facilitator for the learning of the group and the individuals in it. If the participants happen to take the session in a direction you had not planned for, do not automatically force them back. Of course this does not mean you should just be a bystander, or come to the session with no plan. That is not facilitating. Instead, use everything that happens to help the participants get maximum value from the session. Have a plan, and modify it as you go.

Always debrief

I guess there might be a difference for different people, but for me all the learning happens in the debriefing. Or rather, the debriefing sets my mind up for effective learning. During the debriefing I will learn a lot, but even at a later time I will realize things which I believe would have been much more difficult without the debriefing.

During the debriefing participants get to hear other participants’ perspectives. By sharing your own thoughts with others you will refine and extend your own understanding. An interesting way for the facilitator to reinforce this is to find ways to make the debriefing itself experiential. Instead of just having participants say what they thought, help them activate more parts of the brain by using alternative ways of providing feedback.

The Spectrogram activity is a good example. Ask the participants about how they feel about something. Tell them to stand up and place themselves somewhere along an imaginary line from max/agree to min/disagree. Interview people about the reason why they are standing where they are, what their context is.

As the facilitator, make sure that you ask open-ended questions of the participants. A good way to start is just asking about what they saw or heard. Move on to things that puzzled them, and next ask about insights. Finally, ask them about one thing that they can take back to work and apply. Notice the pattern? This is basically the Exploration, Discovery, Application structure again. :)

Safety and comfort

An experiential session can be very different from what many participants are used to. Make sure that everyone understands that participation in any exercise is completely optional. People can have many reasons for feeling that they do not want to be part of an exercise. For instance, Jerry told a story of someone with strong religious beliefs that would not take part in an exercise that involved playing cards. It can of course be much simpler than that, some exercises involve close contact that many people are not ok with. People who do not want to take an active part in an exercise can be given the option of being an observer for the group. They will see things that others do not, so this can benefit both themselves and the rest of the group.

When designing exercises (see more below), have safety and comfort in mind. Are the participants complete strangers to eachother, or have they been working closely together for a long time? Do not use exercises that would need paramedics to be close, or ones that single people out as “losers” (survivor-style). Giving someone a role that will make them look stupid can make them checkout of the exercise, either physically (by leaving) or mentally. Either way, it will affect their learning, and possibly the rest of the group as well.

Regarding people checking out (for different reasons), this is a strong reason (there are others as well of course) to be more than one person leading the session. Use lieutenants to help keep an eye on people. This way if a participant needs attention, the exercise can continue with the rest of the group while someone works with that person to make sure they are ok.

Designing exercises

To end with, here are a couple of tips on how to design exercises and activities for experiential sessions. To me, the most important advice is to keep the exercise itself simple, and let the learning happen in the debriefing. Think about the objective of the exercise, what do you want people to learn from it. Then think about all the steps of the exercise, all the twists it takes, and consider whether they help achieve that objective or if they distract from it. Note that I am not saying there must always be just one clear objective (the great XP game comes to mind), but that you should consider the elements of an exercise to make sure they do not distract from the objective(s).

This is also a good way to invent new exercises. An advice that was given was to try reversing the objective(s), consider how that affects the elements of the exercise, and design from there. I would recommend going further and try using all parts of a technique such as SCAMPER (not just reversal) to design new exercises with different objectives.

Finally, it can be a good idea to have backups for some exercises. Specifically if you are planning on using an exercise that takes some time, it can be necessary to have a shorter backup to use if previous parts of the session ran longer than expected.

To wrap up, in my own experience it helps a lot to include some humor and fun in the session. Try to create a positive energy, and go with that energy throughout the session. And remember, whatever happens, happens!

Collectively defining great teamwork at Øredev 2008

Posted by Chris on November 22, 2008

It is that time of the year again. Øredev, the largest software development conference in Sweden, was this week and we at Blueplane sponsored it again. This year they had a great idea. To encourage people to meet other people and actually go speak with the exhibitors, they had a game for the attendees. Each attendee had to collect a stamp from six different exhibitors to have a chance of winning some nice prizes. Not only that, by collecting those six stamps they also helped contribute money to Unicef for building schools in Africa. A great idea for a great cause!

Each exhibitor who participated in the game (by contributing money to Unicef) got to choose what they wanted attendees to do to get a stamp from them. Some just gave them a stamp when they asked for it. Boring! I wanted to maximize both our opportunity to meet people, but even more so I wanted to encourage people to talk to other attendees. So I came up with a game about collectively defining great teamwork.

To get a stamp from us at Blueplane, an attendee got one of our great looking business cards, which also doubles as a small index card. On the back side they would write a single word that defines great teamwork, according to that person.

Next, we taped the card with the word to their name badge that everyone wore around their neck, and then they had to walk around the conference looking for someone else with one of our cards with a word written on it. When they found someone (hopefully someone they had not met before) they then had to discuss and decide together which of the two words they had that were more important. Between their two words they had to assign seven points, such that the more important word perhaps got five points and the other got two points. They had to assign the points together and then come back to our booth, together, and share their thoughts and how they divided the seven points. That earned them their stamps, and we had an iPod Touch that they now had a chance of winning.

We collected the words and summed up the points they got, and then used this data to write the following definition of what great teamwork is. To everyone who helped us do this, and contributed to building schools in Africa, thank you!

Great teamwork as defined by attendees at Øredev 2008
Great teamwork builds on communication between individuals committed on a common goal. A keen interest in sharing knowledge between one another brings the team members together, creating a fun environment to work in.

I want to give credit to Tobias Mayer, who’s thoughts and description of a session he ran at Agile 2008 inspired me when I designed this game.

From good developer to great developer

Posted by Chris on October 30, 2008

During this autumn we at Blueplane have started a series of breakfast seminars. Next time, on Tuesday 11 november, it is my turn. My presentation is called “From good to great developer” (or as it is presented in Swedish, “Från duktig till fantastisk utvecklare”. I will talk about how I characterize great developers, and show an example of how a great developer implements a new feature while at the same time improving existing code, following an attitude I describe as Simplify, Improve, Modify. I will also discuss ways to motivate and support good developers to take that attitude and become great developers.

As I have been preparing the presentation, I have tried to identify the people will attend it. Next, to make sure that my material is relevant to these people, I have written down their reasons for being there, in a user story format. This way I can quite easily decide if an idea I want to talk about is actually relevant for the audience, or just a darling.

Here are the stories I came up with:

In order to deliver high-quality software with predictability, as a manager I want to support good developers to become great

In order to have more enjoyable challenges, work less with frustrating bugs and more with interesting problems, and advance my own skills, as a great developer I want to advance my colleagues into peers

In order to have more stimulating work and earn the respect of my colleagues, as a good developer I want to have some hands-on advice on what I can do to improve as a developer

If you want to attend the seminar on Tuesday 11 november and have a free breakfast (breakfast is served at 07.30), send an email to The place is St Gertrud Konferens, Östergatan 7b, in Malmö, Sweden. See this pdf (in Swedish) for more info.

AgileØresund 2008

Posted by Chris on August 26, 2008

As one of the driving forces of AgileØresund, I am involved in organizing a conference in Malmö next month. We are planning the conference to be a participant driven conference, meaning that the content is driven by the participants through lightning talks and open space discussions. It will be a full day free of charge, so I hope a lot of agilistas from the Öresund region show up.

Go check out the web site (only in Swedish) and sign up for the conference, and I will see you there!

The elevator pitch introduction session

Posted by Chris on July 02, 2008

Start a conference with a big introduction session where every speaker has to present a 45 second version of his or her session. This would make it easier for the attendees to decide which sessions to go to, and also increase the quality of the sessions.

Photo from bogenfreund’s Flickr photostream

I was recently at the Agila Sverige 2008 conference (which I guess some would call an unconference since it was made up of lightning talks and open space sessions, instead of normal 45-90 minute breakout sessions and keynotes). I presented a lightning talk version of Real Retrospectives – Not Just Talk (download pdf).

I really liked the constraint of presenting the same ideas as before, only this time I only had 10 minutes. In fact, since I am a big fan of the elevator pitch, I started by presenting my content in 45 seconds. After this I told the audience that I had now delivered my core message to them. If they thought the ideas where not that interesting or they already knew the topic, or just did not like me for any reason, they could switch to a parallel session. If not, I would spend the rest of my 10 minutes to build upon that core message and hopefully give them some more value for their time.

This got me thinking, it would be an interesting idea to have a conference start with a general session, where every speaker had to present their session in 45 seconds. This would force speakers to really think through their content and boil it down to the key ideas they want to convey, which in turn I think is a good recipe for improving the quality and consistency of the content. It would also be a lot of help to attendees who are trying to decide which sessions to attend with multiple concurrent tracks. For one thing it would of course be helpful to see what the key ideas are, but also just to see and hear the speakers in action would make the decision easier in some cases.

Photo from mag3737′s Flickr photostream

To take this idea even further, a variation could have the attendees voting for the sessions they think should be included in the schedule after getting the elevator pitches. Attendees could have an Emergency Stop button (for stopping the elevator, giving the speaker more time) to indicate that they liked the idea and would like to hear more about it by attending a full session (however long that is). This would not work for every conference of course, but it would be an interesting idea to try…


Posted by Chris on August 24, 2007

Late friday evening, after some wine, whisky and beer and a movie, I could not think of anything better to do than to catch up a bit on my blog reading (it’s not just my posting that is more or less dead right now, parental leave has left a lot of unread items in Google Reader). After reading a couple of hundred posts, in the end it was two that really stuck in my head. Maybe it was just the short and simple format of them that made it easier to read them, but they really spoke to me.

I used to have the latin phrase Docendo discimus (We learn by teaching) as my personal motto, but I think Jason Yip really nails it with:

There’s no substitute for sharing knowledge

Jason says you should always explain why, especially to children and others who really have no idea why something happens the way it does. Never just say it’s magic or so. I couldn’t agree more.

On a somewhat similar note, Paul Duvall discuss why you should “fire your best people … reward the lazy ones“. Now, the title is of course a bit misleading although there is some truth to it, but the message of the post for me can be boiled down to the following quote from the post:

If the knowledge is locked in your head, you are a less valuable, not more valuable, resource.

To me, these posts say that it is always important to take the time to share the knowledge instead of just “making it so”, whether it is something we implement in software or just something we say to someone.

Programming with your nose

Posted by Chris on July 04, 2007

While flipping through an old MSDN magazine* today, I was inspired to this thought: Programming is done with the nose! One way of describing programming as using your nose would be to refer to the analogy of code smells. While I have always liked that analogy, that was however not what I had in mind here.

The article that inspired my thought was Stan Lippman’s column entitled “Is Programming an Art?”, where he compares software development to art. I like calling software development an art, in the same way as the process of creating a Scotch Blended Whisky is often called an art (as opposed to creating malt whisky which is called a science, since it is mostly about following a protocol). When creating a blended whisky, the Master Blender will use nothing but his nose to select the combination of malt and grain whisky to include in the blend. Sometimes a blend will include up to 50 different sorts of whisky. And every batch of blended whisky that is produced must consistently taste and smell the same way. Anyone interested in Single Malts knows that whisky from different batches, even different barrels in the same batch, will have different characteristics, so being a “Noser” (which is a much cooler title than Master Blender) is truly a difficult job with no easy way of simply following a protocol.

This art of “nosing” in many ways remind me of creating software. Although many would like it to be, software development is not about following a simple process of pressing a couple of buttons and drawing some lines. Producing software requires coding, and no project is ever the same as another one.

Here’s another thought: Maybe this means we can finally retire the term Architect? Lets start using Noser instead, at least for architects doing real work. :D

* Ironically, this was right after I had listened to Don Box and Chris Sells on .NET Rocks!, talking about how no one actually reads magazines anymore and they could not remember when the last time they saw a copy of MSDN magazine was. I think that was the main reason I picked it up and browsed through it. :)