markhneedham/blog huggingface dataset:
Everything I know everyone else knows
Date: 2011-03-13 12:03:13

For as long as I can remember I've had the belief that, at least as far as software is concerned, *everything I know how to do everyone else also knows how to do*.

I carried that assumption for quite a while and only realised relatively recently how harmful it can be.

The most observable outcome I noticed is that I either didn't give my opinion in group situations or just didn't take part in them because I assumed that what I wanted to say would eventually be contributed by someone else anyway.

The danger of doing that is that sometimes people didn't come up with a solution I'd seen work before and I'd be extremely frustrated because it seemed like the others were making what I considered bad decisions deliberately.

I think this belief evolved from the fact that for several years I was nearly always the least experienced person on the teams that I worked on and it was often true that my colleagues knew way more about almost everything than I did.

As time has gone on I've seen more situations and gained some ideas on approaches which work and I haven't been the least experienced in the teams I've been working on so the belief doesn't necessarily hold anymore.

I'm not sure if this is a common stage to go through on the software journey so it'd be interesting to hear about your experience.

I'm now moving more towards an approach where I give my opinions in situations where I have some knowledge while also accepting the fact that there will be other situations where others know much more than me.

In those situations I can legitimately keep quiet and learn from my colleagues experiences.
ThoughtWorks University: The coaching/training conflict
Date: 2011-04-03 17:11:46

As I http://www.markhneedham.com/blog/2011/03/29/thoughtworks-university-coding-dojo-style/[mentioned in an earlier post] Sumeet has been encouraging us to act more as coaches rather than trainers during ThoughtWorks University but it's not quite as easy as it seems.

I've noticed that there are a few things that contribute to this difficulty.

== Assessment

The biggest obstacle is that by the end of TWU the trainers are required to send a review about each of the grads to the respective Resource Managers describing each person's current level of skill in various categories.

Although we're trying hard to be helpful when conveying this message it's difficult for the grads to get beyond the feeling that they're being tested which to some extent is true.

I find the idea of assessing people while I'm working with them quite difficult so for me it's more a point of working out the best way to help each person improve their skills.

On the other hand the advantage of being in a mode where you're explicitly looking for ways for them to improve is that you are able to give much more detailed feedback than you might be able to if you were on a 'normal team'.

== Switching roles

One of the things that a couple of the trainers were doing was acting as a proxy customer as well as playing their normal role.

This is an approach that has been used on previous TWU's and the intention was to give the grads an idea of the different types of customers that they might encounter.

The feedback from the grads was that it can be quite confusing because you're never quite sure which role the trainer is going to be playing when you go to speak to them.

As a result we've decided to drop this idea and let the http://www.sukrupa.org/[Sukrupa] guys completely play the role of customer while the trainers just play their normal role.

== Drifting outside the group

A more subtle thing which can signify a difference between trainers/grads is the tendency for trainers to drift outside of group situations physically.

For example in the http://www.markhneedham.com/blog/2011/03/30/thoughtworks-university-a-double-loop-learning-example/[wrap up that we do at the end of the day] if the trainers don't participate in that then it signifies a difference between them and the grads i.e. they're not really part of the group.

I think we've got better at this as time has gone on and it's actually much more fun to take part in everything than to just be an observer.

It's very difficult to completely get rid of the role of being a trainer but at least having an awareness of the situations where we make it more difficult for ourselves can help us get closer to achieving that.
ThoughtWorks University: v2.0 vs v1.0
Date: 2011-04-27 12:33:56

Since we finished the most recent ThoughtWorks University session last week a few people have been asking me how the experience was and I've found myself comparing this experience to my own as an attendee in August 2006.

Back then ThoughtWorks University was much different. We had 5 weeks of workshop style sessions and then spent the last week working on an internal application.

This time we spent 1 week doing the workshop style sessions, 1 week working together on a story and then 4 weeks working on the application.

== Knowing what you don't know

My general feeling is that although http://www.learninggeneralist.com/2010/08/thoughtworks-university-story-of-our.html[TWU v2.0] is better designed for helping people to learn, an advantage of the previous approach was that there was more opportunity to see the gaps in your skill-set.

From what I remember there was much more trainer input and at times it was amazing to see http://www.markhneedham.com/blog/2006/09/02/watching-a-master-at-work/[how good someone could be at programming] once they'd got years of practice behind them.

Although this still happened, albeit less frequently, there was often feedback that people didn't know what they didn't know and were therefore unsure what they needed to learn.

They will still be able learn about those gaps on the projects they work on but I didn't feel this group had the sense of how much there still is to learn as I did 4 1/2 years ago.

