Emily Bache, Author of Technical Agile Coaching with the Samman Method

Len: Hi I'm Len Epp from Leanpub, and in this episode of the Frontmatter podcast I'll be interviewing Emily Bache.

Based in Göteborg, in Sweden, Emily is a software developer and popular conference speaker with a particular interest in lifelong learning and in community. Having worked for both small and large companies, she is currently a Technical Agile Coach at the consultancy ProAgile.

You can follow her on Twitter @emilybache and check out her website at coding-is-like-cooking.info.

Emily is the author of a few Leanpub books, including The Coding Dojo Handbook, and the very recently completed Technical Agile Coaching with the Samman method.

In her latest book, Emily explains Samman Technical Coaching, a method for software development teams to raise the quality of their work through becoming more agile and learning Test-Driven Development, among other things.

In this interview, we’re going to talk about Emily's background and career, professional interests, her books, and at the end we'll talk a little bit about her experience as a self-published author.

So, thank you Emily for being on the Leanpub Frontmatter Podcast.

Emily: Thank you. It's very nice to be invited.

Len: I always like to start these interviews by asking people for their origin story. So, I was wondering if you could talk a little bit about where you grew up, and how you found your way into a career in software and software development? I listened to actually a podcast that I think you appeared on not too long ago, and I know you have a really interesting story - please take all the time you want.

Emily: Oh thank you. I grew up in the UK. I studied science and engineering at university, and there I met my husband, Geoff. He's also a software developer, and he's been coding since he was like a teenager. He knew from a very early age that he wanted to be a software developer. I sailed through university and didn't really know what I wanted to do, and he encouraged me to try software.

So I embarked on a career as a developer, and it's gone very well. We've helped each other in our careers. We moved to Sweden together in 2000, and we found it actually very easy to get a job in Sweden, with a background in software development; it's a very international industry. We have been living in Sweden for 20 years now - and we love it here, so we never went back.

Len: And as I understand it, you grew up in the UK, so you had to take A Levels in order to get into university, and you did very well on those.

Emily: Yes, yes I did very well.

Len: Extraordinarily well.

Emily: Yeah, I did well on my A-levels. I won a scholarship for the Sixth Form, to go to quite an expensive private school. The teaching was brilliant, and the class sizes were very small. I learned the A Level material very well, so I got the highest grade of anyone who did my A Level physics - and went onto Cambridge. So yeah, I did well.

Len: Yeah. For those listening who might not be familiar with it, there's a kind of standardized testing program - there's a couple of them in the UK. One of them is the A Levels, and it's kind of a big deal every year when they're announced. And performance in them is very important; people actually prepare for a long time for them. It's a really big deal.

And so, you studied the natural sciences for the first couple of years at Cambridge before you switched to engineering, is that correct?

Emily: Yeah. I thought I was going to be a physicist like my dad. But after a while of studying this, I realized that - okay, I'm good at physics, but ah, I don't know - I felt I would like to do something a bit more practical, and the engineering course was very easy to transfer to. I had done a lot of maths in the physics course, so it was actually quite a straightforward change to engineering. And I did find myself fitting in there a bit better, and there were some courses on software development and stuff.

Len: And I've believe you've spoken about - so you switched from one thing into another, but also into something entirely new. And you've spoken in the past about how a lot of people get started in programming very young, maybe on their parents' computer or something like that. And I mean, I can say from my experience on this podcast - I would say like 90% of the people who got into software development that I interview, started quite young. But you don't have to.

Can you talk a little bit about that? About how like, even if you find yourself - you're already sort of in university and you've maybe started studying, there's nothing preventing you from learning programming at that stage.

Emily: Yeah, absolutely. My husband Geoff, of course - he's been programming since he was a child. But I didn't. I learned to program - well, I mean - I did some university courses that involved programming. But I wouldn't say I could actually program until I left.

And then I really got into it. Geoff helped me to learn some of the techniques. And my first job - actually my second job, I had a really good boss who was really a good mentor to me. So programming is definitely something you can learn. It's not something you're born with. If you're intelligent and hard-working, you can learn it.

Len: I'm curious, did you feel judged when you started getting started - you're there with people that kind of - I mean, it's funny when you get older, it can be easy to lose perspective about those things when you're very young. And by very young, I now mean like in your early 20s or something like that. But people who might be way ahead of you in some skill - might treat you like there's some deficiency in you because you haven't acquired that skill yet.

