Mark Needham

Something I’ve noticed when I play around with Ruby in my own time is that I nearly always end up with the situation where I’m passing hashes all over my code and to start with it’s not a big deal.

Unfortunately I eventually get to the stage where I’m effectively modelling an object inside a hash and it all gets very difficult to understand.

I’ve written a few times before about incrementally refactoring code so this seemed like a pretty good chance for me to try that out.

The code in the view looked something like this:

<% @tweets.each do |tweet| %>
  <%= tweet[:key] %>  <%= tweet[:value][:something_else] %>
<% end %>

@tweets was being populated directly from a call to CouchDB so to start with I needed to change it from being a collection of hashes to a collection of objects:

I changed the Sinatra calling code from:

get '/' do
  @tweets = get_the_couchdb_tweets_hash
end

to:

get '/' do
  tweets_hash = get_the_couchdb_tweets_hash
  @tweets = tweets_hash.map { |tweet| TweetViewModel.new(tweet) }
end

where TweetViewModel is defined like so:

class TweetViewModel
  attr_accessor :key, :value
 
  def initialize(tweet_hash)
    @key = tweet_hash[:key]
    @value = tweet_hash[:value]
  end
 
  def get(lookup)
    if lookup == :key
      key
    else
      value
    end
  end
 
  alias_method :[], :get
end

The next step was to get rid of the get method and rename those attr_accessor methods to something more intention revealing.

class TweetViewModel
  attr_accessor :url, :messages
 
  def initialize(tweet_hash)
    @url = tweet_hash[:key]
    @messages = tweet_hash[:value]
  end
end

<% @tweets.each do |tweet| %>
  <%= tweet.url %>  <%= tweet.messages[:something_else] %>
<% end %>

I originally didn’t realise how easy it would be to make the TweetViewModel pretend to temporarily be a Hash but it actually made it really easy for me to change the code and know that it was working the whole way.

For someone with more Ruby experience perhaps it wouldn’t be necessary to break out the refactoring like this because they could fairly confidently do it in one go.

Another interesting pair programming ‘technique’ which I rediscovered while pairing with Priyank is that of doodling or drawing various parts of the solution when your pair is writing code.

I find that this helps to stop my brain wondering off and lets me reflect on what we’re doing from a higher level.

As an added bonus it also seems to allow me to listen more effectively to my pair.

From what I’ve noticed it works most effectively when the other person is reasonably comfortable with the code base and language which was certainly the case when I was pairing with Priyank.

I guess they also have to be reasonably comfortable with the idea that you’re still listening even though you’re not necessarily looking at everything that they type.

It doesn’t work quite as well in other situations where you’re playing more of a coaching role because you need to be more focused on the code that’s being written and provide help with respect to syntax, libraries or context on the code base.

I don’t remember noticing many other people doing this so though maybe this is just a solution for my ADHD.

The first time I came across the Pecha Kucha style of presenting was at the XP 2010 conference during the Agile Suitcase session where Pat Kua and some others talked about the practices, principles and values they most favoured.

I’ve never done one before but as part of the preparation work for ThoughtWorks University each of the trainers had to prepare one which we then presented to each other yesterday.

Despite the format being different than a normal presentation I still think the general idea of presenting any information applies – if you can tell it as a story then you have a much greater chance of keeping people’s attention.

This was advice that I first got from Erik Doernenburg almost 2 years ago when I was preparing to give an F# presentation.

I guess everyone has their theories and guidelines of what makes a good presentation but for me the underlying idea is that it has to be fun for me to present.

If it isn’t then it’s going to be really difficult for it to be fun to listen to.

These were some of the things I learnt from the whole process:

Preparation

• I generally don’t like rehearsing exactly what I’m going to say because I think it makes the presentation a bit less fresh when you actually do it. In this case however you need to have a reasonably good idea of how much you can talk in 20 seconds so it makes more sense.
• A side effect of doing this was that I realised how much I had originally planned to cram into some of the slides and was therefore able to split some of the narrative out onto another slide.
• Most of the ideas around slide design came from the Presentation Zen presentation that Sumeet gave us earlier in the week. I haven’t read the book but from what I’ve heard it seems to give some pretty good ideas for making slides engaging.

