"Don’t Learn to Code" Is WRONG

In this interview, Thomas Dohmke traces his path from a bootstrapped app startup in Stuttgart to running GitHub, the world's largest developer platform. He explains how a 2008 Steve Jobs keynote prompted him to quit his job at Bosch, describes how GitHub began building Copilot the same month GPT-3 first appeared, and unpacks why GitHub's remote-first culture is a deliberate design choice, not a pandemic adaptation. He also lays out a three-part prescription for coding in the AI era that he believes will be just as essential in 2025 as the fundamentals were when he first opened a C64 in the early 1990s.

My name is Thomas and I'm a developer. I've been developing software since the early 1990s, and today my role is mostly being the GitHub CEO, leading the largest developer platform on this planet.

I was born in 1978 in East Berlin, when Germany was divided into two countries. I was on the eastern side, in a suburb called Matsan. I had a normal childhood but was fascinated by technology: remote control cars, little computer games. In 1989 the wall fell, and that opened up a whole new world to me as an 11-year-old. From a toy perspective, I got access to Lego and Mickey Mouse, but also to computers.

In the early 1990s I bought my first computer, a C64. After university at the Technical University in Berlin, I went into the automotive industry. I started working at Mercedes, back then called DaimlerChrysler, on driver assistance systems for the S-Class, and did that for a while before switching to the supplier side at Bosch, a large automotive supplier, among other things, where I worked on parking systems.

It was in 2008 that two things happened. I finished my PhD thesis, and Steve Jobs showed the iPhone SDK. Everybody wanted to build apps. At the time only Apple could build native apps, and I thought I had to build apps myself and get into that space. So I quit my job at Bosch at the height of the financial crisis in late 2008, reconnected with a university friend, and we became two freelance developers building apps for the German market.

Mostly agency work or subcontracting for larger app projects. In 2009 and 2010 we built around 30 apps. That work on building apps for mostly German enterprise customers in media, automotive, and so on gave us the idea of building a platform for mobile app developers. Together with three friends, Stefan, Andreas, and Michael, we founded a company called HockeyApp: a platform where mobile app developers could distribute beta builds and collect crash reports and feedback.

We built HockeyApp for our own freelance business, because we had a pain point we wanted to solve ourselves. Before HockeyApp, you would send a build over email to a project manager, and then the project manager would send it to the customer and explain how to drag and drop it into iTunes and connect a cable. We made that process much easier, which made our own life easier. Those are some of the greatest startup ideas: when you're using it yourself, day in, day out, and improving it based on your own customers' feedback.

We built out the HockeyApp business while running the contracting business, and both were about the same size. When Microsoft came in 2014, we thought they would only buy the HockeyApp platform and the product business and leave the contracting business alone, given there were existing customer contracts and what have you, but in fact Microsoft bought both of those companies, the subsidiary product company and the mothership contracting company, because that company had a number of iOS and Android developers who were a hot commodity in 2014 and hard to hire at startup rates.

And so Microsoft actually took over both of those companies. A fun, funny story: today, of these 11 employees, seven, including myself, work for GitHub. They all got to Microsoft and then from Microsoft into GitHub. Coming from a small company based in Stuttgart, Germany, moving halfway around the world, I moved with my wife and back then two very young kids to Seattle. That alone was a big change. Looking back now, 10 years later, since we moved in early 2015, it feels like a blur. Things moved so fast, and sometimes I don't even realize how we did all that.

Our startup was very small and bootstrapped the whole time. We never took any outside investment until Microsoft acquired us, at which point we had about 11 or 12 employees, all engineers building the product together.

In some ways my role today as GitHub CEO is very similar, in that my developer skills, my understanding of code, and my empathy for how software developers work helps me both with my internal team of about 1,000 engineers and with our customer base, which is also made up of software developers, or those who aspire to become one. I think a lot of my passion for software development is actually perfect for me being the GitHub CEO.