Emily: I don't know. I mean, this whole thing of being doubted because you haven't got a long background in software or because you're a woman or because you are young - I've always been very ambitious. I've always read a lot. And I've always found that if I put my mind to something, I can do it. So software was the same. I decided this was a great career to go into. I enjoyed it, and I invested in it - and I've done well, I guess.

Len: And you and your husband eventually moved to Sweden, I believe, in the halcyon days of the dot com boom.

Emily: Yes, it was the early 2000s, and the industry was just going mad. Anyone who had any experience was being snapped up.

In Gothenburg there is an IT industry here, and there were lots of companies all trying to hire. So Geoff got a job at a very interesting Swedish start-up with a very international group of people. I think he was like employee 65 or something. He worked there for 15 years, and they later got bought by Boeing; it was a very successful Swedish startup.

I just kind of came along with him. I thought, "Well, this'd be fun. We'll try out living in Sweden." And then I got there in March and I applied for a few jobs, and within two weeks I had job offers. It was really crazy.

I remember the first week in my new job in Gothenburg. We had champagne at breakfast for the whole company. It was a consultancy company. Because we'd made so much money the last month - everything was going swimmingly. They were hiring like nobody's business.

And then two years later, that company actually went bust and I was left unemployed. So it was kind of a bit of a wild ride with the dotcom bubble, and then it burst.

Len: Yeah, champagne for breakfast almost sounds like a metaphor for something.

And eventually you found yourself doing some really interesting work at AstraZeneca, I believe?

Emily: Yeah, I spent quite a chunk of my career at AstraZeneca. They - I mean, I thought it was - I was a bit put off by it being a big company. I was worried there was going to be bureaucracy and stuff. But I actually landed in a really interesting place in that company, working very closely with some computational chemists.

They were doing research into small molecules, and they were writing neural networks and machine learning things to try and make predictions about the properties of these small molecules.

This was like 2002, 2003, before machine learning and stuff was a thing. So there were no tools, and they were kind of hacking stuff together. They couldn't maintain and they couldn't distribute, and I came in as a software developer to help them to get their amazing new cutting edge scientific models into the hands of all the scientists in AstraZeneca.

So it was all about, "How can we make this scalable, maintainable? Can we test it to make sure that its alright?" And then, when they update their models, it didn't break everything in the infrastructure. That was a really good time actually.

Len: And were you doing training at that time? Were you training in Agile and things like that?

Emily: I wasn't doing training, no. But I was into Agile. Geoff and I had both come across extreme programming. We went to the extreme programming conference in Italy in 2002 and met Kent Beck and Martin Fowler and Michael Feathers, and all these Agile luminaries. It made a profound impact on my view of software, that conference, and reading up all of the books that these people were writing.

So at AstraZeneca, I was busily trying to do all the stuff I could read about in these books, and deliver frequently new updates to the software I was building, and writing extensive tests for everything. And Geoff, at his company, was doing the same. He was writing tests for everything, and they were being really Agile too. So we were very much early adopters of this extreme programming way of working.

Len: And how did you find your way into training and things like that, and speaking at conferences? Writing books and making Pluralsight videos and things like that?

Emily: How did I get into speaking at conferences? Well, I realized that a good way to persuade my boss to let me go to the conference, was if I was speaking at it. My boss would encourage me to do that. So that was part of the motivation for speaking at it, it meant I could go. And I loved just meeting all the new people and all the new ideas.

When you're a speaker, you also get treated differently. You get to sit with the other speakers. You get to know them. It's much easier - a conversation starter, "Oh yes, I'm speaking about this. What are you speaking about?" Yeah, I really liked that feeling of being able to meet all these interesting people, and find out what was going on.

And then it was 2005, I was at the XP Conference, and I met Bob Martin and I met Laurent Bossavit and [?]. We attended the Coding Dojo, the first public Coding Dojo outside Paris. And that was really influential on me. Because I was like, "Wow, this is a way to actually get developers to be able to practice and learn testing and development."

Because I mean, I'd been doing all this stuff, but I was having trouble persuading my colleagues both within AstraZeneca and the company I worked before that. You find that extreme programming is actually quite hard to do on your own. If you're working in a development team, you actually need the people around you to adopt the practices, too. I'd been trying to persuade my colleagues and it was - I was writing loads of tests, but not necessarily those around me were.

So I really liked the idea of the Coding Dojo, and started to try and do some of that with the people around me. Also at user groups, in the evenings.

So, I joined the local Ruby user group. Although I was working all day in Python, somehow there wasn't a Python user group. There was a Ruby user group. So I went and I joined it, and I started doing a few sessions with Coding Dojos and eventually realized, "I should start a Python user group." So we did that. And then - yeah, so I got into this idea of Coding Dojos through that. It seemed to work, and I really enjoyed leading those.