Delivery

• I tend to improvise quite a bit when presenting so I often throw things in that I think of at the time. The problem with doing that in a Pecha Kucha is that it can ruin the timings that you’ve practiced beforehand!
• I looked back at the slides way too much which I only realised from watching the video that Sumeet had recorded.

  I think it’s a bit of an instinct because in a lot of presentations I’ve done you want to point out something which is on the slide.

  In this style of presentation it was unnecessary.

• People interpret images differently – even with an audience of just 7 or 8 it was noticeable across the different presentations that some people understood or could relate to the images used by the presenter and some couldn’t! I’m not sure exactly how you get around that problem.

Overall I think this is a really cool presentation style and one that I think should be used more often.

Someone actually suggested we should get the ThoughtWorks management to give their monthly update reports in this format which would certainly be fascinating to see.

Something which I frequently forget while reading books is that it’s actually quite useful to know exactly why you’re reading it i.e. what knowledge are you trying to gain by doing so.

I noticed this again recently while reading The Agile Samurai – it’s one of the books we ask ThoughtWorks University participants to read before they come to India.

Implicitly I knew that I just wanted to get a rough idea of what sort of things it’s telling people but I somewhat foolishly just started reading it cover to cover.

I only realised that I’d been doing this when I’d got a third of the way through and realised that I hadn’t really learnt that much since the book effectively describes the way that ThoughtWorks delivers projects.

In Pragmatic Learning and Thinking Andy Hunt suggests the SQ3R reading comprehension method which I always forget about!

• Survey – scan the table of contents and chapter summaries
• Question – note any questions you have
• Read – read in entirety
• Recite – Summarise and take notes in your own words
• Review – Re-read, expand notes, discuss with colleagues

I don’t think it always needs to be quite as organised as this but I’ve certainly found it useful to scan the chapter headings and see which ones interest me and then skip the ones which don’t seem worth reading.

When reading The Art of Unix Programming I felt that I was learning a lot of different things for the first ten chapters or so but then it started to get quite boring for me so I skimmed the rest of the book and ended up reading just half of the chapters completely.

The amusing thing for me is that I knew about this technique a couple of years ago but I still don’t use it which I think that comes down to having a bit of a psychological thing about needing to finish books.

At the moment I have around 15 books which I’ve partially read and at the back of my mind I know that I want to go and read the rest of them even though there will undoubtably be varying returns from doing that!

I need to just let them go…

I’ve noticed recently that while pairing with various different people that I frequently ask my pair what they’re trying to learn through the approach that they’re about to take.

I tend to use it when I don’t really understand what my pair is doing and want to find out so that I can stay engaged.

It seems to be a more effective and less confrontational way of finding out than saying “What are you doing?” or “I don’t understand what you’re doing”.

There tend to be two outcomes from asking the question:

• We were about to go on a yak shaving mission and that’s not been averted.
• My pair was ahead of me, knew something that I didn’t and is now able to teach me that.

The following are some recent examples I can remember asking the question:

• My pair was googling how to do something which didn’t seem directly related to what we were doing.
• My pair was scrolling around files fairly rapidly and I wasn’t able to follow what they were doing

Of course this question is unnecessary if the driver is providing constant commentary about what they’re doing but it’s easy to forget that you have someone alongside you when you’re solving a problem.

Asking this question seems to be a reasonably effective way of keeping the pairing collaborative.

Earlier in the year I wrote about Chris Argyris’ espoused theory and theory in action and one of the interesting aspects to it which I hadn’t previously considered is how we treat people when their espoused theory and theory in action don’t match.

My tendency is to think that these people are hypocrites but Benjamin Mitchell pointed out in a conversation on twitter that it’s not really helpful to think that way:

Benjamin:

I find it hard to accept that other’s can’t see the ‘obvious’ gap I can between what they say and what they do (cf fund. attribution error)

Me:

