A Leanpub Frontmatter Podcast Interview with Mark Pearl, Author of Getting Started with Mob Programming: A Practical, Pragmatic & Opinionated Guide for Co-Located Teams

Mark Pearl is the author of the Leanpub book Getting Started with Mob Programming: A Practical, Pragmatic & Opinionated Guide for Co-Located Teams. In this interview, Leanpub co-founder Len Epp talks with Mark about his background, Mob Programming, John Oliver's interest in New Zealand politics, the challenges of rugby squad allegiance when you're ane expat, his book, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on May 24, 2017.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.

---

A Note About the Leanpub Frontmatter Podcast

This summer we split the old Leanpub podcast into two distinct podcasts:

Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk.

Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider's perspective on what's happening in the huge and evolving world of book publishing.

---

Mark Pearl

Len: Hi, I'm Len Epp from Leanpub, and in this Leanpub Podcast, I'll be interviewing Mark Pearl.

Based in Auckland, Mark is an engineering lead at MYOB New Zealand, a provider of accounting and business management solutions. Mark has being doing software development for most of his life - and is also a frequent conference speaker, blogger, and now a book author. You can learn more about Mark, and read what he has to say on his blog at blog.markpearl.co.za, and you can follow him on Twitter @MarkPearlCoZa.

Mark is the author of the Leanpub book, Getting Started with Mob Programming: A Practical, Pragmatic & Opinionated Guide for Co-Located Teams. In his book, he talks about the value of Mob Programming and software development, and how it can lead to better outcomes for teams and projects, including improved productivity, quality and return on investment.

In this interview, we're going to talk about Mark's professional interests, his career, his book, and at the end, we'll talk about his experience using Leanpub a little bit.

So, thank you Mark for being on the Leanpub Podcast.

Mark: It's great to be here. Thanks Len.

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 come from, and how you first got interested in software and computers, and how you ended up where you are today?

Mark: I'm not from New Zealand originally. I'm born and bred in South Africa. I've spent the majority of my life in South Africa, but only recently moved across to Auckland. I've been involved in software - well, my early memories of writing software were back in junior school on an old XT QBasic. I think for most kids, when they start out they just want to write a game, and that's what got me hooked.

Professionally, I started writing software straight out of high school. I got my first job as a programmer three weeks before I graduated. I went to an interview that I saw on an RSC chat channel, saying, "Hey, there's this company looking for programmers. If you're interested, rock up." I was young and naive. I rocked up to the interview. The two people in the room looked at me, and they said, "So how long have you been programming in Visual Basic?" And I said to them, "I have no idea what Visual Basic is." And they said, "You do know you've applied for a job as a juniour Visual Basic programmer?" And I said, "Well how hard can that be? It's just a language." And 20 minutes later, I had my first job.

Len: Wow.

Mark: And it's been great ever since.

Len: And you eventually got into Extreme Programming?

Mark: Yes.

Len: I was wondering if you could talk, for those listening who might not be familiar, about what that is. What was your introduction to it like?

Mark: I was late to the game for Extreme Programming, or XP. I was first really introduced to it about six years ago. The way I found out about it was, I had been doing my own thing for a while - running my own software company. And I'd just got into a rut. I needed a change and I started looking around for various opportunities. And I came across a small bespoke consultancy called Driven Software.

They interviewed me, and there was alignment in values. They seemed to be doing some very interesting things, and I started with them as a programmer. The first day, I rocked up and they told me what we're going to do, this thing called "Pair Programming." I had absolutely no clue what pair programming was. But I gave it a go, and had an absolute blast. I learnt so much that first day at work. I learnt so many things in how to look at software. I was introduced to tester and development. I was introduced to user stories. I was introduced to a whole bunch of things that I guess at the time were still growing in popularity in South Africa. But it really made a big difference on how I look at software.

And XP's been - for me - the secret sauce ever since. Not so much the practices; one of the things I talk about in my book, is how Mob Programming in my mind is still XP. Even though if you look at the articles around XP they, they'll never make mention of Mob Programming. But it's really the principles behind XP that I like to drive how I make software. And that's been my involvement with it.

Len: What would you say distinguishes XP from other approaches to writing software?

Mark: I think it's a really interesting question. There's been a real boom in Agile methodologies for a while now, and I think a lot of the Agile methodologies that came around, or that were gaining popularity, were mainly process-oriented. So they were mainly [aimed] at how teams changed their interactions with each other, either via standups or scrums, and estimation and stuff like that. But they didn't really tackle the construction side.

What I really liked about XP was it was more for the engineer, hands on - it was driving technical excellence, not only interactions.

