Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

Most famously known as "eating your own dogfood," the process of building our products using our products is key to culture at GitHub. It allows us to learn and experience what you will feel, because if it doesn't work for us, or doesn't behave the way we'd expect, then it's not ready to be shipped. Through internal hackathons, computer clubs, and internal feature requests, we focus on creating products built by and for developers.

In this episode of Beyond the Commit, [__Neha Batra__](https://github.com/nerdneha), VP of Engineering at GitHub, joins host [__Christopher Harrison__](https://github.com/geektrainer) to talk more about this developer-first approach and embracing the idea that if features don’t feel right for us, they won’t feel right for you or your developers either.

<div class="embed-responsive embed-responsive-16by9">
<iframe title="How new GitHub features are born | Beyond the Commit" src="https://www.youtube.com/embed/UzF2AvPbeS4?si=ysPZgSfSj7j6ykdT" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

Many features have been born out of developers discovering pain points. Take [merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue) for example. We wanted to be able to ship faster and reduce the potential for one pull request merge breaking a later one, so we developed an internal tool to support this need. From there, we asked ourselves if others could benefit from this feature, and if so, we’d ship it. And thus merge queue was shipped.

We keep the spirit of "computer club," a group of passionate geeks, alive and well. We allow Hubbers to self-identify their interest in a feature or product, provide early access to features, and look to work their feedback into the product. [Codespaces](https://github.com/features/codespaces) came about from a computer club, and some recent Copilot features have followed the same path.

A remote-first organization since our founding, GitHub has developed a comprehensive set of communication practices to support asynchronous, scalable, and inclusive collaboration. Drawing from the open source community’s emphasis on documentation and asynchronous workflows, GitHub has formalized these strategies into a public guide called "[How we communicate](https://github.blog/engineering/engineering-principles/how-to-communicate-like-a-github-engineer-our-principles-practices-and-tools/)." Many of these practices have been adopted from [innersource](https://github.com/resources/articles/software-development/innersource).

By using tools like issues, pull requests, and discussions—not just for code, but for planning and team communication—we've built a culture that values transparency, autonomy, and adaptability. This framework was created through collaboration across over 100 engineers, establishing guiding principles such as “Be asynchronous first,” “Write things down,” and “Make work visible.” In this episode of Beyond the Commit, we share these GitHub best practices and how you could enhance the way your organization creates software.

To learn more and continue your journey, explore the resources below:

## Insights

- [How to communicate like a GitHub engineer: our principles, practices and tools](https://github.blog/engineering/engineering-principles/how-to-communicate-like-a-github-engineer-our-principles-practices-and-tools/)  
- [How to build an enterprise LLM application: Lessons from GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/how-to-build-an-enterprise-llm-application-lessons-from-github-copilot/)  
- [How GitHub uses merge queue to ship hundreds of changes every day](https://github.blog/engineering/engineering-principles/how-github-uses-merge-queue-to-ship-hundreds-of-changes-every-day/)  
- [How GitHub harnesses AI to transform customer feedback into action](https://github.blog/ai-and-ml/machine-learning/how-github-harnesses-ai-to-transform-customer-feedback-into-action/)  
- [GitHub's Engineering Fundamentals program: How we deliver on availability, security and accessibility](https://github.blog/engineering/engineering-principles/githubs-engineering-fundamentals-program-how-we-deliver-on-availability-security-and-accessibility/)  
- [An introduction to innersource](https://github.com/resources/articles/software-development/innersource)

## Docs

- [Managing a merge queue](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)  
- [What are GitHub Codespaces?](https://docs.github.com/en/codespaces/about-codespaces/what-are-codespaces)  
- [Configuring issue templates for your repository](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.


From innersource, to computer club, to eating our own dogfood, this is how we build GitHub on GitHub.

beyond-the-commit

Resource Page for /beyond-the-commit/building-github-on-github

Beyond the Commit: Building GitHub on GitHub

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

We all know the importance of quality code. It makes code more readable and maintainable, and just generally [improves the developer experience](https://resources.github.com/developer-productivity/) (DevEx). So, when we introduce a tool like [GitHub Copilot](https://github.com/features/copilot/copilot-business?ocid=AIDcmmb150vbv1_SEM__k_Cj0KCQjwrPHABhCIARIsAFW2XBO1Xzs4qeSwyjMImzEXmxKI0u0JoZJL8zTEawm0guFixPgH9m2spgEaAqKJEALw_wcB_k_) into the code creation process, it’s critical to ensure that it maintains our same quality standards. What does the research tell us about the impact GitHub Copilot has on code quality?

<div class="embed-responsive embed-responsive-16by9">
<iframe title="How GitHub Copilot improves code quality | Beyond the Commit" src="https://www.youtube.com/embed/R03lvlbbREY?si=hpHMCZMcfLhOX2SY" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

__[Jared Bauer](https://github.com/jaredsb)__, GitHub staff researcher, [commissioned a study](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-code-quality/) to explore this exact topic, and joined host __[Christopher Harrison](https://github.com/geektrainer)__ to share his learnings. In a nutshell: happy developers create better code, and GitHub Copilot is effective at helping developers write better code.

To test the impact of Copilot on code quality, Jared’s study involved 202 experienced Python developers who were tasked with creating APIs to pass a set of unit tests. The study ultimately demonstrated that those who used Copilot were more likely to create code that passed all the tests put forth.

But passing tests doesn't tell the full story about code quality. It's not just about the code operating correctly — it also needs to be readable and maintainable. Measuring this requires code reviews, which was the next part of the study. All valid submissions were blind reviewed, where reviewers did not know what tools were being used to create the code. THe study found that code created with the help of Copilot was more likely to pass code reviews by over 10%: a statistically significant percentage.

Additional insights were gleaned from the study, including the fact that developers with Copilot both generated, but also deleted, more code than those who didn't use Copilot. The theory behind this behavior is that Copilot allowed developers more time, and gave them confidence to refactor their code to ensure it was of the highest quality possible.

To learn more and continue your journey, explore the resources below:

## Insights

- [Developer experience: What is it and why should you care?](https://github.blog/enterprise-software/collaboration/developer-experience-what-is-it-and-why-should-you-care/)  
- [Research: Quantifying GitHub Copilot's impact on code quality](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-code-quality/)  
- [Does GitHub Copilot improve code quality? Here's what the data says](https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/)

## Techs

- [GitHub Copilot](https://github.com/features/copilot)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.

Are we getting code developers can be proud of?

e65d7f237a3ee8a5bcf2a7a8afb28972c071a131a86a0e75c285b10b952a7a31-1920x1080

Resource Page for /beyond-the-commit/copilot-code-quality

Quality is key: GitHub Copilot and code quality

Published via [GitHub Executive Insights](https://github.com/solutions/executive-insights "Executive insights, curated just for you")

The traditional approach to measuring productivity, and in turn velocity, is the number of lines of code. It's the most straightforward way to both understand and collect from a data perspective. Unfortunately, having this as our primary focus is a flawed approach. It both incentivizes the wrong behavior and doesn't provide a full picture of what a developer does in a day.

<div class="embed-responsive embed-responsive-16by9">
<iframe title="Beyond green squares: Effectively driving productivity" src="https://www.youtube.com/embed/5i9UGeCwl5s?si=TK05djX_-e1GFDR_" width="640" height="480" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe></div>

In this episode of Beyond the Commit, __[Eirini Nathan](https://github.com/ikaliam)__, staff researcher at GitHub, sat down with host __[Christopher Harrison](https://github.com/geektrainer)__ to help us better understand developer productivity. She explains that no developer sits down for a day's work with a goal of writing a certain amount of code. Instead they work to implement features, fix bugs, and design architectures — activities that aren't reflected in the green squares that appear on a developer's profile.

There are established frameworks, such as [DORA](https://dora.dev/) and [SPACE](https://queue.acm.org/detail.cfm?id=3454124), which are designed to provide a holistic overview of productivity. However, if you're new on this journey, these might not be the best approach. A better place to start is figuring out what goals you’re trying to meet by measuring, then have conversations with developers to determine any barriers they may be facing.

During the episode, Staff Product Manager __[Bronte Van der Hoorn](https://github.com/brontevdh)__ calls in to add her perspective on the importance of goals. After all, it's impossible to determine success if there isn't a clear definition of what success looks like. Once you establish goals, you both have a direction and a topic of conversation for your developers.

Talking to your developers should take many forms, including surveys, focus groups, and one-on-one conversations. Eirini recommends taking a three-step approach: listen, act, and learn. As you talk to your developers, listen to their experience and the blockers they face. Act on that feedback, working to make changes to improve both the developer experience and their productivity. Finally learn from that journey, see what worked and didn't, then make the appropriate adjustments.

To learn more and continue your journey, explore the resources below:

## Insights

- [Developer experience: What is it and why should you care?](https://github.blog/enterprise-software/collaboration/developer-experience-what-is-it-and-why-should-you-care/)   
- [The ultimate guide to developer happiness](https://github.blog/engineering/engineering-principles/the-ultimate-guide-to-developer-happiness/)   
- [Yes, good DevEx increases productivity. Here is the data.](https://github.blog/news-insights/research/good-devex-increases-productivity/)  
- [Survey reveals AI's impact on the developer experience](https://github.blog/news-insights/research/survey-reveals-ais-impact-on-the-developer-experience/)  
- [Research: quantifying GitHub Copilot's impact on developer productivity and happiness](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)

---

Want to learn more about the strategic role of AI and other innovations at GitHub? Explore [Executive Insights](https://github.com/solutions/executive-insights) for more thought leadership on the future of technology and business.

Before we can determine the impact of tools on productivity, we need to ensure we're asking the right questions.