Len: That's really great, thanks for sharing that. I've got actually some specific questions to ask you about Coding Dojos and what they are - we'll talk about your book a little bit later.

But before that, one thing that's actually been introduced into this podcast starting I guess about eight months ago, is a digression into discussing the pandemic. And I'll bring this back into discussion of conferences.

But one of the great pleasures - at least for me, of this podcast - is I get to interview people from all around the world, lots of different experiences. And I don't think - it's at least been quite some time since I've interviewed someone based in Sweden. I was just wondering if you could talk a little bit about what it's been like for you, and what it's been like in Gothenburg, and particularly how the pandemic has impacted your working life and your career?

Emily: So, okay - in March, the pandemic struck, and I was consulting with a large telecoms company. I was due to be giving a keynote at the ACCU Conference in the UK in March. And I'd said to my manager, "I'm taking a week off to go to England for this conference." And he was like, "Well, are you sure you want to go? Because we just got a new company policy. You might need to be quarantined for two weeks after you come back from the UK, because it's a high-risk country. And then you won't be able to be consulting with us for two weeks and we won't pay you."

It was obviously going to be an impact. So I cancelled that. And then everything just moved so quickly. Suddenly the conference was cancelled. The consultancy company sent everybody home. We had to all suddenly work from home. And that was even before the government had put in any recommendations. And then, the government came up with, "You should work from home, this is recommended." And then the gatherings were cut to 50 sometime in mid-March. No public gatherings more than 50 people.

And then the advice was working from home if you can. Don't gather in groups. Definitely a limit of 50. So we got all these restrictions that came in. But most of them were recommendations rather than new laws or anything, and they didn't close the schools. I've got two teenage children, and they have been going to school throughout, basically.

Which meant that my husband and I have now been working from home - and it's been really nice, I've really enjoyed actually working from home. With the kids out at school, and we can sit and have lunch together and coffee. I just had to, overnight, switch all the stuff I was doing, all the coaching and training to online, and actually it's fine. The technology is with us. It's all there, it works.

And the Swedish recommendations, I mean it's got a bit of a reputation, that Sweden didn't have lockdown. And but actually in practice, people have behaved as if there's been a lockdown. There just haven't been any police going around enforcing it, as it were. I mean, I've been looking at what's happening in the UK, and what my family have gone through, and they've actually had very strict rules about what they can and can't do.

We've had rules, but they're just maybe guidelines - and they haven't changed. It's been basically the same rules until everything got really much worse about two or three weeks ago. So we've basically had the same rules the whole time, until the second wave took off just recently. And now we actually - we're not supposed to gather more than eight people - that's the latest advice.

Len: And it's also not being enforced by law, it's just a kind of -

Emily: Yeah.

Len: Strong recommendations. It's interesting, here where I am on Vancouver Island in the province of British Columbia in Canada, it's been a very similar experience, qhere people and companies started reacting when they started figuring out what was going on. Some organizations reacted sooner than others. The idea that a lot of behavior and policy changes that people saw were driven by like draconian enforced measures, is just not true in many places. But it is true in some places. And I know - I lived in the UK for nine years, and I've been watching what's been going on there, it's been really sad. Not just the pandemic, but the rules and things like that. Being worried about fines and things like that.

Emily: Yeah.

Len: Which - if you're plugged into the news, you might know that kind of thing. But if you're a kind of ordinary person whose network of information comes from the people you know and chat with - all of a sudden you can be out doing something normal, and like, people are yelling at you - and that can be bad enough. But if the authorities are coming down all of a sudden, it can be really alienating.

Emily: Yeah. I generally think that the Swedish approach to the pandemic has been been good - as far as I can tell. Although the second wave - I mean, right now it's really bad. So they've just introduced this new measure of only gathering eight people. And I hope it's going to start bringing the numbers down.

Len: I should mention, when I started asking people about the pandemic during the interviews, I started putting an ominous time stamp at the beginning of every episode. "This episode was recorded on," date. And so, just for anyone who maybe missed it at the beginning, this is being recorded on November 18th, 2020, when this second wave thing is something that we're all experiencing and worrying about.

Just to bring it away from the digression - conference speaking can have a really big impact on someone's career in various disciplines. But in software engineering, it can really make an impact. And how do you see things -? I mentioned that with your work, you've actually - the technology's here, you've managed to make it happen and continue on. But with conferences, how do you see that changing going forward? Let's say for the next year?

