DevOps Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 534 posts at DZone. You can read more from them at their website. View Full User Profile

ThoughtWorks University: Things people found difficult

  • submit to reddit

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 ‘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.

Programming by wishful thinking

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.

Using Google

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.



Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Javin Paul replied on Tue, 2011/04/26 - 8:25am

This looks to me a nice series of tutorial which will really help programmer on programming and developement concept. I see web is full of article but genuine good article related to programming concept, best practices, experiences are really rare. with due course I found that while developing or programming its always better to discard the first way of solution because its most of the time it blocks thinking and contains bugs , think more and then decide. another important skill is think through process which is pretty important for maintennace and new dev.


Why String is immutable in Java 

David Cameron replied on Thu, 2013/01/31 - 1:00pm

My uncle finished the TWU courses because he wants to live a happier life, he worked as a programmer for 10 years and wanted to try something new and interesting. He started to make software for Python using "programming by wishful thinking" strategy and he managed to create a couple of promising programs.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.