Coding Is Like Cooking

I very rarely go to the cinema, but this weekend I took my two teenage daughters to see Barbie. Mostly it was fun and silly but several scenes had me in tears. Now I want to go see it with my mother, actually.

What really got me was the depictions of the different generations. The grandmother in her kitchen (my mother) trying to create a world where girls of my generation could do anything, be anything. My generation – we got far but it was hard and there is still a long way to go. America Ferrera’s monologue “It’s literally impossible to be a woman…” says it all.

And the next generation, that of my children?

I have a great career in tech. I’ve worked hard and I try not to worry if I’ve been discriminated for or against along the way because of my gender, (which I probably have). I’ve reached a pretty good place.

Both my children are starting new schools in the next few weeks, and both are nervous and excited about it. The older one begins university, studying engineering physics. She looked at last year’s class photo and was troubled to find she couldn’t easily spot any women in it. Maybe they are all standing at the back?

My younger daughter has reached an age now where she can choose a school and some of the subjects she will study. She has chosen science and technology and a school she liked partly because they deliberately mess with the gender balance. Each year they have three classes (forms) doing technology, and they make one all boys, so that the other two can have a more ordinary gender ratio.

When I studied physics and engineering all those years ago, the gender ratio was pretty terrible. Doesn’t feel like it’s got much better. I wish for so much more for my daughters.

After three years of close collaboration with ProAgile I felt it was time to strike out alone as an independent Technical Coach. I continue to recommend my former colleagues at ProAgile – if you’re looking for an agile coach or some training in agile methods generally, they are world class. I hope to find opportunities to collaborate with them again in future.

For myself though, I feel I’m on a slightly different path. I will continue to lead and promote the Samman Technical Coaching Society, and to work as a technical coach. I have a couple of other projects I want to work on as well, that I’m hoping to carve out some time for soon. More details to come later.

I am convinced that the world needs more technical coaches. Practices like Refactoring and Test-Driven Development don’t just happen by themselves. It takes quite an investment in time and effort for most developers to see the point, and to realize how much it would help them to work this way. Then they need to put in some time and effort to become proficient using these skills, and a supportive team culture is essential. Having an experienced technical coach on hand can make all the difference for success. 

During 2021 one of the teams I coached was struggling to make progress in a large, complex codebase. We worked together in an ensemble which enabled them to pool their knowledge and get a grip on the code faster than before. We held several learning hours focused on test design which helped them to improve the unit tests and get better feedback on their changes. Everyone said afterwards they felt like working with the coach had helped them to work more effectively. I’d like more teams to experience this kind of progress. 

Samman is the method I use when I’m coaching software development teams. The two basic components are ensemble working – where you gather the whole team to work together on one programming task – and learning hours – where developers learn new skills and practice on exercises. 

I published my book “Technical Agile Coaching with the Samman method” in January 2021, because I wanted to help other technical coaches to use this coaching method and to promote agile ways of working. When I held this book in my hand for the first time it was somehow larger and heavier than I expected. I felt a huge sense of accomplishment! Since then, I’ve more and more realized the book was just the beginning. There are a lot of development teams out there and only a few technical coaches who really know how to help them.

The book generated quite a bit of interest and I’ve spent a large part of last year talking and writing even more. I was asked to contribute articles about Samman coaching for some of the biggest online magazines in our industry – Methods and Tools and InfoQ. I also had a steady stream of invitations to appear on podcasts. I just went through and counted them – eight were published in 2021! (I list them at the end of this article)

I was invited to give the keynote address to the ACCU conference. It’s always a huge honour to give a keynote and I spent many hours preparing this talk. For the second time in my career I was also invited to speak at the annual Agile conference organized by the Agile Alliance. It’s one of the biggest conferences in the software world – also a great honour to be asked to speak there.

For most of my career I’ve been part of the Agile, XP, DevOps, Testing, Python and Java communities within software development. Although I have previously done a fair amount of architecture work, this year I feel I also took a step into the Architecture community for the first time. I was invited by O’Reilly to be a judge in their Architectural Katas competitions. I see technical coaching as one aspect of the kind of technical leadership that architects usually bring in an organization. Through this competition, architects from all kinds of organizations can practice their skills and learn from each other. I’m really happy to have been involved.

Looking forward to 2022, I’m anticipating another year of hard work doing technical coaching with teams, but also more and more training others to do coaching. I’m getting a lot of enquiries from organizations who see a need for better technical practices. My colleagues and I have only so much time available to coach teams, so I usually suggest pair-coaching with people already in the organization. Most organizations already have architects and technical leaders and often those people would like to learn to coach teams using the Samman method. It’s for that reason that we’re ramping up the train-the-trainer programme offered by ProAgile. We have new courses on Ensemble Working and also on Learning Hour Design, two of the key activities for a technical coach using the Samman method.

I remain convinced that good technical coaching is essential for building up productive and happy development teams. I look forward to continuing to spread better ways of working and coding together with lots of great people in 2022. Happy new year!

Podcast appearances 2021:

