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
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
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
What are main pieces of advice that you’d give
to anyone looking to enhance team collaboration within their
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
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
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
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
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
What do you consider are the biggest obstacles
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
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
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
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