Do Repeat Yourself - returning to the Lead Developer conference

August 10, 2018

This article was originally posted on the Capgemini Engineering blog

After such a positive experience at the Lead Developer conference last year, as soon as I saw this year’s announcement, I saved the date and started writing the email to get my company to pay for the ticket. Thankfully, my boss didn’t need much persuasion, so I was able to join 1100 others at the Barbican Centre for two days of talks at The Lead Developer London 2018.

It’s a conference that really seems to care about doing things the right way to help attendees get the most out of it, whether that’s by maintaining a code of conduct, keeping us well fed and watered, running speaker office hours sessions, or organising mindfulness sessions to help us recharge.

There were a few recurring themes, and as with last year, one of the ideas that came up repeatedly was the difficulty of making the transition from individual contributor to leader, and the importance of realising that it’s not just a promotion but a career switch. As Dan Persa put it, “the skillset required to be a successful lead is not a natural evolution of the skillset required to be an effective developer”. For example, the Don’t Repeat Yourself principle is much less useful when dealing with people than it is when dealing with computers - people often need repetition in order to get the message. Jenny Duckett also highlighted the value of communicating goals over and over again to help the team to have a clear focus.

Similarly, Menno van Slooten talked about his difficult experience of becoming a lead, and made the point that as developers, we like the sense of accomplishment that comes from building things and solving problems, and when we become leads, it’s easy to overlook the value that we can bring by using our influence to help improve the lives of the people we work with, even if it’s just by going to a meeting so that they don’t have to.

A subject that came up in more than one talk was the value of “psychological safety”, the value of trusting your team members, and the importance of avoiding a blame culture. As with last year, Nickolas Means spun an intriguing tale full of nerdy details, to set us up for a few key lessons. Chief among them for me was the idea that we should “assume positive intent” - a team shouldn’t have to earn trust. An important part of the role of a leader is to create a healthy environment for the team to flourish, and to allow them to use their skills - as Alicia Liu put it, “a gardener doesn’t tell plants how to grow”.

Alicia Liu and Christian McCarrick both talked about the value of scheduling time to focus on tasks - or as Alicia put it, scheduling time to worry. Christian’s point about keeping track of ‘dark matter tasks’ by having a ticket for everything really resonated with me, as someone who spends a lot of time in JIRA.

Another theme that struck me was the importance of listening, and allowing other people space to talk, whether that’s in one-to-ones or larger meetings. Both Melinda Seckington, in her session on Goal-Setting Workshops for Managers, and Kevin Goldsmith, in his talk about Using Agile Techniques to Build a More Inclusive Team, provided practical examples of how leaders can help their teams to be more explicit and effective in their communications.

Being more intentional in communication was also one of the subjects of Dirkjan Bussink’s talk on distributed teams was another that really resonated with me. His team at GitHub are spread around the world, and being widely distributed brings a range of communication challenges. He talked about the value of chat (and video chat) as a “virtual water cooler”, and how it can help us to remember that there are real human beings on the other end of the pull requests and chat messages.

While technology can help, meeting in person is ideal to foster team bonds and have the kind of discussions that are only really possible when you get the team together and use the higher bandwidth of face-to-face communication.

Chat is a different medium to real conversation, and as Dirkjan said, it’s valuable to talk in Slack channels, rather than private conversations - it “encourages collaboration and people can jump in and help out, and it also promotes transparency”. This echoed one of the points I was trying to make when I visited colleagues in Mumbai last year, with my presentation on asynchronous and synchronous communication.

All of the talks were worth listening to, but there were some that particularly stood out for me. Clare Sudbery drew on her previous experience as a teacher to talk about how to enhance the skills of developers, building a culture of everyone learning together. She highlighted the importance of teaching people in a way that doesn’t put them off learning by making them feel stupid. As Clare mentioned, teaching (often in the form of pair programming) is enormously valuable as a learning tool for the teacher - being able to explain your complex knowledge to someone who doesn’t get it yet helps you to consolidate your knowledge.

Clare wasn’t the first (or the last) person at the conference to mention mob programming, but she did begin to persuade me that it might not be a completely ridiculous idea.

A point made by Clare that probably sums up my whole conference experience is that “it’s empowering to realise that other people have gaps in their knowledge too” - none of us are perfect, including those people we look up to. It reminded me of an idea that my former colleague (and Clare’s current colleague) Andrew Harmel-Law explored in a previous blog post here - the importance of admitting when you don’t know the answer.

Most of the talks focussed on so-called ‘soft skills’, but some were a little more technical. Alice Goldfuss helped cut through the hype with some sound advice about containers, while Marek Rogala gave a pirate-themed introduction to functional programming.

Adrian Howard was really preaching to the converted with me when he talked about the need to focus on business value, rather than story points.

Alexandra Hill spoke engagingly on a subject close to my own heart - code reviews. It’s too easy for them to become a source of conflict within teams, and she discussed some strategies for mitigating this, not least of which is giving positive feedback.

Just as it was last year, the Lead Dev was an excellent conference, that gave me fresh ideas and renewed enthusiasm. Someone I spoke to in one of the breaks suggested that some of the talks didn’t tell him anything new, but in a way that’s partly why I like the conference so much. I like hearing clearly expressed versions of ideas that aren’t yet fully formed in my own mind. Perhaps some of it is ‘just common sense’, but it’s often easy for common sense ideas to get lost among the noise.

It’s reassuring to know that more experienced leaders face some of the same challenges that I do, and to realise that I’m not alone in finding some things difficult. As Menno van Slooten put it, “talking to them, and knowing that they also had these problems made me feel a little bit less alone, and made me feel a little bit better about myself”. In a way, it feels almost more like a support group for lead developers than a conference. The people on stage are there to share their experiences, those experiences are familiar to most of the attendees, and the talks help us to figure out our personal coping strategies.

Now that the videos of the talks are up on YouTube, I’ll be revisiting some of the talks, and I hope to be back there again next year.