== The 'trainer' role

The role of the ThoughtWorks University trainers has changed from being an actual trainer to being http://www.markhneedham.com/blog/2011/04/03/thoughtworks-university-the-coachingtraining-conflict/[more of an enablement coach] whose primary goal is to facilitate people learning.

I think this makes the 'trainer' a more passive participant as your job is no longer to 'teach' people things but rather to let them learn themselves.

At times this meant sitting back to allow people to explore and learn from their mistakes and although I think this is a valuable approach it can get quite boring!

== Realism vs Creating Learning Opportunities

One of the nice things about the new style is that the challenges and problems that people encountered were actually real and not contrived.

On the other hand this meant that we couldn't specifically target things that we wanted people to learn in such a structured way.

For example, I remember doing several sessions on object design and design patterns and although we weren't experts in either of those by the end of TWU it helped us to see some areas that we could go and read/learn more about.

I think people probably came across similar types of situations in this TWU but in their pairs rather than as a group so it was more difficult to point out the learning area.
Tech Leading: Initial Thoughts
Date: 2011-04-17 11:27:31

As I mentioned in an earlier post I've been playing the role of tech lead on the project that we've been doing at ThoughtWorks University so I thought it'd be interesting to note down some of my observations so far.

Out of the tech leads that I've had I liked the style of http://intwoplacesatonce.com/[Dave Cameron] the best.

He viewed himself more as a technical facilitator rather than as a person who should make every single decision about how a system got built which meant that others also got a chance to take some responsibility.

== Varying the style

I wanted to apply this style with everyone on the team such that I would facilitate a conversation with the pair about the story that they were working on but they would decide how they went about it.

This worked reasonably well for some of the people but I quickly noticed that others were ending up quite lost if we only had a brief conversation.

They needed a bit of a structure around what they were going to work on so in those cases we http://www.thekua.com/atwork/2007/07/onboarding-strategy-tiny-tasks/[tiny tasked] out the implementation together.

== A fresh view

When I worked with https://twitter.com/#!/christianralph[Christian] as my tech lead I noticed that when we were stuck on something he would often come round and ask a question which guided us to a solution which had been completely evading us.

I don't yet do that as well as him but I have found that having a fresh and higher level view of a problem means that you can see things which the pair may now be missing because they're so stuck in the implementation.

That's happened several times and is always immensely frustrating for the pair involved!

== Knowing what's on the wall

I've got quite used to only having to know what story I was working on and not really needing to know that much about what the rest of the team are working on.

That approach doesn't work quite as well in the tech lead role where you need to be the one who has an idea of what's going on with everything that's in play.

This is the thing I've struggled the most with and there have been occasions where stories have been in play way too long where I could have intervened and help the pair work out how to finish them.

Other people that I've spoken to have suggested that one way of ensuring you know what's going on is to browse every checkin that's made to the repository each day.

I did try this a couple of weeks ago but it's really time consuming and I think you can get information about a story quicker by just talking to the people working on it.
The sunk cost fallacy
Date: 2011-04-17 12:05:12

I recently came across David McRaney's post about http://youarenotsosmart.com/2011/03/25/the-sunk-cost-fallacy/[the sunk cost fallacy with reference to Farmville], a fallacy that is very applicable to software.

David starts off with the following statements which describe the fallacy pretty well:

____
*The Misconception*: You make rational decisions based on the future value of objects, investments and experiences. *The Truth*: Your decisions are tainted by the emotional investments you accumulate, and the more you invest in something the harder it becomes to abandon it.
____

I think this is very true in a lot of IT organisations in particular when they've made a big investment on some sort of middleware, usually an http://en.wikipedia.org/wiki/Enterprise_service_bus[ESB].

These can often cost hundreds of thousands if not millions of £'s so the person who authorised the purchase is likely to push very hard for it to be used because if it's not then their decision looks very foolish.

The problem is that in a lot of cases using an ESB doesn't simplify the system being built - it makes it much more complicated.

ESB's are typically difficult to test against, difficult to setup on a continuous integration server and generally make the life of people who have to use them hell.

The sunk cost fallacy applies here because the organisation feels the pain of the initial purchase and doesn't want to write that off even if it would make life easier for them from now onwards.

I even have my own smaller example from something I've been working on over the weekend.

I wanted to try moving this blog from Wordpress to https://github.com/mojombo/jekyll[Jekyll] and I came across https://github.com/imathis/octopress[octopress] which simplifies the process by providing ready made style sheets and layouts.

I've got it mostly working but I couldn't work out how to create pages which showed the posts in certain categories or for a specific month.

