Category: Uncategorized

Videos of talks, interviews and live coding

Videos of live coding

Nov 2020 on Twitch: Refactoring — simple live demo using my Reconciliate code base:

Clare speaking during this video — code in background
Twitch refactoring live stream, 2020

Videos of talks

(not all my talks have been filmed — see here for full list of talks)

YOW! Perth, Tue Sept 12th 2023, Continuous Integration — that’s not what they meant.

YOW! Perth, 2023, Continuous integration — that’s not what they meant

Lead Dev London 2023, Wed Jun 28th 2023, The awful agony of the app store: When software delivery goes wrong. That link requires a Lead Dev account, but there is a free — and longer — version of the same talk (as delivered at YOW! London in Nov 2022) here.

Lead Dev London, 2023, The Awful Agony of the App Store

Lead Dev New York 2023, March 15th 2023, Let them learn! How to nurture great software engineers:

Clare speaking during this video — arms spread
Lead Dev NY 2023, Let them learn! How to nurture great software engineers

Lead Dev London 2022, June 8th 2022, Compassionate Refactoring (Join LeadDev.com for free to access this content):

Clare speaking during this video — big stage, including audience
Lead Dev London 2022, Compassionate Refactoring

Joy of Coding, June 17 2022, Let’s stop making each other feel stupid:

Joy of Coding, Let’s stop making each other feel stupid

YOW! London, Nov 2022, When Software Delivery Goes Wrong (Why App Stores Could Make You Sad):

YOW! London 2022, Why app stores could make you sad

GOTO Copenhagen, Tue 4th Oct 2022, How to stop testing and break your code base:

Clare speaking during this video — big screen in background
GOTO Copenhagen 2022, How to stop testing and break your code base

Thurs 9th Sept 2021, Devbreak21 — “Let’s stop making each other feel stupid”:

Clare speaking during this video — big screen and slides dominate the image
DevBreak21, Let’s stop making each other feel stupid

June 2019: Time Travel — How to Live Outside the Clock (at Lead Dev London 2019 with Sal Freudenberg):

Clare and Sal on stage
Lead Dev London 2019, Time travel — how to live outside the clock

Making learning conscious — how to build a learning culture, Made Tech Talks webinar, Wed 3rd February 2021:

Clare speaking during this video — big screen with slide dominates
Made Tech Talks 2021, Making learning conscious — how to build a learning culture

June 2018: Teaching New Tricks — How to Enhance the Skills of Experienced Developers (at Lead Developer London 2018):

Clare speaking during this video — big screen with slide with picture of dog dominates
Lead Dev London 2018, Teaching New Tricks — How to Enhance the Skills of Experienced Developers

Yves Hanoulle, June 2022: Who Is Agile series: “Asking questions is a good way of teaching

Mob Mentality, April 2022: Learning through the ensemble

How to build a successful engineer academy, Made Tech Talks webinar, Thurs 25th February 2020 1pm — 2pm GMT

Interview with Alex Bolboacă from MozaicWorks, May 2021. About TDD, maths, writing novels and lots more!

Interview with Chris Walker about my IT career, July 2020

July 2020: #MadeTechTalks webinar: Myself and @dreas1 were talking on the topic “How to spin up a digital project during lockdown: challenges, tips and tools”

April 2020: Podcast / Interview about refactoring with Robby Russell on the Maintainable podcast (not actually a talk or even a video, but it seemed to make sense to link to it here)

Feb 2019: Teaching experienced developers — Interview with the .Net Rocks podcast (not actually a talk or even a video, but it seemed to make sense to link to it here)

Jan 2019: NDC London, Jan 28th — Feb 1st 2019: “Teaching New Tricks — How to enhance the skills of experienced developers

Sept 2018: Let’s Stop Making Each Other Feel Stupid (at GoCardless)

August 2018: Podcast / interview on “Let’s Stop Making People Feel Stupid” with @AgileAmped and @ChrisMurman at Agile 2018 in San Diego.

October 2017, ThoughtWorks Manchester: We’re Going on a Bear Hunt — How to Banish Fear in the Workplace.

7th April, 2017: Graphics and circles

27th March, 2017: Lightning talk on “Be Bold for Change” for International Women’s Day at Thoughtworks Manchester