@benjaminm I have the tendency to believe they are a hypocrite but I think it’s just an espoused theory/theory in action gap

Benjamin:

@markhneedham I think that’s the challenge I’m finding: allowing that people have a gap they are blind to, and not punishing them for it

A typical example where I’ve seen this happen is where someone (we’ll call them person A) teaches a group of people how to give effective feedback, probably by following some of the ideas from Pat Kua’s ‘Tightening the feedback loop‘ presentation.

The implicit assumption in the people being taught is that since person A taught them how to give feedback, person A should be able to give feedback perfectly every time.

Almost inevitably that tends not to be the case and there will be a time when person A ends up giving feedback which isn’t effective and is more a reflection of them than the person they’re supposedly trying to help!

If person A is working in a reflective mindset then hopefully they’ll realise their mistake and work on closing the gap between their espoused theory and theory in action.

If that doesn’t seem to be happening then we need to describe our observations to person A, discuss those observations and help person A improve.

A substantial part of William Noonan’s ‘Discussing the Undiscussable‘ is devoted to coming up with ways that we can deal with these conversations more effectively.

The learning from this for me is that just because someone teaches you something or talks about a topic very passionately that doesn’t mean that they’ve have to be perfect at it!

I learnt about the pomodoro technique a couple of years ago and while I did try it out sporadically back then, it’s only recently that I thought I’d properly give it a try when managing my spare time.

My approach without the pomodoro technique is to have a long list of things that I could do and then not really doing any of them because I feel bad about not doing one of the other things instead.

I therefore decided to give it a try so that I’d actually do something on the weekends and during evenings after work.

The pomodoro technique is defined like so:

1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4. Take a short break (5 minutes is OK)
5. Every 4 Pomodoros take a longer break

I pick the task I’m going to do based on what my motivation is at the time – whatever I feel most motivated by is what I’ll do next.

The most valuable thing for me so far from using this technique is that I’m able to stop myself from getting distracted.

When I don’t have a timer running I end up looking at echofon all the time and then loop between email accounts, Facebook and the BBC sport page even though 99% of the time there’s nothing that I want to read there anyway.

I don’t follow the 5 minute break between pomodoros particularly well – it’s often the case that I’m so pleased that I actually managed to do something in 25 minutes where I’d previously have yak shaved for 3 hours that I don’t feel like having that period of focus so soon!

Using the technique is supposed to also encourage us to delay external distractions as well e.g. if someone wants to talk to us then we should try and put that off until we’re done with the current pomodoro.

Mario Fusco wrote about this 18 months ago or so:

Said that, in my opinion there are also other important drawbacks in the pomodoro technique. What should I reply to my customer who is calling me, possibly from the other side of the ocean? That I am in the middle of my pomodoro and I can’t break it? Oh, please.

If someone talks to me in person while I’m in a pomodoro then I tend to just break it and talk to them because it seems strange not to. What I’m doing generally isn’t that important that I can’t talk to someone instead.

It’s also been useful for helping me to focus on learning one thing at a time.

Without the time constraint I can spend hours going off on various tangents thinking that I’m learning loads of things but in reality not learning all that much.

Now I can start with doing just one thing and if I think of something else that I want to do then I’ll add it to the end of the list if it’s not directly related to what I’m doing right now.

I’ve noticed that I sometimes have a bit of psychological dislike of chunking my time into these slots. Part of me quite likes the chaos of randomly following topics of interest in an unstructured way.

I also haven’t yet decided what I should do with instant messenger conversations that happen while I’m doing a pomodoro.

While writing this post I didn’t respond to any of the people I was chatting to but I enjoy IMing in an unstructured way and wouldn’t necessarily want to limit those conversations to just the breaks in the pomodoros.

I realised a couple of weeks ago while pairing with a colleague that I’ve become quite bad at interrupting people while they’re speaking.

I did have an inkling that I’d let my ability to properly listen to someone drift a bit but I hadn’t seen any evidence until my colleague pointed it out.

Somewhat ironically I actually wrote a post about active listening when I first started working at ThoughtWorks in 2006 and reading back over the listening barriers that I listed I realise that there are a few that I tend to break:

