Let a GitHub trainer knock down your barriers to collaboration
Time to douse those internal firewalls and open-source your internal projects – itll make things so much simpler.
Wouldn’t life be so much easier if you could treat internal projects at your company as if they were open source? Well, you can! Just like a business, open source works through similarly-aligned teams and individuals – you just need to know a few fundamentals to make it all come together. In this interview, Brent Beer explains how, by using patterns implemented at GitHub, you can make your in-house development more enjoyable, and easier to get involved with and contribute to.
JAX: How did you become involved with GitHub?
Beer: I first became really interested in GitHub because a lot of my friends were using it. That got me initially signed up, then, once I started becoming more involved in different programming communities – whether it be web application frameworks, or experimenting building stuff myself -I started looking at how other people were building tools, and what they were using to build applications.
I found out that everything they were using was also on GitHub, and any tutorials, or anything like that – anything that I would go through to find out, OK, well, I want to try out this new thing that just came out with this language, where’s that code hosted? Oh, that’s on GitHub as well. So everything just kept pointing me to GitHub, and I became immersed in the environment, I guess, to use GitHub.
Now I’m on board and in the company, seeing firsthand the amount of information that goes into GitHub, the rapid amount of coding that happens, is awesome.
What keeps you motivated to use GitHub now that you’re not so involved in coding?
At this point, though I see things on Twitter, essentially I rely more on my co-workers. We heavily use our chat service – we use Campfire to all stay well connected as we’re an incredibly distributed team, in an incredibly distributed company. So, when I see other people within the company talking about projects and tools and stuff that they use, that gets me interested on things that are happening on GitHub.
I’m also pretty closely connected with the team that’s working on the ‘Explore’ features of GitHub, so Jon Rohan and Andrew Nesbitt. They’re working a lot with the features that will allow people to find things easier on GitHub. They find things and they show them off, or talk about them, and they’re just building features to make that stuff easier to find. So that helps as well.
We also have a daily or a weekly newsletter. That actually comes out from people. Trending repositories on GitHub is also really helpful for me, just to see what the community at large is up to. As you start following more and more people on GitHub, that newsletter also uses your friends, and you can see what they’re messing with too. So that also really helps me.
What are main pieces of advice that you’d give to anyone looking to enhance team collaboration within their company?
My first takeaway would be, if you’re starting out a new company, or if you already have an existing company, one of the first things you have to do is have many, many, many channels of communication. So you have to be able to talk about things. Now, email works for this sometimes, but we built our entire company around a chat service, essentially. When we started out we didn’t have an office – we had a chat room.
We had people in other parts of the country, and obviously we can’t see them face to face, but we see the way they talk, and the way they work, come out through a chat. So Campfire, HitChat, Skype has a group chat service as well….just so long as you have everyone able to share information, and collaborate and talk to each other, through some service. I find that helps a lot – so that’s my first point.
Secondly, having a way for people to be able to explore different projects which are going on within your company is super helpful as well. If there are different projects that other people are working on in a different team to you, it’s great to be able to explore them. And when you do, having that open channel of communication let’s you tell your existing team if you’re going to help out on that project for a little while, or to work on that new idea, or come back to work on that team later.
We’ve seen this with some people at GitHub specifically, like Sean Bryant, who works on the enterprise project itself. But he also worked with our 3D rendering team to work on 3D disks within GitHub and stuff like that. He took a short, you could call it vacation, from what he normally does, worked on something else, and then later came back to working on enterprise again. He was able to do that because he kept the channels of communication open with his team, he let us know what he was doing, and everything was fine from there.
Lastly, when you do have these projects within your company that you want people to collaborate with you on, whether they’re on your team or not, you should make it easy for them to get started. So, if I’m going to jump on to a project, the first thing I’m going to want to do is read the install instructions. I want to get started as easily as possible.
Having a good readme is kind of the first step there, talking about how to get started on something, how to use it, and, once people are using something, making sure that their development environment is also very easy to set up helps as well.
We have a tool called BoxIn which is kind of a tool that allows your new employees to get started on getting up to date and started with their entire laptop, or if I myself completely lost my laptop, I could just get a new one, and with a few short commands, everything would reinstall the exact same way. All my development environments, and everything I would need to actually code on any projects, would already be set up for me. So BoxIn and those readmes make it nice.
Just to tie everything together; if it’s really easy for people to jump into projects, you can talk to other people to bring them into those projects with very little overhead, and they can start helping you out and bringing in their own diverse experience to work with you.
Is it true that nobody at GitHub ‘codes alone’?
We have this way of programming at GitHub called the GitHub Flow – and it’s really closely tied to our features of using pull requests and keeping those channels of communication open. It’s the idea of, if you’re going to work on some feature, to get it out in front of everyone, for them to see and talk about and collaborate with you, as soon as possible.
If I’m going to work on some feature, I don’t want to work on it in some isolated way, on my laptop not talking to anyone for two or three months – or even two to three days. As soon as I start with the idea, I want to present that idea to my colleagues, and starting showing them the first bits of code as the conversation is starting.
This is how our pull requests are set up – there’s an idea presented with a little bit of code attached, and people start talking about it, and then you update the code, and then they keep talking about it…and you keep updating the code. That’s kind of an essential way of how we get any amount of work done.
What do you consider are the biggest obstacles to collaboration?
The hardest part about collaboration, I think, is when you don’t necessarily really know the other person that well yet. So that first time understanding how they work. And tone too – that might come through with writing. From time to time, I see people who might be less familiar with typing having conversations over text, and I might not know the context of what they’re talking about by the tone that they’re using.
We have this unwritten rule of ‘assume no malice’, so anyone I’m working with, especially in GitHub, I assume they’re not being mean to me. That’s a good rule to have when meeting people for the first time! Nobody is going to try to be mean to you – who would do that? That makes it a bit easier.
For the open source community in general, or working on some project with someone else outside my company who I’ve never met before, I might do a double take sometimes and think, “What are they trying to say there?” and I’ll re-read stuff. So that’s the first stick in the mud that I run into on open source. But you know, it’s just a matter of trying to assume the best out of people. If you use more words, it’s easier to figure out how a person’s tone is, or what their context is. Being more explicit in text is always a good thing.
What are your favourite GitHub hacks?
One of the things that I really like is within GitHub itself. We have a lot of conversations that are on the web – within the pull requests, within the issues – and the thing that I like is, when having these conversations, if you actually highlight some bit of text in an issue or pull request and just hit ‘r’, it actually takes it and puts it down in your input box for your comment as a quote. It keeps the context of which questions I’m answering, and helps keep the conversation going.
Besides that, within our repository, if you just hit the ‘t’ button and start searching for different files. This is kind of a fuzzy search – but if you’re in a big project that has lots of different files and you might not remember which one you’re looking for, you can start typing things out, and as you do so, it’ll start filtering that down for you to find those files. It’s kind of the same vein as search, which is also very, very helpful.
I think the explore and trending part of GitHub is the best place for new people to go. Find out the popular people on GitHub, and then also find people who are similar to you, and follow them on GitHub. If they’re similar to you, they’ll be starring stuff which is also very similar to your interests. So if you see the things that they’ve starred. you’ll get those newsletters, and then get ideas, and grow your network that way. Find the interesting projects, and things like that. That’s what people now, and forever, when they are new to GitHub, should do. Make your own little community for yourself, and keep exploring.