London Code Dojo 29

Monday was London Code Dojo 29 and this time we were in Shoreditch in moo.com office. Not the most productive dojo but I learnt some philosophical lessons about myself and my code!

WHAT WENT DOWN

The kata for the night was "Rock Scissors Paper" but this time there was a twist in that we had to implement HTTP servers to play the game. The idea was that you would have two "player" servers which responded to requests with a move. On top of this you would have a "referee" server presiding over a game and deciding who won.

The specification was a little bit vague beyond this and we wasted a fair amount of time getting to grips with the problem. Overall I felt the added complexity of dealing with HTTP hindered the learning experience. I paired with Ian and what code we did manage to produce is here: https://github.com/arkangelofkaos/CodeDojo29_RockScissorsPaper

MY IMPRESSIONS

Understand the scope of the problem

Getting a grasp of the problem at hand is incredibly hard in almost any situation beyond the very simple. Accepting the fact that you are unsure on how to proceed and having an "iteration zero" for setup and learning is invaluable. On the flip side this needs to be balanced with over-designing the problem...

Dealing with new technology REALLY slows you down

I have rarely dealt with writing RESTful services in Java from scratch and approaching the problem was difficult. I reckon we lost a good half an hour getting our heads around whether we had to deal with HTTP errors and what level of testing to start with.

LESSONS LEARNT

Discover a solution with small steps
When pairing with someone new, even if you are both used to approaching a problem top-down with overarching integration tests, it can be more productive to take some small steps to begin with. This way you can get used to each other's TDD quirks and flesh out any misunderstandings. 

Focus hard on learning

As with most things, it can be very easy to get caught up in what you are doing and lose sight of why you are doing it. In dojo's I am still far too focussed in the problems and not thinking hard enough on good practice. Perhaps next time I will make a plan for how I am going to learn and see if I can strictly stick to it...

Uncle Bob: Demanding Software Professionalism

On Thursday I had the pleasure of seeing Uncle Bob for the first first time at his talk: Demanding Software Professionalism.

Previously I had only heard the legends about this man, never making the conscious effort to read/watch more about him. This meant hearing him talking about his beliefs and ideals firsthand was both novel and humbling.

The premise for the talk was all around how software engineers should be expected to be more professional. As is the norm with Software Craftsmanship, this isn't through pushing methodologies but sharing ideologies. We should all believe in a steady work rate, never shipping s*%t and being highly flexible to change (amongst other things!)

Combined with the LSCC Roundtable the night before, I really felt inspired to "be better". At the end of the event, I picked up a coding challenge. I completed the work, trying hard to keep in mind Simple Design and strictly following TDD.

https://github.com/arkangelofkaos/InstructionsProcessing

I've toyed with the idea of trying to make it more complicated with sophisticated error handling and introducing some functional programming to the mix. However the concept of "less code is better code" has hit home and I'm happy with it.

Feedback is definitely welcome and would be much appreciated!

London Software Craftsmanship - Robot Tournament

To usher in the new format for LSCC Hands On Sessions we had an all evening session at the Google Campus!

WHAT WENT DOWN

The kata of the night was a straightforward implementation of a TicTacToe robot. The driving principles behind the night were around releasing early and regularly. At the end of each 5 minute round, each pair's robot would play all other robots. Along with doing TDD, this all meant we got fast feedback on how well our code/strategy was performing :)

I was lucky enough to pair with Sandro and it was really interesting working with him! I've forked the original repository and upgraded the code to use Java 8 Lambdas here:

https://github.com/arkangelofkaos/lscc_robot

MY IMPRESSIONS

Listening to feedback is invaluable

Actually paying attention to feedback is incredibly important. There were loads of problems with our Java 6/7 setup which regular and quick releases highlighted. Sadly we didn't pay more attention to the problem and we could have solved it sooner!

Focus on value

Whenever you are doing any coding, it is very important to understand why you are doing things and how you can measure the benefit. Software development is very intangible but it is our duty as software craftsman to deliver tangible value!

LESSONS LEARNT

Design upfront!
I think from now on I'm going to practice the Green Cross Code everything I under take a kata: 

1. Stop - Think about the problem and check your understanding with your pair.
2. Look - See if the problem has been solved or has a simple solution.
3. Listen - Discuss ideas for how to tackle the problem and agree a path only after listening!
4. Go - Write your first test! :P

A quick sketch of things never hurts either!

Rushing gets you nowhere fast

As the anti-thesis of the above, blindly rushing in "Leeeeroy" style really isn't beneficial at all, especially when time is tight!