 Well, thank you for making it to this last session of the day. I'll try not to keep you too long. So my name is Robert Summers. I'm a junior developer with Armacuni. And I'm here to talk to you a little bit today about my journey as someone new to software development and the processes and tools that we use that I thought really enabled me to really get stuck in and start to learn my profession as a developer. The idea for this talk came about as I was speaking to some friends of mine, and we all kind of started our careers as developers around the same time. And I noticed there was a pretty big difference between my experience, my first few months on the job, and their experience. And probably the biggest difference was that I was coding every day and pushing features every day and working with the client every day, and they weren't. So just to rewind a little bit, you might have noticed in the job title, it says junior. You probably don't see too many junior developers here at the Cloud for Audrey Summers given a talk. So let me just give you a little bit of background about myself and how I got to this place. So I used to work in insurance. I worked in insurance for well over 10 years. And towards the end of my time in insurance, I wasn't happy with what I did. And I wanted to do something else, something more fulfilling, something that I was actually interested in doing. And through a process, I'll happily explain to you in the pub later. I eventually decided I wanted to become a developer. And then I started to look at ways, what are good different ways that I can kind of move from not ever to coding before to becoming a developer. And eventually I decided on joining a coding bootcamp. So I chose one in London called Makers Academy. And they run a 12-week intensive bootcamp where you spend eight hours a day for five days a week, for 12 weeks working on coding challenges, but all the while kind of progressing on the skills that you learn every week in building more and more and more complex projects. To mention the end, everyone works in a team building a final project. But anyway, at the end of this process, then I started to look for a job. And after going through several interviews and different tech tests, I finally got my first job as a professional developer in November of last year at Armacuni. And so what did my experience look like versus my friends? So after the first few months of working today, we kind of got together. And we were kind of sharing our experiences. And I just started to get this picture of what their workplace must look like. And this is how I kind of imagined they were working. They were doing things maybe in old fashioned ways. So what are some of their stories? Several of them had to go through long periods of training. Even though they had gone through an intensive bootcamp and gone through the hiring process. Some level they were trusted by the company they were joining. And they still had to go through another training process, sometimes over a month or two. And that was even before then they get into whatever the process is that they had to integrate within their own teams onto their own client projects. They couldn't show up every day and just start to get stuck in coding. They had to wait till they had a senior member of the team available who can sit with them and make sure they were doing things that was kind of the proper way for their project or their style of coding. And often this was gated by a code review. So I had one friend, they would show up to work every day and they would have a task for maybe a week. And they would work on one task for the week. At the end of the week they would get their meeting with the senior dev and they would look over the code. And maybe it would go into production. Maybe it wouldn't. They would go back and then go through the process of refactoring. And this would just kind of go over and over again. And this just kind of created a long cycle time for them between seeing what they were doing versus the effect that they were having on the product that they were working on. And it just got to make me think, so what was I doing that was different? So that messed me. And if they were doing things the old way, I must be working in some really cutting edge futuristic company, right? So what we're redoing that was different. So my initial onboarding was about two weeks long. Most of that was focused on learning some of the new technologies that we need to get exposed to as part of the client project, such as Cloud Foundry and coming from a bootcamp, things like pipelines and Docker containers and databases that aren't postgres, technologies that aren't Ruby on Rails, how to kind of start to become really familiar with all of this. And after that two weeks, then started immediately working in a team, working in a client project, and delivering code every single day. So comparing these two experiences, I just started, I really wanted to answer this question, what does it take to get a bootcamp grad? Or anyone, not just specifically a bootcamp grad, but anyone kind of new to software development? How do you get them integrated into a team and start getting them productive as soon as possible? I think I lost a slide. The answer, and part of the process to get these, you know, a junior developer productive, I thought, there are kind of several things in the way. So this picture here, if you live in the UK, it's a very familiar picture, a little bit controversial. I mean, it's supposed to mean there's road work ahead, so be aware, right? But many people look at it and say, oh, it's a person who's dropped their umbrella. But anyway, so what are some of these roadblocks that you encounter as a junior dev to getting productive? And one is this long training time, right? Because I mean, there's no possible anyone that starts their job understands all of the technologies that you need to use in order to be productive. So not just the language that you code in, but maybe the frameworks that you use in that language, have another learning curve, and then perhaps you're using a different database technology, using things like in your operations environment, maybe Docker, pipeline technology, and if you're lucky like myself, and you're also deploying the app, so you've got to learn things like Cloud Foundry. There's lots of things you need to learn, right? You know, is that they're not empowered. So I guess what I mean by that is that as a junior dev, you don't just show up to work on day one and get access to the code base, right? And start pushing the code. There's lots of processes you have to go through to complete, and you want to make sure, vet your code, vet that you understand the project, make sure that you know all the HR processes, and lots of things like that. And then finally, part of what kind of drives this kind of lack of empowerment, and kind of the slow burn of getting a junior developer productive is the fear of breaking things. So the senior members on the team, they're afraid if we just give someone kind of free reign to deploy and push code, surely it's just going to start to break things down the road, right? And to be fair, from the junior developer's perspective, we're thinking, I don't want to be the guy that breaks the app. I don't want to be the guy that crashes the server and causes all the problems, right? So what do we do about this? So obviously I think the title of my talk kind of gave this way of what I'm going to talk about here. So Cloud Foundry and Continuous Delivery, how this kind of helps create an environment where junior developers can become productive as soon as possible. So how do we get there? So first, talk a little bit about the process and the environment that we're going to create. And this includes working in an Agile team. And what I mean by all these goodies that come with Agile, so part of Agile development is it's a very iterative process, right? You plan, you're deploying, you get feedback, and then you kind of keep loop, you re-prioritize based on that feedback and redevelop, and you're constantly going over and over in this cycle, again, right? And that's very beneficial as a junior developer because that iteration really reinforces the learning you're doing. So the more you're getting stuck in with the code, the more challenges that you're encountering, the more times you're having to think through different designs and different applications of what you need to do with the client product, then the more you're going to learn about it. And also, one of the benefits of the Agile process is that in an Agile team, you're working very closely with the client or the product owner, right? So you're constantly getting feedback. And this constant feedback really helps kind of build your confidence because it allows, as a junior, you're no longer in the ivory tower of your school anymore, right? You've got, you're working every day. You're pushing code, you're not pushing code, but you're putting it in front of the client, and they're going to say, hey, this feature's good. Well done. Or nope, this isn't quite how we want it. We need you to kind of rework this or rework that. And it really helps give you confidence that you are actively contributing as part of the process and not just being dictated, oh, do this feature. Oh, do that feature, right? And a very important part of the Agile teams is pair programming. Is everyone familiar with pair programming? Does anyone actually use pair programming in their day jobs? Not as many as I thought, I'm surprised. Pair programming is an excellent way to get junior developers kind of on board with your technology, right? You could spend weeks and weeks going through documentations, building sample apps, or you can sit down with an expert or senior member of your team who is familiar, right, and know of it, and learn directly in getting hands-on experience while still actively working on your project. There's lots of other benefits of pair programming. I think because I mentioned pair programming, you're kind of obligated to show a picture of yourself or your team pair programming. So for those of you who don't do it, the typical setup that we follow for pair program is you have two people, right, your pair, one computer, but each person has their own screen, their own keyboard, their own mouse, and they're able to collaborate all day long in that setup without kind of invading each other's space. And then finally, another really important, I think, part of the process for junior developers is a test-first mentality, otherwise known as test-driven development. I know sometimes you can kind of start a holy war in places by advocating for TDD, and I think if you'll actually, if you'll just indulge me for a little bit, if we can at least agree that tests are important and that you do need tests for your code. And why is test TDD good for junior developers? Because it helps focus your mind when you're writing code. Think very specifically about the requirements of what you need to do. And the more code you write, the more tests you write, the more confidence you get in what you're doing isn't upsetting the balance of the code you've already written, right, because we have all of our tests. But just because we write the tests, right, doesn't mean that everything that we push is automatically test-right, because now we have to start thinking about automation. So if we kind of go back to these roadblocks, how do we overcome some of those roadblocks I mentioned before? So other than the guy dropping his umbrella, so we talked about long training time. So a lot of what I've talked about already, the agile environment, tester of the development and para-programming, they kind of help solve this problem, right? And all the rest of the things I'm about to mention, they all kind of synergize as well and kind of contribute to the development of the junior developer. So in the agile environment, using tester of the development, we're working on the code and we're delivering features, right? But I haven't yet talked about that in this team, we're not only delivering the code and writing the features in the app, but we're also deploying the app. And I think from my experience talking to kind of senior developers, people really experience in the industry that this used to be kind of two different worlds, right? You would have a development team and an operations team and one would be kind of specifically responsible for one aspect and the other. So how do we get junior developers not only writing the code and delivering features on the app but also deploying it? And the answer, of course, is Cloud Foundry. And why do we love Cloud Foundry? So many, just listening to some of the other talks say, especially in some of the key notes, it's clear that one of the major features about Cloud Foundry is just as a developer, it's just so easy to use. And Cloud Foundry does so much of the workforce that we can spend most of our time writing the code in our apps and then less of the time having to worry about deployment and configuring deployment and manually doing all the deployments, right? And so yeah, sorry, I lost my place. So just moving on. So how do we overcome the not empowered? So if you recall this as I was talking about, so my friends were, their process and their teams, everything was kind of gated by a code review. So anytime they push code, it was to a feature branch or to something and they had to then wait for the review. And this might not just be for the process for the junior developers, it might be the process for the whole team. This is how they do things. And of course, to get over this, we can talk about continuous delivery. Does anyone use continuous delivery in their work environment? Good, good. Sometimes, I wasn't sure if today if I was gonna be preaching to the choir or maybe introducing ideas that would be new for your teams. But one of the key tenants of continuous delivery is that we're always delivering production ready code in small chunks and rapid iterations. And kind of going back to what we talked about fourth agile, agile is a very iterative process. We're constantly delivering, we want to constantly deliver features to the client and continuous delivery is a process that helps us implement that. So that whenever we push the code, right, it's going right to the customer, right to the client. And again, as a junior developer, being able to get that response, immediate response from the client about what you're doing, kind of helps give you that confidence boost. And then, of course, more confident developers, more productive developers, more independent, right? But another major, one of the important parts of continuous delivery is that you need a pipeline. And how in the world can you get, can you continuously deliver the code from your desktop to the production environment without a pipeline? So what does a pipeline do for us? A pipeline, for those of you who don't know, pipelines will, they will automate all of the steps in our process from when we push the code to our repository to when it gets deployed into production. And this kind of helps, this automation helps us solve this kind of fear of breaking things, right? So if we were following our test-driven development, if we write, if our code has adequate test coverage, and we've been disciplined about keeping, keeping the testing in our repos, and that we've got the proper coverage in our test period, and we know that when we push code that if something's gone wrong, it will break before it will let us know by the test failing. So what do we use for our pipeline? We, we like concourse, and why do we like concourse? Concourse is very easy to learn. It's, and one of the advantages of it, as from a developer's perspective, is that, is that everything you can, everything you do in concourse can be delivered as code. And this helps us deliver value to the client, right? So when we, when we build our pipelines and we use, we can check it into a repository, and then we, then when we have a, when we deliver it as code, then we have a very clear history of, of who's done what, and what changes have been made. And so even if the same team is no longer working on the product, right, then all of the configuration for our deployment, which will be stored in our pipeline, that is then delivered as code to the client, which then adds value to the client, right? And it also adds value to the junior developer, because then we're now part of this whole cycle of the application, you know, from development to our desktop, to the deployment into the application on the cloud. So I've got here, this is a picture of the pipeline for that first project that I was going on. And in case you, so with concourse, it's very simple, kind of breaks down the pipeline into kind of two simple concepts. You have a resource and it basically boils out to, you have a resource and a job, right? So a resource is gonna be things like our code and maybe things like Docker images or even deployments. And then we have jobs and these are the things that we want to do to our resources, right? So we want to, we want to run our integration tests. We want to run our full test suite. We want to deploy it to a pre-production environment. We then want to run our end-to-end tests and our pre-production. And if all that passes, then we want to, we want our code to then be deployed to production and then we want to run some smoke tests on production and maybe a few more tests on production just to make sure everything is great. And it's also very visual, right? And that's very helpful when you're new, when you're just learning, you get very bright red flashes when things go wrong and you know you need to analyze it. So where do we go from there? So this whole process I've talked about, we've worked in an agile team. We're pairing, ideally with where the juniors are pairing with senior developers. We're practicing tester of a development. We're not only writing our code but we're deploying it to Cloud Foundry and we're deploying it using automation tools and automation tool pipeline called with concourse. And so what do we get from this? We learn that tests are really important. Not only do they help focus how you write your code but they also give you the confidence that as your product grows from your Hello World API app to the very complex microservices application that your client has demanded, your tests kind of give you the confidence that everything you're doing is keeping everything in order and you're not breaking. As a junior developer, the next thing you learn is that environment matters. So when you're learning to code right, you're very used to just a single environment. You might have your, or maybe two environments, your development environment on your laptop and then when you deploy your code to something to production. And when you start to work as a junior and you're kind of responsible for the whole life cycle from coding the features to deployment, it really introduces you to more concepts like how to, important cloud native concepts like keeping the configuration as code and how we keep our application as cloud native as possible so that it can run no matter that we're running, we're pushing it on one cloud provider to the other. And finally, you really get to learn the value of the short feedback loop. With part of the agile process, because we're constantly getting feedback not only from our client, but in stand-ups, we're learning about everything that our other team members are doing. And this really helps give you the confidence, I keep saying that a lot, it gives you lots of confidence to keep doing your job, right? And when you see that you're, what you're doing is actually valuable contribution of the team, no longer do you feel like a junior or someone that has to kind of hide or maybe be shy about what we do, but you actually, you know that you have something to contribute and that's very valuable. So in summary, why do we love Cloud Foundry? So I realized this is the Cloud Foundry Summit and I haven't spent a whole lot of time talking about all the massive features of Cloud Foundry. But that's because Cloud Foundry in itself is so simple, simple to learn that juniors can learn it. And I think when I first gave this talk, I made a very bold claim that if you have got an app, I can teach you how to deploy in Cloud Foundry in the pub later. And it's really that good. And because it's so powerful, it does so much for us, it allows us to focus all of our time on value added tasks like in doing the things that we like, like solving the coding challenges and delivering value to the client. And so I hope that I've given you an idea of about the kind of environment and the processes and the tools that you can use to kind of help your junior developers get productive really quickly. And you never know, maybe in a year from now, they might be at the next Cloud Foundry Summit given another talk about what they've done. Thank you. Any questions? When you said you did peer programming, so in our organizations, our team don't do peer programming yet. Yeah. And you were a junior developer and so did you have your own assignment and how did that work together with the senior? So could you only watch or was he only watching or the senior developer only watching? Yeah. No, so in case you didn't hear, he's kind of asking how do you, when you start peer programming, you know, how as a junior do you work with the senior? And I think it's important when you start peer programming you've got to kind of maybe have a little chat with your partner how you want to organize your day. I think one of the things I like to do is make sure we kind of schedule our breaks because peer programming is quite intensive because you're constantly engaging with another person but you're not just kind of having a social chat, right? You're working through complex problems on whatever feature you're coding or developing. So how do you deal with the discrepancy between junior and senior? The most common I think peer programming pattern is you have something called the driver and navigator and the idea is that the driver is on the keyboard and is kind of typing the code and the navigator is trying to keep the coding kind of focused on the problem at hand and trying not to get sidetracked. So how does that work in the kind of junior-senior relationship? I think as a senior you probably have to maybe take a step back and make sure that you're just going to have to accept you're not going to be able to move at the same pace as maybe you could be if you paired with another senior. So if the senior is navigating it's probably going to be a lot of dictation about exactly like, okay, this is the syntax you need to start here, here's the method name. Et cetera, et cetera. But I think the good thing about peer programming is you can actually reverse that role and you can have, there's no reason why the junior can also be navigating and whether that navigation is by directly dictating like, oh, we need to consider this problem or that the data is coming from this source but also can kind of challenge the senior. Like I'm not sure what they can do. What's the right pattern to solve this problem or what's the right feature that we need to implement? And so it's a back and forth and the more you do it the more the senior, I think the value to the seniors, when you teach, you kind of relearn what you know because you have to re-explain it and then yeah, does that help? Same question but in more practical way, for example, are you pushing code to the Git repository and senior is checking the code and sitting, okay, this is not good and there's some writing comments, this is not okay, rewrite this function because it might fail. This test is not enough, write another one or it works through the Git and this iteration works through the Git or some SVN or something like this. So you're talking about like just in terms of pair program or just in terms of like the project team? Per programming, okay. So how does senior is reviewing your work in a practical manner? I think just in the situation as I've been, it's just, it's a constant process. So like just the other week, I had started a new project and it's in a language I've never worked in. It's a new project in Golang and I just have to warn, like I'm gonna be asking you lots of questions, right? But as far as, I'm sorry, what did you mean about checking in? It's okay, sorry. I mean, how you sending to the, sending your work to the senior programmer to check the code if it's okay. So are you pushing the code through the repository and he's looking through the some GitHub or GitLab web interface and writing comments on your, on your code or are you sitting next to each other and he's looking over your shoulder and commenting what needs to be fixed or in this practical way. Okay, sorry, I see what you're saying. So how, when you're, when the junior's pairing with the senior, how is that, how is the senior kind of reviewing the code? So in our case, it's kind of as you go. So as you're coding, the senior's providing, you know, the senior's providing feedback and advice. Actually, this is the kind of pattern we want to use. At first it can be a little tricky because when you're completely new, you have to be told all the basic things, right? And, but the more that happens, then the less you have to be told it. And then, so maybe the second day of pairing, things start to pick up a little quicker because you then have the basic patterns involved. And, you know, part of our process, we're continuously delivering. So the code is always being pushed to the master branch in the repository. So the senior's reviewing the code as we go. I do think there is a place though, like we often put chores in our tracker for code reviews. Like, you know, we've gone a while, we've delivered a lot of code. It would be really great if someone could take a look at this and you know, we can then go through refactoring if, you know, into something better. And that's definitely a valuable exercise. Anything else? Great, thanks.