Emily: Right. Well I think - I mean, a lot of the conferences I have spoken at now have gone online. So ACCU had to cancel, because it was just too short notice to try and re-envisage it as an online conference. But I spoke at another conference a couple of weeks ago that just took the same conference and did it online. And I've spoken at a few other meetups and conferences through the year.

The coming year, I think it's going to be similar. A lot of conferences are just going to try and do the same sequence of talks and workshops only online. I think that's probably not the way that conferences are going to survive. I don't know, it's - I've noticed the audience numbers - for the ones that are just trying to reproduce an in-person conference online, are just too small. It seems that people go to a conference, because - to a large part - because of the socializing in the evenings and the hallway track.

So the online version of the conference isn't as attractive. People don't sign up for it. They have to offer something, a different experience. I think the online events that I've done that have been successful are the ones that have had small group interactions - a much more clear kind of hallway track, ways to meet people and talk, that kind of thing - you've got to try and give more than just listening to talks.

Len: There's a kind of corollary issue with consulting that I've spoken with a couple of people on this podcast. Where the in-person - in the same way that a lot of people see the in-person experience of a conference having greater value than online, for a number or reasons, in-person consulting is something that people often ascribe greater value to than online consulting. Is that something that you think is going to affect your work?

Emily: Well, I'm really hopeful that I'm going to be able to keep doing what I'm doing remotely. The kind of coaching and consulting I'm doing, I'm finding it's - I'm thinking it's working pretty well online. And it means that the reach I have as a consultant is much greater. I don't need to travel to my clients to do what I'm doing. And it means I've got access to more clients than I had before. So I'm kind of hopeful that I can keep doing what I'm doing remotely - by doing it well and finding ways to get around the stuff that only works in person.

Len: It's interesting, and I hope this is somewhat related to the kind of thing you might do, but in the spring, we hired a bunch of co-op students from the local Computer Science department. For some of them, it was their first job. And so they've only known working remotely.

One thing we found was that - and I should qualify this, I'm Leanpub's resident non-coder - so, I do do some coding and I look at code reviews and stuff like that, but I'm not a programmer myself. But the ability for numerous people on a call to suddenly screenshare with everybody full screen their code, seems to be a really powerful way of collaborating on learning and making decisions.

Emily: Yes. We found this ensemble programming technique that I was using, for the in-person coaching before. When you transfer it to online and you've got a team of software developers, and they've got one person sharing the code on their screen - and everyone is collaborating on what code to write next - I mean, you put in a little bit of structure, you've got some tools to support this way of working - it works really well, actually, and in some ways better than it did when I was in a big meeting room.

When I was doing the ensemble programming, you've got your code up on a projector - and there are some little things that don't work so well. I have to try and remember everyone's name. Usually the room isn't set up for it very well. The screen's at the end of a long table. So people are kind of twisting their neck to look at it, and you're passing around a keyboard, and these days it's like, "What, you're going to pass around a keyboard, I'll get your germs."

So when we're doing it online - everyone can see the screen, I can see everyone's name, and we can have a shared timer that everyone can see. And it actually works okay.

The worst thing is the lack of the whiteboard, to be able to have the whiteboard discussion. But I'm discovering ways to simulate the whiteboard discussion with online tools as well. So I think it's pretty good, actually.

Len: That's really great. I think it's interesting that people kind of, in the kind of tech world, might have known for a couple of years that the technology was pretty much there. That you could - even things like taking over someone's computer, you can do seamlessly now. And that's something that like enterprise products would claim you could do it, but it would turn out to be a nightmare. But now you can start a Zoom call, everybody can, with a dozen people - well I mean, many hundreds of people even. But with a reasonably-sized working group of people, you can all share screens, you can take over each other's computers - which is a sort of non-germy way of handing over the keyboard.

Emily: Yeah.

Len: And it can be a really powerful way, not only for learning, but for collaborating on code, and things like that. So, thank you very much for sharing all that Emily. It's great to hear about - well, I'm mean, it's not great - but it's interesting to hear about what the experience has been like for you in Sweden.

Moving onto the next part of the interview, where we talk about your books. So, your first book that was published on Leanpub was, The Coding Dojo Handbook. And that was, I believe, about eight years ago?

Emily: Yeah. I started working on that - I think it was 2010. What happened actually was, because I've been doing these Coding Dojos since like 2005, I had several years’ experience. And I heard about Leanpub. I mean, as I mentioned - I'm quite an early adopter. So I'd been on Twitter and I'd seen people tweeting about the fact they were using Leanpub and they were writing books. I don't remember exactly which books, this was like -

