Bio Zach Holman, educated at Carnegie Mellon University in Pittsburgh, Pennsylvania, travels the world speaking to coders and other tech professionals at software conferences about the joys of GitHub, a popular web site that facilitates collaboration between developers and other members of the software engineering community.
Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
I did not found it. I am one of the early employees. That’s all right. You can say that I found it.
Martin: Let’s get started on the wrong foot, like we are. So, tell us about the founding of the GitHub, Zach.
There are four founders of the GitHub and they started it in 2008. So, I guess whatever the math is, they are five or six years old at this point and it has sort of been growing ever since then, I guess.
GitHub is a website and platform that helps people share code amongst their co-workers or you can also use it for open source. The idea is that we build a bunch of tools to make it easier to communicate with your co-workers or with people with whom you want to build something together.
Traditionally, that is usually code so we have a lot of programming related tools, but also a lot of people like designers and managers and a lot of people who use it just to help move a project forward.
The secret of GitHub’s success? I think earlier on, a lot of the founders were able to get GitHub in the hands of a lot of open-source project maintainers. That started the idea that GitHub was a place for open-source and that open source could use GitHub to help code and program with each other, then it could be good for their businesses as well.
That was the start and I think that ever since then we have been trying really hard to keep it as simple as possible, as straight forward as possible, as accessible as possible and I think that became the driving force for a lot of GitHub.
Disastrous. No! It was pretty good. It was a packed room, little warm with all the bodies in there, but it was fun.
I always love questions. I mean questions are the most interesting part. I would prefer talks where there would be five minutes of me talking and then 50 minutes of just discussions about points.
So there were some really good questions about the finer points of things I briefly touched upon in the talk, about managers and their place in the organization, how to just deal with humans, employees in your company.
I think there are some interesting things going on that GitHub is doing, but also just in general right now. I think there is some real interesting things happening in the market place that people are actually realizing. We do not have to do it the way that we have done for decades.
We can start rethinking some of the ideas about remote work – that’s a good example. You can have a lot of people living somewhere else entirely. 60% of GitHub’s work force is remote in the rest of the US, in the rest of the world and that really determines how we work.
We have an office but you cannot assume that everyone is going to come to the office because they may live halfway across the world. So those are the kind of fun conversations I like having in those types of settings.
Martin: Why do you think your talk was so popular? I mean I went to one where there were only three or four people and well I won’t say who, poor guy.
I do not know. I think GitHub is a kind of an interesting thing. We are a tool for developers. So obviously there is going to be a lot of developers really interested in what we have to say.
It is always the idea developers are hackers at their core. So they always want to know “What am I not doing that can make me 5% more efficient?” and that is always kind of fun to see what other companies and stuff are doing too.
The holo-culture track was actually kind of interesting. Greg Brockman from Stripe was right before me and he had a packed crowd, too. So I think there is a lot people interested in not necessary the technical side of things, but just the cultural side of growing a company, which I think is great to see.
The ones that are correct. I don’t know. My focus is much more on culture, I guess, rather than – I am not a great programmer. I will be the first to admit it.
But I think what is really interesting is just talking about these things and that is mostly what I tried to say in these talks, in general. It is just to start thinking about just workplace culture. Because I think a lot of companies do not.
And it is not a matter of working like how GitHub works or working like a different company works. It is a matter of just sitting down and thinking “What does my company value? Is there something we can be doing to help make that more interesting in our company? Can we make our employees happier by allowing remote work or something like that?”
So I just want to get people thinking about their own situations and trying to rethink these established ideas of what a company means and what it means to be an employee of a company.
That is a really good question. I would say, on a broader level, I think employees should be afforded more power than they had in the past. And I do not mean that like in a political movement like “Power to the people!” and stuff - although maybe - but I think it is a matter of trust.
And I think you should be able to trust your employees to actually care about the company, to actually care about working on things that are going to bring the company the most value. And I think that a lot of things stem from that underlined trust.
If you trust that they are going to work as hard as they can to make the company profitable then you can say “Yes! I do not care where you work because I trust that you are going to do what is best for the company. I do not really care what hours you work or if you are coming at 8 a.m. and you do all these sorts of things because hopefully we can have an open relationship with everybody, that we can trust each other to work on this stuff together”
And I think it is hopefully the employer is not going to take advantage of that and that the employee is not going to take advantage of that. It has to go both directions.
My role changes a lot. As some people would say, it depends on the day. Today I do lots of this sort of stuff. I am going around and speaking and talking to developers and companies, which is really fun and exciting.
I love traveling and all that sort of fun stuff. So, that’s fun. That is sort of been what I have been doing for the last year or two until this fall. Earlier this year I kind of got back into the development role and this is my last talk for a while. So I can get back in the code.
And I like to say I can actually do work as opposed to talking about work for a while. So, that is going to be fun to focus on building features and building out more things on GitHub.com for everyone else to use.
But it really does depend on the day: I will flip back to doing a talk or I will flip back to doing some internal work in the company and back to code. It is kind of fun. It is that flexibility that I really dig. I can work on whatever is the most interesting to me in that particular point in time.
I will be working on GitHub.com on a couple of newish features that have been in the pipeline for a while. So hopefully, in the next few months, we can start pushing some of those things out and doing some really cool stuff.
Top secret, yes. We always keep those under wraps because it is fun to surprise people. And more often than not, even though we have all these things in mind and I am totally excited to launch this thing when it is ready, it could be a year before it is totally ready.
Which I hope it doesn’t because it would drive me crazy but, sometimes deadlines slip and talking about it would be bad for deadlines.
Traditionally I will do Ruby and that is pretty much what I tend to work in. Our stack of GitHub is mostly just Ruby with some C, when it makes sense to get some speed. Our stack is pretty boring which is really exciting to me.
There is not a lot of – I do not have to worry about the stack, it is stable and I can worry about doing really fun stuff and products. So that is mostly what I am super-interested in: doing some of the back end in Ruby, doing some of the front end in design work.
And then once I have a good idea of how that stuff works together, have a web designer come in and make it better than what I had and make a back end guy and make it scale a little bit better. It will just be really fun to just get back in the code a little bit.
Not particularly. I have been using it for six or seven years now, so I don’t know - our philosophy with Ruby is sort of the same with everything in technology at GitHub.
It is that we do not tend to use the flashiest stuff – like ideas, like the really high level programming we do is very standard stuff. We try not to spend too much time worrying about the hip new whatever is going on.
Ruby is a really flexible tool. It can do most of whatever we want to do with it. We just leave it at that and go from there.
Yeah. That was a big deal for a long time because GitHub.com has to deal with - it is a really fat App, I guess. If you think about a code diff, for example, actually rendering that on page, if you have syntax highlighting and then you have an actual diff --like the red/green version of a diff-- you have to wrap all of those in HTML.
With different tags to make sure that, like OK this does the work this doesn't work. It ends up generating a lot of overhead. And that was the main problem with - before we had a mobile site. The loading would be the usual desktop experience on a mobile browser.
We are already loading so many elements into the Dom that a lot of mobile phones would just be slow trying to parse all that sorta' stuff. So that was the idea behind the mobile site.
That we can do away with a lot of that stuff, simplify the experience, you do not get everything that you would normally, but it is a lot faster and you can get to the information that you want.
It is pretty much Ruby across the board with the exception if you are doing some lower level stuff that really requires a lot speed UC or Go or something like that.
But from a product stand point, it will usually spike out as a Ruby prototype, typically with Rails at this point. We just kind of go from there. We try to do a big emphasis on getting stuff out there.
I was saying earlier in my talk, it is a lot easier to take pot shots at code rather than ideas. Before you actually put it to code and actually start building something out. It is just ideas and you can say “Well, that will not work.” And then you all say “Well, that will work” and then you cannot go anywhere.
But as soon as you can actually feel it and click on stuff, it is much easier to sort of have these discussions and say “Oh, that does not work because of this” and “That does work because of this” and you can take it from there. It is a lot of small iteration.
I would say so. I don't know if that's good or bad. I am not good at judging industry wide things. Things are definitely crazy. I mean as a San Francisco citizen, seeing all of the rent prices go ridiculously high – something is happening.
I do not know if that means it is a bubble or just a resurgence of rich entitled people into the city. We will see, but it is one part excitement because there is a lot of smart people in the city and doing really cool things and everybody has a new startup that is going to change the world and stuff and I am one part cautious.
I hope this does not just go bad because there are some really crazy things. I mean Snapchat just got an offer for 3 billion to get acquired today and they said “No”. I mean I would be on to Vegas at that point already.
Before GitHub I was at another company for two and a half years or so in the job-related market. That company was about 20 or so people and those were my work experiences, I guess, before GitHub.
18. I guess the open-sourceness of GitHub is a way for developers to avoid a lot of stumbling blocks. Do you have any other advice to help them overcome the stumbling blocks that you might encounter in making an App?
I think one of the things I just say a lot is to get to the point where you have something built. And that is beyond the point of code and everything. Just showing people: “Hey, look what I built. Is this cool or not?” “No.” “Crap, back to the drawing board”.
I think that a lot of startups try to get to this point where we have to have this perfect "first product" before we show anybody because first impressions are everything.
That is true to a certain extent, but there are also a lot of startups and companies that just keep trying to chase that forever. And by the point they suddenly start trying to figure out somebody has already beat them to the punch.
I mean it is just getting the ideas out there as soon as possible. We have had a lot of things internally at GitHub where we were really excited about this feature and we know it is going to be so great for everybody and it is going to make us a lot of money and stuff and then we have it shipped internally just for the employees for a month or a year or something like that and we just realized we were just totally wrong.
This is not an interesting thing at all and then we end up just killing it. And that wouldn't have happened if we kept going down this path, get the perfect product? So it is just a matter of getting it out there as soon as possible and then just iterating on it over and over again.
Probably similar stuff. I may actually give the same talk; I have to figure that out. It will just have more inside Ruby jokes because I am a Rubyist and I love those Ruby people.
Also Australian Rubyists are crazy and I mean that in the best way. Everybody knows everybody else. It is an amazing community. Anyway, just sort of similar stuff.
And it is fascinating like Melbourne and Sydney and a bunch of other cities like Berlin, Amsterdam – they are starting to get just startup culture all over the place and it is really interesting to travel around and see.
I mean, as much as I love San Francisco, I think it is the best place in the world, I am super excited to see all of these other cities just building really cool stuff. Without even caring what Silicon Valley is. And I think that is the right way forward. I think that is just fun to see.
Repository is basically another word for a project. They see you push your code to a repository and that holds all of your code. It also holds all of the other stuff like issues, bug reports, documentation and stuff like that – it is your repository. So it is sort of the center of what that particular project is, I guess.
We have a specific word, I guess. "Contribution", meaning if you contribute to another project or if you file an issue on another project, you are basically trying to help out with that project.
The most visible thing is on your profile you get a little dot for that particular day. It sort of goes back to the idea – you are familiar with Seinfeld’s calendar – it is Jerry Seinfeld’s idea of “Don't break the streak”.
So, in the context of open-source, a contribution on GitHub we tried to make it very streaky: “I will have eight days in a row where I contributed something to an open-source project”. It is kind of a nice little motivation.
Martin: Like a gold star.
Yeah, exactly. And I have noticed this too. Once you start thinking in that mind, it is not even just programming, it is anything. You don't even have to care about actually doing something.
Like if you have chores you have to do every day at home. Just as long as you do something for like three minutes and usually you start doing like “Oh, yes. I can do this and I will clean this and do all this sort of stuff”.
The idea is that it is the same thing for programming. In that you start learning more about a new language that you had never learned before. It is just trying to get people out there to do sort of new things they wouldn't have done otherwise.
It depends. One thing that pops in my mind is there are a lot of projects that are trendy to work on. Especially if they came from somebody who is very well known.
It is almost cheating because that somebody has enough GitHub followers and Twitter followers and they are the superstar developer. Anything they do, people are going to flock to and try to help out with.
That is sort of the nature of humanity, I guess, for better or worse. So it is also really interesting seeing the long tail of development. I sometimes mention a project that I had – it is for running basically.
So I keep track of all the miles I run and there is one service I used and then imported those into another service so I could use that other service. Really niche, not a lot of people would ever use it, but it was fun hooking up with the two or three developers who had the same similar taste as me.
Sometimes it is just fun to see that thing happen and people push up a new – in this case, an open-source repository – and say “This is my hobby. It is really weird. I don't even know. Some small project and I do not know a lot of people with the same interest as me.
I am just going to push it up to GitHub” and then, over time, you end up meeting all those different people who have those similar interests as you. That is really fascinating to see.
Because I think that is more meaningful than just some celebrity’s repository you are trying to help with because there are millions of other people.
But if you make connections with somebody else who their tastes line up with you; their technology stack lines up with yours, that's the really interesting stuff.
23. What exactly is a call then? I have this project I want to put on GitHub. What do I look for? It is not a repository, it is not a contribution necessarily, or is it a contribution? How do I start entering my thing in?
If you have a great idea and you want to start something new, you just create a new repository and then a lot of people would just Tweet that out or send an e-mail to a mailing list somewhere and say “Hey. I have this great idea for so and so”.
And then I can just go to your repository, check it out and start helping you out or, if that is code or maybe that is just issues and saying “Hey, I have an idea for this. What do you think about this?” and you start the conversation before you actually start working on it.
24. So I do not really have to have any code. I could know zero about code, I just want the new version of Mine Craft, the space age version of Mine Craft or something and maybe I can enlist a coder and pretty soon I will have my own company?
Yes. I mean we do that a lot internally at GitHub too. We will know something is broken or there is a problem and no one really knows how to fix it yet, but you just start that conversation and you say: “Well, let’s create a repository” and it just has one file in it that says “Do something here” or something like that.
Then you just start the discussion: “What would this look like? What sort of problems can we solve with this? What sort of solutions can we come up with?” The code is never really a hard problem in a lot of cases.
It's mostly just a matter of figuring out what is the actual problem and what is the actual solution to that. And once you have these things figured out, just start coding. And step by step hopefully get to that solution that everyone is excited with.
I don't know. We will see. The company has definitely gone big. We have 217 employees today and it's kinda' nice. We have the resources to jump into a couple of new areas that we wouldn't otherwise if we were a lot smaller company.
It's a lot more risk to say “You two people – just go work on this for three years and then see what you can end up doing”. And we have a couple of long-term projects like that that we have been working on for two, three years or so.
And it's kinda' nice just to be able to sit back and like: “Well, just keep working on it and then when it is ready to go, we'll go for it.” So a lot of really cool projects and stuff that we still want to work on. We will see how things go, I guess.
Martin: We have been speaking with Zach Holman from GitHub. Thanks you so much Zach for being with us here at QCon San Francisco.