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.

Why we are writing a monolith, not a microservice

Supriya Srivatsa

This talk was particularly relevant to me as we have a lot of monolith applications, and we constantly talk about the best way to split them into microservices… but maybe we don’t need to?

A key part of good architecture is abstraction, but it doesn’t need to be over a network.

At Atlassian they are building a modular monolith. Boundaries are hard to define, but you can use domain driven modules to split the code base.

A Commune in the Ivory Tower? - A new approach to architecture decisions

Andrew Harmel-Law

The typical way of making architectural decisions is that a team requests a decision. The architects go and have a think, then the decision is received by the team, and they try to implement it. The problem is that this doesn’t scale and can significantly delay the team.

In this talk, Andrew Harmel-Law proposes a decentralised way of making decisions - The Advice Process.

Anyone can make a decision, but before doing so they must seek advice. There are two parts to this process - a lightweight ADR (architectural decision record) and the Architecture Advice Forum.

The ADR is a document that describes a decision that was made (or is in the process of being made). It should contain:

• The title
• Context - you should put real effort in so people can understand why you’re making this decision.
• Consequences of the decision
• Advice - who gave what and when.

The Architecture Advice Forum is a weekly meeting to discuss in-progress ADRs and for people to give and receive advice.

How To Fail

1. “Bad” decisions - how do people deal with decisions they disagree with? Give advice, but let the team do what they want.
2. Old guard is the new guard - if you don’t get new people writing ADRs
3. Off-the-grid decisions

The last of these is quite serious as people are not following the process. You should ask them to write an ADR and find out why they didn’t in the first place. Did they not realise it was a decision?

Sorry… you go ahead. The art of making space and claiming space in meetings

Jemma Bolland

Only 35% of people say they can contribute in meetings when they have a contribution to make.

Some people think to talk and others talk to think. Don’t let your meeting be dominated by the latter category of people.

Make sure everyone knows how you would like them to contribute, and before you attend a meeting, if you’re not confident, find out what areas you can best contribute to.

Leave space before moving on to the next point - ask “is there anything I haven’t considered?”

Using incidents to level up your teams

Lisa Karlin Curtis

Incidents…

• broaden your horizons.
• teach you to fail gracefully.
• teach you to make systems easier to debug.
• are a chance to spend time with, and learn from, the best.

To help people learn make incidents more accessible. You can lower the bar so you declare an incident more frequently. This will help you to practice for the big incidents when they do come.

Encourage everyone to participate by announcing incidents and sharing a public slack channel.

While resolving the incident show your working - share as much as you can, including what you tried that didn’t work so people can follow along after the incident.

Be the catalyst in a junior engineer’s career

Amber Shand and Jessie Auguste

There are four stages to a person’s career in a company:

1. Attraction
2. Onboarding
3. Development
4. Retention

The Tech Talent Charter is a non-profit organisation aiming to improve inequality, diversity and inclusion in the UK tech sector.

Mentors vs Buddies vs Sponsors

Mentors should avoid spoon-feeding people - teach people how to teach themselves.

Buddies should cooperate with them. Be a safe person for them to discuss things with.

Sponsors should aim to identify and promote high performers.

Provide opportunities for people to add value beyond adding code.

Compassionate Refactoring

Clare Sudbery

Refactoring should make things…

• easier to understand.
• so they can fit into our heads.
• cheaper to modify.

Move in tiny steps, and don’t refactor code that isn’t testable.

Why do people not refactor?

• External pressure.
• Unrealistic deadlines.
• Impatience.
• Seeking perfection.

This leads to guilt… shame… and despair.

This makes you feel like you’re not as good as the book you read, or the speaker you saw.

It makes you want to hide bad code.

It makes you try a big bang refactor, which doesn’t work.

We’re in a knowledge industry and yet we find it hard to ask permission to spend time to think and analyse.

People in leadership feel like they need to give the impression of everything they do being great. This makes junior engineers feel bad.

We need to allow time because we are fallible.

Sculptors start a raw material and remove bits. Writers and coders need to create the raw material so we can start editing - the first draft.

Something that is slightly improved is better than something that has been destroyed to try and make it perfect.

Learn how to make the tiniest improvement that keeps the tests green.

Seek the joy of coding and of doing a good job. People who enjoy their work are much more effective.

Skiller Whale Coding Competition

During the conference Skiller Whale were running a coding competition where the top three entries would win an Oculus Quest 2. The challenge was twofold. Firstly you needed to write an SQL query processing some customer data. The second part was to automate the submission so you could submit it quickly enough.