And that for me has been a big part of XP, compared to Scrum or Kanban or any sort of Lean approach. I think it's also interesting that those practices, like Scrum, keep adopting. And as they advance, they start to adapt a lot of the XP practices. So while I'm not in a Scrum team right now, I am aware of people that do Scrum. And in the literature that they're looking at, they're also looking at pairing, they're looking at testing and those sort of things. So I think that's good. But for me, XP was really for the software engineer or software craftsman.

Len: My next question is about computer science, and studying computer science. I see from LinkedIn that you've had a couple of stints studying computer science at university. One of the reasons I ask - it's actually kind of a theme of this podcast, where I would say about half of the people who end up in software formally studied a computer science, or something like it at university, and half haven't. The question I'd like to ask is: if you were starting out right now, say you've just graduated from high school now - would you advocate that someone like you go to do computer science? I'm gathering from your story that the answer's going to be a little bit more complicated in your case.

Mark: That's a good question. Maybe I can share a bit of my experience in software?

I mentioned that I got my first job as a programmer straight out of high school. My father is an academic. He's a lecturer at a university. And when his son came home and told him very proudly that he had his first job, my father was a little disappointed, and very concerned. He felt quite strongly that I needed to get a formal education - a university degree behind my name, or else I was going to be hindered in my progress. And he convinced me to go to university.

I lasted at university the first time around for two years. I was extremely frustrated. I was doing very well in the courses that I found relevant to my passion. But I also found a huge disconnect between what they were trying to instil, and what I had found useful in the professional capacity. And so two years into university, I ended up dropping out and doing my own thing. Do I value a degree? Well, I ended up, several years later, going back to university and finishing a degree via correspondence. It took me almost the better part of a decade to do that.

Part of the reason for that was that I hate giving up on things, and maybe I felt a little - almost like imposter syndrome, that I didn't have a computer science degree, yet I was creating software.

In hindsight, when I got the degree, I thought to myself, "But I still know nothing. What has this actually taught me?" And so, I would probably say, if I could redo things, I would have a lot more focused learning. I think, depending on the university, there's either value or not. But at the institutions where I worked, I don't see a lot of value in that qualification. In fact, I think the only thing that a degree proved to me, was that I had endurance. So I think people with degrees make great employees. They're not necessarily the best engineers. Some of the most talented people I've ever worked with have no qualifications behind their names.

Len: One of the observations that I've heard people make, that seems very practical is - I mean, it's hard to know when you're 18, and deciding what to do - but if you do want to work for a big company, like Google or Apple or something like that, then everyone I've spoken to, I think says the best decision you can make, given all the unknowns - is to get a university degree. And I would imagine that actually part of the reason for that is what you're talking about.

There's a set of shared assumptions about what you know, and what you've been trained in, that the company can make, when they know you've got a Computer Science degree. But it's actually a very interesting observation too, that one of the things you can tell from someone's who's done a self-directed, long term course of education, that they've completed, whether they enjoyed it or not - they were stubborn. Everybody has to be stubborn to get something like that done. And it does show something along those lines, that as you say in a kind of loaded way - makes you a good employee.

I have two selfish questions for you. The first is that I saw you tweeted recently about an MYOB hack day, where a team integrated something called the "partner dashboard" into the Amazon Echo. The reason I want to ask you about that is, personally I'm a little bit of a skeptic about the role that smart speakers and digital assistants will play in our day-to-day lives in the future. It's not so much that I don't see that there's value there, especially if you're doing something with your hands, having a digital assistant that you can talk to and can provide you with instructions and feedback. There's the sort of fun - there are games you can play with Alexa and other digital assistants. And of course, there's the Star Trek computer. "Do this, do--"

Mark: "Do X."

Len: Yeah, "Do X, do Y, give me this answer." But it's the hype around it that gets my spidey sense tingling a bit. But at the same time, I'm worried that there's something I'm missing. I was really curious how something that your company might be working on - and I confess to not understanding it all that well, but something like - how does a partner dashboard -? Can you explain a little bit about what that is, and how it can be usefully integrated with something like an Echo?

Mark: The honest fact is, it probably is a very poor experience. The partner dashboard is one of our systems that we provide to accountants for managing MYOB's products and their clients. It is literally a list of customers with data on it, and it would be extremely unusual for somebody to get value from using an Echo, to navigate that. I think maybe if somebody had a disability, there would be value in it. But for the average accountant, it's probably one of the more inefficient ways of getting information. Why did we do it? We did it because we could. And we did it to geek out.

