Mark Needham

One of the things that Sumeet has been encouraging at ThoughtWorks University is the idea that the ‘trainers’ should be in a coaching role rather than a training one.

As a result of this suggestion one of the things we’ve done is to change the style of the second week so that it wasn’t full of sessions/workshops but instead involved working on code as a group.

Jim came up with the idea of the ‘exploded story’ whereby we spent the whole of last week as a group working on one story for Sukrupa while spending quite a bit of time exploring the different activities that playing a story end to end would involve.

We did this by making use of two types of coding dojos:

• Randori – two people at the keyboard and the rest of the group watching and contributing ideas about what could be done next.
• Kake – one computer per pair but everyone is working on the same problem

Randori

We began last week with a Randori dojo where initially two of the trainers paired while implementing a story to add improved search functionality to the sukrupa admin application.

We rotated one of the pair every 5 minutes, initially making sure that there was always a trainer at the keyboard but we quickly changed that so that it was mostly the grads driving the implementation.

The cool thing about using the randori dojo like this was that we were able to code as a group and people were able to get a rough feel for the strengths of their colleagues and see any areas they might be able to improve on.

We were also easily able to see where people were struggling so that we could break out and do a quick session on a topic if necessary.

One disadvantage of this style is that it does put people under a bit of pressure because everyone is seeing the code they’re writing so I’m not sure that it necessarily provides the best learning environment.

We did the randori dojo for a few mornings while doing a kake dojo in the afternoon before deciding as a group that it would be more beneficial to do a kake dojo for the whole day.

Kake

We initially ran the kake dojo with 10 minute iterations after which we would discuss how everyone was doing and whether there were any learnings to share.

We pair rotated every other iteration and eventually increased the iteration time to 30 minutes so that we’d have more time to solve some of the more difficult problems.

It was getting really irritating being interrupted every 10 minutes at times!

A few times a day we went around the room to each machine and the pair was able to describe the code they’d written and the approach they’d taken.

We’d then choose as a group which code we wanted to push to the github repository as a baseline and then continue working from there.

I quite enjoyed working in this style and it worked fairly well until we got towards the end of the story and the code that each pair was writing was pretty much identical.

At that stage we switched back to a 30 minute randori dojo before the week was complete!

One of the things that I’m learning while working at ThoughtWorks University is to bite my tongue a bit to allow people to learn in their own way.

I noticed this particularly yesterday in a refactoring session we were doing.

For about 10-15 minutes in the middle of the session we’d managed to get the code into a state where it didn’t compile and we couldn’t run the tests.

The ‘natural’ inclination in that situation for me would be to step in and impart some ‘wisdom’ about the importance of taking small steps while refactoring.

Instead we kept on going for another 10 minutes or so until one of the guys pointed out that the code hadn’t compiled and nor had our system test been run for quite a while.

With some prodding from Frankie the pair at the keyboard made some temporary changes to the application so that it’d compile and then completed the rest of the refactoring in a more incremental fashion.

Of course the other side of the coin is to ensure that I do actually give some input when it’s useful.

The key here seems to be to ensure only to give enough input for the situation.

I’ve learnt quite a lot about some topics and with the amount of stories I’ve picked up and the analogies/metaphors I’ve picked up it can easily become a brain dump if you’re not careful.

From my own experience this style of receiving information isn’t particularly easy to digest, especially if you don’t have any context to link the stories to.

The other danger with telling stories is that one story can often trigger another trainer to tell their own story and before you know it 30 minutes has gone by and the original point has long been lost!

I facilitated a refactoring session today at ThoughtWorks University where we spent the morning refactoring our way through one of the problems the grads had to work on as part of the pre coursework.

The previous version of this session has been more structured, whereby one of the trainers worked solo at the keyboard and took suggestions from the group about which refactoring to cover next.

There are a certain number of refactorings that the session aims to introduce and the trainer would have practiced beforehand so they could make these fairly flawlessly.

I’m not really a fan of that style of session so we refactored code which the grads were quite familiar with and I was unfamiliar with.

We ended up doing 3×45 minute stints in the style of a randori coding dojo and we had one person keeping a list of the potential refactorings on the whiteboard.

