00:00:09.320
This talk is called "Code First, Ask Questions Later." My name is Tim Clem. I'm a developer at GitHub. I was born and raised here in Boulder, Colorado, but I live in San Francisco now.
00:00:15.320
This is a talk about money and managers. It's about building community, shipping software, creating culture, and how to communicate and get things done on a daily basis. Obviously, this is also a talk about GitHub and the kinds of questions I get asked informally about how GitHub works.
00:00:27.080
First, I'm going to slightly redefine the word "code" for the purposes of this talk. Most of you probably think of code in terms of writing it in Emacs or VI, hopefully writing Ruby on a daily basis, or maybe some JavaScript. However, I want to include any design activity, whether it's in Photoshop or Illustrator, or simply doing illustrations on paper or scribbling on a whiteboard.
00:00:51.480
Pushing pixels around on a webpage, or even just finding room for whitespace and thinking about the world differently, all of this fits into my definition of code. Additionally, I want to include anything related to making or building hardware, such as an Arduino board. At GitHub, we have weekly hardware hacking sessions.
00:01:15.960
This picture shows Tom making the world's tiniest speaker cone to produce the world's most annoying noises. This is a little extension of Hubot from our office. So, my definition of code really means building. I could have called this talk "Build First, Ask Questions Later," but maybe that wouldn't have gotten accepted.
00:01:58.799
The key is really to build something. Taking that step and doing something is essential. Build anything! Once you start building, you gain a different perspective on the problem. I'm not saying you need to lock yourself away for six months—quite the opposite—but there’s an important step in just doing. I love the Walt Disney quote from the first presentation today: "Stop talking and do something first." Take a step.
00:02:22.560
At GitHub, we put a huge emphasis on ownership. This comes in two distinct forms. First, you need to be able to take ownership. This means stepping in, pulling out the debugger, writing code, participating in a hack fest, meeting someone new, and possibly feeling embarrassed learning something new.
00:02:48.040
What’s really crucial in startup culture is that in order to take ownership, someone has to grant you that ownership. GitHub's founders created an incredible community and gave people total ownership. Many leaders, like Steve Jobs, want to control every detail of the company, but I don't want to work for a company like that. The power that GitHub provides is a strong motivator.
00:03:17.920
Part of our philosophy involves running the company like an open source project. You often hear resistance to this idea, with people wondering how it could possibly work. But open source development happens every day, globally, across a variety of developers. No one is necessarily telling them what to do or what to build, yet bugs get fixed, code is built, and features are implemented.
00:03:47.159
In many ways, we aim to run GitHub daily like an open source project. Our main goal is to reduce friction. At GitHub, we have no managers and a flat organizational structure. There are no specific PTO policies or vacation days. You can hack at 3 a.m. if you'd like!
00:04:02.560
We don't have official meetings, although we do occasionally hold summits where we share presentations about things we love. Our full-time developers and designers all make the same salary—there is no salary differential among us. This simplicity helps take money off the table.
00:04:17.440
We're very open, not only about how we work but also in how we distribute code to the community and what we open source. We share information internally, including topics like how much revenue we're making and whether our projects are thriving or struggling. Being open is essential to our culture.
00:04:51.720
To take charge means having access to all information. If you want to kick off a new project or start selling physical goods at GitHub or doing hardware hacking, the responsibility is on you to make that happen, and we provide the necessary tools.
00:05:07.440
This creates a culture of rapid iteration. By coding first and asking questions later, we have a very short cycle that allows us to release things quickly, whether to our teammates at first or to the public soon after.
00:05:31.320
There is a term for this approach, which I believe has been trademarked by a company, but other businesses and organizations operate similarly. The term "Skunk Works" originated in the 1940s with Lockheed Martin. They built complex projects by assembling intelligent teams and removing obstacles and bureaucracy, resulting in highly efficient operations.
00:06:03.920
At GitHub, we strive to foster a similar environment. Daniel Pink's book "Drive" emphasizes the importance of autonomy, mastery, and purpose. In the past, businesses relied heavily on extrinsic motivators, such as salaries and punishments, but research shows these negatively impact creativity.
00:06:41.600
To encourage creativity, we focus on intrinsic motivators. We grant autonomy, allowing team members to choose what they want to work on. Since you're in the Ruby community, many of you have already made that choice, opting to work with a language you enjoy.
00:07:11.440
Having purpose is equally essential. A higher-level purpose drives our work at GitHub, as we strive to create meaningful contributions. One of the largest aspects of our communication is that it's asynchronous. I cannot emphasize enough how crucial this is for our organization.
00:07:43.600
Meetings are often unproductive and inefficient; they create bottlenecks, halting creativity. We have a distributed team with developers in Australia, Japan, Finland, Germany, and across the United States, and asynchronous communication is vital for us.
00:08:18.320
I believe pull requests are the most underrated feature on GitHub. People often only use them minimally or have never created one. A pull request is simply a conversation that begins with code. The traditional method involves fixing a bug or adding a feature to an open source project.
00:08:54.800
I challenge you to use pull requests in your repositories. You can create a pull request in a single repo by generating a topic branch and pushing it to the server. Don't wait until you think you're finished; create it immediately to start the conversation.
00:09:30.560
Furthermore, as you continue pushing code to your branch, those commits become part of the ongoing conversation. This enables dynamic feedback throughout the development process, allowing for quick iterations.
00:10:05.360
I encourage you to read a recent blog post by Scott Chacon on how we use Git and pull requests daily. Additionally, we use Campfire for team communication. It doesn’t matter which platform we choose; we need a public and searchable record of conversations.
00:10:35.760
It can be disconcerting to see a room full of people not talking to each other, but our conversations happen in Campfire. I regularly travel for work, but by checking the transcripts, I can stay updated on our activities without requiring a meeting.
00:11:13.640
Hubot enhances our Campfire room. Hubot is a Node.js process that operates within Campfire, listening to a variety of commands. He knows the rules and is a valuable tool for managing tasks related to our code.
00:11:52.280
One of Hubot's most useful functions is serving as the interface between our build server and the various branches of code. We use a feature branch-driven development strategy, so as soon as you push a branch to GitHub, Hubot configures Jenkins to set up a new build and run continuous integration for that new branch.
00:12:34.040
The master branch is essentially our deployable code. It reflects what is currently live on GitHub, plus or minus maybe 20 minutes to an hour. This helps me see what others are working on and understand the status of commits.
00:13:15.560
We deploy code through Hubot—just a command away. If someone says, 'Hubot, deploy GitHub to production,' it gets done. When I review the transcripts later, I can see what happened and understand the context of the deployments.
00:13:55.560
At GitHub, we push code live anywhere between 20 to 40 times a day. Everyone—developers, support staff, designers—can deploy code from day one. If you want to check what's not deployed, Hubot allows you to do that too.
00:14:35.560
Another interesting aspect of Hubot is provisioning. We can spin up servers on Rackspace and AWS using it, automating those processes. The fun side of Hubot includes amusing commands and features for everyday office tasks.
00:15:20.480
We keep track of who is in the office, and we even have fun components like remote-controlled office speakers. GitHub aims to cultivate a culture of shipping by making it easy to push code live, encouraging frequent releases.
00:16:08.000
If I say 'ship it' or ask Hubot if I should ship something, he responds with a picture of the 'squirrel ship.' The goal is to lower the barriers for deploying, so it's not intimidating.
00:16:54.560
Until you've tried to create, build, code, or design something, your questions may not fully matter. You don’t need to disappear for days or weeks, but diving in and starting to build will help your questions become much more relevant.
00:17:25.840
William Herschel, an 18th-century astronomer, built his telescopes meticulously and was able to discover Uranus because of his craftsmanship. His story emphasizes the importance of hands-on experience and commitment to the craft.
00:18:08.760
Herschel faced various challenges in building his telescopes, spending long hours perfecting them. This relentless pursuit of quality led to groundbreaking discoveries in astronomy. I encourage you to emulate this approach—dive into your craft and respond to the challenges with determination.
00:19:04.560
When you embrace building, your ideas and questions become meaningful, and as you iterate, feedback will shape your work into something better. I hope you take that first step into creating something.
00:19:49.160
That concludes my talk! If you have any questions, feel free to raise your hand.
00:20:13.720
I'd be glad to answer any questions you might have.
00:20:23.720
Regarding salaries, I won’t disclose specific figures here, but I’m happy to share that privately.
00:21:03.720
A question was raised about GitHub's unique position in developing tools for ourselves. I believe it’s important to immerse yourself in the domain you're working in.
00:21:14.720
You should become passionate about the industries you work with—to the extent where what you're building is something you would want to use.
00:21:41.440
Regarding communication, there are dedicated Campfire rooms for different projects that allow specialized discussions.
00:22:06.040
We have a balance between hiring exceptional individuals and fostering a collaborative culture that facilitates rapid development.
00:22:44.880
Small teams typically work together, executing tasks either individually or collaboratively. Although there's no structured schedule for pairing, many of us sit nearby and work collaboratively involving your peers.
00:23:14.080
Pull requests serve as a form of living documentation, providing a continuous dialogue on code development, even allowing contributors worldwide to engage asynchronously.
00:23:36.320
At GitHub, our teams operate without rigid time structures. We prioritize productivity over hours worked. That culture of shipping and iteration allows us to gauge our impact beyond time.
00:24:00.960
In terms of staging versus production environments, our master branch represents our deployable code. We maintain a swift, efficient deployment process, moving code live within seconds.
00:24:33.760
We deploy based on features through pull requests and internal feedback systems, often pushing code that’s been tested and reviewed within or related to specific branches.
00:25:09.440
Our flexible working environment includes enjoying individual work styles, which often leads to productive output, helping us ship innovative features and improvements.
00:25:47.760
Hubot aids our deployment processes, automating tasks and enabling developers to push changes smoothly. Our ‘no downtime’ approach means releases pose minimal disruption.
00:26:36.960
We use pull requests strategically, allowing early feedback as features are developed, ensuring everything aligns seamlessly with our expectations and quality standards.
00:27:12.240
Our flexibility extends to our casual work culture, where hours worked aren’t closely monitored. It’s not unusual for team members to follow their creative instincts and work hours that suit them.
00:28:04.960
Finally, our office culture embraces camaraderie—sometimes leading to humor-filled discussions about productivity, including entertaining ideas like using breathalyzers to gauge work morale.
00:28:51.200
Thank you for your attention! I hope this talk inspires you to engage more with your craft and to tackle the challenges ahead with creativity and confidence.