Often we get attracted to creating software because it's fun. And then when it becomes our job, we forget to have fun. And fun sometimes just means fooling around, and poking things and seeing how they work. Really the objective of that hackathon for that team was to have fun with an Echo, and find a reasonable excuse to relate it to work. But there I don't think there was any immediate intention of making that an experience that we would release to the rest of the world.

The guys that were involved in that, they tend to play around in that space. The one guy, Lucas, is currently working on controlling his house via an Echo. He has a desk that he tells what height it should be in, it adjusts its height, that he's built from scratch. He just really enjoys that, and we think it's fun and just makes him a geek. From that perspective, that's why we did the hackathon.

From the Echo, and kind of the hype cycle about it - I mean, this is what we see with technology day in and day out. The latest and greatest thing comes out. Everybody jumps on it. They try different things. Everyone's talking about it. But it's really limited use. And then we start getting back to reality and figuring out where is this actually appropriate to use or not. We'll see that with the Echo as well. I think it will eventually level out.

Len: Fun at work, I think is something - when I was researching for this interview, I noticed it's important to you. And having a positive work environment, with great colleagues. I was wondering, did that interest come out of you naturally, or did you have, perhaps, an experience where you saw the contrast between working at a place where fun and having a good time is important, and one where it was not?

Mark: Yes. One of the roles that I've had over my career is as a - well, on my business card it said a software engineering coach. Basically, what we did is, we would go into teams that were at various levels of dysfunction, and try and help them to get back to a healthy state. I've worked in teams that were having very little fun, and, to be honest, you couldn't pay me enough money to stay in that environment for a prolonged period of time.

Some of these teams, I've seen where they get individuals [who are] in it to earn amazing amounts of money. That's really a compensation for them feeling fulfilled. For me, money is important, but it's not the driver for everything I do. Human interaction, feeling connected to people, feeling part of a bigger thing, feeling like what we do makes a difference, is just as important as what I get paid.

And so - creating a healthy environment where we can push boundaries, where we feel safe to have fun and work hard at the same time, is really important to me. Because I believe that it's great to wake up in the morning and just love what you do. Nobody wants to be in the place where they wake up, and they want to stay in bed. I think if you're in that position, you should seriously re-look at what you're doing for employment. Because it's about time for a change. I've been there. I've had situations where I've just absolutely hated what I was doing. It impacts on my professional career, it has an impact on my personal life. And I don't want to go back there again.

Len: I know what it's like to be there as well, and I think probably everybody listening does. If you've had the opportunity to work in an environment where, in a non-artificial way, placing an importance on people's happiness and being positive - you know what the difference is.

Mark: For me, the word there that's really important is "artificial." I think often we mix fun up with doing fun things. And it often is, in my mind, just artificial fun. The teams don't really care about each other. They do fun things, but there isn't that connection. For me, I'm wanting just to deal with real people that really, really connect. I guess that's also a bit about why I'm attracted to Mob Programming, is you get that connection through working with people.

Len: For some reason, I've been thinking a little bit about that general subject lately. I think we've all, especially if you're a bit of a geek, you've had the experience where a certain type of person sees you doing something, and they're like, "Hey man, school's over. Why do you want to sit and read? Why are you torturing yourself, why don't you go out and have fun?" And it's like, "All I want to do right now is sit here and read The Sword of Shannara for the fourth time. That's probably an obscure reference by now, but people do have different ways of having fun, obviously. And for some people, what looks like work, to the other person is the greatest thing ever.

Mark: I have this conversation with my wife often, because I will go home and I'll be coding, and she'll say, "Why are you working?" I'm like, "I'm not working, I'm playing around." And for her, from her background, that division between work and play is separated. For me, I was lucky enough to do something that I enjoy doing. And I get paid to do that, which is great. But I would probably be doing it, even if I wasn't paid for it. And that can be a challenge. So to keep balance is important. But it's also great just to love what you do. And I think we've got to respect each individual and what drives them, and allow them to have that in whatever ratio's appropriate for them.

Len: Speaking of having fun, my second selfish question is about John Oliver. If you haven't heard about this, this might totally not be a question you can answer. But the comedian, John Oliver, who's got a show called Last Week Tonight, for anyone who isn't aware - has a habit of getting into beefs with politicians from New Zealand.

For example, there was a time when a politician got hit in the face by a rubber dildo, and he devoted like five minutes of his show to that. And then recently, the Prime Minister, Bill English, was embroiled in some kind of like, I would imagine mini-scandal, where I think during his campaigning he used an Eminem song.

Mark: Yes.

