LeadDev London 2023 (Day 2)

This is a follow-up to my first post about day 1 of the LeadDev London 2023 conference. That post covers my notes on talks from day 1, as well as my thoughts on the overall conference.

Here are my notes on talks from day 2…

LeadDev London 2023 (Day 1)

Recently I was lucky enough to attend Lead Dev London for a second time (see my review of 2022 day 1 and day 2). As with last year, this is a one-track conference focused on leadership and engineering management. Unlike last year LeadDev was also running a separate one-track conference at the same time, StaffPlus, focused on Staff+ engineers. As I didn’t have a ticket to that, I didn’t attend any of those talks but it was great to see LeadDev expanding and I’ll be considering StaffPlus next year.

LeadDev London 2022 Day 2

Recently I was lucky enough to go to LeadDev London. You can read about my general thoughts, and the first day of talks, here. This post covers the second day.

The following is a summary of my notes from each talk. Any mistakes, errors or things that don’t make sense are entirely my fault. Hopefully, this will provide a flavour of each talk and inspire you to watch the ones that interest you the most to get the full story.

LeadDev London 2022 (Day 1)

Last week I was lucky enough to spend a couple of days at the LeadDev London 2022 conference. This is a series of conferences aimed at senior engineers and engineering managers, although for obvious reasons it’s been a few years since it was last held.

The conference itself was held in the Barbican Hall, which in general is a lovely venue. The seats in the hall were comfortable, and spending two days sitting there was not as unpleasant as I had feared. The Barbican itself was built in the early 1980s, and a few areas, in particular, looked like they needed some refurbishment - particularly the downstairs men’s toilets.

Don't Call It Tech Debt

A common refrain from developers is “We have too much tech debt! We need to tackle it to speed up!” It’s hard to argue with the sentiment - badly written code or outdated software does take considerably more effort to maintain than code that follows current best practices. However, saying we have too much tech debt is not useful, because it’s not specific enough. You can’t create a vague “tackle tech debt” project and expect to get sponsorship from the business for the work.

If you’re lucky enough to have a portion of your time available to be used for engineering directed projects then you’re still unlikely to be successful with a vague tech debt project. Getting agreement for what tech debt actually is is nigh-on impossible. Everyone has their own pet peeve that they will want to tackle as part of that project.

My solution to this problem is to avoid using the phrase tech debt. Sometimes tech debt is clear - it might be a database that is outside of its support lifecycle or a library that is many versions behind the current release. More common is that when people say “tech debt” they mean things like code that is not as testable as they would like, or which follows some patterns that they declare to be an anti-pattern. While there is broad agreement about what constitutes good code, the more detailed you get the more it becomes about personal opinions.