Friday, November 16, 2012

Jamming with professionals


So I just watched this:  http://www.sciencedump.com/content/music-language (5  mins long - don't worry which uses the metaphor of music being a language. The video talks about how many musicians "can only be learned by following a strict regiment under the strict tutelage of a skilled teacher." and that with with learning spoken natural language that you are encouraged to make mistakes. It's argument that this model is wrong.

 - Learning is not something you are sent to do just a few times a week.
 - The people you speak to are not just beginners. They are proficient.
 - that if we are only aloud to speak with beginners we will take much longer to speak like an adult.

And that we should learn to embrace mistakes. That we should learn to encourage beginners to play and with accomplished musicians on a daily basis. And that "music works best when we have something to say." as well as that too many rules can slow down learning.

How does this compare with learning our craft? Many new working programmers are not allowed to be in an environment where they can make mistakes. Most of the time we are always 'in concert'. By the nature of those developers being paid to provide a professional service the majority will only ever end up sounding like band in the school play.

There are others who hack at home. These are the musicians that play without fear. They will make mistakes but learn but can also fall in to the trap having one way to do things. Without jamming with professionals how can the enthusiastic hacker know their weak points? Will they only be able to play one tune?

I guess the solution is that we need to have time & space to make our mistakes with mentored supervision. Now I know that there are some companies that promote this & with the advent of code dojo's, hackathons and code retreats we are being give a change to make mistakes. I just wish that I knew that when I was learning to play.

Saturday, October 13, 2012

much chin stroking at ddd north

It seems like only yesterday that I was sharing stories and having drinks in the bar at Sunderland AFC after the original DDDNorth but somehow 12 months has passed and all of a sudden its DDD time again. This time the organisers moved the venue to Bradford in attempt to make the event closer to my house. So thanks for that.

The venue was the Bradford University's beautiful School of Management situated just outside the city centre. Registration was a little chaotic but after a quick reorganisation everyone was in and ready.
Stunning Venue.


The venue hosted 4 separate rooms for talks. Unfortunately I've not worked out how to fork myself so I'll take you though the ones I attended.
DDDNorth devs watching a session.

10 practices that made me the developer I am today - Gary Shutler

Before we ask the obvious question of do we want to be the developer Gary is today, it's worth pointing out Gary had aimed this session at developers new to the industry. What followed was a walk through of tips of how to really go from Joe average to a great developer. Most of the advice was sound (especially be diverse, and be responsible for your own training) but there was some controversy when Gary rated code reviews but didn't rate pairing. (note: very simplified interpretation). Gary's beard was immaculately groomed.
Gary gave some great advice.

Async C# 5.0 - Patterns for Real world user - Liam Westley

Technically my favourite session. Liam took us through the Task Asynchronous Pattern white paper.  Async is Microsoft's latest attempt to make doing more than one thing at once easy. What Liam does really well is slip from slides to code whilst maintaining an interesting patter. His test application was a simple mp3 organiser & player which give some great audio cues as to when things were done. This was definitely a session that I came out of eager to try new things. 
Liam's was a fascinating session.

Look Ma! No Frameworks - Gemma Cameron

Gemma's BDD message was that you don't need any stinking framework to do BDD. Forget about the tools and just have the conversations. She showed by the help of the audience how you could write meaningful test code with out having to be constrained by a frame works language. We had a live kata and some interesting discussion with good points raised by the grizzly looking Ian Cooper.
Gemma's interactive session was thought provoking

Websockets and SignalR - Chris Alcock

I've seen this talk before and somehow managed to be in here again. What I love about Chris is that he manages to pack in a tremendous amount of information in to an hour. SignalR and websockets on the front of it are powerful tools.
Another great buzz in the foyer. Not too unlike the sound of a Braun series 3.

Using nuget for fun and profit - Joel Hammond-Turner

Joel has found the solution to code reuse and its been right under our noses. It's NuGet! In this session Joel showed us how to set up our own NuGet server and his PublishNPackage tooling. He's used this effectively to reorganise big code dumps of shared code and is now an integral part of his build process. We got a quick insight how this will be used with CI build too.

I just wanted to thank the organisers for today. It was amazing.

Wednesday, July 25, 2012

Returning to Who is agile

A few months ago I wrote a review of the Who is Agile set of interviews compiled by Yves Hanoulle. Time has passed now as Yves has been back in touch and as the book has evolved I'm writing this follow up.

I think that any community has its fair share of navel gazing and it seems that the agile community suffers especially from this. Too often the Agile manifesto's signatories are put up on pedestals and listened to without question. Too often are practicioners sat around telling each other "didn't we do well". When I first came to read "Who is agile" these were the biases that I was laden with and consequently I had some reservations of the underlying purpose of this book and the value that it would bring to those not in the circles of the contributers. I also think that this behaviour is why there are such strong opinions still over agile and I think that some of the criticism is valid.

(It's probably worth reflecting on at this point that this cynicism may be saying more about me that it is about any community)

So inspite of the review Yves has continued on with adding to the book and I've continued to read it.
After grumpily dismissing the format I think I've now think I've worked out at least one way to read it. This book is not about names, nor agile. It's a book about people. If you forget the names and bio bits and just read the questions and answers you get a fantastic insight into how these people tick. Some of the best interviews are where the interviewees talk less about software development and more about the other stuff that defines them. I believe in that to be a good software developer you need to have experience in other 'stuff'. Some stories are very personal too and it's fascinating the influence that some of those incidents have on those people.

I normally read the book on the kindle but that is only half the fun. As the book has become to big to email to the kindle (via gmail at least its > 20mb) I've found I read it less but when I do there's added value. Each interview is scattered with lots of hyperlinks, some go to just some strange places, others infomative distractions, or just plain definitons. You could get lost for hours just reading through some of the links and if you are stuck for ideas for books each interview will suggest a new one. This is really Who is agile's strengh. It's a cornucopia of information! (or a yak-shaving utopia).

The other criticism I had originally was that the book had a narrow geographical focus. Yves has done well by getting a more diverse (geographically) set of people. Yes the book still is predominatly a euro-us set of interviews but there's more from futher a fields. This feels more like a truly diverse publication.

I'm impressed with how the book has progressed. For its current minimum price ($9.49) there is so much in there. Don't be put off it you don't know (or like) agile. This is not an agile book, it's a book full of stories about software people.