Mark Needham

I’ve been using Vim instead of RubyMine for the last month or so and it’s been interesting observing the way that I browse code as I add plugins to make my life easier.

Between files

I generally don’t know exactly where in the folder structure different files live since I’m used to being able to search by just the name i.e. RubyMine’s Ctrl-N

Yahuda Katz wrote a blog post earlier in the year where he listed some of the plugins he’s been using – one of which is called Command-T and allows exactly this functionality.

I also quite like the ability to quickly access files that I’ve recently opened i.e. files which are in the Vim buffer or RubyMine’s Ctrl-E. The FuzzyFinder plugin provides that functionality.

I’ve also tagged all my Ruby gems and the source code of the project using Exuberant CTags which then allows easy browsing to methods/classes.

Inside files

I’ve noticed that the way I browse inside files has changed since I started using Vim.

I used to just scroll around files using the mouse but now I find myself moving around a file by line numbers instead.

A lot of the commands for file editing in Vim are based on moving/changing/deleting to a particular symbol so you become almost a human parser when reading a line of text.

I found/am finding the following quite useful for learning Vim shortcuts:

• Vim cheat sheet
• Vim quick reference card
• Efficient Editing with Vim

When coding in Java/C# I rely quite heavily on auto complete to tell me what methods I have available to me on a certain object.

Although I don’t use it that frequently the SuperTab plugin works reasonably well when you do need help.

Mike pointed out Vimlander-2-The-Quickening which has some of the plugins I mentioned and several others ready to use.

One of the more interesting differences between Indian culture and my own is that in India there appears to be more adherence to a hierarchy than I’ve experienced before.

ThoughtWorks tries to keep a reasonably flat hierarchy so I think the idea of hierarchy would be much more obvious if I was working at one of the big Indian services organisations.

Between peers conversations don’t seem to play out any differently but someone in a position of authority is more likely to be able to get their opinion across and accepted with less resistance than they might experience without that authority.

On several occasions it’s been only me and maybe a couple of others involved in discussions if someone in an authority position expresses an opinion assertively.

I asked several colleagues why this was and they pointed out that when they’d previously expressed an opinion in that type of situation it didn’t have any impact so they’d stopped doing so.

I can’t decide whether or not it really matters – the situations where authority has any influence are relatively infrequent – but it would be cool if all opinions were assessed just on merit.

Of course these are just my observations so it’d be interesting to hear others’ experiences.

I’ve been reading The Goal over the last week or so where Eliyahu Goldratt describes the theory of constraints as a philosophy for allowing organisations to continually achieve their goal.

Goldratt goes on to describe bottlenecks – resources which have a capacity less than the capacity being demanded of the system.

The capacity of the system cannot be higher than that of the bottleneck which means that we need to find a way to optimise the bottlenecks in any system.

In a software context I think an agile/lean approach to delivery is quite effective for allowing us to quickly see where the bottlenecks are – this will typically be where the cards are piling up on the wall.

The problem with this is that we can frequently end up blaming the people working in the role where the bottleneck seems to be.

On the projects I’ve worked on stories tend to get stuck in QA since there are significantly less testers than developers on any team.

Since blaming isn’t particularly useful Goldratt suggests two ways to optimise bottlenecks:

1. Don’t waste time of the bottleneck
   • Processing defective parts
   • Sitting idle
   • Work on unnecessary parts
2. Take load off the bottleneck

The bottleneck ends up sitting idle when we wait until we’ve completely finished a story before showcasing what we’ve done to the testers.

It’s frequently the case that we can QA test a piece of functionality before the whole thing is complete.

We can avoid processing defective parts in this case by talking through a story with a tester before we start and thinking of the bugs we might create in development. Unit testing can also be useful for reducing defects.

I’m not sure how working on unnecessary parts would work most of the time – perhaps testing features which aren’t required for the next release would be an example of this.

We can achieve the second to an extent by ensuring that we have more scenarios automated so that a tester doesn’t need to manually cover them each time.

We could also get developers to temporarily take on the role of a tester to increase capacity but from my experience that doesn’t seem to work out as well in practice as it seems like it should.

For the majority of the time that I’ve spent in Pune so far language hasn’t been a big deal at all but there are a couple of differences that I didn’t initially anticipate.

The local language

While the official office language is English my colleagues seem more comfortable talking to each other in Hindi so quite frequently the conversation will move into Hindi if someone isn’t directly speaking to me.

I initially found it tremendously frustrating that I couldn’t understand what was going on in group discussions and while I did point it out people don’t realise when they’re switching into Hindi so it’s a difficult problem to fix.

