 Okay. So welcome. We will talk about the Cloud Foundry Dojo. So this is a unique program which Cloud Foundry has to introduce new contributors, and we will give you a first-hand experience how it is to do the Dojo. So I did the Dojo, Michael is part of the Bosch team, and so my name is, I'm here on the left. You see me? I'm Cornelius Schumacher. I'm working for Susie Linux, and I did the Dojo in the Bosch team this summer, so all my memory is fresh and we'll try to tell you all I know about it. Hi, I'm Michael Trussman, and I work for Pivotal in the San Francisco office there. Yeah, we're going to tell you about the Dojo. So what is the Dojo? It's not a karate class. It is a program to get new contributors started on Cloud Foundry projects. It is the fast track to committer status for people who want to do that. So the goal is to immerse participants in the practices of the Cloud Foundry Foundation and familiarize them with the related technologies and practices. It's about six to 10 weeks working in a team on-site in one of the Pivotal offices. In most ways, it's very similar experience to being a new hire at Pivotal. The ramp-up is pretty much the same in most ways. Yeah, and for me, the journey got started. So if we go to the next slide, it's basically when we decided to become part of Cloud Foundry, so we started a project at Zouza to work on the OpenStack CPI. Usually at Zouza, we do a lot of open source and what we usually would have done is we would have just started to write some code, contribute, create some requests and get involved. But then we learned Cloud Foundry is a little bit different. There's this Dojo program which gets you started, which is this fast track to committer status. So we had a call with the Cloud Foundry Foundation. They told us about the program and so on. And it all starts with this remote pairing interview. So we heard about that in the keynote or in the fireside chat this morning from Rob Mee. So this is the same process what the Pivotal employees go through when they get hired. So you get this test, this remote pairing thing just one hour remotely via Skype, where an interviewer is doing some remote pairing with you to assess if you actually have the skills, the social and technical skills to successfully complete the Dojo and successfully work on Cloud Foundry. So that's how this started. So we got through that. I got the approval there to start with that and then started to organize the Dojo. And as we wanted to contribute to the Bosch CPI, the OpenStack CPI, the natural place to do the Dojo was the Bosch team, the Bosch Core team. So they were open to accepting me as a Dojo. And so then I started to organize that. And that's being in Germany is not completely trivial because the Bosch team is sitting in San Francisco in the Pivotal office there. So we had to get this organized, took a little bit, but finally I had everything in place. Yeah, and then the first day came, I arrived in San Francisco and the instructions I had were come to the office at 8.40, join us for breakfast there and make sure you are there at 9.04 for the global stand-up. So that were mostly all the instructions I got. So I went there, I attended the breakfast and I attended the global stand-up. And then at something like 9.10 I was basically part of the team and attended the first daily stand-up where I met Michael. And for us on the team, it's just another day. A new teammate is always exciting, but the fact that he's a Dojoer doesn't really matter. You know, it's just welcome to the team and let's get started doing work. And so yeah, one of the kind of unique things about Pivotal and Cloud Foundry and being in the Dojo for most people will be pairing. We pair all day and every day. This is what it looks like. So pair programming is probably our most important core practice. Essentially what it means is that every bit of work you do, you do together with your pair, two heads instead of one. And so usually the way it works is that pairs will stick together for one or two days, sometimes a little bit longer. And then one person will keep the context with a new pair while the other one rolls off to another pair and another story. So what is pairing all about? Ideally what it means is consensus on every decision that you make in the entire engineering process, everything you do. And so we think that this yields two main benefits. The first is good decision making, two heads is better than one. And so hopefully this yields very high code quality, things like rigor and testing, smart risk management when you make decisions about deployment, things like that. And the other key benefit is propagation of knowledge throughout the team and throughout the broader organization as people move around as well. But for it to work, for these benefits to happen, both people really have to understand what's going on as you do things. So this means a lot of communication, like a lot of talking per unit of typing, right? And yeah, so it really puts a premium on communication skills. And it does also imply kind of what you might think of a slowing down to speed up. So in the short term, it can seem like all this talking is taking a lot of time, but we think that very quickly it pays off and is worth it. And so this is a picture of Cornelius and myself in the San Francisco office. No, this is Plato and Socrates. So I like to think that pairing is in some ways a lot like the Socratic method, which is where by asking questions in a kind of open-ended dialogue, two people can come to understand something that neither one did at the start. So you can actually produce knowledge or understanding through dialogue and asking questions. And I think pair programming harnesses something very similar to this for engineering, where you're not just trying to produce knowledge, but actual concrete solutions. And similar because two engineers may have different strengths, different gaps in their understanding, and may come across a problem that neither one of them really knows how to solve. But by pairing, you can solve problems that go beyond what either person has seen before. And this really is at a premium when working on problems that are kind of unique or difficult or baffling or novel, something where there isn't a well-known technique that you can just rely on to solve the problem. And on Bosch, we see a fair amount of problems like that day in and day out. And so really I think by asking intelligent but maybe naive or inexperienced questions and trying new things, an engineer that is out of his or her depth can actually contribute a lot by probing beneath assumptions or looking at areas of uncertainty in novel ways, and that might yield a solution. That might, those areas of uncertainty might actually hide a novel solution that nobody has seen before. And so the upshot of that, the good news for dojoers is that, well, you might feel overwhelmed at first by the unfamiliar technology and unfamiliar tools, but you can contribute just by asking questions, just by kind of being there and by pursuing your own understanding, you can actually, in many cases, contribute to a concrete solution of a problem. Yeah, the pairing certainly is the biggest difference for most of people. I mean, there are not many places where the pairing is done to such extreme degree as in Cloud Foundry and especially at Pivotal. So for me, I never had worked like that, so it was really something I had to get involved in. But the great thing was that I actually was productive from day one, so at the first day we worked on a hot fix for some part of Bosch where we just had to fix something and I mean, this is something where you usually wouldn't let a newbie do that, but as a pair, I mean, that was something which worked out quite well. And for me, it was a great learning experience in this way because if you are always together with somebody else who knows different things, I mean, that's something which really helps and also gives security about what you are doing. So that's really a good part. And one other really great part about the pairing is that you talk to another person for the whole day, so that's usually not what developers are doing. Many developers are talking to their computer maybe if they talk at all. But in this case, you actually have to talk to the other person, so you get to know every member of the team in the first week basically because you're switching pairs every one or two days, so you really see a lot of different people, you see a lot of different expertise, a lot of different ways how to do things and really get into that. So the pairing is, I think, a wonderful way to get into a new project. What also was quite visible there are certain values and Pivotal has pretty strong values and that might not be as visible if you're coming from the inside, but if you're coming from the outside, you see that these are actually there. And I say specifically Pivotal values because they influence Cloud Foundry a lot. And the pairing is one of them. I mean, that's how most people in Cloud Foundry work, but also the other ones, like the be humble, that's something which you need to be able to pair program all day, so Pivotal hires for that. And that makes a very welcoming and open community where people actually have the social skills and also are willing to interact with people, have the empathy to work in a very good way with others. And that's something which I think is also reflected in the community, which is great. And the last value, the dinner at home, that's actually something which surprised me because I was told, okay, they have this schedule and they work like that, but I would have never expected that actually five past six people are gone. So it's really, the office is empty within five minutes and I was really surprised by that. So because that really gives a way how to sustain that every day and again and again. So, following up with that, sure. That might be a contradiction, but I will leave that to explain to the actual Pivotal people. Another question? Well, so you, everybody rotates and within a team, everybody works on everything that's within the scope of the team. So for one thing, teams have to be carefully scoped but that itself is kind of an important Pivotal and foundation value is this idea of collective code ownership. So if you are on a team, you own everything that's in the scope of the team. And so it's not like one person is an expert on one part of something within a team, everybody rotates. If that happens, then something has broken down. And I mean, sometimes code that you write changes because it doesn't work or somebody finds a better solution and that can be frustrating, but it's not your code, it's the team's code. You're just part of the team. So I think that attitude is kind of an important value that we have. Yeah. So yeah, I was gonna talk a little bit about the rhythm of life at Pivotal and in the dojo process. So the way we work is designed to optimize sustainable pace because we believe that happy healthy developers produce better software. And also as a developer, it's nice to be a happy healthy developer. So our workday starts with breakfast and a stand up just after nine o'clock. We are encouraged to take plenty of breaks whenever we need to. Often this involves ping pong, but not always. We have a one hour lunch and no working is allowed during lunch. At the San Francisco office, we often have technical talks which are optional and usually include something to eat. So that's kind of nice. And as Cornelia said, we stop at six sharp. And as well, there's a general norm that you don't push code towards the end of the day. You tend to not make the best decisions then. So it's better to sort of wait until the morning. And so we have a weekly cycle as well which basically starts with a planning meeting and ends with a retrospective which is where we kind of discuss how everything is going on the team, what's been working, what's not, what are the pain points, what are people hopeful about, fearful about that sort of thing. So kind of a blend of technical discussions and also kind of more personal or personnel issues, just a way to connect with the team and sync up. And so at the end of the week, you shouldn't feel tired if you've been working hard, but you shouldn't feel exhausted. It should be sustainable. And by Monday, you should be ready for another go, another cycle. Yeah, this rhythm was really interesting for me because that's not the way I usually work because there are lots of interrupts, people are working at different times and so on. So having this schedule, getting up in the morning, having breakfast, having daily working for eight hours, going back home and doing the same every day basically. That gave me this kind of zen-like state where I just repeated and it was really, I had the feeling that although it was intense and I learned a lot and it was also the tiring, it was something which actually is sustainable. So that was an interesting experience. Yeah, time definitely just kind of melts away. Exactly, a time that's away and then after the six week, where did the dojo arrive? Okay, that's six weeks, interesting. Part of that also is the environment. So I think we have a photo on the next slide. Yes, so that's a pivotal office. And this is designed for this style of work. It's an open plan, so it's basically a big open space where everybody's sitting together. It's, the workstations are set up for parings so you always have two people working on two monitors, two keyboards, but one computer and sitting next to each other. And an interesting part is that there's no desk ownership in this sense. So the team has a certain area in the office and then the team finds the place where the pairs work after they have figured out who works with whom. And this is, especially if you're doing the dojo and you're new in the team, that's very nice because you're basically on the same level as everybody else. You are part of the team. You find the desk like everybody else and then you can just start working. So, and then the office is designed in a way that it's actually quite pleasant to work there and by the pairing, I think it's also, that's something I also realized. There is some noise level there, but if you talk to another person, your brain is trained to kind of remove the background noise and focus on the other partner. One thing which you also see a little bit small there up there and there's a monitor which shows some CI results. So that's something which also is kind of dominating the visual presence, which is part of the extreme programming culture, that everything is test-driven, everything is covered by CI and the CI is omnipresent in the office. So all wards are covered by, or every team has a couple of monitors which show the current CI state. And that's an important part of the way how the teams work. So next I'll talk a little bit about our CI. So this is an illustration of some of our pipelines, our Bosch pipelines and these are series of tasks that test our code in various ways and then promote the code for use in other pipelines. So we use concourse, that's what these visualizations are here. That's our wonderful open source CI system that was made in the San Francisco office. So CI is, yeah, as Cornelia said, a very important part of our culture. We're always watching the board. It is the command center and keeping the builds green, green is when they pass, is everybody's responsibility. When, if a build is red, if that means if the last code that's been pushed to it is failing some tests, then you can't push to it. So basically you're held up until you fix it so the team must coordinate and figure out what has to happen to get the build green again. Do you revert or do you move forward? It tends to be kind of a team decision or one pair is sort of in charge of keeping the build green. Different teams work a little bit differently, but yes, this is the roadmap of life as a developer and pivotal. And so the structure of our pipelines, I think nicely reflects the structure of the system of components that compose Bosch. So the main components of Bosch are the director, the agent which operates in each stem cell and each deployed VM and the client that you used to interact with it and then a simple utility packages. So basically each component has its own pipeline that runs it through a gauntlet of tests that are in isolation or sort of quasi-isolation. And then at the end of each pipeline, the build that's passed through is promoted and then ultimately we have a kind of master pipeline that we call BATS, the Bosch acceptance tests and that runs all of these promoted builds together on against real infrastructure before finally publishing the final release on Bosch IO where it's available to the community. Yeah, for Dojo actually, having the CI is great because you know when you do a mistake there is some kind of safety net which tells you that something goes wrong before it goes out to a release or to a production server or something. So concourse is a really important tool and it's part of the tooling. There's more tooling involved. Of course, the teams have settled more or less on a standard set of tools. So it's all Macs, it's all RubyMine, it's all Shell, there's Vagrant involved, there is the Linux command line involved. There are plenty of tools. I think there's a little bit of variety and people also try out things. They sometimes they try out things for remote pairing and so on. So it's a variety of tools but kind of a standard set of tools. And even if you're not used to this, you get to learn them very quickly while pairing because you don't need to read a manual for looking up keyboard shortcuts but your partner will just tell you you're slow, type this and you will be faster. And that's great. One problem with the tooling actually is what I also realized is that most tools are not prepared for pair programming. There's usually only one author and there's no way how to get two authors into something. So Git, for example, doesn't allow for more than one author. So there are a couple of workarounds in place to be able to do that. So for Git, for example, we use Git Duet which alternates author and committer with every commit. So both members of the pair get basically the same share of commits. So these are kind of workarounds. If you happen to work on tooling for developers, please take this use case into mind and add the feature to have multiple authors for the same thing. Yeah, that's the tooling. What's next? Oh, that's a good question. So in principle, there's no code review aside from pairing. So we rely obviously very heavily on good test coverage and good decision-making during pair programming. That varies a little bit. On Bosch, for example, our product owner, Dmitry, is a very deeply technical, very knowledgeable developer in his own right, and he tends to get his hands dirty a little bit with our code. Ideally, there's no code review as a separate phase in principle. So yeah, so next I'm gonna talk a little bit about learning kind of as a core value that's built into the way we work. It's built into our process in a few different ways. So I think first and most important is pairing itself, working with people with different backgrounds leads to a very potent cross-pollination of ideas and techniques, like Cornelia said, just kind of even something like keyboard shortcuts, but it goes all the way up to architectural patterns and just ways of making decisions. These things just spread in a kind of organic way when you pair program that doesn't require a lot of extra overhead. So that's really great about it, about pair programming. But at Pivotal and on these Cloud Foundry projects, we also, as I mentioned, we make time for talks, both kind of technical talks where we invite outside speakers, but it's also great because if you work in this office, you have an opportunity to give talks very frequently. And so there are these kind of office-wide tech talks, but on Bosch anyways, we also have kind of a weekly slot for lightning talks within the team where somebody will discuss an issue. They'll do a little bit of research, something that's been bouncing around. People have been asking questions about, someone will go the extra mile and do some research and then present that to the team. So that's always nice. Our pace as well is designed to leave time and energy for outside learning. So ideally you can do some continued learning on your own as well. And finally, I would say that hosting Dojo participants is great as a pivot as well because we get to work with people with different backgrounds from different countries often. And yeah, so that's always great. Yeah, for me, the learning was great, of course. Through the pairing, I learned a lot about the technology and so on, but also by being in the Dojo, by being in the office, I also learned a lot about the context in which this happens. So what do the people think? How do they work? What happens outside of the actual code contribution? So what you usually don't see if you are just communicating via GitHub. So that was a great thing to learn. And what also was quite important for me and kind of a relief to me when I realized, okay, for me it was clear, I would have to learn a lot there. But when I was there, I realized that actually everybody was learning a lot all the time. So you always had to learn about a new story and how to tackle a new topic. And everyone, the team was in this constant mode of learning. And that's something which I think is quite healthy because it really keeps you awake. It keeps the code fresh and it makes sure that the knowledge is transferred. So after the Dojo, after the six weeks, I went home and I'm now working in the OpenStack CPI team. I'm doing pairing all day. And that's actually something which surprised me a little bit how natural this became. So when I got home, actually my daughter came to me with a computer problem and sort of just fixing it. I realized, okay, my natural reaction was, oh, let's sit down together and fix that together. That was kind of interesting to see that it's really, it becomes kind of a second nature. And it's really a great way how to work together. Yeah, and from that on, yeah, I'm working as part of the team now and that's kind of the natural progression. Then I have commit rights now. I'm a contributor. I'm a committer in Cloud Foundry and that was just done in six weeks. So that's great. Good. Some challenges, doing the Dojo, I think it's a great thing and it's really a great way to get started. But it's also, there are some things which are challenging with that. So the first of the things is that Cloud Foundry really is a unique project. We talked about the way how people work, about the pairing and so on. That's pretty unusual. And it's also, I mean, it's an open source project. So everything is open. But you can't start just with contributing by pull request and just, you won't be involved in the same way as in some other projects where this is the primary way of contributing. So this is kind of a barrier and a challenge, which I think, especially when Cloud Foundry is growing, we probably have to find ways how to make this less of a barrier. The other thing is you have to be open to actually light pair programming. If you don't do that, if you don't want to do that, you won't have fun and you won't succeed. So that's a big part. Yeah. That's a good question. I personally don't have numbers about that. The people I worked with and I have met by that, I mean, most are actually prepared for that. They want to do that. And they were really very happily getting involved in that way of working. But I don't have any statistics about that. So that's actually a good and interesting question. And that's part of, I think, my third point there. Some of the thing is not very transparent. So this kind of data is not publicly available. How you get in the doger is documented and so on. But there are some processes where it's not always clear is that pivotal, is that the Cloud Foundry Foundation, is that the community. And a lot of things are just happening by talking to other people. And then things become very clear and you understand them. But you need to do this conversation thing. And that's, I think, also part of the culture. It's great if it happens. But if you come from the complete outside, it would be very difficult, I think, to get started. And that extends a little bit to the technology as well. There is a lot of tested knowledge which you realize when you're there. You learn everything and that's great that the doger is a great way to get people into the community. But maybe sometimes we could document things a little bit better for people who would just look from the outside. And last but not least, it is an investment to send somebody to the doger, spending six weeks in San Francisco is expensive, also committing to basically a year of full-time participation after the doger, which is part of the agreement. That's something, I mean, that's a serious investment. You have to really seriously want to contribute. But then I think it's absolutely worth it. And to conclude that, some tips, how to do the doger. You have to talk to people who have done it. I think that that's very important. So you get the impression what it is. You learn about how it works, what you have to do, and so on. So that's quite important. And you have to be really very open. You have to be open to a lot of things which are different from what you are used to. So you have to be open. You have to get engaged. You have to ask. You have to speak up. You have to tell people what you need. You have to ask questions. You have to ask all these seemingly stupid questions, which actually are the right questions to get some thinking going, and so on. So this is absolutely essential, I think. You have to be humble. That's part of working with a pair every day. That doesn't work if you are not humble and you're insisting on your opinion. But you also have to be fearless, because you, in many cases, work on something where you don't have any idea at the beginning how to deal with that. But that's, again, something where the pairing helps a lot, because you have the means to find out what attacks. So it's an interesting combination of what you need. You really need to be active but also humble in the same way. And your life as a developer will be different after the dojo. That's for sure as well. And I can only recommend to brush up your ping pong. That's the main activity to have a small break between coding, and that's a great thing, and you will have fun with that. So for me, the general advice is, yeah, enjoy the time, enjoy doing the dojo. And I think it's really, really very beneficial to the project and a great way to introduce people. Yeah, talk to us if you want to know more. We are here for the conference. You see our email addresses, write us. We also are on Slack. That's the usual platform. There's a channel, dojo alumni, where we try to collect some of the people who have done the dojos so we can actually share knowledge. And I think that's the end. Thank you. So do we have time for some questions? Are there still some questions? Really, but maybe we can take one. So they want pressing questions? OK. Nobody else seems to need the room at this moment. Yeah, so that is the thing, not just for dojoers, but in the pivotal office we have regular teammates on Bosch, some of whom don't work for pivotal. So there are occasional meetings, I'd say maybe once every month or two, where the product manager will say dojoers and non-pivots, you'll have to excuse us. So it's relatively rare, but it does happen. Yeah, from my experience, it was in the pivotal office, they are pretty open anyway. They are people from other companies as well. So sometimes you get told, OK, this is an internal meeting, so you can't participate. All the stuff we are working on is open. The tracking is open. The planning is open. The code is open, so there's nothing to hide and no secrets. And I think there is a little bit of a separation between teams who are working in open source and who are working in proprietary parts. But in general, of course, there is some trust part of that, so you might see some things there which are not meant for you, but I think that's part of trust for collaboration in most situations anyway. OK, our time is up. Thank you for attending.