Len: And of course, John Oliver couldn't help but do the accent, and call him "Eemineem." Which is something I'm personally familiar with. I use my own name as a way as a way of testing whether someone's from Australia or New Zealand. I used to be able to tell naturally, but now I have to do that. "Len Epp" becomes "Leen Eep." Anyway, so the "Eemineem" scandal - and then of course, the politician made the, perhaps, mistake of saying, "John Oliver isn't always that funny." And then of course, John Oliver's like, "What do you think I'm going to do now?" So I guess, my question, after that preamble is - is this something that people in New Zealand care about?

Mark: That's a good question. First, from the politics side: coming from South Africa, which has its own flavour of politics going on, and just some insane stuff - New Zealand seems to be very tame. What's weird about being really an immigrant in this country, is this country's built out of immigrants. So especially in the teams that I work in, we're lucky if we come across a Kiwi. That's almost an exception to the norm. Most of the people I work with are also immigrants.

Do New Zealanders care about something? There is one thing they take very seriously, and that's rugby. And that is one thing South Africans take very seriously as well. The only problem is, Kiwis have been beating us at rugby way longer than we've been beating them. And so it's nice to move to a country where now, I'm a world champion. That's always a plus side. But other than rugby and being outdoors - they're pretty chilled here. They don't get worked up about too many things. It's a really, really nice place to be. We've been really enjoying it. Our outdoor life has just skyrocketed. It's a beautiful place.

Len: I do then have to ask - have you changed your rugby allegiance?

Mark: Oh this is so tough. No. I wish I could, but the green and gold is too deep. For those in the rest of the world that don't know rugby too well, the green and gold is the Springboks, which is the South African team. The All Blacks are the New Zealand team. And I can't remember the last time we beat them. I kind of sit on the fence now, because I can probably claim it either way. But I think when South Africa plays New Zealand, I'm still supporting South Africa. But when New Zealand plays anybody else - I'm behind New Zealand all the way.

Len: It's really interesting actually. You reminded me - I worked in an office in London with a lot of expats, and I know what that community is like. But one thing happened that was unexpected one year, was - Australia got into the World Cup for soccer, and it was an Australian company. So although I was in London, most of my colleagues were Aussies and Kiwis and South Africans and people from all over, including people from France and Italy, because we worked throughout Europe. And man, was it intense.

I mean, work stopped. They bought TVs for the whole office, because they knew people were going to be preoccupied with the World Cup anyway. And when Australia was playing, the EAs roved around with carts of beer, right in the office.

If you've been in a place for a short time, it's maybe not that hard. But the longer you've been in a place, the more pressing questions of allegiance can become.

Mark: I can totally relate. There is another thing that is very popular here, and goes hand in hand with sport. It sounds like we've had pretty similar experiences. I think when we moved from South Africa and we were looking at different options, the typical options that come up - it's either the UK, Canada, New Zealand or Australia. At the time I just couldn't do it to my kids, to move to Australia. So it ended up being New Zealand. Which is ironic, because MYOB is predominantly owned by Australians, so I spend most of my time working with Australians. And it turns out they're pretty decent. But at the time that we were making the choice, I was like, "No, I just - I can't."

Len: I will not press you on that.

Mark: But I love you, Australia, now.

Len: Having only been there once, myself.

Mark: I've just offended like millions of people, I'm sure.

Len: No, I know what you're saying.

Moving on to the subject of your book. Before we talk about Mob Programming and your opinions about it, I thought we could frame the discussion a little bit by my asking you about Tuckman's model of group development - can we maybe talk a little bit about that, and why it's important to you?

Mark: A lot of people don't know that it is Tuckman's model, but they'll recognise the pattern. The pattern really goes as follows. When somebody joins a team, or joins a group, the group goes through some recognisable stages. The stages are forming, storming, norming and performing. And in my experience, whenever somebody joins a group, the entire group goes through those stages.

What are those stages? Forming is when everyone's still polite to you. You don't know where you sit in the social scheme, and so you're just being very polite to everyone you work with. The storming stage is when you start to push social boundaries. You're trying to figure out what's appropriate and what isn't. That can be a point where there's a lot of friction in a group, and at some stage, if a group is able to progress through that, they start to norm, which means that they've figured out the social boundaries, and now they've really figured out how to work together.

Ideally you want to move from norming through to performing, which is accelerated performance, because everybody's gelled. There's no disruptions. They can focus at the work, and they can get things out the door. So that for me is Tuckman's model, and I see it in Mob Programming every single time. It really, for me, is a model that very closely maps to reality most of the time.

Len: And with that structure, what is an understanding of the progress that things move through stages? Can you talk a little bit about what Mob Programming really is? You've got some videos online that I found. But what does it look like? What does it involve doing?

