How GitHub builds GitHub on GitHub | BRK189

Key Takeaways

[Music] all right all right we're going to get this session started just a couple reminders before we get started uh this is going to be a hybrid event so we do have people as you can see in person who are joining us here but we also have people joining us virtually so great thing about that is that if you look to your left and to well to your my right your left uh you go ahead and check out the QR codes uh just go ahead and scan those join in the chat you can answer any the questions that are there we also have our expert Meetup up on the on level five so feel free to go ahead and stop by ask any questions that you have there for our experts uh and uh enjoy this great this great session that's coming up so I'm going to kick it over to y'all thank you Caleb hey everybody well welcome to the last session of the evening I think so uh hopefully we've got what five more oh one after this so what we go welcome to the best session of the evening anyway that's good so this is how GitHub builds GitHub on GitHub hopefully that's enough GitHub for you hopefully nobody's playing the GitHub or the co-pilot drinking games Cu uh you're all still here so obviously not um but yeah I'm with my my good buddy n SOA hi everyone hi I'm n I'm a VP of engineering at GitHub and I oversee uh this area that we call Core productivity but for you it might be like your daily developer workflow um so that includes projects issues pull requests and some of your more like round well-rounded areas uh notifications your profile photo or your profile and um some of the underlying pieces as well like the monolith and um our front-end Services uh and so for me I kind of oversee an area that's got like over 300 engineers and so so I don't focus on what we ship as much as I focus on how we ship and so I'm really excited to share a few of those stories on how we build engineering culture and some of the lessons that we've learned along the way fantastic thank you and then um yeah we're going to talk my name is Martin Woodward VP of devil a g up so uh like N I approve a lot of expense claims delete a lot of email full time job and then um today we're going to um look at how we use GitHub ourselves um and we use GitHub across the entire stack when we're developing things uh sort of building all the platform building the tooling all that sort of stuff we're going to talk a bit of time you know about the like the technology and the processes and how we use them but we're going to spend a lot of time about kind of the processes we put in place and some of the human things as well you know like we call people who work at gild We call we call us hubbers Hubers so if we say that word that's we're not we're not insulting anybody that's what we call ourselves so how uh other hubbers you know how we how we interoperate how we work how we communicate that sort of thing um so I was that soes that makes sense that's the session you're in if that's not the session you want to be in I won't be insulted feel free to leave now but it is an awfully long way to the next session so uh you can stay here in a nice cozy room if you want as well cool so first of all let's dig into some of the challenges of like the scale that we're dealing with here um we're going to be playing in the code base for GitHub live on stage what could possibly go wrong and then um the code is so if we say GitHub GitHub that's what we mean it's the it's the repo on the GitHub organization that contains all the source code for GitHub and it's on GitHub so that's what we use um it's mostly Ruby um in in the monolith you know the big theom monolith and then the front ends reacts m equal database and then there's this big monolith of like a big lump of Ruby code of rails code and then there's around was it 2,000 how many microservices it's over 2,000 I don't know I feel like it increases by the day it's like 2025 services or something like that um that all you know like microservices all way around and then you how many people do you have in your team 3 350 320 320 as a yeah as of this morning as of the last rorg and then I there's a total of about 1 and a2k people in engineering so um yeah it's reasonably big um now what's fascinating as well as an interesting problem of working at GitHub is just kind of the scale um there's it's grown a lot since that first commit on that Ruby monolith in 20 2008 um there's over 100 million accounts now we see like a 26% increase in accounts year overy year last year and it accelerating yeah uh there are over 4 and a half billion like contributions bits of data that came into GitHub in the last year um 420 million repositories I was reading and then of those repositories I think 284 are public yeah but um 136 million of them are private and yet those private repos account for over 80% of the activity that happens on GitHub so there's lots of the open source but the busiest repos are the ones that are private quite often because people are being paid to work on them probably so yes that's good and then so you know things are busy and we thought life's busy you're busy you know what I mean and a little thing came along you might have heard a little bit about this week called co-pilot the G co-pilot as we like to say and co-pilot was launched in 20 2022 and it's seen massive success it's growing 35% quarter over quarter right now which is quite challenging to cope with and deal with as a team um the growth stops the number of features being added keeps going because people want new features people want things to be fixed and yet actually the engineering headcount that doesn't grow at those same rates it's been relatively flat yeah it's been relatively stable relativ relatively stable so how do we do that how do we like you know be responsible for like this whole service and how do we keep scaling how do we keep improving our processes to get better at building so that we can cope with this growth with roughly the same amount of people um and that's what kind of what we're going to dig into because you like you're responsible for folks the whole way down the stack you know you got people who actually rack mount like machines like Max in things and like deal with stuff stuff but then we also do a lot of like Cloud native stuff so um like co-pilots backed by you know the Azure openen AI you know like Cloud native Services you've got things like Edge caching you've got you know Linux and windows actions they're all hosted in in Azure as well so uh yeah it's a lot so we um we measure things and in terms of the key metrics that we like to look at actually obviously security metrics looking at that number one and then availability and productivity it's no point having an amazing website if the website's down like people actually have to be able to use it and they have to be performant but then we also look a lot at product internal developer productivity how well the teams are collaborating and how well those teams are able to scale so yeah and if you were to join GitHub one of the things that you're going to hear us say a lot is ship to learn and this is codified in our GitHub values it's up in our internal site and um this basically encourage us encourages us to not go down the waterfall path um don't go chasing waterfalls uh and instead sticking to the rivers and the lakes that you're used to basically taking things that are a little bit smaller um and shipping them out and looking and learning from what we do and iterating accordingly right incorporating those learnings so when most people when you hear ship to learn you think that we're focusing on the shipping side but actually what we're focusing is on the learning side and um uh so like while you know we have like we have to measure to improve right it's really important to keep in mind our major goal right and that is like I'm going to let you in a little secret right what is our master plan for GitHub and the master plan honestly is the fact that we uh our master plan for GitHub as a company is the same as GitHub as a product and that is to build happy developers right and um you know when I mean happy developers I mean the audience of people who use GitHub and and I think what's really interesting is that in GitHub we use GitHub but also externally use GitHub and that actually has like an interesting balance right between external users that use GitHub and internal users that use GitHub and so we have to think about those two things um as a VP right like I think about um these incremental changes that we do and how we ship incrementally um I think about that in terms of like our engineering culture so like if you think about what it really means to do culture it's about every action that you take and every action that you take is moving away from today's culture and towards the next culture right so this is devops right and so we love to measure uh and so how are you going to measure developer happiness the best way to measure developer happiness is to ask your developers right and so we ask our developers internally at GitHub we have something called the developer satisfaction survey devat for sure short and we ask our developers what they uh care about and like I don't know about you but developers love nothing more than than to complain so they complain they tell us what they want right and if you want to change your culture and you want to make things better for your developers you're going to take what they're talking about and if you can incorporate that into your road map then you can actually get started and start to change that culture and make things better um and don't get me wrong it is really hard to carve out that time as I was saying before right because we have external users that we want to make your lives better and then we have internal users uh y'all don't necessarily have the exact same stack that we do or the same problems that we have and so we always have to figure out how to balance between internal users and external external users and one way to do that and the way that it makes it really easy is if we can find those story lines where this aligns right and what I mean by that is if there's something that we can do internally to make our lives better that can also make your lives better it becomes a lot easier for us to justify and take a look at that and those are some of the things that often get prioritized so so the first thing that we're going to be talking about today is the GitHub developer environment one of our top needed areas of improvement cool yeah so um the goal we had as a team we set ourselves was to get to the point where on day Zero cuz you know we're developers so everything starts at zero um on day Zero in the in the team you want to have code running in production in the hands of customers that's the goal and that was hugely ambitious like it takes weeks sometime how long does it take to sell development boxes in your like Place sometimes it takes weeks to do that to clone the code alone I have a fiber connection I live in a field I have a fiber connection and it takes me 45 minutes to clone like.com down to my machine it's a big mannery yeah and so um you know people can like it can be too fragile so we had the real goal of actually bringing the time down from 45 minutes down to less than a minute to get a brand new Dev box on your machine uh we do that with a thing called GitHub code space um that's what it's called now anyway so code spaces is a containerized um Linux based development environment that's run runs in the cloud it's fully hosted for you and it scales like you can get whatever size of compute you want you know like you know however many cores kind of thing up to 32 I think you can get um and um yeah it's great and and they're disposable really as well because it's all configuration is code so if anything goes wrong with your data with your Dev environment as just happened as I was stepping up here uh you can trash it and get a new one so that's what we're going to go do now so good job so uh let's do the first demo right so behind me on the screen uh this is the source code for GitHub live as we speak this is the main branch you'll notice that the last commit was a couple of days ago that's cuz we've been in a deployment freeze for build so that we don't break anything while we're live on stage fingers crossed um so yeah so let's go do some stuff I'm going to if I scroll all the way down here we'll see opening GitHub code spaces so as a developer on the team I can come in I can say where do I want it Us West or whatever and I'm going to create a code space so that's going to download all the source code it's going to set up a brand new you know virtual development environment it's going to download of code it's going to set up rails it's going to set up 2,500 oh actually it's finished so that's me with a brand new Dev box up and running ready to go and I can this is like a brand new Dev box so I can just come in here and I can say yes to these V vs code pop-ups that run the first time you do vs code whatever right and I can do script uh Slash server and then hit that magic and that's going to run uh it's going to start running there we go it's going to start running the server and it's going to set up all the test data for me in my brand new Dev machine and get me up and running now what I thought I would do this is the homepage for github.com uh sort of is a blatant advert for an event we've got coming up but yeah this is the homepage let's build from here what I thought would be cool would be to um change the homepage let's let's graffiti the homepage so let's do that live um the first thing I'm going to do though is what quite often you uh like you would use vs code normally wouldn't you like you so what you can do in vs code if you haven't seen this before you can connect oop sorry uh remote development you can connect to your code space from VSS code so it feels like you're running in a container in the you know like on a local machine sorry it feels like you're running a local machine but actually you're connected here to a code space if I open up a I'm running on a Windows machine here but if I just do a quick un name minus a we can see it's running in a Linux code space up in the cloud so that's you know but I feel like I'm local and so much so actually let's just make this a bit uh let's get rid of that let's move that down a bit for now so if I go to my browser and I click on Local Host I'm just going to hit refresh fingers cross L if everything's yay right this is GitHub running on GitHub do localhost on my local machine now that's mad and I can come in I'm logged in right now but if I come in here and do slome uh there we go there's the homepage that we were just looking at so I'm going to edit that homepage and they come in here so you know this is just uh some Ruby stuff and I say let's build from Seattle yeah yeah let's spell it right silly British keyboard layout that n has been battling with all week but there we are shattle and come in here hit refresh and then pray to the demo Gods fingers crossed please work God otherwise oh thank you for coming everybody it's been great to see bye yeah yeah whoops so that's how oh hopefully my mic is my microphone yeah I can sorry right I got too excited that's a great feeling when you're a new developer on the team because you can get code working really really quickly really easily and so it took us a long time to actually get there and get to the point where we fully adopted code spaces but now it has it's kind of like a massive change for us yeah I think actually this is a really critical part about when it comes to having other people adopt new technologies uh unsurprisingly uh when we first built code spaces internally we didn't have everyone adopting it right away right and adopting new technologies especially as someone who's very passionate about developers I can you know bring them to the river but I can't make them drink and so how do you help other people adopt new technologies for COD spaces in particular there were two things that we did that were really effective number one was that we uh started to look at like the time to get started right and so as you can see how electrifying it was right when you could make that change right away that started off around like 45 minutes right and so we just started making incremental smaller and smaller milestones in order to get it down to 10 seconds right and then the second thing that we did was we kind of gave it the Supreme effect are you familiar with like the Supreme brand um it's like biggest appeal is that there's so there's like not many items and so if you have something that says Supreme it's like very special and so for us what we did is we had the computer club and so we created an exclusive area where if you wanted to opt in and try new technologies you were in a crew and you were in a club and it was very cool and you all elected that you're going to try code spaces and um share what you learned with each other and if it didn't work out right all we asked was that you just share with us why and so as people exited and didn't like code spaces at the time because it wasn't filled and fulfilling their needs all we did was use that as our road map right so as we saw more and more people coming in trying out giving us feedback we use that to optimize the experience and make it better so that was like a very big tip for us on how to do it and um there's a much better story uh telling of this story by Cory Wilkerson so if you actually check out this link here um on codes spaces adopting you can see the five minute story and you can hear it for yourself so uh with um code spaces like we're all adopting that now everybody is there like there's not a single developer I know at G but doesn't use codes space no I mean especially for like the onboarding experience right right into the onboarding experience when you join GitHub we already set you up with code spaces so um co-pilot's different story like we sort of of give copay to everybody but getting people to use it um it can be interesting because people have to take time out the day and like you learn a new tool install the plugin use the plugin all that sort of thing and so adoption is now in the like the 80% but it's not at 100% yet um but we do see for the people that do use it we see a massive jump in productivity we were seeing very very early like two years ago a 55% jumping productivity when we first installed it and then Accenture being Accenture when they're doing a massive roll out of co-pilot right now and they're doing like loads of testing and they're seeing huge increases in productivity my favorite stat is that one there about builds because one of the fears that people sometimes have with like AI Technologies is all right well if you can use AI to generate lots of code for you then you're going to like make really really big PRS that are hard to code review and you know but actually we see 50% more builds happening amongst teams that are using co-pilot within Accenture so people are iterating quicker people are are shipping more often and actually directly correlated to that is they 90 they're 90% more fulfilled and happy like more people are fulfilled and happy because of uh having this extension installed so that's huge and that shows you the direct correlation there is between the perceived productivity how quickly you can iterate and happiness in your job funnny enough um now when people adopt co-pilot I did that I'm quite pleased with that one when when uh when we when people people adopt co-pilot we quite often see the early adopter so people like you who come to conferences who learn stuff who listen to podcasts who watch YouTube videos they grab it and they go thank you very much and then you know they're using it but then there's a large Shunk of people who just don't want to get bothered in their day and so it's how do you reach those people how do you and we find it actually it's about 20 25% so it's kind of the classic you know more like Innovation curve so how do we cross that Chasm how do we help the whole org adopt co-pilot the best things we found that's working is actually people sharing the excitement like they're not going to believe me I'm a I'm literally a paid shill that is actually my job I'm a developer Advocate okay so they might believe nah cuz she's actually like codes a little bit I don't know I'm leadership now like basically the enemy yeah so not believe you either but they'll believe they mate they'll believe someone on their team who tries it and it's like yeah this is great so we do think we created we've got a channel called t today I learned and people can share like oh this is amazing and so encouraging people to share like prompts share things where co-pilot is like help them that day has been really helpful and we've seen other people do that as well like create channels teams channels whatever to sort of share look at this it helped you know and find those mavens find those internal Advocates and and and Empower them to share their excitement with as Nan mentioned with um code spaces it's also good good to introduce some ceremonies to make it a privilege to have co-pilot you know make it um give it to the team allow that team to take some time out so the whole team installs co-pilot on the same day they take 4 hours 2 hours out of their day to just play with it get used to the tool learn things like if you press Escape it gets rid of the code suggestion um if you press command eye or control eye it'll bring it up in your you know it'll bring up in line so you don't have to go to a chat window like stuff like that that just take the time to use it in a safe environment before then going back into production and then last but not least is Clarity is have some like data have you made things better or worse um so run surveys before you roll it out run surveys afterwards use we've got a new metric API that you can look at um within co-pilot Enterprise you can look at the level of adoption within your teams who's using it that sort of thing so use that API there if you want to learn more there's a link G hi/ copilot adoption that will take you to a paper that details the Accenture study how they did it how you can run similar studies in your organization and then there's also a bunch of like open source repost because we GitHub that has all the survey questions all that sort of stuff so next we're going to talk about planning and tracking I'm just letting take a photo of that slide there we go I'll also like share a few like interesting current stories here at GitHub so one is that when we talking about like giving a spot to the people who really understand the tools well uh like even I think it was 2 days ago here at GitHub um one of our most prolific uh developers her name is Sarah vessels um she has like the most commits at GitHub right now and like you can kind of see based on the graph um she just shared all of her tips and tricks on what she does to be productive right and if she is the one who's sharing her tips and tricks other people are going to take up on that as well um the other thing that I think is really fun and interesting and more like Whimsical at GitHub is that we have um you know how like you have emojis right so we have a T emoji we have a channel that says every single time someone uh reacts with t um with the T emoji it'll show up into this Channel and so if you're curious about what other people are learning there's ways for you to kind of connect that and make that more visible as well um so yeah those are my two stories um let's talk about planning and tracking so when it comes to planning and tracking um uh you know what we're talking about is the communication essentially right I feel like that's the hardest problem in any organization is communication and if you think about software right we are talking to computers in a different language and then they are talking back to us and then we are talking to other humans to talk to computers better right and get more out of it and so like really it just Turtles all the way down right it's all about communication and so uh I think this is even more complex in an org like GitHub uh because we are 100% remote and like I don't know if you know but we when we started 15 years ago we were remote first from day one and uh that is a very long history to be remote um and honestly like with today's technology and Internet working remote is pretty easy um it's really the time zones that are going to get you right and so that's why at GitHub we have to work really deliberately to create a culture that supports asynchronous working um and so we have this uh saying at GitHub and that is if you liked it then you should have put a URL on it so there's this really wonderful uh uh blog post by Ben Balter so if you just search if you liked it you should have put a URL on it you'll find it and um uh essentially what that means is that if you want information right you have to figure out how to make it work in an asynchronous culture we actually distilled our communication philosophy and we released it earlier this year it's in this that link at the bottom this is actually a public repo on the GitHub organization it's how engineering communicates and this is the philosophy on it shares a few philosophies and a few key Concepts um on what to do where and so for us we say that conversations can happen you know in slack it can happen in your chat it can happen in teams it can happen in video calls um but issues are for tracking work and ideas discussions are for long running conversations rfc's announcements and poll requests are for bringing code and process into the repo right and so that means uh including like changes to your documentation playbooks adrs edrs whatever decision record acronym of your choice uh and uh you it's really important to take all of those different lessons and be able to align on those so for us we put up a public repo if you want to Fork that you want to um modify and then use a documentation and just attribute it back to us you're more than welcome to start with what we have and then make it work for you all um but this is all Theory land right so I'm going to tell you about like three specific stories on how we build our tools to change how we work and that's through discussions projects and merge CU so um the first one is for disc discs so I told you about like oh yeah when you when you want to communicate with each other use discussions but we've got, 1500 engineers and we have a wide variety of functions and we grew pretty quickly so like at some point at GitHub the average tenure the median ten year I think was 2 years so imagine a bunch of people are joining the company they don't know how to handle the nois to Signal ratio but they're the ones who are doing all the posts right and so how are we going to make that work for a large organization where we want to Leverage discussions we want to use what we build um and so what we did was we had everyone start using their local repositories and then we used magic labels right so this first screenshot on the bottom right hand corner are the labels that we use and we put in all of our repos and then we had an action which is a background screenshot and that the actions were the ones that were taking the different labels and then rolling all of these up into like yesterday in engineering and last week in engineering uh blog posts not blog posts to have discussions so um you know this is what helped us go from you know the unmaintainable to the manageable because otherwise you're just taking a fire hose of notifications and you have to like either handle the fire hose or opt out entirely so um what we ended up using was this so This is actually a screenshot with a few like redactions of our engineering discussion page and so you can see there's pin discussions you can actually you see that first post my code review philosophy that chesh 137 that's Sarah vessels the one I was just telling you about that was her posting her code review philosophy to help other people understand what she uses and the tools that she uses and you can see here at the bottom the last post in this index page is yesterday in engineering you can see on the left hand side um the categories for yesterday engineering and last week in engineering right and so what's uh really important here is that you can leverage our tools right we're basically taking discussions plus labels plus actions and we're solving a more complex problem like how to address the noise to Signal ratio now I'm also going to show you a little bit about projects and that's going to be with a live demo as well done okay yeah let me go over here then so um I think the big part the big story that I want to tell you all is that has anyone um uh used projects like back in 2020 or something like that or before like we released the most recent projects yeah uh actually I don't remember when it went out so I'm going to ask co-pilot really quickly um when oh it's still here when did GitHub projects go to GA we just asked this an hour ago um and it says that it uh went to GA in 2022 so did anyone use projects before 2022 there were a few people who raised your hands before you don't have to raise it again so you're good um and so the way that that used to look was that we just had these columns and these uh story cards and it kind of look like Trello and unsurprisingly our tool was simple and the problems that we could solve were simple right we weren't able to do these cross collaboration complex uh um cross org initiatives and we weren't able to solve these harder problems and so what was really important for us was that as we started to invest in our project infrastructure we could have harder we could address harder and harder problems inside and uh that includes you know all of the latest features like um uh swim lanes and uh our Gant charts Etc and so I'll show you literally what we have been using lately this here is our release tracker internally at the company and how we coordinate across the board so you can see that um right here co-pilot extensibility that was our our ship yesterday right you should be familiar with it right and that's like literally here on our project board and you can see the different labels that we use and how we organize this information we also have a public road map if you ever wanted to see what was coming up and what was up next you can go to with the public road map and we have the ability to be able to provide this information to you in a granular way in a way that you can search against because we have this infrastructure and this technology now and finally when it comes to events we even have like a uh tab for upcoming events and you can see that's for you right here right so um we've got Ms msfp build um and then we have our later events later on and so you can use projects in many different ways and this is like very important um is that you you might be thinking okay cool GitHub projects is just a project board a project management tool but the way that I see things is that discussions is your Word documents and projects are your Excel spreadsheets or your um Google Sheets of the world right it's a way for you to organize information if you start thinking about it in that in terms of that you can start to address more and more problems you can start to link up these tools together so the final thing that I wanted to talk to you about and tell the story of is is shipping it so this is actually a um a neon sign that we have in uh in HQ in San Francisco um and it's the ship monk squirrel if you're familiar um and so how do we ship things here at GitHub well a long time ago a long time ago is probably like before 2020 we used to have something called deploy trains and that was really great until we crossed a line where the number of commits that we had and the number of deploys we had were unmaintainable right and it became more less about quality code and more about who knows all the tips and tricks on how to get something into production how to get something into release how to get past the deploy train stage and so like I I kid you not I was literally talking to Engineers um and they were like okay cool I'm on this deploy train of 15 uh poll requests and but my train got derailed three times this week so they're on their second week for a feline change trying to get that into production and like obviously that's not going to work so um we in 2020 we had this project to go and address this problem we time boxed it to 3 months obviously we didn't finish in time because it's a gargantuan effort and um that was just unstaffed then we did our developer satisfaction survey the devat survey said that deploy times and being able to like work with their deploy process was their number one problem and we're like all right we got to fix this and we got to ship it so internally we started working on this effort and we started to address this through merge cues and um we also started to find out that publicly people were interested in this product as well so what do I mean by merge cues merge cues is essentially automating the merge pull request process um so that you can go into busy branches and you don't have to worry about incompatible changes you're not like contending with other people's changes you kind of have a process where your change goes to a temporary Branch um we go and test that against a CI if it passes then it goes in and if it doesn't it doesn't um unlike the deploy train process where you have a conductor of the train and they're mostly in charge of making sure that all the changes reconcile if there's any changes they have to derail the train they have to address it and they also have to wait for CI to pass every single time so this is like more of an automated way of doing it for us internally and um as we started doing this people were like wait I want that too and so this is one of the unique stories I don't actually I don't think it's that unique but I think it's one of my favorite stories around how we address a problem internally to address our developer satisfaction survey in our pain and then it turned into a product that you all get to use now all right so let's talk about actions let's talk about actions indeed so if I go uh into uh back into. uh and then press three two there we go so um here we actually have the docs repo uh the docs is GitHub is docs are available publicly um you can do them but this is the repo that controls the building and releasing of them so we can come down here and we can see we've got one deployment of uh production of uh of docs and we can just go look that was done 12 minutes ago so this shows you this is live uh so then we'll go and have a look at that deployment and we can see what was done why it was changed uh turn off the domain name experiment apparently is what was going on and then I can come in here and I can come in and like look at the workflow that was ran and this is a fairly straightforward you know actions workflow cuz it's just it's deploying a container uh it run or container and then there's like front end caching in front of it so that's you know actions as most people know it it's cool almost like we do in demos and things like that this is GitHub actions running on GitHub now even though there's a deployment freeze happening we're not merging uh into main at the minute we are doing CI all the time and so you can see look somebody's build just failed uhoh uh it says testing they're probably trying to get CI working is probably what's happening so um they're going through and they're like doing all their builds and this is actually running using the yaml file here but actually when you look at this yaml file it's still fairly simple um what you'll notice is he using Matrix jobs matrices because they're actually uh they allow you to split out and do lots of things in parallel but then everything all is fairly simple and templated because it all makes use of a common uh action a common workflow internally that's our golden path and that's the only approved path into production that's the only way of getting in there and that will when you run that with the appropriate things the appropriate certification on the box then you can push changes into production and um you have to follow that process you know it's kind of baked in exactly what we do so let's try and put all this stuff together and we'll do some more stuff live so here we go what I thought would be cool uh if I can actually for some reason contrl C is not working in my uh in my script this is going to be exciting right so we've got here we've got what I thought we would do is um this is our browser that we were just playing with uh let's build from Seattle because that's on Local Host so we're going to do it on Local Host I'm not going to push this change to production quite yet yeah please do not okay uh so I'm going to go into this test repo and then what I thought would be cool though is rather than just you know yada yada uh like let's edit the website I got quite excited earlier I thought i' try something a bit more complicated and I'm going to um try and do a change to co-pilot with co-pilot so this will be exciting that's mattera so I'm going to say let's ask co-pilot you ask co-pilot question in.com and I'm going to say how do I write a for Loop in Python for example uh and it gives me the answer so that's great blah blah blah blah blah blah blah cool so what I'm going to do instead is I'm going to do a I'm going to play with the prompt this is the prompt that's being used I'm going to play with that and we're going to give it a better prompt so I was thinking I'm going to G it talk like Yoda or something like that Yoda yeah yeah yeah what about like Jean Luke Bard or something like Star Trek instead you're not bored of like old British guys with a bald head I could never Martin I could never okay U right we going ask the audience I mean I guess you all can help us decide right right go on if you want Star Wars or Star Trek so who wants Star Wars how about online as well Ashley can we ask online thank you right we have a poll online if you and then who wants to ask uh who wants we did Star Wars was that is that what we just said Yoda for Star Wars okay so Jean Luke beard star treack a solid that's amazing online got a result yet Jean luk online Johan Luke online but then in person they said Yoda well let's do Jean Luke cuz we're going out of time right so uh so uh respond to the question like you are uh Jean is it working no it's uh yeah this is fun this is going to be exciting so it's uh I'm actually worried I'm going to reload my code space uh I can't so this is going to be very very exciting seon not so uh yes Save oh hello yeah oh this is exciting well six minutes to go we apparently are having network issues so uh well hey this that's how you know it's real so uh right I'm going to kill uh vs code and we're just going to YOLO it and see what happens close anyway I'm remembering everything you're saying Martin and I'm going to write a a chat bot just for you thank you have a chat bar that that sounds like a panicked English person this is like the opposite of Jean Luke Bard okay uh well while this is firing up uh let's just we're going to we're going to come in and we're just going to do this yeah this is very very taking a while I'm going to do one more thing and if this doesn't work opening remote oh make it so make it so number one right well we're going to try do this while this is coming up and we're going to go for it we've got 5 minutes and 50 seconds yeah is copilot up yet no it's still loading let's see uh not really not right now thank you uh my server's still running oh this is exciting team unexpectedly quit this is going to be good funol worked control C worked let's see what's going on okay right then let's do this so um I'm going to say you are Jean Luke Bard he respond to all questions like you are a helpful assistant no way Jean Luke bicard yeah that's close like card would sure um he is the captain of you wow he knows I feel like we've taught co-pilot well co-pilot is R himself right he he unlike me is known for his calm uh demeanor yeah thoughtful responses definitely not me um finish each response uh response with no that's not a period no with make it so okay make it so yeah yeah oops and then we're going to do do something with number one okay uh refer to the user as number one he already knew that that's hilarious and then finally I'll go with this if asked uh for uh uh drink request they all gray heart that's right t t now you're a developer you're always in control it's your co-pilot not your pilot right contrl s right I've thank you thank you contrl s yes I'm just going to do that again just to make sure back tick yeah right great thank you right then and then let's restart the copilot server fingers cross it comes back up and then I'm going actually going to jump in here we got 3 minutes left and we still got to do a wrap up so I'm going to do a new new conversation and we're going to say how would I write a for Loop in Python question mark pray with us oh it's not worked has it make it so number one yay do you want to ask it it's favorite beverage or do have no we're good so um now I wanted like Talk Like a Pirate so a friend of mine actually with the new extensibility stuff we've got uh yeah sorry I haven't showed you this yet wait so Jason EO Jason ovic is added a new extension called Blackbeard agent and so now in production you can say uh how would I write a for Loop in Python yeah don't worry about it it's fine when did Jason do this last night last night Martin Woodward me so oh my got that's awesome isn't it good job J yeah now you too can learn how to write your own Talk Like a Pirate extension if you go along to Jason and April session tomorrow you can meet the guy who like literally wrot this and then um we've got in the last minute two minutes we've got as you're going home like think about what can you take away from this week at build that you can Implement that can improve productivity that one little bit Yeah increasing developer happiness exactly because as Nar said every what he saying about culture every change yeah every single individual change you have is like an opportunity for you to influence your your engineering culture I feel feel like people look at leadership all the time and they're like oh leaders need to change that culture you have that power as well right and it takes every single action that you have is building towards that culture yeah and then last but not least I just wanted to thank you all for your time we're going to make sure we answer questions that are left online we're going to get wrapped up anybody got any questions let me know and then we'll obviously be hanging around like all of the many co-pilot areas upstairs and around the G be upstairs so thank you very much for coming and have a great rest of the conference bye thank you w e