From what I can tell you can get that functionality by implementing a plugin but unfortunately plugins were only added to Jekyll from version 0.6 and octopress relies on henrik-jekyll version 0.5.

I've spent about a day and a half getting the blog to its current state  so I'm pretty reluctant to write off that time and scrap the octopress idea.

Unfortunately that may not be possible if I want to get all the functionality of wordpress.

I'm not sure exactly when we should take the sunk cost and when we should write it off but being aware of it is at least a step in the right direction.
Unix: Getting the sound from 'say' as a wav file
Date: 2011-04-07 19:18:04

I spent a bit of time yesterday afternoon working out how to get the output from the Unix command 'say' to be played whenever our build breaks.

We're using http://ccnet.sourceforge.net/CCNET/CCTray.html[cctray] on a Windows box for that purpose which means that we need to have the file in the 'wav' format.

Unfortunately 'say' doesn't seem to be able to output a file in that format:

[source,text]
----

> say "WARNING! Drainage has occurred, please fix it. Drainage has occurred, please fix it." --output-file drain.wav

Opening output file failed: fmt?
----

So I first converted it into a 'wmv':

[source,text]
----

> say "WARNING! Drainage has occurred, please fix it. Drainage has occurred, please fix it." --output-file drain.wmv
----

And then converted it into a 'wav' via http://media.io/[media.io].

Sadly media.io doesn't seem to have an API so I can't fully automate it.

If anyone knows a service that does have an API let me know!
HTML encoding/escaping with StringTemplate and Spring MVC
Date: 2011-04-09 10:54:59

Last week my colleague T.C. and I had to work out how to HTML encode the values entered by the user when redisplaying those onto the page to prevent a cross site scripting attack on the website.

I wrote a blog post a couple of years ago http://www.markhneedham.com/blog/2009/02/12/aspnet-mvc-preventing-xss-attacks/[describing how to do this in ASP.NET MVC] and the general idea is that we need to have a custom renderer which HTML encodes any strings that pass through it.

In our case this means that we needed to write a custom renderer for String Template and hook that into Spring MVC.

We already had a view class +++<cite>+++StringTemplateView+++</cite>+++ so we needed to add to that class and add our custom renderer.

The viewResolver was defined like so:

[source,java]
----

    @Bean
    public ViewResolver viewResolver() {
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/templates/");
        viewResolver.setViewClass(StringTemplateView.class);
        viewResolver.setSuffix(".st");
        return viewResolver;
    }
----

And after some guidance from http://twitter.com/jimbarritt[Jim] we changed +++<cite>+++StringTemplateView+++</cite>+++ to look like this:

[source,java]
----

public class StringTemplateView extends InternalResourceView {

    @Override
    protected void renderMergedOutputModel(Map<String, Object> model, HttpServletRequest request, HttpServletResponse response) throws Exception {
        String templateRootDir = format("%s/WEB-INF/templates", getServletContext().getRealPath("/"));

        StringTemplateGroup group = new StringTemplateGroup("view", templateRootDir);
        StringTemplate template = group.getInstanceOf(getBeanName());

        AttributeRenderer htmlEncodedRenderer = new HtmlEncodedRenderer();
        template.registerRenderer(String.class,  htmlEncodedRenderer);

	...
    }
	
    private class HtmlEncodedRenderer implements AttributeRenderer {
        @Override
        public String toString(Object o) {
            return HtmlUtils.htmlEscape(o.toString());
        }

        @Override
        public String toString(Object o, String formatName) {
            return HtmlUtils.htmlEscape(o.toString());
        }
    }
}
----

At the moment we want to HTML encode everything that we render through StringTemplate but if that changes then we could http://www.antlr.org/wiki/display/ST/Object+rendering[make use of the formatName parameter] which we're currently ignoring.

In retrospect this looks pretty simple to do but my Googling skills were pretty much failing me at the time so I thought it'd be good to document.
ThoughtWorks University: Letting people explore
Date: 2011-04-06 01:34:00

I've been acting as the tech lead on the project that we're working on at ThoughtWorks University and as a result I sometimes find myself being dragged away from my pair to help someone else.

An interesting thing which I've noticed on more than one occasion is that when I've come back from helping - maybe 15 or 20 minutes later - my pair has actually got much further than I expected them to.

I think there are probably more than one factors that lead to this but one which I think is quite applicable is that *having me there is stopping the grads from exploring the problem*.

In general if I see someone moving around the editor or browser without there seeming to be any logical path I'll start asking questions to try and 'guide' them to where I believe we need to go.