2nd Feb, 2017: Test Driven Novel Writing — pecha kucha talk from OOP Munich.

21st Jan, 2016: Mob Programming

9th July, 2015: Lightning Talk on Collaboration

Inclusive Design ID24, Sept 22nd 2022, Let’s stop making each other feel stupid

The Legacy of Socrates, Nov 24th 2021, Let’s stop making each other feel stupid

NE Bytes, online, Wed 20th Oct 2021: “How to stop testing and break your code base

Fri 3rd Sept 2021, Agile on the Beach — “How to stop testing and break your code base

Wed 19th May 2021 — io.net virtual meetup — “How to stop testing and break your code base” (my bit starts at 1:04)

June 2017: Teaching New Tricks — How to Teach good software development practices to both experienced and inexperienced team members.

27th Oct, 2016: How do you know what you’re doing? at Women of Silicon Roundabout

28th Jan, 2016: Women Can do That Too at Women of Silicon Roundabout

Surviving and thriving in tech

Help and support for women and under-represented genders

Luce Carter, Sal Freudenberg, Cynthia Lee and me in our winning team at Hack Manchester

Do you need support to survive and thrive?

Are you a newcomer to the tech industry? Are you from an under-represented gender, eg a woman or non-binary? Do you worry about how you can find success and fulfilment in a male-dominated industry?

I often meet women and other people who are worried about their futures in this industry, but who have so much to offer, and find it helpful to get advice and support not just from someone like me with years of longevity in the industry, but also from each other.

Based on some conversations I had recently at a Code First Girls event, I’ve decided to offer a group coaching programme for gender minorities in tech.

How will it work?

  • We will meet weekly, online, for five weeks
    • Dates will depend on availability of participants – express an interest and I’ll keep you updated
    • Times will be adjusted to best suit the time zones and preferences of participants
  • There will be no more than ten people in each group
  • The total cost will be £150 per person (working out at £30 per person per session), payable in advance
  • Each session will last for one hour and will consist of a combination of
    • Brief inspirational presentation
    • Group discussion
    • Q&A
    • Conclusions and actions
  • Connections formed will be long-lasting, and I will facilitate the possibility for group members to continue supporting each other for no extra cost
  • For those that wish, they can sign up for another five weeks (group members will probably change in each run)
  • Details will vary according to the needs and desires of each cohort, but I expect the following takeaways as a minimum:
    • How to handle imposter syndrome
    • How to progress in your career
    • How to handle prejudice and the effects of unconscious bias
    • How to get support in the workplace

Who is the coach?

I am a woman with 24 years of software engineering experience. Halfway through my career I was laid off by my employer. I lost heart and gave up altogether, deciding instead to try another career. Actually I tried two separate careers. But four years later I realised that tech is my home, and I returned with renewed determination. That was 12 years ago, and since then I’ve achieved more than I ever believed I would. I now travel all over the world meeting amazing people and speaking at major events, as well as working closely with software engineers in multiple industries, helping them to improve their software development practices.

I used to lead the Made Tech academy, I taught the Coding Black Females Return to Tech programme, I taught for Code First Girls, and I’ve always been passionate about increasing opportunities for under-represented groups in tech.

How do you sign up?

Fill in my contact form and let me know you’re interested in the Surviving and Thriving in Tech Group Coaching. We’ll take it from there.

Let’s stop making each other feel stupid

I’ve been delivering a talk with the same title as this blog post for a few years now. It’s a popular talk, and a topic that’s close to my heart.

Here’s a video of the talk from DevBreak 2021, and the following blog post was originally written for Agile Meets Architecture, Berlin 2023.

Note: At the end of this post I present the “Stupidity Manifesto”, which you can sign here.

Ginger cat covering its eyes, as though embarrassed or ashamed
This cat looks ashamed

Once upon a time, there was a female software engineer. When she studied mathematics at university, she was one of a tiny minority of female students. That was the first time she internalised the idea that women can’t do the same things that men can do. The evidence was in front of her eyes. And it was there again when she switched to software engineering. In her first job, she was the only female developer. And compared to her colleagues, she was a late developer. It seemed they had all taught themselves to code as children and teenagers. But this was the mid 90s. She attended university in the early 90s, where she never owned a computer and barely used one until after she graduated.

