I have been spending a bit of time lately reflecting, as one tends to do on milestone occasions, on my first year at GitHub. And since several people have asked me about my experience working here – what’s it like, what do I do – I figured it was time to write my thoughts down, especially because (as a fellow Hubber has taught me), if I get the same question twice, my answer the third time I’m asked should probably be a URL.
While every year has its ups and downs (as does every job), overall, this past year has been one of learning, growth, and, most importantly (and surprisingly!), joy. I’ve found a kind of magic in naturally working more openly (thanks to working in GitHub), having a role that lets me stretch in any number of different directions, and being encouraged to keep exploring and experimenting.
I really like working in GitHub
This is the first time in my career that I’m actively using the product that I’m helping to build (unless you count using RHEL Desktop as my daily OS during my tenure at Red Hat). Even though I don’t frequently work with code, I use GitHub for all of my work – to the point where now if something isn’t captured in a GitHub Issue, I’m going to forget about it.
Not only is using GitHub to build GitHub awesome because we can improve our own working environment by improving the product (like fixing bugs that we encounter as part of our daily workflows), but working in GitHub has also allowed me (a staunch supporter of open source principles!) to work more openly than I ever have before.
For example, because all of my work is in GitHub, anyone in the company can comment on an issue if they have thoughts or suggestions related to something I’m working on, or check out my team’s project board to see our roadmap – no more tedious slide-deck roadshows! If anyone has an idea for work we should pick up, they can file it as an issue in our backlog for consideration. Decisions are captured as they’re made in issues and pull requests, so we can go back to see what was done and why. And I can learn through watching my fellow Hubbers work, like checking out a diff in a pull request to see what was changed.
As an added bonus, since work progress is documented in issue comments, my manager can run automated reports, so there are no more tedious status updates for me to provide, either. I spend a lot less time doing work to explain my work (doing meta-work?), since I only have to document things once.
From an internal communications perspective, it was an initial shock to the system to move from email to GitHub Discussions (you can read more about how this works over on the GitHub blog), but getting to leave email behind relieved more stress than I knew I was carrying. I do not miss it.
What would you say you do here?
Speaking of internal communications, one of the things that drew me to my current role was that it wasn’t “just” a communications role (my current title, for what it’s worth, is Staff Technical Business Operations Manager).
I have an eclectic mix of interests and skills – primarily thanks to a winding career through such job titles as technical writer, business analyst, project manager, program manager, and chief of staff, aka I can’t decide what I want to be when I grow up – and I’ve found myself in communications-centered roles over the past several years because, to me, communications involves bits and pieces of all of those different things.
Because GitHub hasn’t lost all of its startup mojo, there’s still plenty of opportunity to (as we used to say at Red Hat) “find a gap and fill it” – meaning there are simply more things to do than there are Hubbers to do them, and the best thing to do is to pick a problem and start solving it. So while my role is described as being focused on internal communications and culture initiatives for GitHub’s Engineering division, I might be a change management lead in the morning, a comms strategist mid-day, and a project manager to close out the afternoon. It’s a lot of fun to pull on all the random experience I’ve collected over the years.
I am technical
Like so many other members of underrepresented groups (and/or other English majors), I started my career in tech saying, “I’m not technical.” At some point, I realized that was nonsense, and what I had always meant to convey by that statement was “I don’t code”, so that’s what I started saying instead.
But, that hasn’t been entirely true, either: While I never seriously got into programming, I grew up playing around with BASIC (yes, I’m that old), and I know just enough HTML and CSS to be dangerous (don’t look too closely at the code for this site; there’s a lot of duct tape holding things together).
The gift of GitHub has been a mindset shift, primarily thanks to Copilot and OpenAI. Now I’m (at least a little more) comfortable claiming my technical ability. Copilot has given me the confidence to know I can find my way around code well enough to understand it and make small changes. And it turns out I’m not too shabby at prompt engineering, given my background in communications and my basic understanding of computer logic.
Experimenting with LLMs as part of my daily work has been so much fun (and while AI didn’t help me with this blog post, it did write the tl;dr summary!). I’m appreciative that I work for a company that not only allows use of generative AI, but encourages it – as well as to have a manager who suggested we explore it to help with our internal communications automation, otherwise I might never have starting learning about it in the first place.
The future of programming is conversational, and I am here for it.
Finding joy
A friend asked recently what joy feels like to me. The first thing that came to mind was that feeling of delight I get when tinkering with something – learning through exploration and hands-on experimentation, working through challenging problems, being midwife for invention. That’s what I’ve been able to experience during my first year at GitHub, and for that, I am grateful.
This website is a great example. I knew I wanted to write this post; it just didn’t feel right to publish it anywhere but on GitHub. So I spent a couple days over my year-end break standing up this site – GitHub Pages made it really easy (I never had to open a terminal), and Copilot (and my manager) helped me a few times when I got stuck trying to make changes to the template. It’s not perfect, and I probably definitely didn’t do everything the “right” way, but GitHub and my fellow Hubbers inspired (and enabled) me to explore and learn and create, and that brought me joy.
And that’s my wish for everyone, as we head into 2024 – it might sound cheesy, but my word and intention for this year is “joy”, and my hope is that we all get to experience more of it, however it manifests itself in our lives. As for me, I’m excited to get back to tinkering.