My brain now seems to zone out when people stop speaking in English so I don’t even notice that it’s happened unless I observe myself becoming much more aware of my surroundings because I’ve tuned out and started looking around the room.

An interesting side effect is that I don’t pick up as much information from osmotic communication as I have done when working in the UK/Australia because conversations between my colleagues have a 50/50 chance of being in Hindi.

I guess the easiest way for me to fix the problem would be to take lessons in Hindi but I’ve never got around to that.

Another interesting thing to note is that it’s not only me who doesn’t understand Hindi but also people from the Chennai office.

Swearing

Swearing in India is a bit of a taboo which is quite strange for me because in the UK/Australia there’s not really any stigma attached to the majority of words.

There are a few people who are more easily offended so you have to be a bit more careful about word selection when speaking with them.

Having said that, with the majority of people that I’ve worked with the language that I use makes no difference at all.

I’ve been reading some of the articles written about the disruption caused by the snow across Europe and I found one quote in The Daily Telegraph by Phillip Hammond particularly interesting

“I think whilst people are obviously deeply upset about the inconvenience, particularly at this time of year, of having their travel plans disrupted, most of what I am hearing is a sense of outrage about the way they were then treated when they were stranded at Heathrow airport.”

I was stuck in Brussels Airport for almost a day and the communication by just about everybody there was as non existent as it sounds like it’s been at Heathrow.

I think part of the reason for that was that the people in charge didn’t know what was happening and part of it was because they didn’t want to give people bad news.

I’ve noticed the same type of thing happen in organisations when there there’s something bad to be communicated or an unpopular decision has been made and needs to be explained.

Often in this situation there will be no further communication because it’s assumed that people won’t react well to that communication.

I don’t think that’s actually an accurate assumption and in addition not communicating is actually quite a dangerous thing to do because it then puts people in the position that they will now guess why certain things are being done.

More often than not those guesses will be more damning of people in leadership positions than they deserve.

Whenever I’ve seen someone in a leadership position explain what’s actually going on (and the thinking behind it) the response of the people receiving the message has always been much more reasonable than they expect it to be.

I think the people in charge of communicating what was going on in the airports would have had similar results if they’d only communicated something!

A couple of months ago I briefly touched on the very stretched days I’ve experienced while working in India.

This is in contrast to what I’ve experienced in the UK and Australia where the day was much more time boxed and tended to go from 9am to 6pm.

At the moment we also have a call with colleagues in Chicago at 9pm for about 30-45 minutes so the day has now stretched out until nearly 10pm. We start with our standup at 10am.

We’re certainly not working all of that time but you’re never really done for the day until the call has finished.

With or without the call I’ve found it a much more difficult environment to work in than anything I’ve experienced before.

I frequently get to the end of the day and can’t really determine whether I’ve actually achieved anything because I’ve started and stopping working so many times.

I find I get distracted really easily working in our Pune office so I need my pair to be quite vocal about keeping focus!

One disadvantage of the stretched work day which I’ve only noticed recently is that you can become less reflective about the code because you don’t get as much time where you’re awake but not directly working with the code.

I frequently came up with possible ways to improve code bases on previous projects while playing around with something else or watching a presentation or similar.

I find that I play around with stuff outside the project less than I have previously partly because I’ve lost the 4 to 5 hour stretch that I used to have each evening.

On the positive side you get to know the people you’re working with pretty well because you’re with them for a lot more hours per day.

Not every project in the office has hours as stretched as mine but it certainly seems to be more common in India than elsewhere.

For the last two weeks we’ve had a ThoughtWorks colleague from the onshore team working with us in Pune and it’s been really cool having someone who has been working on ‘the other side’.

In my time in India there seem to have been many more people going from offshore to onshore than the other way around but based on this experience I don’t think that should necessarily be the case.

The typical argument in favour of someone from offshore going on site is that they’re able to interact with the client and onshore people and pick up any required context which they’ll then be able to share with their colleagues offshore.

The impact of those trips is perceived to be higher than what would be achieved by having someone do the reverse trip.

Having seen the interactions my US colleague was able to have with people has made me realise that perhaps that perception isn’t as true as it seems.

A big part of the success of distributed projects seems to be about the ability for the two sides to communicate effectively and having someone who interacts daily with people that we only know by phone/email is very helpful.

My colleague was able to provide context about our client and what they’re trying to do in a way that I don’t think someone going onshore for a couple of weeks would be able to do.