But then in 2010, I remember seeing a tweet from Laurent Bossavit saying, "Oh, I'm thinking about writing a book called, "The Coding Dojo". He put a landing page up on Leanpub with a potential cover for it. And he said, "Look, if I wrote this book, would you read it?" That was his tweet, basically. So he hadn't written this book at that point. He'd just done exactly what you recommend - trying to do the Lean Startup thing, "Is there a market for this book before I write it?"

I saw this, and I looked at it and I thought, "That's a great idea. There should definitely be a book about the Coding Dojo, but I want to write it. I don't want Laurent to write it." I can write a much better book than he was going to write.

So I saw this, and I thought, "Mmm." I can't quite remember if I warned him in advance, but I put out my own landing page on Leanpub then, saying, "Well, I would write this book, and it would be called "The Coding Dojo Handbook", and it will be a practical guide to how to set up your Coding Dojo.

So basically I was saying, "I'm going to compete with you." But I think I got in contact with Laurent and said to him, "Look, I think I'd like to write this book." And he was like, "Oh yeah, fine - no, go ahead." So he was really nice about it. Which, I was glad. And so I started writing.

And at the time, I had the time to write it. I was at a place in my career where I was just starting up my own business as an independent consultant, and I didn't have much work at the start. So I had time to write. I found I really liked writing this, and it turned quite quickly into a book, actually.

Len: That's such a great story. We always like to hear that. I don't know if I've heard of people like competing quite directly in that way, but I'm glad to hear it ended up amicably, and Laurent ended up writing his own pretty successful book on Leanpub as well, on something else.

We'll talk a little bit about that maybe later, but that is kind of part of the idea, is like - instead of going off into the cabin for three years and writing something and then realizing that you didn't even want to write that book, or other people didn't want you to write that book - you can kind of sort these things out by being more public at the beginning of the process.

But yeah, on the subject of the book - so for people listening - obviously "Dojo" is kind of a metaphor. But what is a Coding Dojo, and how does it work?

Emily: Right. So the name comes from - a long time ago, Dave Thomas came up with the idea of a Code Kata. He was watching his child practice karate, doing these karate kata exercises. And he figured that that was a good way to get better at karate, to do these exercises. And said, "We should do that in coding. We should have Code Katas." So he put up on his blog some of these exercises that people could try out.

And then later, these people in Paris decided, "Well, actually the best way to learn something like karate is not just to practice on exercises, it's to actually join a dojo and meet other people and practice together." So logically, the best way to learn coding skills is to get together a group and practice Code Kata exercises in a dojo.

And they came up with some forms for that, for how to get a group of programmers to collaborate together and solve a programming problem in a collaborative way, that meant they all learned about the solution to that problem, and they could talk about it, and they could encourage one another, and they could improve their skills.

That's basically the concept of a Coding Dojo - that you're trying to learn in a group. And the slight difference - with a karate dojo, you would have some kind of sensei or master who would be in charge, or at least everyone would look up to them and try to emulate them. In the Coding Dojo, as I see it, that tradition really hasn't taken root - that you should have one person who is kind of like the head honcho or the sensei. It's been much more a group of peers learning from one another.

So that's what my book is about, basically. If you're a developer, you can see that you'd like to improve. You'd like to learn skills like testing and development. You're perhaps struggling a bit by yourself. Form a dojo, get some people together, get a peer group, support one another in your learning. This is a form of how to do that practice, and how to make it fun, and how to actually help one another.

Len: It's such a great idea - having a place and a time where you go to learn and practice your coding skills with a group of other people who are likeminded, and there for the same purpose. But it's not at work, and it's not like a hackathon where it's really competitive. It's like it's - where there's this kind of hybrid of group learning and individual advancement. But that goes through - if I understand it correctly, repetition is an important part of it. That there's the idea that you can lose skills if you don't use them, like in music.

Emily: Right, yes. This idea of practice. If you repeat something, you will naturally get better at it. And if you repeat, but with a twist, to make it a little bit harder - then you can expand your skills into new areas. That's kind of the difference between - with deliberate practice, where you're deliberately trying to stretch yourself a little bit, just enough that you're gaining skills and not getting discouraged. And having a group of people around you who are also trying to stretch their skills a little. And some of them maybe have got a bit further than you, and some a bit less far. You can be encouraged to move further, and pull people along with you.

I mean, if you're going to learn a skill, the saying is, "See it, do it, teach it." So in the Coding Dojo you have the option to see someone else do it. You can do it yourself or in a pair. And then perhaps, if you're in a pair - you can then teach the other person in the pair, or someone else in the group, what you have just learned. That's a great way to consolidate knowledge. So, the Dojo is a natural environment where you learn stuff, and that's really the point of it.

