I think there’s sometimes a reluctance for people to volunteer their strengths so we end up with people working on tasks that they hate that other people in the same team would enjoy.

It’s not about you

Pink then goes on to point out that even if we do work out how to play to our strengths we still need to ensure that we’re focusing on our customer/client.

Pink calls this focusing outward not inward.

In terms of working in technology consulting that would therefore be along the lines of ensuring that we’re focused on solving our clients’ problems in the best way for them rather than the most interesting way for us.

Persistence trumps talent

The underlying idea is that people aren’t born brilliant at any skill, it only comes through practice and if we’re intrinsically motivated to do something then we’re much more likely to put in the time it requires to become really good.

To add to that I think intrinsic motivation is highest when we’re focusing on our strengths so this piece of advice is linked with the earlier one.

Make excellent mistakes

Pink talks about making excellent mistakes which he describes as ‘mistakes that come from having high aspirations, from trying to do something nobody else has done’.

I think this is somewhat linked to the idea of failing fast although it seems to be perhaps one level beyond that.

One observation I have here is that smaller companies seems more willing to make excellent mistakes. As organisations grow the aversion to risk because of worries about loss of reputation increases which makes excellent mistakes less likely.

One of the cool things about software development is that despite writing code for 5 years professionally and just under 10 altogether, there are still a phenomenal number of things that I don’t know how to do.

The learning opportunities are vast!

One of the areas which I’ve known I don’t know that much about is Unix command line tools such as awk and sed.

Since the majority of projects that I’ve worked on have involved using Windows as the development environment I’ve never had extended exposure to the types of problems we get on a project which require their use.

I’ve finally got the opportunity on my current project and my colleague Priyank and I have been looking to use those tools wherever we can.

We’ve learnt how to do some very basic commands with both the tools and although those few command have been very useful for allowing us to quickly manipulate text files we didn’t quite realise how little we knew until coming across Eric Pement’s ‘useful one-line scripts for Sed‘ article.

I knew that Sed and Awk were powerful tools but I had no idea that you could do this many things with them.

I’m now reading the sed and awk book so that I can close this gap in my knowledge and trying to use these tools wherever possible even if it does slow me down a bit initially.

In terms of the four stages of competency model I would say I’ve moved from being ‘unconsciously incompetent’ with respect to sed and awk to being ‘consciously incompetent’.

This is because there IRB is implicitly called ‘inspect’ on the result which shows a different string than what we would actually get.

While writing this blog post I’ve also learnt (thanks to Ashwin) that ‘p’ is not the same as ‘puts’ which is what I originally thought and has been driving me crazy as I try to understand why everything I print includes an extra backslash!

The following code:

p"/mark/dir/".gsub("/", "\\/")

is the same as typing:

puts"/mark/dir/".gsub("/", "\\/").inspect

We were able to change our Capistrano script to escape forward slashes like so:

We recently created a new project to handle the reporting part of our application and as with all our projects we decided not to checkin any configuration “.yml’ files but rather ‘.yml.example’ files which people can then customise for their own environments.

So in our config directory would look something like this when you first checkout the project:

config

database.yml.example

some.yml.example

And we’d need to copy those files to get ‘.yml’ versions, changing any parameters that we need to for our local environment.

The disadvantage of this approach is that you have an extra step on using a project for the first time, a step that I’ve been meaning to automate.

Several people ran into a somewhat confusing error message when running our rake file after forgetting to create these ‘.yml’ files which looked like this:

Despite being part of numerous retrospectives over the past few years I don’t remember actually facilitating one until my current team’s last week.

I’ve gradually come to appreciate the skill involved in facilitating this type of meeting having originally been of the opinion that there wasn’t much to it.

I recently read Agile Retrospectives which has loads of different ideas for activities beyond just creating ‘went well’ and ‘could improve’ columns and then filling those in as a group.

In the best retrospective I’ve attended recently the facilitator had us work together in small groups while coming up with ideas to fill in on the retrospective starfish.

I really like the idea of working in small groups because I think it encourages more participation in the discussion of problems on the team.

My general observation is that a sizeable percentage of people are more comfortable taking part in discussions in smaller groups than with the whole team (~ 25 people).

We split into groups of 4 or 5 and then populated a time line of the project since the last iteration before going across the board and discussing the most prominent topics.

These were some of the main areas that I had thoughts about during and after facilitating this retro:

Time keeping

Perhaps somewhat ironically given the amount I’ve been hassling my team mates to keep meetings short this one over ran by about 25 – 30 minutes, taking around 90 minutes instead of 60.

I had a rough idea of how quickly we needed to move across the board in order to finish on time but it got thrown completely off track by one point which resulted in a much longer discussion than I had expected.

I tried to move across the rest of the items a bit more quickly to make up for that but it didn’t really work.

I’d be interested to hear what a more experienced facilitator would have done in this situation as I’m sure it’s very common.

Participating

On a couple of occasions I was asked to give my opinion on certain things so I had to step out of my facilitating role temporarily, join the discussion and then step back in.

I think this worked reasonably well but I can see how it would be difficult to keep quiet if you had really strong opinions on a topic being discussed!

Summarising the discussion

I see part of the role of the facilitator being to try and summarise what is being discussed so that it can be written up afterwards and distributed to the team.

I didn’t realise how difficult this is, especially if the discussion drifts slightly away from its original direction.

I found it quite tricky to follow what was going on at times but luckily one of my colleagues was able to help me out when I didn’t quite get it right.

Overall it was an interesting experience and I hope I’ll get another chance to try this role again soon although for now we’re trying to rotate it around the team to give everyone an opportunity to facilitate.

