Developers’ Perspective – Re:Develop 2016
Never disappoint a child with a promise you can't keep. What’s this got to do with eLearning? Well, for a start it was an important lesson that Unicorn’s developers took from their recent team trip to the annual re:develop conference in Bournemouth.
You see, when we deliver final client projects to you looking slick, working smoothly and - most importantly - delivering effective learning, it’s from giving our teams the chance to get out to key events like this that has fuelled their enthusiasm, sparked them with new ideas and kept them at the top of their game for your benefit.
So although our development team didn’t all head to re:develop to improve their parenting skills, it did provide an important analogy for business – never promise something you don't know for sure you can deliver; it's far better to under-promise and over-deliver.
That little scrap of wisdom came from a talk entitled, well, 'Little Scraps of Wisdom' from Matt Northam, Lead Front-End Developer at Redweb digital agency. Matt was just one of nine speakers doing the honours on the day and we got to see them all. Here, the development team share some of their top takeaways…
Agile in the Public Sector Roo Reynolds, COO at Digi2al
Dan Proudfoot: Roo Reynolds' talk "Agile in the Public Sector" focused on Roo's experience with Agile practices within a relatable working environment. He touched on the topic of Agile principles really well - and avoided the common mistake of making 'Agile' sound like a bad marketing pitch! Seeing the inner workings of the Government Digital Service (GDS) was even more exciting. The energy Roo had for explaining the work that was done to modernise the UK Government's web presence was fantastic, and also followed on nicely from a talk last year which discussed accessibility concerns on the government websites.
Wayne Young: I found Roo's point on shared team responsibilities interesting - the idea that developers can carry out QA, UX and Accessibility roles as part of their day to day development role. From previous experience I would lean away from this point of view, thinking developers have one set of skills and aptitudes and other specialists have others (I can't imagine myself as a QA engineer!). The other point I found interesting was the one that touched on diminishing returns when doing usability testing - Roo mentioned on average, 1 user will find 30% of usability problems, while 5 users will find around 80% of them, which generally speaking makes 5 users a good maximum number of users to test with.
Software Craftsmanship vs Lean Product Elizabeth Ayer, Product Manager at Redgate
Jack Sinclair: Elizabeth's talk focused on the differences between two approaches to software development - software craftsmanship and the lean approach. Her points on different points of view when it comes to developing a solution was a relatable one - most developers can agree that they've found themselves debating the quality of their own or other people's work even on a daily basis! But which one is correct for the business? The one that involves great code, or the one that delivers the solution quickest to the customer? It was good to see the perspective from a software craftsmanship point of view and a lean point of view, and definitely made our team aware of our own opinions on the topic that might affect our team decision making.
There's More to Code Reviews than You Might Think Clair Shaw, Freelance Software Engineer/Tester
James Allen: Clair's talk gave advice to developer's on what to look for when carrying out a code review. This talk was an enlightening one - and was good to compare against our own process of code reviews. It's also a tough topic to take on (the process of having your own work reviewed by other people), and one that can often attract differing opinions. In particular, there was an interesting question raised after the talk on the benefits of 'face to face' code reviews vs online code reviews, and the speaker mentioned they weren't a fan of face to face code reviews due to the demoralising effect of having your code criticised in front of you. Personally, I disagree, and this question does raise a very important point on the culture of code reviews. I'd argue if somebody is feeling irritated, insulted, or personally defensive over criticism of their code, it suggests there is a mindset problem in either the reviewer or reviewee which is causing that. The way critique is delivered should be with the aim of improving the work, and critique should be received as an opportunity to improve, rather than as a personal attack. We should have pride in our work but we should be able to objectively analyse where improvements can be made and accept them. Ultimately I think we should treat our code like ideas are treated in the scientific method; as disposable if necessary, and always open to criticism and improvement.
Employee Evangelism: Make Your Team Badass Melinda Seckington, Developer at FutureLearn
Christy Mariaselvam: Melinda's talk focused on the theme of communication in and outside of a team, and her experience in improving this. This talk was one of the most interesting talks of the day with some of the best quotes in my opinion. I enjoyed the general of the theme which was all about sharing with the community, and improving communication within and outside of your own team. It got us thinking - how do we communicate inside of outside of our team? Could we be more transparent? I particularly enjoyed some of the ideas focusing on learning and sharing, such as having a dedicated library in the office, and also having dedicated time in the week to learn, to write blog posts, find inspirational talks to enjoy, and other methods of communication.
Vikki Price: I really enjoyed this talk. The energy Melinda had was contagious and she was able to engage the audience well. I took away the ideas about the team sharing their great work more, blogs and 'lunch and learn' sessions, talking about what they enjoy both inside and outside of work. The development team is always looking to improve at communicating what we do - and writing more blog posts is a great way to start. This also applies internally, and making sure we use our internal systems to share things that we have found interesting.
An introduction to Service Workers Phil Nash, Developer Evangelist at Twilio
Little Scraps of Wisdom Matt Northam, Lead Front-End Developer at Redweb
Stuart Jones: Matt's talk was full of advice and inspiration, giving 'little scraps of wisdom' to development teams. As a parent, I really related to Matt's analogy of software development being similar to raising small children. Matt's talk was really funny - drawing on obvious and more tenuous links. Some of the tips which stuck out in my mind was about positively sharing achievements - I loved the quote "If you are going to do great things and not tell anyone about it, you might as well do mediocre things". This is so true in software - we must be better at sharing. Another great anecdote around not disappointing your children with promises you can't keep - it is so true to your stakeholders too. Never promise something you don't know for sure you can deliver, and always under promise and over deliver. The studies in children that showed trust being eroded in confident adults who've let down children previously versus lots more trust in unsure adults who've never let down the children demonstrated this as an ingrained behaviour from a young age.
As Matt Northam summed up: "If you are going to do great things and not tell anyone about it, you might as well do mediocre things.”
We don’t do mediocre and re:develop is one thing that helps us try to stay great. If you'd like to find out more about the Re:Develop conference, you can do so by checking out their website here.
Photo credits throughout this article to We Are Base. Original photos can be found here.