markhneedham/blog huggingface dataset:
The working long hours culture
Date: 2011-03-29 17:25:20

One of the aspects of software development that I've thankfully seen relatively infrequently over the last few years is that of some people in teams working long hours on a consistent basis.

I have seen it happen on a few occasions and I think it can have a detrimental effect on a team rather than the good which is presumably intended.

The biggest disadvantage is that it makes other people in the team feel guilty that they aren't working long hours and they may feel peer pressured into matching the hours of their colleagues.

In a conversation with http://www.learninggeneralist.com[Sumeet] about work/life balance he pointed out that if you really enjoy what you do for work then you don't necessarily see a clear distinction between the two and it wouldn't be a big deal to work for 10+ hours a day.

While I understand this point of view I think in a team environment it's very easy to start believing that you're more important to a team because you put in more hours.

It's then very easy to stop valuing the contributions of your colleagues or considering their opinions less important since they *only* worked a standard work day.

*Someone isn't necessarily not committed to something because they don't spend their whole life doing it*.

Another aspect to this which is easy to overlook is that the people working these long hours might not actually be working in a particularly effective way.

If I spend most of the day getting distracted/procrastinating and end up 'working' for 12 hours then I may actually end up being just as productive as someone who works only 8 hours but is much more focused during that time.

Even if we assume that someone is productive for 12 hours a day it still isn't necessarily great because they'll end up being the only one who knows the code that they write when everyone else has gone home.

When I was in Pune one of the other teams in the office had a mandated finish time of 6.30 and it actually seemed to help people remain focused during their time in the office because they knew they wouldn't be able to work after that time.

I'm not necessarily a fan of setting rules of what people can/should be allowed to do but in that case it seemed to work reasonably well.
Pair Presenting
Date: 2011-03-17 06:52:37

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 http://twitter.com/#!/frankmt[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 http://skillsmatter.com/podcast/open-source-dot-net/mike-wagg-mark-needham-functional-and-oo-approaches-to-c-sharp-programming[Functional Programming in C#] with http://twitter.com/#!/Mikewagg[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 http://www.learninggeneralist.com/[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.
TWU: Session Preparation - Limited WIP
Date: 2011-03-09 14:42:41

I've spent a fair percentage of the last couple of weeks preparing sessions for ThoughtWorks University and one thing http://twitter.com/#!/frankmt[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 http://www.pomodorotechnique.com/[time as a constraint].

Something to try out at least...
ThoughtWorks University: The use of games
Date: 2011-03-30 20:34:32

When I attended ThoughtWorks University in August 2006 we spent quite a bit of time playing games which had been designed to help us to achieve various learning objectives.

At the time I didn't think much about it but now being on the other side as a trainer I've started to doubt whether these types of sessions are as useful as I originally thought.

I recently came across http://www.learninggeneralist.com/2010/08/think-workscapes-not-training.html[a blog post Sumeet wrote last year where he talks about effective e-learning environments] and I think his point still applies here:

____
The really effective elearning is where people actually practice real-world tasks, but we have little time for that post our fascination with card games and flashy animations.
____

== The Agile Lego Game

I was pondering this a couple of weeks ago when we ran the http://agile2009.agilealliance.org/node/476/[agile lego game].

Interestingly the feedback that we got from the participants of this session was that they really enjoyed the games part of the sessions.

My current thinking is that the feedback may have been more indicative of the fun that people had rather than the learning gained.

The problem I see is that people do know it's a somewhat contrived situation and may therefore have difficulty relating it to a real life problem that they face later on.

For example in the agile lego game</a> I acted as a customer with the instructions to be very picky/particular about what I actually wanted so  that the team would communicate with me more frequently.

The idea was to try and simulate a real life customer and to allow the participants to see the value of collaborating with the customer frequently.

I found this part of the role really difficult as I knew how much I would hate to be on the other side facing someone acting like that.

On the other hand we did encounter the same types of problems that can happen on real projects:

* Making assumptions about what the customer wanted
* Not speaking to the customer and just building something
* Miscalculating how long it would take to build something and spending ages doing it
* 'Committing' to way more points than could ever be done

Despite seeing people learn those lessons and not committing the same mistakes in the next iteration I have noticed these same mistakes happening now that people are working on a real project.

From what I've seen *it's not until they make these mistakes in a real environment that the learning really sinks in*.

Having said that I wouldn't completely write off the use of games in learning environments.

They certainly provide a really good way to get people to interact as a group as well as proving them a good opportunity to know each other better.

The real learning happens when you're in a real environment though!
ThoughtWorks University: A double loop learning example
Date: 2011-03-30 19:17:57

