TuringTech's team meets GitHub's CoFounder and Former CEO/CTO

Engineers from TuringTech through its partner company Fêtefully had the opportunity to get on a call with Cofounder and former CEO+CTO of GitHub, Tom Werner-Preston. This gave our team members a chance to get candid advice from a business executive who is one of the pioneers of open source.

Thomas Preston-Werner is an American billionaire software developer and entrepreneur. He is an active contributor within the free and open-source software community, most prominently in the San Francisco Bay Area, where he lives. He is best known as the founder and former CEO of GitHub, a Git repository web-based hosting service, which he co-founded in 2008 Preston also serves on the board of Netlify.

So if you want to become a good developer write a lot of code, like mountains of code.

Can developers become good managers as it is usually expected after 4-5 years:

‍Host: Nowadays, programmers are expected to manage the projects on which they are working. Do you think that’s necessary?  

Tom: Those two are entirely different roles. It would be preferable to keep a coder in his field of interest. Forcing someone who's a great coder to become a manager isn’t favorable. Keep that person as a coder, and go find somebody who wants to be a manager. 

There’s another way if your coders want to become great managers: you can train your coders to start managing. Like you can have coaches that help them out. Sometimes it just takes time to get those experiences. There are plenty of books and lots of material on how to become a better manager. But it's rarely going to happen if you don't want it. So I'd figure out what is the reason behind a coder’s struggle to go in that direction and address it from there.

Birth of RedWoodJS in the JAMstack ecosystem:

Host: So then my next question is what was your motivation behind RedwoodJS? Because with Fêtefully, there are a lot of things, like our store, which can be made as a pure JAMstack app, we don't have to put in a bunch of stuff that we don't need. 

Tom: RedwoodJS was kind of a realization that there was a gap in what was available from a JavaScript ecosystem from a full-stack web framework perspective. It seemed like there was an opportunity to be able to build full-stack applications using a JAMstack architecture. No framework was trying to make that easy, especially with integration to a backend ORM. So Prisma just came out and thinking about what Netlify could let you do with the automatic deployment of Lambdas. Like, could you kind of smush all these things together: React, GraphQL, Prisma? and deploy on Lambdas? It seemed like a cool thing. Working on different kinds of projects and going up the chain of complexity and building a web framework is pretty high complexity these days.

So I thought it would be a challenging product to work on. It's changed now to become kind of a more generalized thing. It doesn't have much to do with JAMstack. You can deploy it on a server-less architecture and serve full environments as well. So that’s from where we got this idea. 

What drives him to keep coding or learning new things:

Host: What still motivates you, even though you have done multiple ventures, to still keep coding yourself?

Tom: The thing that motivates me to code is creating something from nothing and learning things. So those are kind of the two big things. Also, helping others achieve those things for themselves. And so with those kinds of desires, like building stuff, and with (being able to) code is the easiest way to kind of fulfill that. It's like you see a product that could exist in the world, a tool that could exist, and you have the tools and the skills necessary to make that exist and scale it and market it to potentially millions or billions of people like that. That capability is pretty amazing. And the thing is that I'm happy writing code, but I'm also happy being a CEO. Like, I like both of them because they're both different parts of the journey along that same path. So it's really about what needs to be done if it's the very beginning of a project like Redwood, and I'm like, this should exist. I'll just do it myself because I like to code. And I like to make things from nothing. And then I try to bring people in to help me with that. Because it's very hard to do anything all on your own. So if that's what's necessary, then I'll write code because, you know, I love learning things. 

His experience open sourcing internal tools and open core model:

Host: In one of your articles (Ten lessons from GitHub’s first year) you talk about open souring whenever you can. An average developer(s) can have a hard time putting it on Git, because they are avoiding feedback or a pushback from the community. I don't know if I can take it or not. So what is your opinion about it? Still the same or has it changed somehow since 2010? 

Tom: I think the bigger problem is when people like your open source thing. If nobody cares then it doesn't matter. The things that are not the core business value  should be open-sourced. Like we should be able to put them on GitHub and have people be able to use them, follow the instructions, and install them. The value of that is it encourages people to think in a way that makes that thing even more useful to yourself and especially other team members. It tells us how we are supposed to use it and how it's architected. It's not tightly coupled to our existing systems because it is a standalone open source thing. And it turns out all of those things are really good engineering principles anyway. The mentality of open-sourcing has a lot of value in that. You get a lot of Goodwill out of open sourcing things (if they're useful). 

The danger is in having to deal with contributors that come along because nobody likes to come along to a popular open-source project and try to contribute. If you open-source something and it's wildly popular then it's a good problem to have. It can help you hire. Engineers are more likely to work for you if you have popular open-source products. It is amazing from a recruiting perspective. 

Host: So you said you had a complex billing and scheduling service. Did you opened source it?

Tom: Yeah, Chatterbug. It is a foreign language learning software. From the billing perspective, how do we sell this to businesses that want to offer it as a perk for employees? We never open-sourced it because it didn't seem worth it at the time. It was too specific like this code is relevant only to your company. There's no point in open-sourcing it. It should just be embedded and tightly coupled into your system.

So we've built the queuing system for GitHub that'd become one of the most popular queuing systems that were available in the Ruby on Rails ecosystem. We had a chatbot that was not part of the core system. So it was a good candidate for open sourcing. The open core model is now becoming a lot more popular like look at GitLab far more than GitHub was ever worth. They're open source from day one. There's a lot of power in that model. 

How useful is Machine Learning for early-stage ventures:

Host: Any challenges that you got in GitHub or for your other ventures where machine learning became a bottleneck?

Tom:  I'd say be careful what you think ML can do for you. And don't fool yourself into thinking it can do more than it can. So you have to think if your training set is large enough to produce accurate results. The more training data the better the results.

You can waste a lot of time trying to figure out an ML system where it's like if that does people need it, is that a core tenant of your system? a core advantage of your system? 

We experimented with some ML in Chatterbug where there was a flash carding system. We used an ML system to predict what would be the best kinds of cards to give you next, based on the cards that you had already done. And it turned out it was useless. It was just not the right kind of thing to solve with that. 

Advice to younger self:

Host: What’s the advice that you would give to your younger self?

Tom: You get good at what you practice. This is true for anything that we do. And it's always true. So if you want to become a good developer write a lot of code, like mountains of code. You can read all you want, but until you start putting it into practice, you don't start perfecting it.

‍