The first part was pretty fiddly to get right. There was a customer table and an orders table. The problem was to calculate the average rank of customers over a period, where customers are ranked daily based on the amount spent, including on days when they didn’t spend anything. Ranking customers is easy enough using the rank function. The challenge comes from including customers on days they didn’t order anything. This requires a full outer join between a table of dates and the customers and then left joining onto the orders table.

Each time you submitted an entry you were given a different date range and target rank to return. The second part of the challenge is to automate the submission so you can submit in less than one second. Luckily for me, only two people completed this part, leaving the third spot open to the person with the most efficient query. I managed to sneak into third place by replacing the date table, which initially I was doing this by running a distinct over the dates in the order table (requiring a full scan of the table), with the generate_series function which is much more efficent.

I’ll write a review of the Quest 2 when I’ve played with it a bit, thanks Skiller Whale!

I’ve included the SQL I submitted below, just in case anyone is interested.

with sales_by_day as
    (select dates.date, customers.id as customer_id, name,
            rank () over
                (partition by dates.date
                    order by coalesce(sum(amount), 0) desc)
                as pos
        from customers
             full outer join
                (select @start_date
                        + (n || ' day')::interval as date
                    from generate_series(0, 30) n) as dates
                on 1=1
             left join orders on
                orders.date >= @start_date
                and orders.date <= @end_date
                and orders.date=dates.date
                and orders.customer_id=customers.id
        group by dates.date, customers.id, name)
select name, avg_pos from (
    select name, avg(pos) as avg_pos,
           rank () over (order by avg(pos) asc) as avg_rank
        from sales_by_day group by customer_id, name
) as avg_rank
    where avg_rank=@rank limit 1

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.

The food was very nice, particularly the Banoffee pie from lunch on day two. The size of portions was generally good, although you did need to stock up from the salad bars at lunch to get a decent plate full. Queues were also not too much of a problem, other than the first ten minutes or so of lunch.

Enough about the practicalities though, what about the content? No one goes to a conference for the food, but instead for what you can learn and take back to your job. LeadDev is a single-track conference, so you have no choice over what to see, but fortunately, most of the content was general enough to be useful to everyone. Both days were hosted by Meri Williams who did a great job keeping things moving swiftly, and setting the scene for each talk.

The one talk I did skip was about scaling a mobile app deployment process because I don’t work in mobile. There was another talk with a brilliant title about driving and defining software quality, which turned out to just be a story of someone’s time in game development QA, and I struggled to find any useful takeaways. These scheduling missteps were rare though, so now let’s talk about the talks I enjoyed the most.

As I write this you can buy on-demand access to all the talks from the LeadDev site. I don’t know if they plan to make the talks available for free at some point, but previous conferences are available, so that suggests they will be.

The following is a summary of my notes from each talk on the first day. 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.

Navigating The Chaos of Scaling

Vitor Reis

This talk was about how to tell what a high-performing team look likes, but also about how to make the trade-offs to make high performance sustainable.

What does chaos look like? It can look like managing 20 people and still being on the on-call rota (depressingly this applies to me!) or doing five or more interviews a week because there aren’t enough people available to do interviews.

Try to recognise when you’re doing poor work, or are wrong, by being self-aware. Also, ask your manager what they think it would great looks like in your position, and compare it to your current performance.

Your aim is to be replaceable. If there’s a process you run can you automate it? Can you delegate it?

Be efficient with your time, and take the time to reflect on how you’ve spent your time each week, Try to do better each week!

It’s tempting to add people to a team but this can have negative consequences. People start to wonder if they’re being replaced. They worry that the new person might not do their job well, or that they might do it better than them! Adding people will make things go slower, at least for a while.

As a leader, you should be writing all the time. Writing is thinking, and it helps others to follow your thought process.

Keeping Your Code Base Fun At Scale

Raul Chedrese

This was a short talk looking at the question of how we ensure every developer has a fun experience? Code bases naturally become less fun to work on as they get bigger.

Don’t assume you know the answer - try to understand the developer experience, then form a vision and iterate on it. Understanding can be as simple as sending a survey with the question “What is preventing you from having a fun experience?”

Focus on building strong tools. Pick one thing and focus on that, rather than trying to solve too many things at once.

CSS: Cascading Support Systems

Phil Bennett

Empathy in senior leadership is a superpower. It increases creativity and productivity. When you are several levels up it’s easy to burn out worrying about the problems of all the people who report to you.