One of the most interesting things that I've been reading about recently is the idea of single and double loop learning which were defined by Chris Argyris and Donald Schon in their book 'http://en.wikipedia.org/wiki/Organizational_learning#CITEREFArgyrisSch.C3.B6n1978[Organizational Learning: A theory of action perspective]' in 1978.

image::{{<siteurl>}}/uploads/2011/03/single-double-loop.jpg[Single double loop,477]

I quite like the definitions that Mark Smith gives for these types of learning in http://www.infed.org/thinkers/argyris.htm[his article about Chris Argyris]:

*Single Loop Learning*

____
Single-loop learning seems to be present when goals, values, frameworks and, to a significant extent, strategies are taken for granted. The emphasis is on '`techniques and making techniques more efficient`' (Usher and Bryant: 1989: 87) Any reflection is directed toward making the strategy more effective.
____

*Double Loop Learning*

____
Double-loop learning, in contrast, '`involves questioning the role of the framing and learning systems which underlie actual goals and strategies
____

I've found in a lot of 'agile' teams that I've worked on we do single loop learning pretty well but often struggle when it comes to double loop learning.

For example while working in Pune I would often hear people justify the use of an "agile practice" with the phrase "we do it because it's agile" without necessarily reflecting on the benefit the practice was supposed to be providing.

I was therefore quite pleased to see my colleague http://twitter.com/cepitchford[Claire] employing some double loop learning while questioning the value of the wrap up that we do at the end of each day of ThoughtWorks University.

The wrap up is a 15 minute stand up where people share what they're learned during the day that might be useful for other people to know as well.

Claire raised the point that it doesn't necessarily work well as a learning device because it's quite difficult to switch so quickly from working on the project to having to reflect on what you've learned.

When we discussed the usefulness of the session as a group a couple of people pointed out that it works quite nicely as an end of day activity and helped create some closure on what they'd been working on.

http://twitter.com/jimbarritt[Jim] also encouraged the group to stick with it for a bit longer as his experience from the previous university was that the wrap up sessions tended to get better as people got more used to the format.

We decided to stick with it for the moment and it's been interesting to notice that the quality of the discussion does seem to have improved as the days have gone by.

Despite that I thought it was really good that the group took the chance to reflect on whether something which had been pushed on them was actually useful rather than just going with it for 6 weeks and not getting much out of it.
Coding: Reflection vs Action mode
Date: 2011-03-06 04:19:01

It recently struck me while preparing some ThoughtWorks University sessions that there appear to be two modes that I spend my time switching between while coding:

* *Action mode* - we're focused on getting things done, making things happen
* *Reflective mode* - we're a bit more detached and looking at things from a higher level

I spent the majority of 2008 and 2009 in reflective mode on the systems I was working on which can be seen by scanning through a lot of the blog posts that I wrote during that time.

I'm sure would have been times when I was action mode but I was far more interested in how something was being built and whether that could be done more successfully.

In 2010/2011 I became much more interested in building stuff and spent more time thinking about that rather than how to refactor code or design it in a more functional way for example.

I'm now coming to the conclusion that both of these mentalities are useful at different times and I need to be more aware of when I've been spending too long in one or the other.

== Examples of the two modes

When http://www.markhneedham.com/blog/category/pair-programming/[pairing programming] these modes describe the role of the driver/navigator reasonably well.

While driving we're head down focusing on building the required functionality whereas the navigator focuses more on quality of what's being written, whether we can do that better, whether we're going to cause ourselves big problems down the line and so on.

When we're learning something new we'll mostly be in action mode to start with - we want to see something working so that we get some feedback that we're getting somewhere.

After a while when we're a bit more comfortable with the language/tool/technique we'll probably step back and reflect on how it's going.

I think you can be in these two mindsets in non coding situations too.

For example I've recently become much more vocal in trying to get teams to use approaches that I've seen work before whereas previously I was happier to sit back and watch how things panned out and learn from that.

== Are the modes this clear cut?

While writing this post I've started to wonder whether the way we use these two modes are actually this clearcut and whether I'm only aware of the 'obvious' switches between the two when in fact there are many more switches.

I'll keep observing...
Java: Faking System.in
Date: 2011-03-24 21:58:31

We ran a http://www.markhneedham.com/blog/2011/03/22/thoughtworks-university-a-refactoring-dojo/[refactoring dojo] a couple of days ago at ThoughtWorks University and in preparation I wrote some system level tests around https://github.com/mneedham/biblioteca/blob/master/src/main/Program.java[the coding problem] that we were going to use during the session.

It's a command line application which is called through the main method of 'Program' and since there's no dependency injection we need to be able to set System.in and System.out in order to do any testing.

My initial thinking was that it should be possible to fake System.in with the following code:

[source,java]
----

String input = "1\n9\n";
System.setIn(new ByteArrayInputStream(input.getBytes()));
----

