Eight things I wish I knew my first week at GitHub

TL;DR: A short list of tips and tricks I offer to new employees when they join GitHub. Specifically, ship something in your first two weeks; spend your first month learning how to learn and how we communicate; about one month in you’ll get overwhelmed; the challenge is in deciding what not to do; GitHub wants you to grow and learn; just do it; professional, not formal; and share your past experiences, but be prepared to unlearn things.
8 minute read

GitHub is a strange, magical place. We have a quirky culture, work very differently than other companies, and all have access to a never-ending firehose of organizational knowledge. It’s been a while since my first week at GitHub, but I can still remember what it was like starting — and it was overwhelming to say the least. GitHub’s changed a lot since then, and your mileage may vary, but looking back, here’s eight things that I wish I knew when I first started:

1. Ship something in your first two weeks

Find something small and inconsequential to ship in your first two weeks. The first ship is always the hardest, and once you’ve overcome the initial intimidation, it becomes much, much easier. It’s far preferable to learn how we work on something that doesn’t matter if you misstep than when it’s your first big subject-matter ship. Call it a training-wheel ship, if you will.

It can be a single character, a word, or a sentence, code or prose, whatever, it doesn’t matter. The important thing is that you’re going through the motions and learning the workflow. If it’s day 15 and you haven’t gotten anything out the door, don’t sweat it, but at least set the goal on day one, and push yourself slightly outside your comfort zone. If you work openly and ask for help when you don’t know the answer, you won’t take down the site, I promise.

Pro-tip: If you’re looking for something to ship, as you’re onboarding, read the internal and user-facing docs with a critical eye. Is something out of date? Did the author skip a step? Could something be clarified? Whether it’s an article on our “internal knowledge base”1, your team’s readme, or help.github.com, even so much as correcting a typo provides your fellow GitHubbers value and is a great way to learn how we work.

2. Spend your first month learning how to learn and how we communicate

GitHub has a unique and awesome way of communicating. We communicate a lot more asynchronously and a lot more openly than you might be used to at your last job, so it may not be as easy (or appropriate) to walk up to a coworkers desk or shoot a quick email to ask that burning question. That’s okay. It’s really easy to ask questions at GitHub, and in fact, it’s highly encouraged. I think you’ll find that your fellow GitHubbers will often drop what they’re doing and go out of their way to help you.

If your first ship is something small like documentation, your second ship for your second two weeks should be learning how we work, and more importantly, learning how to learn. If you don’t know something, what do you do? Where do you look? Who should you ask? Keep in mind, that information at GitHub is largely available to all. Don’t be alarmed if someone answers a question with a URL. Over time you’ll build up the mental model to be able to find the information yourself (and do the same for others).

Pro-tip: When I don’t know something, I usually look in the following places, in order: 1. Searching the company’s “internal knowledge base”, 2. Doing a code search with the keyword “@GitHub” (to scope it to the GitHub org), 3. trying to find a logically named channel in Slack and asking the question there.

3. About one month in you’ll get overwhelmed

Just as you’re finally getting the hang of how we work and how to answer questions, about one month in,2 you will become completely overwhelmed. You’ll stare at your inbox, stare at your notifications, stare at your todo list, and not know where to start or what to do.

That’s okay. It happened to all of us. Honestly. There’s a firehose of information, an incredible opportunity to tackle, and so much to do that you won’t know where to start. You may get frustrated, you may get imposter syndrome, or you may want to quit. That’s completely natural. Stick with it. The feeling will pass.

Pro-tip: Whether you feel overwhelmed your first month or your 101st, communicate with your team and take a mental health day (or if you can’t, a mental health morning/afternoon). Go for a walk, put together that new bookcase, or run some errands. Anything offline. You’ll come back refreshed and with a new perspective on work.

4. The challenge is in deciding what not to do

As a GitHubber, you’ll be presented with more opportunities to have a meaningful impact on what you care about than you’ll be able to take advantage of during your time at GitHub. That’s true in two ways:

  1. GitHub itself presents a unique opportunity. The products we build are uniquely positioned to better the open source community, and in many ways, the software industry as a whole.
  2. GitHub gives you a great deal of freedom in deciding what to work on. If there’s something that you care about, and that thing is also something GitHub cares about, there’s a good chance the organization will be receptive to you working on it.

Given all the opportunities we have as a company and that you have as an individual, the challenge is in deciding what not to do (prioritizing lower lift, higher impact work), than deciding what to do.

Pro-tip: Remind yourself that you have a limited amount of time, and that every minute you spend on a less impactful task is time you could be spending on the more impactful one. Write down the top 3–5 things you think are most important to work on in the next year, and stick to them.

5. GitHub wants you to grow and learn

There’s a reason every GitHubber is given a learning and development stipend. It’s because GitHub wants you to be constantly growing and improving. If there’s something you’re interested in, grab a book on the subject. Here’s a few of my favorites. If you’re getting your work done, you can even take 20–30 minutes out of the workday to read it. Better yet, share the highlights with your team so they can learn as well.