I don't think I've seen anything more exciting, or anything more transformative for how we think about software development, in my 30-plus-year career as a software developer. When I started coding in the early 1990s, there wasn't even the internet, or at least I had no internet access, so I had to figure everything out by myself with books, magazines, and trips to the computer club in the community center. Fast forward to now, and it's so much easier to get into software development. You can just write a prompt into Copilot or ChatGPT and it will likely write you a basic web page, a small application, or a game in Python.

AI makes software development so much more accessible for anyone who wants to learn coding. On the other side of the spectrum, it makes developers so much more productive. Most developers working on a project have way too much work to do. They have long backlogs: their own ideas, customer feedback, things from their managers, from the market, from competitors.

Almost any software project of a certain age has too much work on the innovation side, but also what we call technical debt, things that have been created over months or years that need cleanup and refactoring. So engineers constantly balance those two backlogs. Having something that brings effort down and makes developers 10%, 20%, maybe even 50% more productive is completely changing how they work.

The role of GitHub in the first five years of the age of AI, given that we started working on GitHub Copilot in June 2020 right after GPT-3 was first shown to the world, is that we want to be on the forefront of AI code generation. We want to provide tools for developers to be more productive and more happy when writing code. The dream for most developers starting their journey is that they have an idea in their head and they're trying to find the fastest way how they can get from that idea to an app or web page or service.

The challenge is not that developers don't have enough ideas. The challenge is that you take that big idea and have to break it down into small building blocks. As you're working on the first block or the first module or the first class or microservice, whatever it is, you're realizing that this idea is so much more complex to implement than you thought.

What began as a weekend project becomes a month-long or sometimes year-long project. Many apps that I wrote as a teenager, and that I know many of my friends and employees wrote, never got anywhere because you ultimately realize it's much more complex than you thought and it's not worth spending the time on it. In the world we live in today, you can always download an app from the app store or find some online service that does the same thing.

AI helps us realize the dream of taking an idea and implementing it much faster. You can see some of the early signs, where very small startups, sometimes just five developers and in some cases only one, believe they can build million, if not billion, dollar businesses by leveraging AI agents available to them, and maybe building their own, to write software much faster.

The flip side is that we're nowhere close to a world where you can write a single prompt saying build GitHub and an AI agent builds all of GitHub's features, or even just the very basic primitives like repository storage, git storage, and issue tracking. The decisions that developers, engineers, and product managers must make to build a complex system like GitHub run into thousands, if not tens of thousands: the simple ones like which programming language, which open source framework, or which cloud to use, or do we even use a cloud, and the much more complex decisions of how you architect the system, whether you're building a monolith or microservices.

Getting to a point where agents can make all these decisions and write an app that is a viable business, finds product-market fit, has a great user experience, and ultimately generates revenue and profit, because any business at some point has to get to the place where they're making profit and returning that to the founders or shareholders, I think we're quite far away from that. So we need engineers to do engineering. They need to exercise their craft, apply systems thinking and design, and build really great applications.

The unique thing about GitHub is its size and both the love that developers have for our brand, for our mascot, the Octocat, or as we call it internally, Mona, and the reputation that GitHub has built for itself since the very early days. I remember the early launch of GitHub, and seeing Chris, one of the founders, speaking at RailsConf in Las Vegas in 2009, then signing up for my own account and starting to use it. I was excited about GitHub then, and now in 2025 there are still many people who love it.

What comes with love is that people don't hold back their criticism. We have 150 million users on the platform, so there are at least a million opinions about what we should invest in, what's working well, what's not working well, and what's the one feature that is important to that set of users while it's not important to me and my product leadership team, because we have our own strategy and decisions to make. So filtering out the signal from the noise, and I don't mean noise in any negative way, just so much feedback that we're getting.

I remember when we did the acquisition in 2018 and I joined GitHub, we sent an email to 10 GitHub users asking for feedback on a new project. We got nine responses from excited users who wanted to provide feedback. Do that at many other companies and startups, and you get one response, with maybe 10 minutes of time offered.

There is just so much information coming back to us: on social media, on our platform, in email, in support tickets. The second thing that comes to mind is that GitHub has had a very strong remote culture for a long time, well before COVID. The GitHub founders started hiring developers, sales, and support people all over the world, and today I think we're one of the largest remote-only companies, where everyone works from their home, from a hotel in Seoul, or from wherever they are.