Len: Yeah, the ability to - I've done a little bit of martial arts training in my life, and the opportunity to see someone who knows what they're doing do it, outside an environment like work, where there's all kinds of other kind of things going on - is really - as you said, the first thing is "See it, do it, then repeat it." Seeing it first is kind of a crucial thing for certain kinds of skills and learning.

And so your latest book, Technical Agile Coaching with the Samman method - I always like to ask people before these interviews how to pronounce everything, but I forgot to ask you how to pronounce this word, which is Swedish for "together," I believe?

Emily: Yeah, that's right. "Samman." [Here's a Swedish example of the word's pronunciation online - Eds.]

Len: Okay.

Emily: It's just said like you said it. It's not difficult. That's one of the reasons I chose it as a name, because it's fairly easy to pronounce in English and Swedish, yeah.

Len: And what is the Samman technical coaching method?

Emily: It's the method that I've been using for a few years now, in my coaching. And the basis of it is that you are - I'm a coach, I'm trying to encourage teams to improve the way they build software together. And the basis of the method is that I coach a team altogether. With that team, we will do ensemble programming, which is also known as mob programming. It's a whole-team programming approach.

So that's one part. And we'll do that in their production code or in a realistic situation for this team, so that they get the benefit of the experience of me as a coach in their ensemble, in their normal working environment.

The other part of the method is the learning hour, where we practice on exercises. That's like a small, short Coding Dojo - basically, which are called a "learning hour," to emphasize that it's an hour, and you're supposed to be learning new skills in that time. So that's why I take them out of their normal environments, and try and get them to see what's possible, to show them new things, to get them to practice - and to - ultimately, to teach each other those skills.

So the learning hour is - I'm very keen to use teaching from the back of the room methods. That's active learning - making sure that they are fully engaged and active learners, and it's not me preaching or trying to stuff their brains with knowledge. It's got to be interactive.

Len: And for someone who was thinking of buying the book with the intention of carrying out these principles and practices and methods, what does - let's say you were hired to be a Samman technical coach at a company, what would your day look like as a coach?

Emily: So the day - I usually coach two teams each day, at the moment. Before I was trying to do three, but it got a bit stressed. So two is good. We'll do two hours ensemble programming with the first team in the morning, and two hours with the other team in the afternoon. And then there's the learning hour.

I started out by trying to do the learning hour common, for both teams, so that they would come together and have the same learning hour together - and that worked fine in some organizations, but in the organization I'm currently working with, the teams are all really different, and I was finding it very hard to find a learning hour that would work for two teams together. So I'm doing them separately as well. I've got basically, a learning hour in the morning, and a learning hour in the afternoon.

Len: I'm curious. I've talked to a lot of people on the podcast who are consultants, and there's so many kind of meta issues to consulting. One of which would be, in this case - convincing someone in charge that taking these people out of their straightforward work into a learning hour every day, might be a difficult challenge. How do you go about -? Or I mean, is it - I don't know? By the time you're brought in, has someone else already done the convincing that this is right? Or do you have to participate in the convincing process? Or do people just get it?

Emily: No, I definitely am involved in a convincing process.

Len: Okay.

Emily: That's been a big thing. Because I mean, I'm selling something that nobody's ever really bought before, or very few people have bought. So there's a lot - there's been a lot of sales and marketing. But one of the things that probably I should mention, it's - on a coaching day, the team spends all morning with me, all afternoon. But not every day is a coaching day. I try and break it up a bit so that they get ten coaching days over a three-week period. I can do that when I'm remote, so that it's not every day of the week. And also, I take a break. After ten coaching days, they get a break from coaching, and I'll coach a different team. And then we'll come back, and I'll coach them again a bit later on.

So from the team's perspective, they have a three-week period where things have been intense, and they've got some coaching happening. But they've got quite a lot of their time left to do their ordinary job, and to continue to produce features, and do what the company is paying them to do.

That makes the sell a little bit easier for the managers. Because it's - I can go to the manager and say, "Look, you need to reduce your feature capacity for a limited period while I'm coaching them. And we're learning on the job, we're looking at their real coding problems that they're having, in these Samman ensemble sessions. And quickly, the team hopefully will be able to apply the knowledge that they've gained."

I'm finding that's quite good as a sales pitch to managers, to realize that they're - it's not like a training course, that they lose everybody full time for three days or a week, or something. It's much more spread out. That helps. And I think it helps with the learning for the team as well, because they get plenty of time between the coaching, to reflect and to try and apply the stuff that we've been going through.

