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 'quit thinking and look' from '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.

One of the programming techniques which we tried to encourage is the idea of 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.

I wrote a couple of months ago about 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.