On other projects that I've worked on this has worked reasonably well because we both have a similar understanding of the problem, the tools and so on.

In this case I think that shared understanding is much less and my approach is much more harmful.

I've been reading John Medina's http://www.amazon.com/Brain-Rules-Principles-Surviving-Thriving/dp/0979777747/ref=sr_1_1?ie=UTF8&qid=1302114250&sr=8-1[Brain Rules] over the last couple of days and Rule #12 seems to agree with what I've observed:

Rule #12: We are powerful and natural explorers

____
We are natural explorers, even if the habit sometimes stings us. The tendency is so strong, it is capable of turning us into lifelong learners.
____

I particularly liked the following section...

____
[Humans] Make a sensory observation, form a hypothesis about what is going on, design an experiment capable of testing the hypothesis, and then draw conclusions from the findings.
____

..which seems to describe the process that I'm sometimes restricting by asking 'guiding' questions.

http://twitter.com/jimbarritt[Jim] suggested that one way to get around this problem could be to split up as a pair when we're in this explorative mode but what I've been trying at the moment is keeping more silent and trying to understand what discovery is going on.

I'm still getting it wrong sometimes but I'm starting to pick up more where they're really stuck and need some help and where I should just keep quiet and allow them to work out what to do themselves.
The ladder of inference
Date: 2011-04-24 14:11:36

In http://www.discussingtheundiscussable.com/[Discussing the Undiscussable] William Noonan describes *the ladder of inference*, a tool which can be used to help us achieve double loop learning with respect to our interactions with other people.

____
Ladder of Inference helps people identify what information or facts are used as the basis for their reasoning process. It also helps people understand how they interpret that information and how they apply their interpretation to the issue or problem at hand. Essentially, the Ladder of Inference is a metaphorical tool designed to help people understand and describe their use of inductive reasoning. Given what we see, what conclusions do we draw?
____

image::{{<siteurl>}}/uploads/2011/04/ladder-of-inference.jpg[Ladder of inference,326]

The book mainly describes the ways that we end up climbing the inference ladder ourselves but I've been thinking recently that it's quite interesting to know that in all likelihood that's how other people are thinking about the things that we do.

One of the main examples of people climbing the ladder of inference in an 'agile' context is when somebody comes late to the standup in the morning.

The other members of the team often jump up the ladder and come to the conclusion that the late person is lazy/doesn't care about the project or their time and is generally a bad person, all before finding out why they were late!

The ladder climbing gets even worse if the person is a serial offender and even though it's unfair to that person, it's unlikely that you're going to be able to get all the other people in the team to change their way of thinking.

It therefore makes sense to be aware that people may be making these inferences about our behaviour and perhaps adjust the way we act accordingly.
ThoughtWorks University: Things people found difficult
Date: 2011-04-23 19:47:01

After six weeks ThoughtWorks University #21 finished on Thursday so I thought it'd be interesting to summarise some of the things that people seemed to find difficult over the course of TWU.

== The stack trace

We were using Java for the duration of TWU and as a result there were plenty of stack traces for people to debug.

These were most frequently related to incorrect wiring of Spring components but there were other reasons too.

People seemed to find these stack traces quite difficult to understand, particularly when one stack trace was nested inside another, and often just started guessing why the code wasn't working.

This is a good example of where 'http://www.markhneedham.com/blog/2010/06/28/intuition-and-quit-thinking-and-look/[quit thinking and look]' from 'http://www.amazon.com/exec/obidos/ASIN/0814474578/debuggingrule-20[Debugging - The 9 Indispensable Rules]' comes in handy.

I think it takes a while for that lesson to sink in but it makes life much easier once it does.

== Programming by wishful thinking

One of the programming techniques which we tried to encourage is the idea of http://dsoguy.blogspot.com/2007/01/programming-by-wishful-thinking.html[programming by wishful thinking] i.e. you write the code that you wish existed and then you go and implement it.

Some of the group seemed to find this approach quite difficult to understand and preferred to go and create the class/methods of the object rather than just pretending that they existed for the time being.

I think the intuitiveness of this technique might be linked to how easy people find the TDD approach to writing code and since many hadn't done this before that may explain why it didn't come naturally.

== Using Google

I wrote a couple of months ago about http://www.markhneedham.com/blog/2011/02/06/university-coding/[some observations I'd had while pairing with people during a university recruitment event] and one of them was that people struggled to find the answers to their questions on Google.

A lot of the time the most useful thing I could do for people when they asked for help was to show them how I'd search for the answer on Google.

More often than not this was enough for them to figure out the answer themselves.