Because that's really what's going to make the difference. It's not the things that I change when I'm there, it's the things that they change when I'm not there, that is actually going to make a difference to the company. So there has to be time for them to consolidate and challenge what they're learning, and then come back and ask me questions and say, "Well, this isn't working." And then hopefully I can help them with that.

Len: The book is obviously full of really, really helpful advice, and very detailed descriptions of ways to do things, and what they're for as well, which is one of the things I really like about it.

Just before we move onto the next part of the interview, I wanted to talk to you - this is sort of a little bit of a callback to what we were talking about before, but I think you write in the book about a Cyber Dojo?

Emily: Yeah.

Len: I was wondering if you could just talk a little bit about, like, let's say someone is out there, and they're struggling with - I mean, a lot of teachers are struggling with teaching - I know a couple - with Zoom, basically. Which is a wonderful tool, we're using it right now - but it can be really hard. Do you have any tips for anyone listening, that you've learned in the last few months, for handling multiple people in a learning environment that's entirely virtual?

Emily: Yeah. So of course, Cyber Dojo's been around for a long time. It's an online coding environment that a friend of mine, Jon Jagger, and some other people I know, came up with. And it's great, I use that a lot. Another really useful thing I've found though, is just an ordinary Google Doc. I've found it's almost better than an online whiteboard. I've used Miro as well, and that's nice.

But with a Google Doc, everyone can just get in there and start editing and typing. And in real time, you can see what everyone's doing. So I can set up a little exercise with a list of bullet points, and I have a list of little icons that they can copy and paste next to the bullet points that interest them, or answer the question that I've asked them. And they can all see - everyone else is putting things into these bullet points, and that kind of thing. So I use Google Docs quite a bit, actually.

Len: Thanks very much for that. That's actually a funny coincidence. Some friends of mine from Montreal and I, and some people from all around the country, have started doing a - we used to do pub quizzes together in person. And during the pandemic, we started doing them online - and we've had to do a lot of figuring out. Because there's a lot of real-time collaborating going on, if you try and replicate the pub quiz idea - where there's an announcer who's announcing. Then when you have to write down the questions, and then you have to try and come up with your answers.

Google Docs is the solution that we alighted upon in the end. Because you can share it easily with like - you just change one setting, and everybody can edit on it. People learn their etiquette relatively quickly, and you can actually process a lot of information really quickly. You can add and delete very easily. You can make jokes, things like that. Yeah, it is a really wonderful tool for real-time collaboration. And of course - but one of the best things about it is you've got this document afterwards, that people who attended, and even people who didn't attend, can look at. And having this kind of documented record of what went on -

Emily: Yeah.

Len: Is a really powerful thing.

Emily: Absolutely, absolutely. For a teacher, you want them to take something home and put it next to their desk and be able to refer to it.

Len: Yeah. I know, that's fantastic.

Moving on to the last part of the interview, where we talk a bit more in the weeds about your experience as a writer and a content producer - so, before we talk about writing - over the years, you've produced a couple of video courses for Pluralsight. I've interviewed a few people who've done that before. What was your experience like with that? I've basically only heard positive things.

Emily: I mean, that was like 2011 or something? I did my first course for them. And the first course I did was based on The Coding Dojo Handbook, and the next course was "Unit Testing in Python." I found the experience of making the videos very lonely, actually. Sitting at home recording videos by myself. I got feedback from an editor as well, but generally the feedback was just, "Oh, you're doing great, carry on." Which is kind of nice, but -

After I'd done those two video courses, I actually decided I didn't really enjoy it enough to want to carry on. So I went and did other stuff. Then they came back to me recently, a couple of years ago, and said, "We need you to update the course on unit testing, because it's a bit out of date now." And so I did. I spent a few weeks doing it again - and again, I found the experience of recording these videos not very rewarding, because compared to giving a conference where people ask questions and stuff, and it's much more interactive - but it was okay. It wasn't bad. I'd do another one if it came to it.

But I did notice though that - I get a royalty payment from Pluralsight, and I've been getting these royalty payments since 2011. But suddenly when COVID hits, the size of the royalty payments increased quite a lot. So it's actually earning me a lot more money than I'd really anticipated. So I do recommend video trainings as a way to get a steady income, at least now that everything's online.

Len: I've heard similar things from other people. There was someone I interviewed not too long ago named Nigel Poulton, who does videos a lot. And I mean, the one thing is - yeah - that you sort of talked about, was - that it's actually really hard in different ways. If you want to get into that, it can be very rewarding in the end, monetarily.