A few years later, in her second software job, she kept asking to work on the more difficult, more interesting, code bases… but she was always denied. When she interviewed for a more senior position elsewhere, she was told she didn’t know enough. She wasn’t surprised. It confirmed all her worst suspicions about herself.

Twelve years into her career, she was laid off and it was a relief. She had never felt like she belonged. She didn’t want to work in IT any more.

Here’s a question for you: Do you ever have to Google anything related to your sphere of expertise? When you do, do you shame yourself for it? Do you feel as though you’re supposed to know everything, and there’s something wrong with you if you don’t?

If you feel this way, you’re not alone. The woman described above is me. But now I’ve been doing this for over 23 years, and I make a living out of teaching software engineering skills. Does this mean I’ve finally reached the “comfortably confident that I know all the things” stage of my career? Nope. Quite the opposite.

The more I learn, the better I understand how little I know.

Text reads “Being an effective IT professional is not about what you know!” next to an image of a cat looking surprised.
Being an effective IT professional is not about what you know!

These days, when I find myself beating myself up for my ignorance (and I’m sorry to tell you that I do still beat myself up), I remind myself that learning is a fundamental part of this profession. Rather than worrying because you still have stuff to learn, you should instead be concerned if you don’t.

But even when we know on some level that this is true, it’s not always what we tell each other. And as a result, we do untold damage by making each other feel stupid.

What if we didn’t do this? Imagine a world where you arrive at your desk each day excited about learning new things. Where you never worry that you don’t know enough. Where there is no such thing as imposter syndrome. Because it turns out that being an effective IT professional is not about what you know. But we think it is — and that causes problems.

Problematic behaviours

I left the industry because I felt inadequate and stupid. It seemed that everyone else knew more than me. But I do a lot of teaching these days, which means I’m now very aware of how common this feeling is, and I’ve noticed some behaviours that I believe make it worse for all of us. I run through all of them in my talk, and I’ll present the following key ones in this article:

  • Laughing at others for gaps in their knowledge
  • Talking in jargon
  • Hiding a lack of knowledge
  • Gatekeeping

Laughing at others for gaps in their knowledge

I’ve lost count of the number of times I’ve witnessed colleagues emerge from interviewing a prospective employee and saying things like “Can you believe, I just interviewed someone who didn’t even know what a Z was?” followed by incredulous laughter. Haha, what a doofus, fancy thinking they could get a job here if they don’t even know that.

A cat peeking out from a box, looking as though it might be scared to come out
Don’t make people want to hide away!

For Z, you can substitute your favourite surely everyone knows about this item, and I guarantee I can find you somebody amazing, experienced and successful who knows nothing about it.

But it helps us bond with each other, right? If we can have a bit of a laugh about how stupid those other people are? And it doesn’t do any harm, because they’re not in the room. They don’t know we’re laughing at them. No, they don’t. But you do. I do. Everyone else in the room does. I’m certainly not the only person thinking, I must make sure I don’t become the next butt of the jokes. Instantly feeling stupid, as I consider all the things I don’t know enough about.

The worst thing about this is, I’m likely to handle this problem by taking steps to hide my ignorance. I’ll join in the next round of laughter extra loud, to prove I’m one of you clever people and not one of those stupid ones. I won’t ask questions to clarify crucial details. And I will find myself increasingly…

Talking in jargon

This is another one that can help us to bond with each other and feel clever, but it comes at the cost of making others feel stupid. Every time you make assumptions about what jargon others will understand, or even worse, judge them for not knowing the same jargon as you, you make it less likely they’ll ask for clarification. It becomes more likely that gaps in communication will widen, and your product will not behave the way people expect or need it to behave.

And of course, not only do people avoid asking for clarification, they take active steps towards…

Hiding a lack of knowledge

Of course we all do this. We avoid “asking stupid questions.” We exaggerate what we know in job interviews and on CVs. We don’t admit it when we find ourselves in meetings where we have little or no idea what anyone is talking about. It’s just self preservation, right?

The more we work in environments where knowledge is considered to be a good indicator of our colleagues’ proficiency, the more likely we’re not being honest with each other about what we know. The last time I was in the market for a new job, I reached a point where if I saw companies imply that they possessed advanced techniques for filtering out only the very best and rejecting the rest, I automatically rejected them. Because in those kinds of environments, people will go to advanced lengths to prove they are indeed the best… which means never admitting any weakness and therefore covering up the unavoidable fact that they don’t know everything.