Mark: Essentially, Mob Programming originated from Extreme Programming. In Extreme Programming, this concept of pair programming was advocated. An idea of pair programming was two people working in front of a single computer on a single problem. Mob Programming had - in my mind - somebody to keep an eye out in the Mob Programming circles is Woody Zuill, who's also on Leanpub. You can get his book now. I really recommend people that are interested in the topic to read Woody's book as well.

Why do we just need two people? Why was the limit set to two? The experience that Woody had a while back was, he worked with a team where they just took a group of people, and they put them in front of a single computer, and they worked on a single problem as a group, day in and day out for well over a year. He started speaking about the experiences of doing this thing. And slowly as it's made it's way around the world, different people have been introduced to it, and they've taken it in different directions.

My first introduction to Mob Programming was when I was travelling in the US. I attended an Agile regional conference in Utah, called "Agile Roots." In attending there, I'd organised to spend two days with a company called Pluralsight. Pluralsight has these small teams that are very autonomous in what they're doing, and my expectation of spending my days at Pluralsight was just to pair program with someone. It's the way that I learn and see how different companies do things.

When I arrived at Pluralsight, they told me we weren't going to pair, we were going to do this thing called Mob Programming. Dssentially, I spent a day with three to four other people, working together on a single computer, and it was an absolute blast. It was amazing. It takes a lot of the elements of XP, and merges them all into one - feedback, diversity, collaboration, those for me are all principles of XP, and they all come out through Mob Programming.

Len: That's really interesting that you got introduced to it without anticipation - just suddenly, there you are working, coding with a group of people, something that people I think generally would associate with solitary enterprise. It is fascinating to watch. I saw a couple of fast forwarded videos of people sitting in front. Like you might have three or four people, and then people might come and go, even.

So one person is driving, as they say. One person is sitting at the keyboard. And then there's a timer involved. When the timer goes, you switch to whoever's driving. So everybody gets a chance to sit back. Everybody gets a chance to be directly in control. It's just a very interesting process to watch.

Mark: The mechanics of Mob Programming are very interesting. I think they also evolve as a group evolves. Part of the reason for me writing Getting Started with Mob Programming was to give a group of people wanting to experiment with the practice, a formula to start out with. But the intention wasn't to define that as the only way to do Mob Programming. In fact, I think it's really important that teams embrace this concept of experimentation, and exploration. Start out with the formula of having time-lapsed intervals, rotating the keyboard around. But that's not the only way to do it. There are lots of valid ways of mobbing, without keeping to that formula.

But thanks for introducing that video. That video was an example of the first team I was in, how we did Mob Programming. We worked that way for over a year. There are some very real benefits to working that way.

Len: And when one is doing Mob Programming, I imagine that that's part of the day, and part of the day is also still spent alone coding, is that correct? So it's not the entire coding for the entire project is done in a Mob style?

Mark: I think it would be unfair to be dogmatic about it and say there's only one way of developing software, and that you should apply that way all the time. I think one of the challenges we have is, there's very little research in when it's appropriate to do one thing over another. And so because we don't have that as a thing out there in academia, we end up relying on our gut. Which is fine. I think that that can be appropriate. What I've seen in the teams that I've mobbed with, is they find a balance.

Typically, in the first team that I mobbed in, we mobbed a lot. I would say we could average six hours a day Mob Programming. Quite realistically, it would be the majority of the way we would code, although we would still have breakaways where people would pair or where they would work on their own and have review. And that's A-OK. In the team I'm in currently, we probably Mob about 50% of the time. The thing that I'm interested in when I look at our team working, is - are we collaborating, and are we collaborating in appropriate ways? Whether that is mobbing or pairing or working on your own and getting feedback - I'm fine for that to be decided based on the problem you're solving at hand.

Len: I think one of the first questions someone who's being introduced to Mob Programming for the first time - especially like a product owner or team leader - might ask is, what do you do about conflict? Because if someone's sitting there, they've got the keyboard, and someone else is disagreeing with them, and it's a step that has two paths that diverge into wood, as it were - how do you decide in the moment to deal with that conflict? Do you take a break, do you just use common sense? Are there things you've learned about resolving those kinds of issues in that very particular context?

Mark: Conflict can often be intensified in a Mob. I've seen people that are really bad at handling conflict, and I've seen people that are really good at handling conflict. How do we handle conflict in the teams that I've worked in? Well, you know that conflict has always been there. If you're in a team that doesn't Mob, but you work on your own, you're typically still working in a shared code base. What you'll find is that there are different styles that different people are using, and if they can't find alignment or agreement, they decide to ringfence it. So, one person owns a certain area of the code base, another person owns another area, and never the two shall meet.

