In 2017, as a recruiter, I wrote an article about getting hired from GitHub contributions. Hacker News hated on it so hard that I quit my job as a recruiter, got a job as a developer, spent 14 months contributing on GitHub, and got myself hired from it to work on Zeebe.io. Turns out it does work!
My 16-year-old son, Prahlad, just walked into our apartment.
"What did he say???" I ask.
"He said 'Yes'."
Understated, playing it cool, like many teenagers do with their parents. But I know he's deeply excited, and probably a little bit scared.
He just got a gig working at the table-top and role-playing store in the building next to our apartment block in Brisbane, Australia.
I coached him how to get it. I saw that he was enthusiastic about the games they sell there. He plays Magic - The Gathering (MTG) there with his friends, and a couple of weeks ago I came home to twenty teenagers (yes - 20!) in our apartment playing the game. He went to the recent MTG pre-release and played it all day.
"Why don't you ask Sean if you can do some part-time work in the store?" I suggested. Sean is the owner of the store.
Prahlad asked Sean, and Sean said that he doesn't have any work that needs to be done there.
"Go back and tell him that you want to get work experience," I told him. "Tell him you'll do it for free. That way you can learn from him. He is running a successful business, and you can learn that. You can learn how to DM, how to run events, and how to do customer service. You might find ways to expand the business. And if it doesn't turn into a paying gig, when the time comes you can get a job at another store based on your experience."
So he had that conversation, and he starts tomorrow.
The Impact GitHub is Having on Your Software Career, Right Now...
In 2017, I wrote my (so-far) most popular article of all time: The Impact GitHub is Having on Your Software Career, Right Now….
In that article I cast the vision for how you can develop your career through open-source contribution.
It clearly struck a nerve - it got 382 points and 237 comments on Hacker News.
Many of the comments disagreed with my main premise, but I felt that they had missed the point.
They said that:
- My experience at Red Hat was atypical. There are no other opportunities like that.
- I didn't know what I was talking about because I was a recruiter (they must have skipped my ten years in engineering at Red Hat part)
- It was unrealistic advice for developers with a day job in companies working in BitBucket.
- It wasn't possible for devs who work in companies in the financial sector with high regulation and security.
- It wasn't possible if you weren't willing to sacrifice your life outside work.
- It just wasn't possible.
There is nothing that I love more than a challenge, so I went "deep cover".
I quit my job as a recruiter, and got a job as a software engineer in a pure closed-source company that uses BitBucket and has PCI-compliant security.
Fourteen months later, I got hired by Camunda to work as the Developer Advocate for Zeebe - a workflow engine for orchestrating microservices, purely based on my open-source contributions while working at that job. I just did everything that I advised readers to do in the comments of my original Medium article.
While I was doing that, I didn't sacrifice my hobbies or my family, in fact:
- I kept building my side-hustle Magikcraft.io
- I did a launch event for Minecraft for Type 1 Diabetes that was filmed for Mojang's YouTube channel.
- I trained for and competed in three physique competitions with my wife - it was on her bucket list to win a bikini-modelling competition. She won her division, and I eventually placed 2nd in a State-level competition.
- I trained to lead a personal development course.
- I did a three-month long course with my son.
I don't say this to brag - just to show that it's not a zero-sum game, as some people paint it: "Oh that's easy to say, but it privileges people who are willing to work for free and sacrifice their time with their family."
False.
Of course, for the person who starts with the conclusion that "it's not possible", no amount of evidence is ever going to be enough - and to those I say: "What do you want to see now?"
Not because it will change their mind, but because it's a fertile source of inspiration for me.
Misconceptions and Strawman Arguments
Before I sketch out how to do it, I want to explicitly state a couple of objections that just miss the point:
- You can't tell anything about a developer from their contribution graph on GitHub.
- I've hired lots of developers and I've never looked at their GitHub profile.
Let me just say this: you aren't going to get hired through your open-source contributions by these people. That's all those things say. There is more I could say about that, but I'm not going to address them any further.
I also want to make it clear: I'm not saying that you have to do this. Just that you can.
How I did it
As I pointed out to commenters on the original Medium article, in your day job you either use open-source libraries, or may be able to introduce some to your stack on new projects.
If you don't have a day job, then you can introduce them to your stack easily.
While doing research for a new project at my day job, I tried a number of different projects - including a TypeScript gRPC server. I found a bug in it, and opened an issue. Then I wrote a patch for it, that got merged in.
We didn't use that project, but it was just part of being a member of a global community - like picking up a piece of paper in the hallway of our apartment building or on the street.
We eventually did use a gRPC library, and we needed it to support gRPC streams. So I wrote a patch for that, and it got merged. That contribution was enough to get me a mention in the contributors on npm.
I opened issues and submitted patches to Netflix Conductor (example). Nothing earth-shattering, just contributing to the environment I live in.
One of the things I explained to management was that a key decision-making factor in which technologies to adopt is how fast issues get addressed, and if we patch something for our own production use-case, how amenable the maintainers are to accepting our pull requests to the mainstream.
No-one involved in hiring me at Camunda looked at these (callback to the peeps who say they never look at people's contributions on GitHub - X-Factor judges don't watch you practicing in front of the mirror either - just sayin').
I will say, however, that smart recruiters at Google and Facebook would hit me up based on watching my activity. It's not enough to land a job, but it does have people come looking for you - especially as you build up a history of it.
The Big Break
The big break came when we landed on using Zeebe as the orchestration engine for our new microservices project.
I was over the moon, because Zeebe had an officially-supported Go client, and this was my chance to get our team coding in Go. I'd done some POCs and side-projects in it, but we coded in JavaScript.
No-one else on the team of six was keen to make the move, however, so we needed a JavaScript client.
I managed to get alignment on using TypeScript for the new project, and so I created a TypeScript client library.
I had logged some issues and contributed some small patches to Zeebe, as part of the civic duty / evaluation. Now, I pitched to management making the client library open-source.
My argument for it had two parts:
- It means that our library has the opportunity to become the most widely-used one, which means it gets more eyeballs on it, and the possibility of patches from the wider community. Meaning that we don't end up maintaining something internally and finding out later on that there is a more widely-used/supported one that we have to rebase on.
- It is a good developer-marketing tool to raise our profile, build our engineering brand, and differentiate us in the market when hiring.
I got alignment. However, the company had no GitHub presence. I got that by explaining that we needed a GitHub organisation in order to collaborate with the engineers at Camunda.
This is a company with no prior experience in Open Source. I had the advantage that I spent ten years working in it, so I knew both that it works, and how it works. Looking back at it, I probably wouldn't have stood for it the way I did if I had an ounce of doubt - if I "listened to the haters" in the comments.
Once that was in place, we pushed the library live, and published it to NPM.
One of the things that can you develop over time participating in open-source as a civic member, is a sixth sense of opportunities. I could see that this was an exciting technology that was poised to land on a rising wave - and we were about to ride that wave too. And there was no JS client.
It took over a year for the factors to align, but if I were sitting at my desk committing to BitBucket (yes, I was committing code to private BitBucket repos too) only, then I wouldn't see an opportunity like that in ten years.
I wrote an article on Medium.com announcing the library. I actually got in trouble for that. I jumped the gun and didn't get alignment for it before publishing. Lesson learned.
However, the library, the article, and my participation in issues, patches, and the Slack channel got me noticed by the folks at Camunda.
Enough so, that when I was looking for another role, they acted fast to hire their first employee in Australia - faster than local companies moved, even with their time zone and established infrastructure advantage.
On a call with Berd Rücker - one of Camunda's cofounders - I shared why I thought it was a good match: at Red Hat we would often hire or acqui-hire from the community (*acqui-hire means you bring an entire project in, people and tech - it's a portmanteau of "acquire" and "hire").
We would "find someone who was already doing it, and just pay them to do it for us". Normally when you hire, you find someone, pay them, and hope that they will enjoy what they are doing and be good at it. Hiring open-source contributors reduces the risk. They still might turn out to be terrible to work with, but you have a sense already of how you work together, and you know what their work is like.
It's a universal principle
So it's the same thing for my son. He has the opportunity to demonstrate value, build trust, and gain skills at the gaming store. And when the time is right, he will start getting paid - either there, or elsewhere.
At the careers fair for Red Hat in 2004, I brought along a 20-page paper I had written where I predicted the future of tech: open-source eating the world; devices shrinking to hand-helds; emergent network effects. I wrote it on breaks while working on an ISP help desk, between installing Linux on old computers I bought for $20 a pop.
In a recent Slack discussion, someone said: "The problem with Open Source contribution is that it privileges those who have time to do it"
Firstly, that's the opportunity of Open Source, not the problem. Secondly, everyone has the time - and I would say civic duty if you use it - to contribute something.
And lastly: yeah, that's right. Just like people who have the time to play clubs and pubs every Friday night, and practice their chops in their bedroom are privileged to be able to be discovered by an A&R talent scout and get a record deal.
The Beatles played for two years straight in Hamburg to hone their skills. As a professional software developer, if you are going to hone your craft anyway, you might as well do it in a way that contributes to a greater civic good and your own portable, public reputation.
Or not. Whatever.
I'm just saying that it is possible.
Top comments (0)