Are these people happy and confident? No. They are likely peddling furiously underwater and permanently paranoid that someone will find them out… for what? For being stupid? Well yes, that’s what it feels like. But what they’re really in danger of revealing is their own basic humanity.

And of course, the kind of culture I’ve described above, the kind I came to deliberately avoid when looking for good companies to work for, is that of…

Gatekeeping

This is where we decide that we are special, and large swathes of the rest of the profession are not, and all we need is to perfect our formulas for identifying the pearls and rejecting the swine. And what does it do? Yep. It makes us all feel stupid, terrified as we are that we will come up against these standards and fall short.

Solutions

So, what can we do to address these problematic behaviours?

The Lucky 10,000

The Lucky 10,000 - comic by xkcd
https://xkcd.com/1053/

As described in xkcd’s excellent cartoon above, today’s lucky 10,000 will learn something exciting and new. And the rest of us have a choice: Embrace that journey and travel with them, or stand on the sidelines laughing at them for not having learnt it yet.

Making that decision to get excited about the learning our colleagues have yet to do, is about a lot more than individual choices in single moments. It’s about recognising that the range of knowledge in our industry is very wide. It’s wide, and it’s widening exponentially all the time. You could take two respected professionals with long successful careers, and find no overlap in their knowledge. Hell, you could find a busload of them with no overlap. It’s pointless to wring our hands over what people don’t know, and much more enlightening to embrace the learning of our colleagues and ourselves.

They don’t know as much as you think they do

Four circles, all with the same faces, but each rotated with a different one at the bottom. The following topics appear under the faces: Hadoop, iOS Native, AWS, AIOps, Recursion, Encryption, PySpark, SonarQube, Golang, Terraform, CentOS 7. The faces always look happy / confident, apart from the bottom one, which looks confused / distressed. The person at the bottom is feeling intimidated by the knowledge of all the others. But everyone has a turn at being confused.
The wheel of confusion

I use this series of graphics a lot in my talks. Here I show only four of the images, but it’s enough to illustrate the point: When you look at an internal message board where your colleagues are discussing a range of subjects, it’s tempting to think to yourself, “Oh my, all these people are so knowledgeable and confident on all of these subjects, and I don’t know about any of them.”

But of course each one of those people is only posting confidently about some of those topics, maybe only one each, and chances are you have posted knowledgeably yourself on at least one of them. And they are likely suffering the same worries and insecurities as you are, looking at each other — and you — and thinking how much less knowledgeable they are than everyone else.

You’re not doing anyone any favours — least of all yourself — when you assume people know more than they do. We can all benefit from being realistic about each other’s capabilities.

Be confident in your own ignorance

At the start of this piece, I talked about how I ran away from this industry in relief, glad to be laid off and determined never to return. But a few years later I found myself in need of a new job, and recognising that despite having not previously valued them, those twelve years of engineering experience were worth something to me.

I returned to this industry, but this time with a different approach. In the intervening years I’d been working for a lower salary as a high school maths teacher, so it wasn’t hard to return to technology at entry level, joining all the new computer science graduates and behaving as though as I was brand new. This gave me a new lease of life. I wasn’t pretending to know anything I didn’t, but I was excited and eager to learn. I let go of any shame and made a point of asking simple questions.

Of course those previous twelve years did count for something, and it wasn’t long before I found myself in senior leadership positions. And it was something of a revelation to me that the more open and confident I was about what I didn’t know, the more people respected me.

Not only did it help me to progress and learn quickly, it also helped those around me to do the same. When senior figures ask simple questions and show no shame about what they don’t know, everyone around them is empowered to do the same. Everyone feels less stupid, and their knowledge and competence increase more quickly as a result.

Happy cat, curled up on a rug and smiling.
Happy cat!

I’ll leave you with what I call…

The Stupidity Manifesto

[If you’d like to sign the manifesto, you can do that here.]

LET’S STOP MAKING EACH OTHER FEEL STUPID. Instead, let’s…

  • ENCOURAGE EVERYONE TO ASK QUESTIONS
  • Lead by example: Be honest when we’re confused
  • Value curiosity over knowledge
  • Prioritise clarity over jargon
  • Remember we all forget stuff
  • Get excited about teaching and learning
  • Acknowledge the broad range of knowledge in our industry, and avoid judging someone if their knowledge doesn’t match ours
  • LET’S STOP MAKING EACH OTHER FEEL STUPID.