A lot of our culture is built around GitHub as a platform, which through open source encourages asynchronous collaboration, along with tools like Slack and video calls that we use much more heavily internally than email. When I wake up in the morning, especially here in Seoul, which is many time zones away from the US, where about 80% of our employees are, I wake up to 30 to 40 Slack messages plus hundreds of channels with conversation. Figuring out what is actually important for me as CEO, what to react to, what to snooze, and what to ignore: that's a big part of my job.

But it's also exciting, because I can be here in South Korea at this event and still run the company. A lot of what we do on a day-to-day basis doesn't actually matter whether I'm in Seoul, Berlin, New York, or anywhere else in the world. For many Hubbers, which is what we call our employees, that's a really strong part of our culture. We are a remote company. It's not related to the pandemic. It's a choice we made about how we want to run the company, how we select GitHub as an employer, and how we believe we can be successful.

I strongly believe that every child should learn coding, and we should teach them coding in school in the same way that we teach physics, geography, literacy, and math. Those are all fundamental skills. Coding is one such skill, and it has just taken us too long to realize that, because software is everywhere. We carry both software and hardware with us through our day, and our day-to-day life is dominated by software. You can't really live your life, travel, or wake up in the morning without software anymore.

As humans, it is crucial not only to be in read-only mode but also to be able to create things ourselves, or at least understand how creation is done on these devices. That doesn't mean that every 18 or 19-year-old leaving high school becomes a software developer. Just as not every kid who learns physics or chemistry in school becomes a physicist, just because you learn those fundamental skills doesn't mean you decide that's the career path to take. So that's number one: you've got to learn coding.

Number two: you've got to use AI to do it. Whether in Korea or in Germany, most people don't speak fluent English, which is the primary language of software development. AI democratizes access to technology, and that's true for many other things in the world. Having an agent available that answers any question and lets you realize your dream and build your dream application is incredibly exciting.

The third thing, for anyone who is already a software developer or wants to develop their craft: you've got to keep rehearsing, keep training, keep learning. You're never done with learning. Looking back 30 years at what development looked like then versus now, I would have been very far behind if I hadn't constantly read blog posts, literature, and tried things myself. Those habits are as crucial as they were in the '90s, and they are still crucial in 2025. You just have so much more access to information to become top of the field.

The obvious answer is that I most enjoy using GitHub Copilot. That's our product, our baby, and we're working on it day in, day out. I often see features long before the world does, and the flip side is also true: I often don't actually know what's shipped versus what is still in preview or in internal testing. I'm daily excited about what we're building, and I use a lot of it myself, since I'm a developer at heart. Sometimes it's very simple, like asking it to write me a quick script that downloads the IDs of all our repositories from our API.

In the past, I would have gone to our API documentation and figured it out myself, which would have taken me about half an hour to get to a shell script. Today, I just ask Copilot and it writes me the script and it works within minutes.

I think that is one of the true superpowers of AI: whether for learning to code or exploring the world, you have an assistant available to you that has infinite patience. It doesn't judge you. ChatGPT or Copilot never tells you that's a stupid question. It always gives you an answer and even accepts when you tell it it's wrong or it needs to explore the topic a little bit further.

You have seen the prompt examples where, by telling it to outline its thought process, it actually gets to a better answer. I also love using AI for blog posts and PowerPoint presentations, to generate some images and play with that. I'm really bad at using Photoshop and drawing myself, but I'm creative and I can write prompts and figure out how to rewrite the prompt to make the image more closely match what I had in my head.

There are tools like Teams Copilot to summarize meetings, especially when I'm on business trips like this, where I miss a lot of meetings happening on the west coast time zone. Just getting a summary and figuring out the action items. The same goes for summarizing emails, or using Reclaim AI to manage my calendar. Those things make me more productive.

The really exciting thing is that there's always a new tool to try out and see how far along that journey AI has come, and how much more we still have to do as an industry to get to that dream of having an orchestra of agents that we control in our personal and professional lives.