In general, you should always be pushing yourself to step 10% outside your comfort zone. That means taking on tasks you think you’re 90% qualified to tackle. Your fellow GitHubbers will help you rise to that last 10%. That might mean that you submit your first pull request to an open source project. Maybe you pair with a developer to implement a simple change (and learn some Ruby in the process). Maybe you ask to be involved in a product launch or marketing plan. Whatever it is, it can’t hurt to ask (and try).

Pro-tip: GitHub’s learning and development benefit is explicitly for your personal development. If there’s a class, certification, whatever, that you’ve been eyeing, talk to your manager to see if GitHub can foot the bill.

6. Just do it (but keep others in the loop)

GitHub doesn’t have a strong permission (or CYA) culture. Instead, it’s more common to ensure the appropriate teams (and people) have the opportunity to provide meaningful feedback at various phase gates, usually the idea, proof of concept, staff ship, and final stages (or 1%, 10%, 50%, and 90% of completion).

Rather than wait for someone to give you explicit permission to do something, continue to make forward progress until you hear otherwise. If you’re doing something wrong or something that doesn’t align with the company’s goals, you’ll either hear it explicitly or you’ll hear silence, both of which indicate that you should maybe be focusing your efforts elsewhere.

Pro-tip: For this model to work, it’s important that you maintain an open dialog with your manager and cc relevant teams in a way that provides ample opportunity for meaningful feedback before what you’re doing can have a potential impact on users, both internal and external. Use @mention autocomplete to liberally cc teams (with context). For larger ships, provide an explicit deadline for which you’d like feedback before proceeding.

7. Professional, not formal

I like to say that GitHub is professional, not formal. What I mean by that, is that when you get a pull request from a coworker, you can respond tactfully, be helpful, and display technical prowess, without beginning your response with “Dir sir or madam, I am in receipt of your pull request dated 27th of October, 2016.” Instead, respond with emoji, animated GIFs, and a human-centric tone.

Put another way, GitHub treats you like an adult. We prefer social constraints to technical or administrative constraints, and it’s your responsibility to handle that newfound freedom. On my first day at GitHub, I could have taken down GitHub.com if I wanted to.3 I didn’t, not because I didn’t have the right password, but because I knew if I did, I’d have to live with the judgmental looks of a hundred other Hubbers in perpetuity.

Pro-tip: If it’s your first time working from home (or with unlimited vacation), you may be tempted to take a four-hour lunch every day, make every weekend a four-day weekend, or stay out late every school night, and chances are, nobody will notice for a while. It’s on you to be a professional. Regardless of how you choose to manage your own time, you’re expected to get your work done and to communicate your availability to those that depend on you.

8. Share your past experiences, but be prepared to unlearn things

Every new Hubber joining a team, almost without exception, injects a renewed sense of energy and creativity. You bring a background and set of experience unique to you and often not already represented on your team. If you see something that doesn’t seem right, have a “duh, why aren’t we doing X?” idea, or have seen a challenge at your last job that was solved a different way, by all means, speak up. Working on the same problem with the same group of people for an extended period of time can lead to tunnel vision, and you may be exactly the fresh set of eyes your team needs to succeed.

At the same time, be prepared to “unlearn” some prior habits and workflows. GitHub works and thinks in a unique way, and “this is how we did things at X”, or “this is how the industry generally solves X problem” is not often persuasive, absent a strong reason why that approach is better than whatever we’re currently doing or what’s proposed. The status meeting/Sharepoint/Google Docs workflow at your last job may have it’s advantages, but so does ours. Approach GitHub’s workflows and culture with an open mind. Give it a few months before you choose to write it off as too difficult (once you get the hang of it, chances are, you’ll find that you like it).

Pro-tip: Although Markdown, pull requests, and GitHub issues may be the result of most workflows at GitHub, they’re not always the start. Feel free to draft documents in a Google Doc and share it with some trusted colleagues for early feedback before sharing more broadly if you’re more comfortable working that way, especially to start.

Conclusion

One of my favorite parts of working at GitHub is being able to talk to new GitHubbers. Looking back, these were eight things I wished I knew my first week, but they were my experience, and as GitHub continues to evolve, YMMV. In any case, new GitHubber, feel free to DM me any time, if you have a question. It’s often helpful to be able to talk to someone outside your report structure, especially once you’ve passed the awkward “it’s too late for me to ask their name” stage of onboarding.

Welcome to GitHub! I’m glad you’re here.

  1. The original post referenced a previous iteration of how we stored and shared knowledge internally, so I opted to remove the system name entirely to keep it future proof (that’s not what we really call it). If you’re a GitHubber, ask your manager or a teammate. It’s the thing with internal policies, docs, guides, updates, and so on ↩

  2. As we’ve grown, this timeline has likely accelerated. Don’t be worried if you hit this point sooner. ↩

  3. To the auditors out there reading this (👋), in hindsight, I’m not sure how realistic that non-aspiration was, but either way, since then we’ve added a number of developer-friendly technical and administrative controls. ↩

Originally published October 31, 2016 | View revision history

If you enjoyed this post, you might also enjoy:

benbalter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit