Learn how to use generative AI to build reliable, maintainable software, apply test-driven development to guide AI outputs, and make smart decisions about when to trust AI.
Even Kent Beck is vibe coding these days. But does it really work? Are you wary about jumping on the bandwagon, but also worried about being left behind? This workshop creates a safe space for you to explore the real efficacy of using generative AI to write software. You’ll spend between one and five days immersed in building an app using generative AI. We’ll examine any concerns and explore how to keep your work robust, safe and ethical while maintaining control over the results. You can be in charge!
Takeaways
Build better software with the help of genAI, without losing control
Learn how to turn AI outputs into reliable, maintainable code
Master TDD techniques to keep code quality high
Get hands-on practice building real apps with AI support
Discover how to reduce risks, errors and environmental impact
Walk away with practical skills you can apply right away
Host this popular workshop at your organisation
You can help your software engineers by bringing this in-house!
“Lots of tech people can talk about technical topics, not many can generate rapport in a small group.” Emily Bache, founder of Samman Technical Coaching.
How to sign up?
Fill in the contact form and indicate that you’re interested in hosting the “Building Software Using AI” workshop. Alternatively you can register an interest here in attending one of the public facing workshops, either online or in person. We’ll take it from there.
How will it work?
This workshop can last anything between one and five days. The greater the length, the more hands on experience your engineers will get, and the more opportunity they’ll have to explore different approaches.
The maximum number of participants is 20 people.
This workshop can be run either in-person or online.
If online, participants need access to enough breakout rooms for the entire cohort to be split into pairs.
The cost is £4000 per day.
Discounts are negotiable for smaller cohorts or not-for-profit clients.
If travel outside of Manchester (UK) is required, travel and (number of days plus one) nights’ accommodation will be added to the cost.
Who is the trainer?
“Clare’s combination of coaching, leadership, advocacy, technical depth, pedagogic skill is very rare.” David Heath, Head of Engineering Enablement, UK Government Digital Service.
Clare Sudbery is an independent coach who has worked in software engineering since the mid 90s. She specialises in helping those in technical leadership, and teaching eXtreme Programming (XP) practices such as TDD, refactoring, pairing, continuous integration.
In 2009, Clare sharpened her teaching skills via a brief stint as a high school maths teacher… but quickly returned to software, gaining new energy via leadership and XP. Clare taught the Coding Black Females’ Return to Tech programme, runs various online trainings for O’Reilly, and co-ran Made Tech’s academy. She has a passion for helping under-represented groups to flourish in tech.
Clare hosted Season One of the acclaimed Making Tech Better podcast, and is in high demand to present workshops and talks at a wide variety of international conferences and events. She blogs at Queen of Questions.
How to sign up?
Fill in the contact form and indicate that you’re interested in hosting the “Building Software Using AI” workshop. Alternatively you can register an interest here in attending one of the public facing workshops, either online or in person. We’ll take it from there.
“Clare has the rare gift of being an experienced software engineer and having the ability to translate complex learnings into something that all participants can understand, regardless of their knowledge base.” Laura Poblete, Former Head of L&D at Made Tech.
Gamified version of this workshop at Agile on the Beach, 2025
How technical do technical leaders have to be? Are you worried that you’re too hands-on, or not hands-on enough? Are you exhausting yourself trying to keep up with every technical detail in your domain?
“Clare’s combination of coaching, leadership, advocacy, technical depth, pedagogic skill is very rare.” David Heath, Head of Engineering Enablement, UK Government Digital Service
Sometimes individual contributors are promoted to leadership positions and worry that they won’t be as hands-on as they used to be. Sometimes they worry that they no longer have time to stay up to date with modern technology and / or the state of their team’s code base(s). Sometimes it’s the other way around: Somebody who has never been hands-on in the technical realm is given a leadership position, and worries they’re “not technical enough”.
Whatever your position, this workshop will help you to overcome your worries and figure out the best attitude and approach for you and your circumstances.
Takeaways
How to embrace the difference between individual contributor and technical leader
How to take a step back from “knowing all the things”
How to make the most of the knowledge and experience of your team
How to identify when technical knowledge matters, and when it doesn’t
How to identify the things you need to know
Gamifying
There is also a gamified version of this workshop, “Technical Leaders for Humanity – the helpful card game”, which uses a game format based on the game Cards Against Humanity (but with all questionable content removed). Participants make snap decisions that earn them points as well as laughs, and then have an opportunity to explore those decisions in more detail.
Host this hugely popular workshop at your organisation
This workshop is always over-subscribed wherever it’s hosted. It keys into worries that are common at all levels of technical leadership, and offers practical takeaways. You can help your technical leadership by bringing this in-house!
“Lots of tech people can talk about technical topics, not many can generate rapport in a small group.” Emily Bache, founder of Samman Technical Coaching.
This workshop at LDX3, London 2025
How to sign up?
Fill in the contact form and indicate that you’re interested in the “How to handle the technical” workshop. We’ll take it from there.
How will it work?
This workshop can last anything between 90 minutes and half a day (up to 3.5 hours). The greater the length, the more we can really get into the problems and the practical advice.
The maximum number of participants is 40 people.
This workshop can be run either in-person or online.
If online, participants need access to enough breakout rooms for the entire cohort to be split into pairs.
The cost is as follows:
90 mins: £2,000
Half day: £4,000
I’m based in Manchester, UK. If travel outside of Manchester is required, travel and two nights’ accommodation will be added to the cost.
Who is the facilitator?
“Clare is experienced, insightful and a joy to work with” Diana Montalion, Systems Architect and author.
Clare Sudbery is an independent coach who has worked in software engineering since the mid 90s. She specialises in helping those in technical leadership, and teaching eXtreme Programming (XP) practices such as TDD, refactoring, pairing, continuous integration.
In 2009, Clare sharpened her teaching skills via a brief stint as a high school maths teacher… but quickly returned to software, gaining new energy via leadership and XP. Clare taught the Coding Black Females’ Return to Tech programme, runs various online trainings for O’Reilly, and co-ran Made Tech’s academy. She has a passion for helping under-represented groups to flourish in tech.
Clare hosted Season One of the acclaimed Making Tech Better podcast, and is in high demand to present workshops and talks at a wide variety of international conferences and events. She blogs at Queen of Questions.
How to sign up?
Fill in the contact form and indicate that you’re interested in the “How to handle the technical” workshop.
“Clare is genuinely nerdy, positive, kind, and focused on the greater good.” Amy Newton, Founder of Manchester Tech Festival.
Help and support for women and under-represented genders
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.
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.
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.
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
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
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.
I’m an independent technical coach, with 25+ years of software engineering experience, offering a variety of services.
Subscribe to my newsletter (queen-of-questions.kit.com) for regular updates
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.
2. 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.
3. 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.
5. 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.
6. 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. In 2024/2025, I hosted The Street Pianist podcast. I am interested in finding a new podcast to work with!
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.
My name is surprisingly hard to spell. It’s actually Clare Sudbery: There’s no I in Clare, and my surname ends ERY – like surgery or carvery).
(This page exists in a vague attempt to make this site easier to find when people spell my name wrong in search engines.)