The 3 stints went like this:

1. Me always at the keyboard, people pairing with me and Frankie facilitating/controlling the whiteboard.
2. Two grads pairing and me facilitating the session
3. Two grads pairing and one grad facilitating the session.

We’re slowly trying to encourage the idea of the grads owning the way they learn so this was a step on the way to that.

These were some of the learnings from covering a topic in this way:

• Frankie noticed that I was dominating the keyboard in round 1 so we decided that the grads could pair with each other for the remainder. We’d already gone through a lot of the main refactorings in that 1st round so it made sense to make this change.
• We switched the order of people before the 3rd round after some feedback so that people would have the opportunity to pair with different people than they had in the 2nd round.
• In the first round I was a bit too focused on teaching keyboard shortcuts to the people I was pairing with. Frankie pointed out that it’s more useful to learn the refactoring first and then once you have that concept then teach the shortcuts. By the 3rd round the grads were teaching each other the shortcuts which I thought was pretty cool.
• We didn’t get to cover as many different refactorings as we would have in a more structured session but we’ll get to those in the next few weeks when we’re coding on the project so I don’t think it’ll be too much of a problem.
• Since this was a problem everyone had worked on previously several of the people had already done some of the refactorings in their own solution. Therefore parts of the session weren’t a big learning experience for those people. That’s been a bit of a theme so far – working out how to cater for all skill/experience levels seems a difficult problem to solve!

Overall I was quite impressed with how much we managed to refactor the code in the amount of time we coded for.

The only thing I’m a bit unsure about with the randori style is that it leaves a lot of people observing for big chunks of time.

The Kake/UberDojo format is one that might be more suitable but that would mean splitting up the group which wasn’t something we’d considered.

Over the last year or so I’ve had some opportunities to pair with a few different people on sessions/presentations that we’ve been giving.

I much prefer doing this than presenting something by myself mainly because it’s much more fun and seems to encourage more participation than when I do something alone.

I feel that it’s probably easier to pair present if you both have similar opinions on the subject matter and are comfortable with a similar style of delivery.

For example Frankie and I have run a couple of sessions at ThoughtWorks University and beforehand we’ve created a rough outline of how we expect the session to play out.

Once we’ve started though both of us are quite comfortable with changing it while we’re going if that will make the session better whereas others might prefer more to the pre planned structure.

Having another person there can allow you to approach a topic in a way that is quite difficult to do alone.

About a year ago I did a talk about Functional Programming in C# with Mike Wagg and we were able to play different roles to demonstrate certain points.

He played the guy who’s predominantly in favour of OO programming but is interested in learning about functional programming while I played the guy who loves functional programming and wants to use it everywhere.

It seemed to work reasonably well.

A variation on this which Sumeet and I tried is to have one person leading the session and the other recording any questions that need to be answered later on or create a mindmap of what’s being covered in the session.

One of the dangers of pair presenting is that you can end up just having a conversation with the other person rather than talking to the audience but I think this is something that can be overcome with practice.

Preparation also becomes more difficult because you need to do at least some of it together so you both know what’s going to happen in the session.

I think that’s outweighed by the other benefits I see from pairing though.

As part of a session on ThoughtWorks values at ThoughtWorks Univesity we held a fishbowl to discuss the trade offs we often have to make between the values when confronted with real life situations.

A fishbowl conversation is a form of dialog that can be used when discussing topics within large groups.

Four to five chairs are arranged in an inner circle. This is the fishbowl. The remaining chairs are arranged outside the fishbowl. A few participants are selected to fill the fishbowl, while the rest of the group sit on the chairs outside the fishbowl. One chair is left empty

Any member of the audience can, at any time, occupy the empty chair and join the fishbowl. When this happens, an existing member of the fishbowl must voluntarily leave the fishbowl and free a chair. The discussion continues with participants frequently entering and leaving the fishbowl.

A photo from a Lisa Crispin led fishbowl

We tried a slight variation on this in that we had the people not currently in the fishbowl stand around the outside of fishbowl rather than sitting down in an attempt to encourage participation.