A fairly common trend on nearly every project I’ve worked on is that at some stage the client will ask for more people to be added to the team in order to ‘improve’ the velocity.

Some of the most common arguments against doing so are that it will initially slow down the team’s velocity as the new members learn the domain, code base and get to know the other members of the team.

Frank also identifies the following consequence of increasing a team’s size which I think is perhaps even more important:

the decrease of communication levels brought by the addition of new nodes

The majority of teams that I’ve worked on have had 15 or less people but there have been a couple of exceptions including my current team.

We currently have somewhere around 25 people working in Pune and then perhaps another 10 in Chicago so it’s the biggest team that I’ve worked on. Having said that I do recognise that it’s quite small in size compared to some of the other projects in India.

The following are some of the consequences with respect to communication that I’ve noticed. These are applicable as we increase team size and also just generally when having larger teams.

Standup takes longer

This is somewhat inevitable since there are more people taking part. It’s therefore much easier to lose focus on what other people are saying.

We’ve managed to reduce the time to something more reasonable by not having any discussions in the stand up, instead taking them offline.

Other meetings are much more difficult to control with more people in and I think it requires quite a skilful facilitator to allow everyone to take part and still ensure that the meeting doesn’t overrun.

Technical decision consensus

Getting consensus on any technical approach is much more difficult than when there are just a few developers on the team.

Technical discussions seem to take way longer than I’m used to because we try to ensure that everyone gets to express their opinion.

There are also more people available to then disagree with that opinion which tends to mean that we go around in circles more frequently.

I’ve found that there are rarely more than 3 or 4 ways to solve any problem so a lot of the time people are expressing similar opinions in a slightly different way.

When the team gets this big I don’t think it makes sense to include everyone in all technical decisions. My current thinking is that having a group of 3 or 4 people involved in each one is more than enough.

Greater distance between team members

I think the optimal setup for a software team is to have all the team members working on a single table – this means we can have around 12 members per team.

That way everyone is within talking distance of each other and communication remains smooth.

Once we have more people than that we need another table which means that there are 2 rows of people in between people on the far side of each table.

Priyank and I have been pairing a bit lately and we thought it’d be interesting to try and not use the mouse for anything that we had to do while pairing.

Editor

Priyank uses GVim (Yehuda Katz recommends MacVim if you’re using Mac OS) so we already don’t need to use the mouse at all when we’re inside the editor.

One annoying thing we found is that sometimes we wanted to copy stuff from the terminal into GVim and couldn’t think of a good way to do that without selecting the text on the terminal with a mouse and then ‘Ctrl-C’ing.

A bit of Googling led us to the xsel command which takes standard input and makes it available on the clipboard.

For example we’ve been using sed and wanted to copy the code we’d been spiking into a shell script:

Although we mostly split the work on my project so that there aren’t too many dependencies between the teams in Chicago and Pune, there have still been some times when we’ve designed major parts of the code base in Pune and have needed to communicate that to our Chicago colleagues.

I’ve never seen this situation so it’s been interesting to see which approaches work in trying to do this effectively and allowing the people in the other location to have input as well.

Explanation on specific email threads

While it’s useful to communicate the approach being taken by email we’ve found that it makes more sense to have a specific email thread for that conversation rather than tagging it onto something else.

It’s surprisingly easy for emails to get lost amongst the hundreds of others that people receive each day but at least if the important messages are all under an email with a clear title then it’s much easier to deal with.

While discussing this with Saager, he suggested that an effective approach he’s used previously is to include details of design decisions taken in commit messages and then point people towards those particular commits.

Of course however skilful we may be in communicating via email it does help to talk on a conference call as well – that medium seems to work better for explaining the reasoning behind decisions, especially if there’s a disagreement in the approach.

Commit early

As much as we can explain design decisions in emails or conference calls it’s still not as useful for people as seeing the actual code which is something we didn’t totally appreciate until recently.

We’re now trying to ensure that we check in more incrementally when making big design changes.

This should help to tighten the feedback loop and ensure that we get the benefit of the design skills of people onshore as well as offshore.

Something which I initially considered as a disadvantage with checking in incrementally is that you will most likely get suggestions/criticism about what you’ve done even if you had already planned to address some of those areas anyway.

As a colleague correctly pointed out, the intention is generally good and it’s not the end of the world if someone suggests something you could have done better anyway.

In summary

These types of things seem obvious looking back at them now but I guess it isn’t so obvious to me because you never have to think about them at all when anyone interested in the code is sitting in the same room as you as it’s been for me when working onshore.

I’d be interested to hear any other approaches that have worked well for others working in a distributed fashion.

This means that we want to ensure that we don’t have an over reliance on one person to handle any communication.

We have a call once a day between developers in Pune and Chicago and the Chicago guys have been able to achieve this by rotating the person attending the call.

In Pune we’ve typically had half the developers attending the call but perhaps only one or two actually speaking.

I originally didn’t think of this as being a problem because those two guys were really good at communicating and in other teams I’ve worked on we’d typically have the tech lead and maybe one other communicating with other teams.

In this case we are communicating with people in the same team and by chance a few weeks ago both of the main communicators from Pune were away at the same time so we had to have the Chicago call without them.

Perhaps unsurprisingly others were able to fill the gap that had been left and as an added benefit the guys in Chicago had now had the opportunity to interact directly with more people from Pune.

A interesting and positive side effect I’ve noticed is that the people who had now started communicating directly with team members in Chicago seemed to become more involved in the project as a whole and are now also more likely to communicate via email than they may have been previously.

Our challenge now that both the original guys are back is to ensure that the whole team still remains involved in communication with Chicago and don’t delegate back to those two every time.