This works fine when I just want to simulate one value being passed to System.in but it doesn't work so well if I want to simulate passing more than one value because we had a BufferedReader being created each time we loop.

[source,java]
----

...
while(true) {
	...
	InputStreamReader inputStream = new InputStreamReader(System.in);
	BufferedReader reader = new BufferedReader(inputStream);
	...
}
----

This means that the second time System.in gets read it is empty.

http://jimbarritt.com/non-random/[Jim] and I paired on the problem for a bit and came to the conclusion that we'd need to 'stub' the 'read' method of 'InputStream' if we wanted to be able to control exactly what was being returned by System.in.

We eventually ended up with the following https://github.com/mneedham/biblioteca/blob/master/src/test/StubbedInputStream.java[StubbedInputStream]:

[source,java]
----

class StubbedInputStream extends InputStream {
    private Queue<String> input;

    public StubbedInputStream(Queue<String> input) {
        this.input = input;
    }

    @Override
    public int read(byte[] bytes, int i, int i1) throws IOException {
        if(input.isEmpty()) {
            return -1;
        }

        int byteLocation = 0;
        for(byte b : input.remove().getBytes()) {
            bytes[byteLocation] = b;
            byteLocation++;
        }
        bytes[byteLocation] = "\n".getBytes()[0];
        return byteLocation + 1;
    }

	public static InputStreamBuilder stubInputStream() {
        return new InputStreamBuilder();
    }
	...
}
----

Which can be constructed using the https://github.com/mneedham/biblioteca/blob/master/src/test/InputStreamBuilder.java[following DSL]:

[source,java]
----

System.setIn(stubInputStream().toReturn("1").then("9").atSomePoint());
----

The code we wrote is on https://github.com/mneedham/biblioteca/tree/master/src[github] - I'm not sure that it covers every possible scenario that you might come up with but it does pass the tests that I've managed to come up with!
ThoughtWorks University: Brain dumping
Date: 2011-03-23 18:45:59

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 http://twitter.com/frankmt[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!
TWU: Fishbowl
Date: 2011-03-15 01:11:37

As part of a session on http://www.thoughtworks.com/values-and-culture[ThoughtWorks values] at ThoughtWorks Univesity we held a http://en.wikipedia.org/wiki/Fishbowl_(conversation)[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.
____

image:http://lisacrispin.com/wordpress/wp-content/uploads/2010/06/FishbowlBetter-300x225.jpg[]

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.

http://www.learninggeneralist.com/[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.
Use of language: Intuitive
Date: 2011-03-13 13:39:54

http://www.learninggeneralist.com/[Sumeet] and I were recently discussing the difference between the use of Google Groups for internal communication compared to the http://www.jivesoftware.com/[Jive platform] which we're now moving to and I suggested that I found the former more intuitive to use.

Sumeet suggested that the word 'intuitive' is quite overloaded and later pointed me to http://docs.moodle.org/en/Usability[an article on the Moodle website] which advocates the same thing:

____
Intuitive is a word you should avoid in discussions of usability as its meaning is often confused. It is generally accepted that a large part of usability is based on familiarity and experience. Using 'intuitive' as a short-hand for something that is familiar often gives the impression that if something is 'intuitive' then it is so regardless of prior learning or experience and therefore equally true for everyone.
____

While the article is technically correct, from my experience it's very difficult to get people to change the language that they use and to tell them to not use certain words is likely to provoke a defensive reaction.

I've found it more useful to look beneath the language used to work out exactly what is meant by the word since that's what you're really interested in.

In my case the use of the word 'intuitive' means that the way Google Groups works is *exactly the same as other mailing lists that I've used previously*.

Therefore when we moved to using Google Groups internally about 15 months ago it was really easy for me to understand how to use it.

The steps are pretty much:

* Search for mailing list I'm interested in
* Subscribe to mailing list
* Messages on that mailing list come to my inbox
* Job done!

With Jive the 'algorithm' has to be a bit different because you're initially met with a new feed which contains absolutely everything that people have posted.

It's conceptually the same as being met with the twitter stream for every single person using twitter.

The only difference I can really see between twitter and Jive is that twitter doesn't default to having every single item on your stream, you have to build it up yourself.

That was pretty similar to the metaphor being used by the Facebook news feed which I was already familiar with and could therefore get the hang of very quickly.

On the other hand I've found it more difficult to work out how to reduce the noise on Jive so that it would only contain information I'm interested in.

It would probably be possible to find some documentation that would explain what I need to do but I like it better when I can work out how to use something myself without external help.

Maybe it'll just take me a bit longer to work out how to use Jive and then it'll be as intuitive to me as Google Groups and twitter are.

For further reading, Jared Spool has an interesting article where he goes into much more detail than I have about http://www.uie.com/articles/design_intuitive/[what makes a design seem to be intuitive].