The overall feedback that we got from the session was that it was enjoyable to take part in although it was clear that people weren’t rotating into and out from the fishbowl as frequently as I’ve seen before.

The tone of the discussion was also relatively agreeable and there weren’t any big disagreements between people where they got really fired up in defending their view.

Sumeet pointed out afterwards that the fishbowl is often more effective in facilitating discussion around a topic which people are really passionate about and have strong opinions on.

Since we had only introduced the ThoughtWorks values about 20 minutes earlier this wouldn’t fit into that category.

Interestingly although the trainers had strong opinions on certain topics it was difficult to create a discussion because the grads mostly didn’t have examples to disagree with those points so the discussion became more theoretical/hypothetical.

I do like this format though so we’ll have to try it again with some other topics or perhaps the same one in a few weeks time to see how it works out.

I’ve spent a fair percentage of the last couple of weeks preparing sessions for ThoughtWorks University and one thing Frankie has been trying to encourage is only preparing one at a time i.e. limited work in progress

Normally I’d be completely in favour of that approach but it doesn’t seem to work at all for me with this type of work.

There seem to be a few parts to creating a session, including:

• Plan out how you want the structure of the session to be
• Write up any presentation aspects of it

The first can pretty much be stream lined so that you’re doing one of them at a time but I find the latter to be a much more creative process and I don’t do that work in a linear way at all.

I’ve noticed over the last couple of years that I prepare presentations in a very stop/start way. I really struggle to create them in one go. I’ll create a rough outline and then add to it randomly after that.

It seems to work reasonably well and I’ll come up with ideas that improve the presentation at random different times when I’m not even working on the presentation.

Presumably this is because I’m thinking about the presentation subconsciously which is one way of being creative (to a degree).

I’m curious as to whether I could get a similar effect by stimulating creativity by using time as a constraint.

Something to try out at least…

We’ve been spending our time recently preparing the sessions for the next ThoughtWorks University batch and one thing Sumeet has encouraged us to do is ensure that we have a measurable goal for each session.

In our case that means that we need to design our sessions with the intention of the grads being able to do something rather than understand something after the session.

It’s very difficult to measure whether someone understands something and from what I’ve noticed having a goal of someone understanding something can encourage you to put in more than is strictly necessary.

Sumeet pointed us to Cathy Moore’s action mapping which talks about the need to create some sort of action from the learning opportunity that we’re providing.

She also talks about the need to avoid brain dumping and I’ve noticed that I have a tendency to do this if my goal is for someone to ‘understand topic x’.

I’ve found it quite difficult to work out how much information and context we should be providing but our current thinking is that providing just enough to allow the grads to work on their project while encouraging them to seek out more information when they need it will be the most effective approach.

On a somewhat related note, after a recommendation by my colleague Jim Barritt I’ve been reading through Gerald Weinburg’s ‘Becoming a Technical Leader‘ and I quite like Weinburg’s advice around this:

When I write a book or an essay or a novel, or give a workshop, I measure my success by one simple test:

When I’m finished with them, do they care less about the subject?

If the answer if yes, I’ve failed.

I’m not sure how measurable this one is but it certainly encourages you not to make the session boring!

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.

While reading some of the rough drafts of Apprenticeship Patterns online I started thinking about the stages I have gone through on my Software Development journey so far.

I have worked in the industry for just over 3 years; 1 year at Reed Business and 2 years at ThoughtWorks. Over that time my thoughts, opinions and ways of doing things have changed, and no doubt these will continue to evolve as I learn more and more.

My time at RBI

I started working at RBI in August 2005 a few months after I finished University. My experience up to this point involved several years coding PHP in a very procedural way and a little bit of Java.

I was hired by RBI as a C# Web Developer and my work there involved working on several internal projects and looking after one of their websites.

At this stage I was still very much convinced that the art of software development lay in learning languages, so I used to spend all my time reading about C# and playing around with all the different APIs.

At this stage I was using Visual Studio without Resharper so I didn’t have the ease of Refactoring or moving code around that I now take for granted.

