 This talk is called Code First. Ask questions later. My name's Tim Clam. I'm a developer at GitHub. I was actually born and raised here in Boulder, Colorado, but I live in San Francisco now. This is a talk about money and managers. It's about building community. It's about shipping software. It's about creating culture. It's about how to communicate and how to get things done on a daily basis. Obviously, this is also a talk about GitHub and kind of questions that I answer informally all the time. About how GitHub works on a daily basis. And this is also a little bit of a talk about Hubot. But I'll explain more later. First, I'm going to slightly redefine the word code for the purposes of this talk. Most of you probably think of this when you think of code. You're in Emacs, or you're in VI. Hopefully, you're getting the right Ruby on a daily basis. Maybe it's some JavaScript or some copy script. But I also want to include this. Any sort of design activity, whether it's Photoshop or Illustrator, or whether you're simply doing illustrations on paper or scribbling on a whiteboard, pushing pixels around on a web page, or like the talk earlier, just finding room for white space and thinking about the world in a different fashion. I also want to include this in my definition of code. Anything that where you're making or building, hardware hacking, this is an Arduino board. We have a weekly hardware hacking session at GitHub. And here is Tom making the world's tiniest speaker cone to make the world's most annoying noises. This is a little extension of Hubot in the office that's come out of this. So my definition of code really means building shit. And I really could have titled this talk, build shit first, ask questions later, but then maybe they wouldn't have accepted it. So the key really is building something. Taking that step into doing something, build anything. Because once you start building, then you have a very different perspective on the problem. And I'm not saying that you necessarily need to go into a dark room for six months. In fact, I'm arguing exactly the opposite. But I think there's a very essential step about really doing, I love the Walt Disney clothes from the first presentation today, stop talking and do something first, take a step. So at GitHub, one of the things that we do is we put a huge emphasis on ownership. And I think this comes in really two separate forms. Number one, you have to be able to take ownership. And this is what it means to step in, to pull out the debugger, to write a line of code, to step up in a Hackfest and meet someone that you don't know, and maybe be embarrassed because you aren't as good at Ruby as you may have thought you were, but to learn something and to be there. But what's really important in startups is that in order to take ownership, in many cases, someone has to give you ownership. And this is what I think is so unique about how GitHub operates is that the founders of the company created this amazing thing and built this community. And there's such a temptation when you do that to want to hold onto it. And to be like Steve Jobs, where you're emailing someone in the middle of the night to change the gradient on something for a public-facing thing because you have to control every little detail. And that works for some of those people, but honestly, I don't want to work for a company like that. And so one of the greatest things that GitHub does is they give people total ownership. And this is a very powerful thing. So part of what we really talk about a lot is running your company like an open-source project. And you always get the immediate pushback of how could we possibly do that? There's no way that we could ever run our project like an open-source project, or run our company like an open-source project. And I'd like to pursue the argument just a little bit. Open-source happens on a daily basis. It's global, it's around the world. There's a variety of developers working on this project. There's no one necessarily telling them what to do or what to build and what create. And yet, bugs get fixed, code gets built, features get implemented, version gets shipped. Sure, some are better than others, but it's this evolving ecosystem. And in many ways, we try and run GitHub on a daily basis like an open-source project. The main goal is to reduce friction. So at GitHub, we have no managers, total flat org structure. There's no specific PTO. We have no vacation days. There's no time off. There aren't even specific work hours. You can hack at 3 a.m. in the morning, if you feel like. I'm an early riser, so I'm usually in the office around 7 or 8 in the morning. We don't have any official meetings, although we do get together on a semi-annual basis and hold what we call a summit, where we give presentations about things that we love. Sometimes there's a code, sometimes it's otherwise. And all of our developers and designers, which is most of the company at this point, everyone who's full-time makes the exact same amount of money at GitHub. There is no salary differential across this. And it's enough where we take money off of the table. We're also very open, not only about how we work and how we distribute code to the community and the things that we open source, but we're very open internally. Things like, man, how much money are we making right now? Like, are we doing well? Are we doing poorly? Is this jobs thing actually bringing in revenue or is it losing? Being open is super essential to this. And the other half of that is back to this ownership, is take charge. And taking charge, and part of taking charge means that you have full access to everything. If you wanna kick off a new project, if you wanna start selling physical goods at GitHub, or you wanna do hardware hacking, or you want people who are using Arduino to use GitHub, the onerous is on you to make that happen, and you are given the tools to make that happen. All of this creates this culture of really iterating quickly. And by coding first, asking questions later, you end up with this very short cycle of being able to get things out in the open and in the public. Maybe it's just to your teammates at first, but then immediately turning around, talking about it, revising it, ship, repeat, rinse, it all happens. So there is a word for this, and Lockheed Martin I think has this locked up in trademarks, but there are other businesses and other organizations who run themselves like this. And I think Skunk Works, the name came out of the 1940s, Lockheed Martin. They were building things like this, some sort of bomber of sorts. And what they did is they found that if they took a group of people, a team of very intelligent, these were engineers and designers, like all of you guys, and they cut away all the red tape and took out all the bureaucracy, that this team, and these are large teams of people, this is a very complex project, actually ran way more efficiently than anything else in the company. And so what we try and do is create an environment like that at GitHub. Daniel Pink has an interesting book out called Drive right now that talks about these last three things here, autonomy, mastery, and purpose. And his argument is that in the old world of business, we really were focused on these extrinsic motivators and carrots and sticks are the words he used, so salaries and then punishments for things that you do or don't do well. Whereas in a creative field, the research actually shows that having these kind of extrinsic motivators actually makes you less creative, less affinitian and do worse work on a daily basis. So instead, we need to create these intrinsic motivators. We need to give people autonomy. We need to let them master things. So choosing what you wanna work on, choosing stuff that you're excited about working on. And in many ways, because you guys are in the Ruby community, you've already sort of taken that step, right? You're not writing Java code anymore. You may be building enterprise applications, but you're doing it in a language that you like to write on a daily basis. And then giving purpose. And there's still, I think, to tie it together, there's gotta be a higher level purpose to what you're doing. So one of the biggest things that GitHub also does on a daily basis is all of our communication is asynchronous. And I feel like I can't communicate to you exactly how important this is. This is like no other organization that I've worked for. Meeting stuck. Now, there is a time and a place for this, and there is, you need to communicate well with people, but the general concept of a meeting is about the most unproductive thing for your organization you could be doing right now. It is like a global lock. It's like the garbage collector is running, and everybody is stuck and has to be at the same place at the same time talking about the same thing. It's extremely inefficient. We are also a distributed teams. We have developers in Australia. We have a guy who's living and working out at Japan. We have people in Finland and Germany, all over the United States. And most of the get-hubbers actually live in San Francisco, but none of us come into the office at the same time during the day. So asynchronous communication is essential for a distributed team. And this gets back to some of the very first things. You know, we did a little meditation this morning. This idea of focus is so essential for you as a creative individual living in an industry where you are writing code and doing design. And you have to maximize in order to take advantage and be in a place where you can focus. So pull requests, I feel like, are the most underrated feature on get-hub. And I find over and over again that people are using these to the bare minimum that you can do with them, if at all. It's surprising to me how many people I walk up to who have never created a pull request before. So at the end of the day, a pull request is just a conversation that starts with code. And the traditional use of the pull request is you saw an open source project. It needed a feature or had a bug, and so you forked it, fixed whatever it was, wrote some tests, and then submitted a pull request. I challenge you guys to actually use pull requests on your own repositories. So you don't need to have a fork. You can do a pull request in a single repo. Create a topic branch and push it to the server, and from that topic branch, you can create a pull request. The other thing I encourage you to do is don't create a pull request when you're finished. Create it immediately. As soon as you get that up there and in this place where you wanna start talking about what you're doing, start the conversation, create the pull request. Now the other great thing about pull requests is as you continue pushing code to this branch on the server, those codes, those commits come in line as part of the conversation. And so I can say, yes, no, this is, I love what you're doing here. You need to fix this before it's allowed to go out live. Oh, we're not allowed to do that, but I like what you're doing. And you start to get this pulse. You start to get in that cycle of really iterating quickly on code. ScotchaCone actually just this week, everyone's leading up to this talk in a wonderful way, released a really brilliant blog post on how we use get and how we use pull requests on a daily basis. And I encourage you, hopefully these slides will be available somewhere. If you haven't already read this, please go check it out. The other thing we use on a daily basis is Campfire. And it doesn't matter that it's Campfire, it could be IRC, it could be any form of group chat. But the key is that you need to have a public searchable record where you're having a conversation about whatever it is that you're building and working on. And so we live in Campfire. If you, it's very disconcerting, like my wife walks into the office at GitHub and nobody is talking to anybody. And it's because our conversation is going on here. And the key advantages to that is I'm traveling this weekend on the airplanes and out of hotels. And I'm not sitting working with everyone. I'm not in the same time zone as all the other developers. But at the end of the day or in my spare hours, I can go see exactly what happened in the company. And I can read back through the transcripts and I can see who's working on what, what branches were pushed to the server, what code was deployed to production, what support requests came in, what bugs were fixed. And all of a sudden I'm up to date again. I didn't have a meeting. I didn't have to get, have a daily scrum meeting. And none of this stuff had to happen. And for me to be in sync with the organization. The other thing we've done is we've robot-enhanced our campfire room. And so we're gonna go through a little bit of some of the things that I love the most about Hubot. So Hubot is a Node.js process that kind of participates on campfire as a user. And he listens to a variety of commands. So the first thing you want when you have a robot is you gotta make sure he knows the rules. So if you ask, if you ask Hubot what the rules are, he very graciously makes sure that he's not gonna explode and attack us in the middle of the night. One of the most useful things that Hubot does is he is the interface between our build server and all of these branches of code that we're working on. So we have a very feature branch-driven development strategy. And anytime you create a branch and push it to github.com, we have this janky over here is a connection between Hubot and our CI server. We use Jenkins. And what happens is as soon as you push that branch, we immediately auto-configure Jenkins to set up a new build and run all the CI for that new branch. And so with master being basically the deployable set of code, master is what is out on github.com right now, plus or minus maybe 20 minutes to an hour or so. This is brilliant because I can see, you can't see too clearly here, but I can see that Josh is, he's working on something. And it's not quite there yet. He broke a couple of tests. But I have a link to the build blog so I can go see what tests he broke and what's happening. I have a link to the compare view so I can see a diff of what code was just checked in. And then I can see very clearly, here is the commit messages of what he's working on. And this happens anywhere in any of our repositories on github if you create a branch and push code, a build is automatically created and configured and run for you. The other thing that we do is we actually deploy code through Hubot. So here you can go, JP is working on something and he says, you bought the deploy GitHub to production or the cloud as I've highlighted here, which is just an alias for production. And the joy of this is now when I come back in at the end of the day and read the transcripts, I can see what JP was doing. Not only that, but I can go click on this compare view and I can see, oh, this is the code that went out there. And so you end up with this incredibly iterative cycle for the way that code goes out live on the site. And so we don't do release versions. We don't have anything like that. We push code out 20, 30, 40 times a day. And not just the developers, but support guys and designers and people within the site. You're basically given the keys to the castle on your first day of work at GitHub. The other thing that kind of is a useful corollary to this is if you are about to push something out on the site, you can say, Hubot, what's not deployed? And you can give them a branch and there's all sorts of other fancy syntax on here. But basically you're gonna get back a compare view and you're gonna be able to see, here's all the code and sometimes people try and sneak in things into master so it's always good to see whose code you're actually pushing out right now and who to yell at if it breaks something. We have some other interesting things that are less talked about. There's a provision me aspect to Hubot so we can actually spin up servers on Rackspace and AWS via knife and puppet, all via Hubot. But then there are just the fun parts of Hubot. So you got your basic image me, which actually I use to do things like post the drink up which you should come to tonight, 8.30 catacombs, free beer, free drinks, you're all invited. And so you can say, Hubot image me, you know, the Rocky Mountains. You can get some ASCII art back from a variety of things. Some of you were hacking on a derivative of this last night which now needs to make it into Hubot but you can put mustaches on a whole variety of things. You can ask Hubot who's in the office right now maybe to decide whether you want to come in and hack with these guys or not. So if you'll notice we've kind of hacked up campfire a little bit here as well. You can add custom JavaScript and CSS into propane and so we have kind of avatars and custom repainting of statuses and stuff. But we keep track of people's MAC addresses and see who's in the office and what's going on there. Maybe they're having a party and you want to go. You can define words. You can open the door downstairs. That was that little Arduino chip I showed you in the beginning. We have a public grocery list for stuff coming into the office that you can add things into. You can control the office speakers. You can say, you know, Hubot play me some Tribe Called Quest and he'll queue up some tracks for you and start playing them in the office. You can say, Hubot play it louder and he'll play it louder. He speaks. He does translations from different languages. And at the end of the day it's also one of the side projects that a lot of our developers like to spend a couple hours adding something in there. I think TMM was looking for apartments in San Francisco and so he's got a whole series of Hubot that searches Craigslist and all these sources and aggregates apartments and pulls back the top ones and gives them phone numbers and stuff like that. At the end of the day, GitHub really tries to create a culture of shipping. And one of the things I love is if you say ship it or if you ask Hubot if you should ship something, he's gonna send you a picture of this. And this is the ship it squirrel. And basically the concept is we wanna make shipping easy because really it's kind of the scary thing, right? Like it's the same as sitting and down and hacking with someone. You're putting something out in the world and people may love it. They may hate it. You may crash production. All sorts of bad things could happen. So you gotta make it easy and you gotta encourage people to do it. And part of making it easy is you need to do it all the time. And so by lowering the barrier and making it so that anybody can deploy the production code of GitHub through a campfire chatbot, means that I'm gonna do that and I'm gonna do it over and over again. And so we have this very greased path for the way that code moves off of our servers and out to you guys. And so a lot of times I'll find myself working on something and you say, Hubot, should I ship with this? This is what he's gonna tell you. So I think until you've tried to design, to create, to build, to develop, to hack together, until you've tried to solve the problem, I'm not so sure that your questions matter quite yet. And I wouldn't say that you need to disappear for weeks or days even, but I think you gotta dive in and write a little bit of code. Read what's going on, add a little bit, test, debug, hack, and then come back because then your questions start to really matter. This funny looking dude is one of my favorite scientists from the 18th century. A gentleman named William Herschel. He actually was knighted, so Sir William. And Herschel was an astronomer and the thing that I like most about him is that he actually built all of his own telescopes. And so this is, I think it's a replica, but this is one of the telescopes that he built. And people were overwhelmed and amazed by these things because at this time period, putting together a device of this mechanical complexity was really rather difficult. And the way he put together his telescopes was just painstakingly detailed. And you can see actually this thing's got like a stand. He can carry it around the city. He can, you know, it like unzips itself and he can basically set it up anywhere and do his stargazing. And he's most well known actually for discovering Uranus, which was originally named after King George, the guy who went, the one who went crazy. And later on in time actually got renamed. But the only reason he was able to discover some of these things is because the craftsmanship of his telescope was just ages above what anybody else was doing at the time. They tell a great story of him as he was building these things. They're reflecting telescopes. So there's a big mirror at the bottom there. And in building these reflecting telescopes, one of the hardest parts is getting that mirror just right. And he would literally spend days polishing his mirror. And once you start polishing it, you can't stop. Or it'll set up wrong and you won't get the right shape and you won't get the right clarity. And so they have these great Victorian pictures of his younger sister spoon feeding him his dinner while he's polishing these mirrors. And it's a nonstop process. Like he has to do that for 16, 24, 36 hours at a time. At the end of the career, he actually started building some huge telescopes. And so this is a 40 foot telescope that he constructed in his backyard. You can kind of see the gantry system here. It spins in 360 degrees. And then you get all these pulleys and stuff that allow him to kind of move it up and down and see in the night sky. And so what I love so much about Herschel is just that he approached the problem from building things. And out of that, out of his craftsmanship and out of diving in and really getting his fingers dirty, I mean, you think this thing almost killed him. It's like a 50 inch mirror at the bottom, 50 inch diameter mirror at the bottom of the sink that weighed like over a ton and it almost fell on him once. But because of his craftsmanship and his dedication to code, to building, to creating, he was able to find things in the universe that nobody else was. Including he even was able to identify that basically we live in a spiral galaxy and they didn't call it a galaxy, it was just everything was a nebula at that point in time. But discoveries that weren't verified officially until many, many, many years later. So I think you got to take that first step into writing code, tear down the process, get away from the meaning, but as soon as you do take that step into building something, now you can do all these things. Now your conversations really matter. Now you can talk, you can tweet, you can blog because now the feedback loop cycles. And whatever you build and put out there, it's probably not gonna be perfect the first time. And that's okay because what's gonna happen is this is gonna turn right back around and you're gonna build something else and it's gonna be better than it's gonna be around. So now your questions really matter. Ah, that's all I got. I'm Tim, that's how you can get ahold of me. I think we have time, I'd be glad to answer questions if you raise your hand high, yeah, go ahead. Absolutely. What's the current salary? I will tell you at the bar later because it's shared with everybody else. So let me summarize that real quick so everybody else can hear because I think it actually has a very good point. So the question and comment was that GitHub is in a unique position where basically we are building stuff for ourselves constantly. And a lot of you and a lot of other services, people are building code for someone else who they don't understand. And the thing that I would take away from that is immerse yourself in that domain so that you are building code for that. So become passionate about telescopes or whatever industry it is that you're writing code for. Like you should be so immersed that by the end of the day what you were building is actually something that you would love to use in that industry. And I know that everything from medical to banks to insurance and trust, like I use banking software and I use those services and I go to the doctor and I have to deal with insurance forms. So turning it around and approaching the problem from that standpoint as I own this too, I think it's still very valuable, but you're right. We are in a unique position of getting to build developer tools. Anything else? Way in the back, talk loud. That's you, yeah, I'm in the hat. That's a really great question. So originally there was only one campfire room and actually we now have, I think, up to maybe 10 and they're really focused on small projects. There is one central room that is like the core ops of the site and all important business goes through there including the github.com, Bill's dad's and that kind of stuff. Stuff like the Mac app has its own room and the issues app are all kind of in a Mac-based room and then we have a room called the danger room which is basically for goofing around and using the other obscene functionality if you bought. Does that answer your question? Sure, that is a great question too. I think, so the question was to what degree is this collaboration a product of the culture versus the people that we hire? I think it is a small combination of both. We obviously do hire great people, github, probably the smartest group of developers and designers I've ever worked with but the culture really defines it. I don't think any of us necessarily worked in an environment like this before working at github and so there definitely is an aspect of getting brought into the rush of development happening at a much faster pace than you've ever been used to and of really people saying, no, don't talk about that to me because everybody else is gonna miss out on that right now. Like don't write me an email about that. Let's talk about that in Campfire or do this in a public fashion so that almost bringing people up to speed on it. It can be a little bit disconcerting, like I think most of the individuals who work for us are highly motivated and highly individualistic individuals at this point who can really jump into our organization and understand the need and their skill set and dive in and fix something and build something and so we'll see, I think it's an interesting experiment as the company grows to see how this scales but there's some huge open source projects that still operate on these principles and do very, very well, so great question. So the question is, do you do individual work or do you pairing or do you do group work? I would say by and large we work in small teams. The core website maybe has the most people working on it short of FI has been getting a lot of attention recently. I don't, we don't do a lot of like direct pairing as a specifically scheduled activity but I do sit next to people and write code periodically. The collaboration I would say in the most, our teams are like two to three people.com is maybe up to eight to 10 at a time working on the main site, so correct. So the question was, is pull request a substitute for pairing on ours on end? I don't know if I would say a substitute but I would definitely say there's some major advantages to the asynchronous nature of pull requests. There's still nothing quite like sitting next to someone and watching them type and learning how they use their tools and I think you glean a lot of information just by observing that but a pull request, some of that same stuff happens but it can happen with someone who lives, you know, 16 hours time difference from me and so I have the opportunity to connect with a developer that I wouldn't otherwise have sat next to and done it and they're very, pull requests are very living documents, it's like a living code review. You know that diff is constantly changing as you're working on that pull request. It isn't this like yes or no, this pull request comes in or comes out of that code base. Sure, pretty open. I mean I would say, sorry, keep repeating questions here. So the question was how do we deal with a very loose time structure and I think it was surrounding, you know, people who wanna work 10 hours or 12 hours versus who wanna only work their eight hour day. Nobody really tracks it or watches it and the GitHub crew travels quite a bit and so people are in and out of the office and I tend to come in early as I said so I usually come in to work because I think best in the morning and then go home, I go climbing in the afternoon and I go home and I play with my kid and say hi to my wife. Some people, I mean, you know, to Mako you'll like find him sleeping on the couch because he fell asleep at the office because he was up acting till three in the morning because he was excited about something. So there's no, nobody's really looking over your shoulder. You can look, it's really interesting to look at some of the like impact graphs of people at GitHub and what they're working across all of our repos and as far as I can tell right now I mean, everybody is hammering away on stuff like this. It's just not police, it's not a concern we're not taking, time doesn't, time is meaningless. Like it doesn't really mean anything to us, so. Things are, yeah, we keep shipping stuff and so I think like that culture of shipping those are very, because we do those in very incremental and very quickly those are kind of the measures of oh, this team, these guys did this and they did this and you know we have a new version of this and so that frequent shipping almost gives you a pulse on what everybody else is up to in the company. Sure, right here. The question is how do you handle staging versus production and kind of the interface between them? So we do have a staging setup. The staging setup is all virtualized and so we have a way of like shipping subsets of the production data into staging and testing. To be honest I would say we actually ship more to production than we do to staging. Our master branch is really deployable code. So if stuff's on master, like it should be ready, ready tested passing green, ready to go out the door. Master gets deployed, you know, it's probably within the hour at most. Our deployment strategy, it's a zero time, downtime deployment, a lot of code deployments take less than 10 seconds to make it live on the site and we can target different front ends to test things out. So you can say like QBOT deploy this to production, whack FE1, FE2 and then watch like exceptions and Twitter and support and see if like people are yelling or you're getting a high exception rate on that particular code and then you would maybe do a full deploy out across the whole stack. So it's a very, it's a very, almost the way you write, like the way you would write a test and immediately be able to run, debug and see what was wrong, that's kind of how we do deployment as well and another advantage of that is that when issues do come up, when we do have security issues identified or whether there are major bugs, we can often fix those in a very quick time. I do a lot of support for the API and it's what I've worked on recently and people are always like, I usually respond to the support with I fixed your bug, sorry, here you go and it's like literally within 20 minutes of them reporting it and they're like, what, oh my gosh, how did that happen so fast? So does that answer your questions over here? Okay. So the question was do we use feature flags? We use pull request in branches. We often deploy features just to staff first or staff and friends and then run them for significant periods of time in production where only if you have a staff flag are you actually allowed to see it. So issues two, for example, we'd been running that for months. We actually used issues two to develop issues two basically. That was kind of internal feedback there, so, wait. The question is does the Balmer Peak effect GitHub employs a lot? There usually is a very good sampling of fear on tap and always whiskey, because a few of us are whiskey lovers. Some of the hardware hacking recently, actually my latest hardware hacking session I was building, it was actually, we can get breathalysers that plug into our twinos. So we were playing around with the idea of if you put those on the desks and had people breathing whether you could graph out the current status of GitHub employs and whether we were hitting the peak on a Tuesday afternoon. How am I doing, Marty? And on that note. Yes. Thank you, Tim.