Filling-in: You don’t let the other person finish her sentence; instead you finish it for her.

Daydreaming: You get triggered by something the other person says and you’re off in your own world. You don’t have a clue what the person said to you.

Rehearsing: Rather than listening, you are mentally preparing what you are going to say. You might look interested, but you’re really concentrating on planning how you’re going to respond.

I find it really hard to understand what someone is saying purely by the words so I create images in my head based on what’s being said.

My tendency is then to just say what I’m thinking without actually realising that I’m going to interrupt the other person.

Of course that’s because I wasn’t totally listening because I was visualising what they were saying.

I feel that I still need to do this in order to understand what someone is talking about but I’m practicing keeping my thoughts to myself and then vocalising them if necessary when the other person has finished speaking.

The challenge for me is that when I try really hard to not break any of these barriers I’ll often end up being pretty silent when the person is speaking to the point where it might seem that I’m not interested in what they’re saying.

6 months after my first attempt to train one of the ThoughtWorks University batches was cut short I’m back in Bangalore again and spent the first few days of this week pairing with the grads.

It’s been interesting for me trying to balance how much I help and suggest ideas while still allowing them to learn at the same time.

At the moment I think I’m leaning too far towards helping and not realising until later on that my colleague hadn’t quite understood why I’d suggested what I did and therefore hadn’t learnt anything from my suggestion.

In one case we came across a similar problem later on in the day and I realised my colleague hadn’t understood exactly what I meant before.

This time I let them run with it for a bit until they came to the realisation that their approach probably wasn’t going to work.

They were then able to come to the solution that I’d been thinking about originally by themselves which I think is much more valuable than me telling them it up front.

A couple of times I’ve made the mistake of saying ‘yeh I know’ when they’ve pointed out that their approach isn’t going to work but hopefully I’m getting better at being less smug and keeping my mouth shut!

The other interesting thing about letting them run with it for a bit even when I think I know better is that there have been occasions where I was wrong and we ended up with a better solution through their exploration.

We’ve got a few weeks until the next ThoughtWorks University starts but hopefully then I’ll get even more chances to find the right balance between these two things.

After a few recent conversations with colleagues as well as my observations of several projects I’m coming to the conclusion that the way that people react in situations often differs significantly depending on whether they’re working in a large or small team.

One of the most obvious ways that this manifests itself is when there comes a need for someone to volunteer to take care of something – be it a particular functional area, communication with the onshore team or something else.

In larger teams there often seems to be a noticeable silence as no-one or one of a very few people offer to do it.

There seem to be two theories about why this happens:

• People assume that because the team is so big someone else will almost certainly take care of it so they needn’t bother.
• People assume that because the team is so big someone else is probably better placed than them to take care of it.

The problem that arises from people not taking care of things is that they don’t tend to feel as if they’re an important part of the team which invariably means that they don’t contribute as much as they could.

From what I’ve noticed this type of thing doesn’t seem to happen as much on on smaller teams – there are just things to do and they tend to get distributed amongst the people on the team.

The concept/stigma of ‘volunteering’ to do something isn’t there.

I recently came across Lewin’s Equation which suggests the following:

Lewin’s Equation, B=ƒ(P,E), is [...] a heuristic designed by psychologist Kurt Lewin. It states that Behavior is a function of the Person and his or her Environment.

I think this is reasonably accurate and I’ve noticed people who were fairly anonymous in larger teams become amazingly effective when they were put on a much smaller one.

The ‘agile’ approach to software delivery tends to encourage smaller team sizes and the idea of creating collective responsibility seems to be a key part of why you’d want to do that.

A typical approach to achieving that would be to split the building of a system into smaller teams where each covered a specific stream of work.

The collective team will still need to work together at some stage to build the entire system but at least within their streams they can feel a sense of ownership.

From my experience it can sometimes be quite difficult to do that because it seems that all the streams of work are tightly coupled.

I think we need to really endeavour to find a way to break them up though because it will lead to a much happier team and most likely a more productive one.