• DevOps Sauna – a lovely chat with Sofus Albertsen, a former colleague of mine.
• Richard Kasperowski – we talked more about music than software I think!
• Mob Mentality Show – Chris Lucian and Austin Chadwick were really friendly and easy to talk to.
• Mosaic Works – Alex Bolboaca really knows his stuff and how to interview people
• That Tech Show – I was really pleased to appear on this one which has such a varied lineup.
• Arrested DevOps – Matt Stratton is a busy man, heavily invested in the DevOps community. Great to talk to him.
• Maintainable – the theme of this podcast is making existing software more maintainable, something I can really get behind.
• Making Tech Better – Clare Sudbury got me talking about Refactoring – a really important topic. 

Note: this article was first published on ProAgile’s blog.

I’ve just joined ProAgile, and it feels great. I’ve known many of the other coaches for some years, and admire their work. My background is as a software developer, and I specialize in the technical side of Agile. Practices like Test-Driven Development, Refactoring, flexible and extensible design, Continuous Integration and so on. If you’re developing software, then you’re going to need to include these kinds of things on your agile journey.

I see great opportunities for collaborating with my new colleagues. We can coach organizations and teams with agile ambitions and cover more aspects if we work together. I work primarily with software developers and help them to write the code in a more agile way. Many of my colleagues are focused on organizational change, agile leadership, team development and other aspects of the agile journey. I think coaches who collaborate will be a win-win situation for everyone.

As well as coaching developers, I am also planning to offer open training courses in agile coding techniques. I wrote a book a few years ago ”The Coding Dojo Handbook” and I love designing small code kata exercises. Many are available on my github page. I’ve worked for many years with an automated testing approach called ”Approval Testing” which I’ve written about on my personal blog. I’ve also worked with testers on strategies when doing Continuous Delivery, and recently developed a card game. I hope to add some new courses to ProAgile’s selection shortly, I have a lot of teaching materials and experience to draw on.

Note: this was originally posted on Praqma’s blog

The life of a consultant has drawn me back, but perhaps surprisingly, this time it’s not a return to my one-person firm. Rather than reinvigorating Bache Consulting, I’ve decided to join Praqma, the Continuous Delivery and DevOps Company. I was pretty happy at Pagero. I’ve successfully run my own business before. Some of my friends think I’m crazy to leave a good job with a great team working with exciting technologies. Others think I’m crazy to not want to be my own boss again.

So why Praqma?

Code that gets used

Writing code is really good fun. Writing code that people actually use is even more fun. That’s one of the reasons I like setting up Continuous Delivery pipelines for a development organization. Anything you change gets used almost straight away, and you get feedback from people around you all the time. It’s a fantastic feeling when you implement something that means the whole development team can move forward more quickly, confident in the quality of what they’re producing.

The kind of work I’m talking about is setting up build and delivery pipelines using a CI tool like Jenkins or Go.CD. It’s automating all the installation steps needed for a new machine in a staging environment. It’s moving all the code into a modern DVCS like Git, and setting up automated processes to help keep the master branch in a working state.

In my experience, this kind of work gives you the opportunity to raise the productivity of so many other people, it can have far more impact than if you stayed in your cube hacking on a product by yourself.

Amplify your effect

Another activity I really enjoy is facilitating and teaching. Preferably that kind of teaching that you do from the back of the room, where your job is to set up situations where learning is inevitable. I’ve spent a lot of time over the years facilitating Coding Dojo meetings, and more recently I’ve started doing more Mob Programming with teams. My aim is usually to get people to experience effective development practices like Test-Driven Development (TDD), and understand the difference it makes.

Again, the focus is on raising the productivity of other people, this time through coaching and training. Actually, I’m not directly raising anyone’s skill level. What I’m trying to do is to activate people’s innate motivation to want to get better at their job, and showing them a way to do that. It goes hand in hand with making the technical environment they’re working in conducive to good practice by having good automation infrastructure. TDD makes a lot more sense when you have a CI system to run the tests, and information radiators that show you when the build is broken.

Raise your game

So I’ve just joined Praqma, which is a consultancy focused on Continuous Delivery and DevOps. I now have a host of colleagues who are also really skilled with this kind of technical coaching role I just talked about, and know how much fun it can be. We’re really good with tools like Jenkins, Docker, Artifactory and Git, we set up Continuous Delivery pipelines, and we coach developers in how to use them. What we’re finding though, is that once we’ve got all that set up, the next step usually involves improving the automated testing in the pipeline. We need to be there coaching developers in TDD, and getting automated system tests set up.

That’s where I’m hoping my joining Praqma will help us all to raise our game. Starting with the consulting work Praqma already does, which of course lays the foundations with Continuous Delivery, we can start doing more coaching in test automation. I have long experience of that, teaching TDD in particular. I have much less experience of some of the other things that Praqma does though. What I’m hoping is that by working together with the other consultants at Praqma, and collectively sharing our toolboxes, we can all have more fun and achieve more for our clients. I don’t mind working alone at a client, I’ve done it before, but having colleagues is so much better. We’re going to have a blast!

Join us

Praqma is expanding throughout Scandinavia right now, with offices in places like Copenhagen, Oslo and Stockholm already. I’m starting the office in Göteborg. If the kind of technical coach role I’ve just described appeals to you, I’d be delighted to tell you more, do send a mail, emily.bache@praqma.com, or a tweet, I’m @emilybache.

We’re not only looking for senior people with lots of experience, by the way. If you have the right attitude and willingness to learn, that can take you a long way. We’re looking for people to join Praqma at all our offices, please send your resume and a covering letter to jobs@praqma.com. Of course I’d be particularly pleased if you wanted to join me in Göteborg.