If you’d like to sign the manifesto, you can do that here.

Need help rediscovering your geek joy?

Sudbery Software Engineering Ltd

Sudbery Software Engineering Ltd

I’m an independent technical coach, with 23 years of software engineering experience, offering a variety of services.

I’m most effective at the things I love the best, and these are detailed below. I’ve worked with a variety of groups and individuals, and you can see many recommendations on my LinkedIn profile. Please do contact me if you’d like to start a conversation about how I can help you and/or your organisation.

Things I love to do:

1. Help teams improve their software engineering practices, particularly in areas such as Test Driven Development, refactoring, continuous integration and collaborative working practices. For instance, the Samman Technical Coaching technique developed by @EmilyBache.

2. Keynote / speak at public and private events, on a wide variety of topics relating broadly to (a) good engineering practices, and (b) how we can look after each other. For instance, my talks at @SDDConf@JoyOfCoding@GOTOCon and @TheLeadDev.
For topics past and upcoming, see my events page. You can also see videos here.

3. Run workshops, coding retreats and online training on practices such as TDD, refactoring and collaborative working. For instance, my ensemble working workshop at @GOTOCon Amsterdam 2023, my coding retreat in Nov 2023 with @KevlinHenney for @SWCornwall, or my online quality code bootcamp and refactoring trainings for O’Reilly.
See my events page for more details.

4. Writing. My report on trunk-based development and continuous integration was published by @OReillyMedia in June 2023, my article on refactoring is published on Martin Fowler’s site, and there will be more to come.

5. Podcast hosting. For 12 months in 2021/2022, I hosted the Making Tech Better podcast, where I published fortnightly interviews with industry experts on the topic of improving software delivery. I am interested in finding a new podcast to work with!

Tips on Organising Hack Days / Hackathons

Caroline on Twitter asked “Currently researching “how to put on a data hack day” Any tips?”

Here is my very notey response, mostly based on my experience as (a) participant at Hack  Manchester (RIP) and (b) being a judge myself at various different events over the years.

  • Think about the comfort of the participants – both physical and emotional.
  • How can you be welcoming and supportive?
  • Give them the opportunity to solve real-world problems but with a lot of scope for creativity.
  • Give them a choice of different challenges.
  • Don’t expect judges to do full code reviews (too time consuming) – judge by presented results instead.
  • Ask participants to present their results in an easy to digest format (to streamline the judges’ job).
  • Let people present vision as well as working results (it’s hard to get things fully functional in a short space of time).
  • Recruit helpers to give a hand when participants are stuck.
  • When recruiting helpers, emphasise they do NOT have to know all the answers. Their job is to help people seek solutions, not provide solutions themselves.
  • Have a v strict time limit for final presentations. How many teams do you have? How long will presentations take overall if (eg) you give them 2 mins each and allow extra for changeovers? Is that too much?
  • You’ll be surprised how much people can present in even 1 min. Let them know in advance that time limits will be strict. Cut them off if they overrun.
  • One great approach if you have a v big event is to get them to create a 1-min video each, to be watched separately by judges.

SDDConf May 2022 – Compassionate Refactoring

Part 1 – Refactor Tennis1

git clone https://github.com/emilybache/Tennis-Refactoring-Kata.git

Choose your language

Refactor TennisGame1

Part 2 – Example of unit tests retrofitted

Either… git clone git@github.com:claresudbery/gilded-rose-kata.git

or… git clone https://github.com/claresudbery/gilded-rose-kata.git

(if in doubt choose the second)

cd gilded-rose-kata

git checkout csharp-test-start

Look at this file for description of problem (GildedRoseRequirements.md in root of repo)

Look at this file to see tests (/csharp/GildedRoseTests.cs)

Part 4 – Easier to understand / cheaper to modify

Demo 1 – Easier to understand / cheaper to modify

Part 6 – Extract Method

Demo 2 – Extract method

Refactoring catalog

Part 7 – Refactoring tools

Demo 3 – Refactoring tools

All Parts – Sticky notes from Walls

All visible here

Part 8 – Further resources and ideas