One of my colleagues took me under his wing and started teaching me how to write better code – separation of code across presentation/business/data layers was my first lesson. Suddenly it became so much easier to make changes! All the code I wrote was still in a non TDD way and after one episode where I created a bug in production I started to think that surely there was a better way to develop software.

Eventually my colleague suggested to me that if I really wanted to learn how to write software then the best place to do so was at ThoughtWorks.

ThoughtWorks Days

I started working at ThoughtWorks in August 2006, hired through the TWU graduate program.

I thought I had a fairly good idea of how to write Object Oriented code but that theory was quickly disproved as I went through Object Boot Camp as part of my TWU training. The Single Responsibility principle was the overwhelming lesson learned as part of this. I also remember believing at this stage that it was all about Design Patterns.

I came back to the UK and did a couple of small projects where I first came across continuous integration and TDD before going onto my first big project.

I remember my first day on that project involved pairing with Darren Hobbs and being amazed at the speed with which he was able to move around the code using IntelliJ. It became clear to me that I had a long way to go.

Working on this project for the best part of the year I learned a lot, including how to write code in a Test Driven way, that everything you do in software is a trade off, but most importantly I learned how to master the IDE – if you can do this then you feel more confident and you can complete tasks much more quickly. This is always the advice I see given to new Graduates at ThoughtWorks – learn how to use your tools!

I moved onto my second project where I was immediately surprised at how much easier I found it to move around the code base than I had at the start of my first project.

We were designing a client side application so a big part of my learning here was around testing presentation logic. Jeremy Miller’s blog proved invaluable at this stage.

It was also the first time I came across the concept of Domain Driven Design – it was amazing how much easier it was to develop software when the developers were using the same language as the BA, QA and in fact the business. InfoQ’s cut down version of Eric Evans’ famous book proved useful in helping me understand the concepts that I was seeing in our code base. I remember thinking at the time that I didn’t need to bother reading DDD as it was all covered in this version – I was wrong!

We had an very lightweight version of Agile being used on this project – we tried to have minimal process and do as many things as possible just when we needed them. It was almost Lean in nature although this was never explicit. It was interesting to me how easy and fun software development could be when it was done like this.

My third project was the first time that I got the opportunity to work with legacy code – i.e. code that hadn’t been unit tested. My early lessons on trade offs came back to me here as I realised that not writing unit tests is a trade off – you can choose to go more quickly initially by not writing them but eventually it comes back to haunt you.

I was working with Alexandre Martins on this project, and his enthusiasm for writing clean Object Orientated code gave me a new outlook on writing code. Working with him got me in the frame of mind of hating exposing the internals of classes and constantly looking for other ways to solve the problem when I was considering doing so.

Halvard Skogsrud’s knowledge around concurrency was another eye opener for me around how non functional requirements should have an impact on the way that software is designed. It also introduced me to the way that other languages such as Erlang handle concurrency – and behind this the idea of having as much of your code immutable as possible to avoid threading issues.

During a debate at a ThoughtWorks Geek Night another colleague brought up Alistair Cockburn’s Hexagonal Architecture, which was the first time that I had come across an Architectural Design Pattern. This is a useful technique when thinking about the design of systems at a higher level.

On my next project I did a lot of work around build and deployment which gave me the insight that developing software is about more than just the code. This was a lesson first taught to me by Chris Read a year before but it finally made sense to me.

A big part of this project was inter process communication between different components of the system which introduced me to the idea of event driven messaging. I immediately saw the benefits of this over the RPC style messaging I had seen previously.

I also had the opportunity to do some work with Ruby on Rails and in particular around the use of Active Resource. This introduced me to the idea of RESTful web services which feels like a much more natural way to communicate over the web than any of the other approaches I have come across.

In Summary

The interesting thing for me is that I didn’t plan to gain any of these learnings, they came about as a natural progression from my interest in software development and from working on different projects with different people.

The biggest things I have learned since I started working in software development are that it is much more an art than a science and that there is no right or wrong, just trade offs that we should be aware of.

I still have a lot to learn but I thought it would be good to have a look at what I’ve learnt so far in the hope it can help others just starting out on their journey.

It would be interesting to hear about others’ journeys and the similarities and differences you have experienced.