But recording videos is hard. It takes a lot of time. It's actually - like other things, it's a skill that you kind of build up in immediate term and you get - there's a steep drop off. And you have to get those skills back if you haven't been doing it for a while.

But it can be very rewarding, and people love watching videos. And so, if you're looking into getting into the content-creating world, books are great - way easier to update, way easier to edit. But videos have a unique quality of their own, that's very productive, and that a lot of people love.

We talked a little bit earlier about how you found out about Leanpub, and why you started using it. I guess one question I would have for you, since you're someone who's sort of been around a lot longer than most authors that I interview - what would you say are some of the biggest changes you saw in Leanpub over the years, that maybe were improvements, or things like that?

Emily: Well -

Len: And I'm looking for criticism - not necessarily for praise.

Emily: When I wrote my first book, it was Dropbox for syncing the files, and for the latest book, I have used GitHub. But I'm still using Markdown. And yeah, I wouldn't have said that there was a huge difference for the experiences as a writer. Maybe I haven't discovered enough of the new features? In the intervening period, I haven't been in on Leanpub particularly. I have bought a few books off you, and quite a few interesting titles there. But as an author, the experience of writing - I wouldn't have said was that different from 2010, 2011 to now.

Len: Thnaks for that. That's actually - I mean, I'm very glad to hear that actually. Because part of our whole idea is, write in plain text - if you know how to write in plain text, like in Markdown - you should be able to write in plain text, just like you would write any other Markdown document. And just click a button - or if you're using our API, fire off a command - and get things done as easily as possible. And so the idea that it's been actually a relatively consistent thing from that perspective, over time, is really nice to hear.

The last question that I always like to ask Leanpub authors on the podcast, is - if there was one thing we could build for you, or one really annoying problem we could fix for you - can you think of anything you would ask us to do?

Emily: Oh, well the thing is - probably whatever I'm going to ask you, you'll come back and say, "Actually we do have that." I just - it's - the only annoying thing I've got at the moment is that I'm not - I'm just writing my text in Sublime, and I haven't taken the trouble to install the spellchecker. So I keep publishing really annoying typos. But I'm sure you've got a solution to this, I've just not been clever enough.

Len: We don't.

Emily: Ooh.

Len: It's funny. It's a really curious thing. Because Leanpub is a self-publishing platform that's intended to be used by all self-published authors - but for a number of reasons, it's been particularly popular with people technically-minded people. And one of the interesting things about technically minded people, is - when they encounter a problem, they stubbornly seek out their own solution. So we've had people build entire workflows to achieve things, without telling us about it.

And then I'll find out about it in this - I leave this Leanpub stuff until the end of the interview. But then I'll find out they built this crazy thing, super complicated, and it's always super interesting to hear.

But for that reason - at least this is my opinion - it's only in the last year or so, that people have started asking about spellcheckers and stuff like that. Because they were finding - they were like, "I just copy and paste it into Word," or something like that.

But I guess, there's something I think about our authors, that they - anywhere else, people would've complained a lot more about the fact that we don't have spellchecking. But I've been kind of glad to hear people start asking for it. And like, I'm not making any promises about timing or anything like that - but the more we hear people requesting something, the higher up it gets in our queue of things to discuss, and think about finding a solution for.

And I think - one thing that actually changed on that front was, people who use Gmail or anything where Grammarly - I don't know if Gmail uses Grammarly, they probably don't - but people are just becoming more accustomed to having spell checking going on in real time, in all of the tools that they use. So now they're like, "Hey, why don't you guys have that? It's all about words."

Emily: Yeah.

Len: "Correcting my typos would be nice."

Emily: I think my spelling's fairly good most of the time, but everybody makes the odd typo, so -

Len: Yeah, and I mean it's - again - and just expressing my own like naivete, that it wasn't a bigger concern from the beginning - particularly for a self-publishing platform, where people don't have the same kind of resources that you might have in a kind of conventional publishing workflow with, working with the publishing company - so anyway, thank you very much for sharing that. Yet another person in the last year to start bringing that up, and so I'll make sure to communicate that to the team.

Well Emily, thank you very much for taking the time to do this, and for continuing to use Leanpub to publish your books.

Emily: Thank you for putting together the Leanpub service - I guess, as an author, it feels like a service. You publish my books. This is great, it's been a mutually beneficial relationship. Thank you.

Len: Thanks very much.

And as always, thanks to you for listening to this episode of the Frontmatter podcast. If you like what you heard, please rate and review it wherever you found it, and if you'd like to be a Leanpub author, please visit our website at leanpub.com.