I think that that's very dangerous. You're setting yourself up for varying standards. You're setting yourself up for key man dependencies. You're setting yourself up for a lot of pain.

So Mob Programming really brings that conflict out. But those differences were always there. It's just Mob Programming is making it something that you need to deal with. How do you deal appropriately with conflict? I think you've got to gauge what matters and what doesn't. Some things are purely opinionated, and really for me just stylistic choices. Certain syntax. Really there is no performance improvement. There is no difference in readability. It's just a preference. And in those situations, I'm willing to go with what the group wants to go with, or what we decide as a group we're going to follow. The other differences that are maybe more important, where there are varying opinions - I think it's useful to explore all of them.

One of the benefits of Mob Programming is it introduces diversity. We know that when there is diversity in solving a problem, the solution it produces is more robust. And to embrace that diversity and to listen to what people are saying when they don't agree with you, to really discuss it, can be valuable, because you're going to end up with a better solution.

I don't have a specific formula for resolving conflict. I do encourage people to see each other as people first - to realise that we are human, we have feelings, and we need to treat and talk to each other in a kind and respectful way - but that we should also be listening to everybody's opinions, and be exploring them enough. And that means, "Let's try this way and see how that works. And I'm happy to go with where you want to go, and then we can re-evaluate at the end."

Len: How do you set up the space? You recommend getting over the hurdle of introducing Mob Programming to teams - this can include representing what you're doing genuinely as an experiment, because then people understand that things can change as you go along, or you might even abandon it. If I'm thinking about doing Mob Programming with my team, how do I decide how to set up the space where the Mob Programming will happen?

Mark: We talk about this concept of psychological safety. And psychological safety seems to, at least in the material that I'm reading lately, be coming back into focus. And really what it is, is creating a safe environment, where people can make themselves vulnerable. You can say, "I don't know," or "I think," and know that there aren't long-term judgements that are going to be made against them, just because they don't have a solid solution.

So with Mob Programming - when I look at teams starting out, I often talk about finding a safe place to start. And in the traditional company environment, often that safe place is not in the team area, because we have these open space offices where the team next to you can hear what's going on. That can be quite a vulnerable place to work. So I often recommend that when a Mob starts out, they want to go into a place where they are feeling comfortable enough, and that's a room away from everybody else, where it's just the Mob dealing with what the Mob needs to deal with.

Once you've got that going for a while, and you can create that trust and that safe space, then bring that back into your work environment - bring the team back to where they should be working, because they've gotten over the vulnerabilities that they needed to actually work together.

Len: And distinct from the space that one chooses - like a separate meeting room, if that's all you've got available, or something like that - you also talk about the importance of physical layout. I think that a lot of people who do software development have a particular interest in physical layout, by which one can mean things like, what size monitors are you using? What configuration? Things like that.

I was wondering if you could talk a little bit about that. I mean obviously - from listening to you, you would advocate people thinking about what they're doing, and doing the best things for them. But, for example, should people be sitting down? Should people be standing up? Should you have a giant monitor? Should you have three small ones?

Mark: We've experimented with different set ups. In fact, when I started Mob Programming in my first team, we needed to prove that the practice worked, before we were going to invest time in the equipment. And so I ended up taking my home screen to work. At the time it was big, a big 40-inch screen. And we set up in the office space, and we stood around it. Since then we have worked with two 60-inch large screens next to each other, with a smaller screen on a timer, and that's worked really, really well, where everybody can see the code comfortably, and yet not have people on top of each other.

One of the challenges I've seen is people try Mob Programming, but they try it in their normal development space, where they've got a smaller screen, like a 24-inch screen, and practically, to have three or four people around that can be very uncomfortable, because you're just in each other’s space. You want people to have enough space to feel like they're in a comfortable situation. You also want them, from wherever they are sitting or standing, to be able to see the code that's being written. That is, for me, the most important thing. And the bigger and the clearer that is, the better.

Now whether that is one very large screen or three semi-large screens - we've played around with different ones - and it depends on the team and the environment they have. I would be going as high-definition a screen as possible, and as large as possible that your budget can support. Some of the best times that we've had is when people can walk up to the screen and point at the code and go, "Over here. This is what I'm talking about. What's going on over here?" And that makes it a very hands on, very immersive experience.

Len: I'm going to ask a very in the weeds question, and then I'm going to ask a from 30,000 feet question. I'm just prefixing this one with the fact that something bigger picture is coming after.

One of the things that I found really interesting in your book, was talking about keyboard shortcuts. To those who are unfamiliar with the world of software development or financial modeling and things like that, one of the first rules of Fight Club is, don't take your hands off the keyboard. If you're working in Excel or if you're working in coding and you're taking your hands off the keyboard, as one person I heard once put it, you've already lost.

