I joined GitHub as an intern back in 2018. Eight years later, I’ve left the company.
GitHub was my dream job as a computer science student. It was probably my third most used website (after Reddit and Stack Overflow), and the day I got my internship offer was one of the best days of my life. I got the opportunity to help shape the way people program and give back to the open source community.
What kept me around was how often the work changed. When I joined, GitHub was mostly where you put your code. Then came Actions and Codespaces, and eventually Copilot came around. I spent about six and a half years there, all on Product Security. We shipped new products and features nearly every month, and it felt like we changed how we worked almost every week.
The last 18 months, when I worked mostly on Copilot and GitHub Next, were the most interesting of my career. Building new AI products on a platform people already depend on is really hard! But I learned a ton about security, product, engineering, and even sales from the people I worked with.
Leaving GitHub was a hard decision. But when I got the chance to work with some folks I’d wanted to work with for years, I had to take it. I will always miss GitHub, but I’m excited for what’s next.
I got my start at GitHub, and a lot of what I think of as “how I work” is stuff I picked up there. Here are three things I’ll bring with me to the next job.
1. “Product” Is the Hardest Part of Product Security
Some of the hardest decisions I made in Product Security were about what the product should do in the first place.
For example, which APIs should be off-limits to a coding agent? The answer depends on what you want the agent to do and who you’re building it for. These were some of the hardest product discussions we had.
One thing we did at GitHub to support our product partners was restructure our security reviews around three sets of requirements: one for internal staffship, one for individual users, and one for enterprise customers. The security bar stayed the same for all three. The policies we had to enforce depended on the audience.
2. Ship to Learn
When I started in Security, the idea of shipping early and often terrified me. I got more comfortable with it once I saw how much we could learn from putting our own tools in front of engineers.
We worked this way on our own internal tooling. We iterated super quickly on small MVPs like our Threat Modeling Agent, vulnerability discovery pipeline, and OSINT scanners. Once they showed some promise, we put them into production.
We once rolled out a linter that flagged way too many things that weren’t problems. That rollout taught us a lot about running linters in GitHub Actions workflows, and we put what we learned to use on the next project.
When we worked with product and engineering, my team separated need-to-haves from good-to-haves early in the review. That helped us focus on what had to ship first and keep track of improvements for later. In discussions across GRC, Security, and Legal, we spelled out what was required for launch, what was at stake if we skipped it, and what we recommended.
3. No Problem Is Too Small to Solve
One of my favorite things about GitHub was how easy it was to work across teams. If you saw something you wanted to fix, you could send a Slack DM, open an issue, or put up a pull request yourself.
In Security, we started a program called Papercuts to fix the small security problems we ran into across GitHub. Engineering teams didn’t always have time for those defense-in-depth fixes, so we picked them up. We built a library to prevent server-side request forgery (SSRF) and worked on route collisions and name squatting on the main platform.
We wanted it to be just as easy to ask Security a small question. We redesigned our reviews so engineers could ask any question in their own words, even if all they had was a half-formed idea. When we helped someone get unstuck, they were more likely to come back the next time while they were still figuring out what to build.
Farewell, GitHub! I’m glad I got to work here.