A technique that Phil has borrowed from therapy is Solutions Focused Brief Theraphy. This works in a similar way to how we work in product and engineering teams, so is familiar to people. To follow it you ask the question “Imagine the problem you’re facing has gone away. What do you notice?” Work with them to define the steps to get there, and help them to execute those steps.

As a senior leader, you should ask people to support each other, and cascade this to the people who report to your reports. You can scale empathy!

What Dashboards Don’t Tell You

Laura Tacho

As someone who is passionate about dashboards and trying to be data-driven in management, this was my favourite talk of the conference.

Some metrics can be perceived differently. Laura used the example of peaks and troughs in a tickets completed metric. Without additional context different people can interpret the data differently. By overlaying the number of incidents the metrics become more valuable.

People’s self-perception matters more than we think, and we should not discount qualitative metrics.

How do you move from metrics being perceived as surveillance rather than empowerment?

Vanity metrics are metrics without meaning. We can add tension to metrics to make them more valuable. Balance speed or activity against quality, reliability or satisfaction.

Laura recommended three sources that I have not yet checked out, but I intend to.

• The SPACE of Developer Productivity
• Mind the Gap: On the Relationship Between Automatically Measured and Self-Reported Productivity
• How to Misuse and Abuse DORA Metrics

She also recommended GetDX.com as a tool to help you measure developer experience. Unfortunately, it has a truly terrible website, with no information about the tool, or any hint of pricing, just a “request a demo” button. I really liked the sound of this tool, but it’s going to be hard for me to justify investing time in it.

Building The Perfect Asynchronous Meeting

Alexandra Sunderland

How is an asynchronous meeting different from a Slack thread or an email? It’s still scheduled like a meeting, but instead you just put deadlines into people’s calendars about when they should have responded to the meeting. It requires all the usual good practices for meetings, but they’re even more important. You should share timelines for the meeting, expectations about what people should do, logistics of how to contribute (Google Docs, Miro, etc), and what you expect from people.

Meetings don’t need to be 100% async, but the preparation can be done before a shorter synchronous catch-up. For a retro, you could fill in the retro board ahead of time, and then have a meeting to discuss the board.

Meetings can be asynchronous for information pushing or brainstorming, but relationship building should be synchronous.

The benefits are that you get more time for thought, as the context is more accessible (although more effort is required to set the agenda and in keeping notes). The downsides are that it requires more coordination, and you don’t get real-time answers or fast-paced discussions.

This was a really interesting idea, and I intend to try it out for the next retrospective I run.

How to build trust as a new manager in a fully remote team

Sadhana Gopal

Being remote means you must be more intentional about building relationships. You are only represented by your active voice, so don’t be passive.

It’s easy to misinterpret when remote - assume positive intent.

As a manager try to design the wider environment, then design the team environment, and finally design yourself to model the behaviours you want to see.

Use asynchronous meetings for productivity, but synchronous meetings for engagement.

Don’t be always on - acknowledge FOMO, and take time to switch off.

People Building: Career planning for your direct reports

Daniel Burke

On a practical level, this was a really great talk. Daniel Burke was a really engaging, enthusiastic speaker who really owned the large stage in a way that most other speakers didn’t manage.

The great resignation is not about people quitting, it’s about people growing. This talk was focused on Daniel’s method of career planning. He asks people three questions.

1. Position - where are you?
2. Plan - where do you want to go?
3. Progress - how will you get there?

Aligning on performance with your manager is essential to moving forward on career building. You can only be successful if you’re on the page as your manager about what success looks like.

Don’t wait for the role to open up to begin preparing for it.

As a manager, it’s important not to project your motivation onto others. Although it’s a dirty word, money is a valid motivation for going for a promotion!

It’s not about the next level, it’s about the next step.

Taking the 737 to the MAX!

Nickolas Means

This was a really great talk about the two Boeing 737MAX plane crashes, the failures that lead to the plane design that allowed them to happen, and precisely why they crashed. The talk was really hard to take notes from, and isn’t directly relevant to many people, but is well worth a watch if you have time.

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.

The Power Of Dashboards As A Management Tool

In November 2021 I gave a virtual talk as part of the IT Non-Stop 2021 Conference. Here is a recording of that talk.

Office Based Osmosis

Recently my collegue Chris Sheldon posted an article titled “Under Pressure”. It’s excellent so please take a few minutes to have a read of it.

Ok, are you back? Great. Chris talks in part about feeling like he misses absorbing knowledge through osmosis in an office.

Osmosis, in case you’ve forgotten your biology lessons, is the spontaneous passage of something through a semipermeable membrane. In this case, we’re talking about knowledge entering your head without you needing to consciously do anything about it.