Sometimes it’s felt like we’re just building something because we were told to do so and my colleague has been able to explain the underlying thinking and what we’re trying to do with the system.

I think he’s also found it a pretty useful experience in terms of learning about the strengths and weaknesses of the team and what the real pain points are.

Everyone offshore now knows one person onshore personally which should be useful for any future interactions.

Some colleagues have been asking me recently what cultural differences I’ve noticed working in India compared to my experiences in the UK and Australia and one of the biggest differences by far is the amount of tolerance and patience people here have compared to me.

These attributes seem to show themselves in roughly two situations:

With respect to the environment

We’ve had some building work done in the Pune office recently which has meant that there’s been extremely high volume drilling being done to the extent that you can barely hear someone who’s sitting a couple of metres away.

I was quite amazed to watch colleagues continuing with their conversations as if nothing had happened – I was totally distracted and had to go and sit in a meeting room away from the noise.

I’ve talked to a few colleagues about this and they pointed out that they’re pretty used to the environment not being perfect from previous experiences at school or just in general life situations so it’s not such a big deal.

I find it interesting to see how influential the environment (as far as I can see) can be on some fairly fundamental personality traits.

With people

People here seem to give others the benefit of the doubt much more frequently than I’ve seen elsewhere.

I’ve noticed this especially when communicating with people in remote locations.

I worked on a project distributed between two cities a couple of years ago and the distrust between the two locations was fairly evident in all methods of communication.

I haven’t noticed the same thing here as much and the majority of the time people don’t react at all to something which I would consider to be inflammatory.

There’s also much more tolerance for repetition of information than I’ve noticed elsewhere.

I get very frustrated if I hear the same thing repeated multiple times but the majority of people here don’t seem too bothered by that and take it in their stride.

It’s a strength not a weakness

I think that people here sometimes don’t recognise that their tolerance/patience is a strength rather than a weakness and I’ve frequently heard conversations where what I consider being tolerant is seen to be ‘rolling over’.

I don’t necessarily think the ‘western’ style of presenting an argument very assertively/confidently is the only way to go and I’ve seen colleagues successfully communicate while using their own style.

Of course these are massive generalisations based on my observations so it’d be interesting to see what other people who’ve had the chance to work in both cultures/environments think.

Back in 2007/2008 when I worked on my first couple of projects at ThoughtWorks I always found it strange how frequently my colleagues would try and figure something out themselves rather than asking someone else (who already knew how to do it) how to do it.

Fast forward to 2010 and I find myself being the one encouraging people to figure things out themselves.

There’s still merit in communicating with colleagues when we’ve tried to work out how to do something and haven’t managed to figure it out but it’s also useful to not have this as our default mode.

This seems to be particularly the case when working offshore if we have a reasonable idea that someone onshore might be able to help us with something we’re working on.

We can stop and wait for them to start their work day but frequently we’ll be able to make some progress without their input and then if we really do need help we can always get it later on.

While someone else can often solve a problem quicker than us the disadvantage is that we don’t tend to learn by watching others but rather by struggling ourselves.

In my first job it was suggested to me by a colleague that I should try and solve any problems alone for an hour before asking someone else for help.

Having said that I do think it’s still useful to know which people in a team have expertise in certain areas so that we can ask them for help when required.

Earlier this year I wrote about some of the problems that we can run into when we have implicit assumptions in stories and another problematic approach I’ve seen around this area is where we end up with stories that are very heavily focused on technical implementation.

Initially this seems like it will work out pretty well since all the developer then needs to do is follow the steps that have been outlined for them but from my experience it seems to create more problems than it solves.

The first problem is that it seems to create a non thinking mindset and the more detail there is the less it feels like you need to think.

This isn’t a great position to end up in since there are frequently multiple ways to solve any problem and we will probably exclude those from our thinking if we’re just following instructions.

As a developer part of the skill-set is knowing how to implement a solution but an equally important part is being able to suggest alternative approaches which may be more appropriate in a given context.

Technically heavy stories only encourage the former as the developer may now assume that any other options have somehow already been considered.

In addition to this it tends to take a lot of time to explain these types of stories which presumably also means that it takes longer to write them up as well.

I’ve also found that it’s more difficult to understand these types of stories since it’s not initially obvious why you need to implement the technical approach that has been described.

Another thing which I hadn’t appreciated until quite recently is that it’s very boring/demotivating to implement stories if all the problems have already been ‘solved’ before you even start.

Given that it’s somewhat inevitable that we may end up with a story that is shaped like this the key seems to be not to get frustrated by the story but rather to try and find out what the underlying intent of the requirement actually is.