Often what happens is - we all know with things like this, where you're doing them all the time, the shortcuts that you use become second nature. I'm by no means an expert, and I'm not a coder myself - I can do some - but I use Emacs for a lot of things, and I mean, my fingers know things about Emacs that I do not know myself.

I was wondering how you would suggest dealing with that issue? Where you might get a bunch of coders who've got all these instincts, all the way down, built in to their typing - how do you decide what to do if you're all using a shared editor?

Mark: So, when you start talking about tooling, you get people really, really passionate and fired up. I'm a Vim fan, and hearing that you're an Emacs user, that almost meant that this was the end of the conversation.

Joking aside, tooling is important. As a professional, I've invested a lot of time in understanding my tools of preference, and in being efficient and quick at it. One of the challenges of Mob Programming is you have this shared development environment, and that might mean that you might not have the ideal tools of your preference.

I always think it's good to have a discussion about what tools we're going to use when we Mob, and what our setup of an environment is going to be. Depending on the tools, it is possible that you can have multiple editors working on the same code base. As different people take the keyboard, you switch their editor of choice, and they carry on. Often that's not possible though, and in that situation, you do need to get to a common agreement.

In the team that I'm in right now, I was the only person that did Vim. I've slowly converted one other person across to Vim. But there's another four or fivve people that I need to get to see the light. And so, when we Mob, I don't use Vim, because it is just too hard for anybody else to work with. I do have a set of agreed keyboard shortcuts that we could standardize on that we use. We have those shortcuts printed out by the keyboard. Muscle memory is an amazing thing. You do it a couple of times, and suddenly your fingers start to remember it. And you can relearn it.

So I encourage trying to create an environment where people can use their different shortcuts. But you've got to be willing to let go of a few things for the greater good of the Mob.

Len: I understand. I've never been a part of such a battle, but I do understand the importance of tooling to people who use these tools all day long.

Connecting it to my next question from 30,000 feet. Software is behind everything nowadays, and it's going to be behind everything plus one, going forward, and the way software is developed is actually really important for everything we do in our lives. You only need to see how important with a calamity like the HealthCare.gov scandal in the States, and other things like that, where you know how software is built is actually really important. These technical matters matter as much as - should a surgeon be washing his hands or her hands in advance of surgery or not? And we're still in the, "Should you wash your hands?" stage, I would say. Well, that's an exaggeration. But we're still early on if you consider the long arc of history in understanding how software development should be done, and what best practices should be.

Related to that is the question of co-location versus remote work. And obviously this discussion in your book about Mob Programming - this is actually a really big question about software development. Various companies answer it in their own way. Apple built its ring. They made a bet that people should be together. Other companies have done the same thing.

My question to you would be - imagine the ring hasn't been built yet (this is Apple's new fancy headquarters, for those who aren't aware.) Imagine you're the CEO of Apple right now. What would you decide about this? Would you say 100% - just putting this question starkly - 100% remote. 100% you've got to do the commute, and you've got to come to the office. Or some blend of those two things.

Mark: This is a good question. For me it's never been a question of co-location. It's been a question of collaboration. Essentially, I don't care whether you share, or you're remote, if I can collaborate with you just as effectively. My experience right now is that co-location just increases the fidelity of the experience. I've found that co-location leads to better collaboration. But I think that we are at a very interesting time in terms of technology. There are - for instance - HoloLens, Oculous Rift, all of these devices that are giving us these augmented reality, almost virtually new world experiences. Maybe that's going to change how we collaborate effectively. And so maybe remote work - or we'll have a big breakthrough where that experience is still the same.

If I was starting a company right now, and I wanted to get something out really quickly, and collaboration was important, I would probably still be pushing co-location. That said, people have lives, and there are challenges in getting talent all in one place. And so there is an argument to say, "Well, we will have a reduced experience of collaboration, but we will have a wider pool of people that we can use at a certain level." And so that could be an argument on the other side. I think it really depends.

I think what I have learnt is, the worst experience is mixing both. The worst experience is when you take a team and some are co-located, and some are remote. And you have this quasi co-located remote, where you're trying to have face-to-face conversations - but you're always Skypeing somebody in, and you never know where they're at. And so my advice would be - pick one or the other. I'm very wary of mixing both within a high-functioning team that has got to work at a high pace, because it just becomes extremely hard to maintain both at the same time.

