Asynchronous Communication
Code First, Ask Questions Later
Edit
#open-source
#github
#engineering-culture
#asynchronous-communication
#teamwork
#developer-experience-dx
#ruby-on-rails
Summarized using AI

Code First, Ask Questions Later

Tim Clem • April 07, 2015 • Earth

The video titled "Code First, Ask Questions Later," presented by Tim Clem at the Rocky Mountain Ruby 2011 event, provides insights into GitHub's unique approach to software development and company culture. Clem emphasizes the importance of building quickly and iterating effectively, redefining the concept of 'code' beyond just programming to include design and hardware projects. The video outlines GitHub's operational principles, which resemble those of an open source project, focusing on the following key points:

  • Ownership and Community: At GitHub, ownership is crucial. Employees are empowered to take initiative, participate in hack fests, and learn in an environment designed to grant autonomy without overwhelming oversight.
  • Flat Organizational Structure: GitHub operates without managers and formal vacation policies, allowing for flexibility in work hours and reducing bureaucratic friction. Everyone has equal salary, which fosters collaboration and transparency.
  • Open Communication: The company culture encourages openness in sharing information, including financial data and project statuses, which helps maintain transparency and trust within the team.
  • Rapid Iteration: By adopting a fast cycle for development, GitHub enables frequent code deployments (between 20 to 40 times a day), which helps in refining features through continuous improvement.
  • Use of Technology: Tools like Hubot facilitate automation and streamline tasks, such as code deployment and server provisioning. Clem highlights the importance of asynchronous communication for their distributed team, which avoids bottlenecks associated with meetings.
  • Pull Requests as Communication: Clem argues that pull requests are underutilized yet critical for ongoing discussions about code changes and feedback, providing a living documentation tool for collaborative development.
  • Culture of Innovation: By prioritizing intrinsic motivators such as autonomy and purpose, rather than extrinsic rewards, GitHub fosters a creative environment where employees can thrive and contribute meaningfully to projects.

The conclusion of Clem's talk encapsulates the essence of GitHub's approach: engaging hands-on with one’s work leads to more valuable insights and contributions. He encourages attendees to embrace challenges and be proactive in their engagements with code and design, ultimately leading to productive solutions that resonate with their passions.

Code First, Ask Questions Later
Tim Clem • April 07, 2015 • Earth

Ever wonder how software is designed and developed at GitHub? Are you curious about how new features are deployed to the site? (Hint: ask the robot.) Want to know why we don't have any managers and don't track vacation days?

This talk will explore running your company like an open source project and give some insight into how GitHub continues to leverage ruby and other open source tools to keep up with massive data loads and a growing community of users.

Rocky Mountain Ruby 2011

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.
Tim Clem
@misterfifths
Explore all talks recorded at Rocky Mountain Ruby 2011
+14