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!

Lambdas: Myths & Mistakes

This evening I went along to SkillsMatter to watch Richard Warbuton give his talk "Lambdas: Myths and Mistakes"

FEEDBACK

• Always good to have humour in the presentation
• Great to invoke audience participation
• Awesome to have well formatted and properly colour coded code
• Too many "umms" throughout, will be improved with practice.
• Particularly noticeable when demo'ing the conversion to lambdas for the first time.
• Perhaps the jump from external iteration to internal iteration was too fast?
• Speak a little about streams first?
• However it was good to see a worked example straight away
• During some parts of the talk, around myths, there seemed a lack of "relevance"
• Not knowing which section a slide was part of was an issue. ("Is this still related to Myths?")
• Namely when you were talking about "Differences between expectations"
• You mentioned "Boxed primitive error messages" for streams(?). Would be better to show people rather than just telling them.
• Throughout the slides kept being changed accidentally, be wary of this as it can be jarring.
• When showing a visual example, try to keep the following code example the same.
• Don't add 1 to 4 visually and then suddenly count numbers in code.
• You mentioned "simply using .forEach() isn't great", perhaps show a quick example of "a better method".
• Going through the "count all occurrences in a book" kata. Don't just show the code solution, first talk through the semantics in plain English!
• Similarly going backwards and forwards across the messed up half solution isn't so valuable.
• Overall the content was fantastic and pitched at a good level.

FEELINGS

• This talk has left me really hungry to start using Streams and Collectors in anger.
• Visualising all these abstract concepts really seems like the way to go!

Are you better than a Coin Toss?

This evening I went along to SkillsMatter to watch Richard Warbuton and John Oliver give their talk "Are you better than a Coin Toss?"

FEEDBACK

• Having a backup for the presentation platform (i.e. second laptop/iPad) is tantamount!
• Test your presentation beforehand! Fail fast!
• Keep water to hand, fizzy drinks don't help.
• Always good to adapt (i.e. basic introduction to buy boot up time)
• Er's & Um's distracting
• Use a pause before speaking to build confidence and removes need to think mid-flow.
• This goes away with practice
• Great to use examples away from the core field (like Moneyball)
• Generally great to illustrate points with concrete examples
• Beware of standing in front of the slides and blocking them!
• Try to speak slowly, looking for cues that your audience has understood you.
• Great to have humour intermixed into the presentation!
• Good to reaffirm each others points.
• P-value diagram didn't really help to illustrate the point to those who don't know about it, try something more universal? Dartboard with % probabilities of hit area?
• Beware naming things part 1, 2, 3… because it can lead to "we are only on part 2?!" syndrome
• Avoid reading off slides directly
• You say what you need to, the slide should only illustrate your point
• Throughout it felt like a few different slides or an animation could have better illustrated the point
• On the clustering slide, show actual clusters and why they are good/bad
• On the elbow slide, show a few elbows and highlight your point
• Good example is the over/underfitting, the pictures made the point perfectly!

FEELINGS

• Producing useful data analytics is really hard.
• Using hard data analysis techniques is better than using subjective expert opinions.
• Science FTW!!!
• Without concrete and unbiased measurements, algorithms may be not better than randomness.
• Holy cow how much work does jClarity do with their mad polygot skills!?