Len: As I understand it, one of the problems with a mixed approach, where some people are always co-located, and some people are always remote - I think my colleague Peter said this, when he had an experience where he was in a situation like that - one thing that happens, is there ends up being an in-group that knows each other. And life is like high school - no matter how old you get, or what you're doing, there's an in-group and there's an out-group. That's just a natural development from people being around each other and not around others.

Mark: Absolutely. Typically what you'll find is that - or at least my experience is, that in-group would generally be the people together, because they are having conversations that the people remote don't get to have, and they're building those relationships. For me, the important thing is just being really conscious of how teams work, and being really intentional about how you do things, so that you're equally connected with everybody in your team. The worst place to be is to feel that you're isolated or that you're the "out" person, and that you're not being valued or appreciated.

Len: Switching subjects, but going back to the topic of what tools one uses to do one's work - I was wondering, just before we end the interview, if you could talk a little bit about why you chose to write your book using Leanpub?

Mark: I have never attempted to write a book before. What I have done in the past, is I was a fairly regular blogger, where I would post one or two postings a month. If I was on a good wicket, I would be doing four or five. And with Mob Programming, because it was such an emergent thing - there wasn't a lot of material out there. There was Woody's book. There was maybe one or two other writings out there. But it was really a new topic.

And because of the experiences and the impact that it had on the software that I've been involved in creating, I didn't want teams to make the same mistakes that I had made. I really wanted people to have a great experience. In speaking to other teams that had tried it out, there were a couple of things that we had figured out, that they hadn't. So the idea behind writing the book was really to help teams starting out - in an environment that I could relate to.

Why did I do it through Leanpub? Well, Lean software in general has been the way that I've made software for a long time. I want very small, quick feedback loops, and I found that the concept of Leanpub, of being able to iterate very, very quickly and increment and get something out and get quick feedback, was very appealing to me.

That said, I had no idea of how much work is involved in writing a book, and I have absolute admiration to people that have done this before. It is a very addictive thing. But it's also very, very work intensive. If I hadn't had those feedback loops through Leanpub, I probably would've given up halfway.

Whereas, what happened with me is, I wrote the first run of it. And I sent it out. I got some feedback from it. And I felt like I had kind of let down everybody, and that I had to refactor and improve. That's been the driver of it, up to now, the experience of publishing, to be able to do that. I linked it up through GitHub, so I do a commit into GitHub, and I work it in - I'm going to pronounce it wrong, but the Leanpub-Flavoured Markdown, or is it Markua?

Len: Markdown, that's right. Then there's Markua as well.

Mark: Markua, yes. Which I think you guys are working on. It really appealed to me, and it appealed to my workflow. It allowed me to use the editors that I liked, which was an editor like Vim. And to be able to get a PDF, just with a click of a button. That worked really, really well for me.

Len: How have you been managing feedback? I know you give out your email address in your profile on Leanpub. Do you invite feedback explicitly? That's something that a lot of Leanpub authors do, for example in the introduction to their book.

Mark: I would love to get more feedback, specifically, I've received feedback, but once or twice it's been a little frustrating. Maybe somebody didn't understand something or they had a negative experience and they were like, "I don't agree with X." And then I never hear back from them. Really what I'm wanting is to dig a little deeper into their world and where they're coming from, so that I can give something that is going to be applicable in multiple places.

The ideal feedback for me is via email, and then having an engagement to find out other people's experiences. This is a relatively new field, and so I am by no means the know all of it all. I think that there are situations I just haven't thought of, that I'd love to understand.

But in general, the feedback through Leanpub has been great, and it's been via email. I think I have my Twitter handle in the beginning of the book, and so I've occasionally gotten feedback via that, which has been great. That's kind of been the place that I engage the most.

Len: That's really fascinating. One of the things that authors often say they would like, is more community - more features and more of a structure around community. I've always seen that the way I think it is conventionally seen in the world of books, where readers enjoy putting up their profiles, and then growing communities around certain genres or authors, where the readers talk to each other. One of the things we like to encourage at Leanpub, is to have the readers talk to the author. And of course, since time in memorial, the bio or profile of the author is something that's really appealing to the reader.

But I think you're the first person to make such a straightforward and practical claim about the value of the author having some understanding of the reader’s bio. Because if they're giving you advice or commentary - if they voluntarily can let someone know a little bit where they're coming from, maybe with a profile, that then that can help the author to process the nature of the complaint or suggestion that's coming at them and how best to address it. So thanks for that, that's going to be something which is very interesting for us to think about when we get more focused on community and things like that.

Thanks a lot for doing this podcast, I really appreciate it. That was a really interesting discussion. And I just wanted to say, before I go - thanks for being a Leanpub author.

Mark: My pleasure, it's been a lot of fun. Thanks Len.

Len: Thanks.