Journeying into Open Source: Part 2 — Building your Network
How you can leverage Open Source to help develop and grow your career as an engineer
This is part 2 of a three part mini blogpost series on the advantages I learned I could leverage that come from participating in open source in my career. If you want to start from the beginning take a look at Part 1.
In the previous section, we took a look at how you could grow as a developer by looking at how you can better understand your tools, and break out of your usual patterns.
In this section, we’ll take a look at the people side of open source and what advantages working with people outside of your job will actually help you with.
The people side of open source
Working with new people wasn’t something, I had consciously thought would bring any significant advantages or learning experiences. By participating in open source you’ll end up working with people that you’ve never worked with/have never met. There are various projects of all different sizes, but if you’re looking at working on a new project and it’s a project you didn’t start and are just jumping on to, there will be at least one other person you’ll have to collaborate with.
This might not be something that immediately jumps out as an advantage…
But when you take into consideration how people communicate and what they communicate about, it can positively or negatively affect your experience. For starters, if you’ve ever been on a team that for whatever reason doesn’t perform code reviews, then you’re pretty much guaranteed to participate in one here. This is where it gets really interesting. If you’ve participated in these before, or currently have these as a part of your development lifecycle, there’s a chance that you already know the kinds of comments or questions that are going to come up with your team. As a team, you’ve decided that you care about following certain practices. On this new codebase you’re working with different people. Different people means different ideas and points of views. In software there isn’t always a “right” way of doing things, and the more people you work with, the more that tends to come out.
For example: Some projects are strictly “no tests = no merge”, where some people have never really had testing practices encouraged before. To me, this was a huge learning curve. I hadn’t been on teams that had really written tests heavily before, and most of my time was spent actually figuring out how to write tests.
You might encounter a project whose community particularly cares about nice structured commit messages. This is such a big deal to some people that there are all kinds of sources out there that people use to help defined what a good commit message looks like to them. I never had to focus on this because I’ve never been on teams that had been around long enough to have a negative experience going back through their commit histories without being able to find specific changes that caused issues. In open source projects that have been around for so long, and that have so many people contributing to them, it’s of paramount importance that people leave good documentation trails.
Usually these are things that you have to get used to. But in many of cases, you might find that these things make your experience as a developer more pleasant and might be something you can even bring back to your team. Are there just too many differences in their practices and things that they value? Then lucky you, you don’t work for them so you can just not participate and find something else.
Following some of these practices seems obvious to a lot of people... Structured commit messages, tests, code style, submitting pull requests etc., but with all the different backgrounds people are coming from, many of us skip things like these. If you’ve come from a startup environment where you’ve had to move particularly fast to ship software that means deadlines for rounds of funding, you probably skimped on writing tests and good commit messages. You might not care about code style. In another case, if you’re on a team at a company that’s been around for so long that they no longer question anything they do, where most people there have inherited processes because that’s just how they’ve, “always done it”, then there are more than likely new habits you can pick up.
Getting hired and hiring
Working in open source makes you very visible…
There are cases where the people that you’re collaborating with on open source projects will work at other companies where they’ll be hiring. These “other companies” might pique your interest and if you’re interested in applying, the best place to start might be through the people you’ve been working with in the open source repos. This is for a few reasons:
- Hiring is a risk. No one interviews perfectly, and no one has quite figured out the interview process. Bad hires happen, and conversely, people miss out on good people because there isn’t a one-size-fits all interview process. At the end of the day, people are trying to figure out how they’d work with you and what your skill set is. If they’ve gauged both over an extended period of time because you’ve been working with them already, then the interview sometimes just becomes a formality. In some cases it’s really just a culture interview with other members fo the team.
- You also interview the company, and in this case you know what it’s like to work with those engineers as well. This doesn’t really imply that people are being disrespectful or rude, but sometimes communication styles are different, their established practices might be something you’re not so hot on, or various other reasons.
- Say they’re not at a company you’re currently interested in. People move around and some times go into positions where they’re now building the team. If you’ve worked in an unofficial capacity with them before, and you’re now interested in their new company, this is a great way to get in.
Many of the engineering hires that get made aren’t because they’re the “best” engineers, it’s because they’re the most visible and they meet the hiring bar. It’s not who you know, it’s who knows you, and your ability to get the job done. Building your skill set in a public way can be a great way to build out your brand as an engineer.
This concludes part 2 which covered how participating in open source projects can help you build your network. In part 3, we’ll go over how you can start dipping your toe in open source with some tips on how to get started. If you have any questions, feel free to continue the conversation @rmorenocesar
