Journeying into Open Source: Part 1 — Becoming a Better Developer
How you can leverage Open Source to help develop and grow your career as an engineer
Open source is talked about in our community on a pretty regular basis. Chances are, a few of you use third party open source libraries in some of the systems that you work on. If you’ve used those tools enough, you might even have opinions on how you could make them work better, or functionalities they have that you dislike. You might have even found some bugs in them as well! The good thing is, you actually have some amount of control over what is possible to publish to these tools, and besides just contributing to the greater developer community, it’s a great way to grow your career as an engineer as well.
Contributing to open source might be something you’ve never really ever thought of, or maybe you have and for various reasons decided not to contribute, but it can be a really valuable experience. It actually took me quite some time from knowing this was possible, to actually making my first commit onto an open source project. Initially, I did it just out of the shear curiosity of how the project I contributed to actually worked, but I learned so many more reasons to participate along the way.
In this three part series of blogposts we’ll go over:
- A quick intro on what Open Source is — Part 1
- How participating in Open Source makes you a better developer — Part 1
- How you can use it to develop your network — Part 2
- How you can get started participating in Open Source — Part 3
What really is Open Source?
This was really meant to help people of all ranges of experience. So I’m making the assumption that you might be making your first leap into tech and not really know what open source is. If you already know what Open Source then you might want to skip this section and go straight to how it makes you a better developer below.
The internet will give definitions like
“Open-source software is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose.” — Wikipedia
It’s not the worst internet definition I’ve ever read that explains a technical concept, but I like to simply put that open source is code that is made available for a developer’s use and modification. That’s a sufficient enough explanation. At least, it usually tends to be the case whenever I explain it to my non-technical friends.
These open source projects are hosted on public repositories that live on websites like Github, Gitlab, or Bitbucket. In terms of popularity, Gitlab is one that has been picking up steam, but in my experience I tend to default to, and gravitate towards Github whenever I hear people talk about open source.
How Open Source can make you a better developer
Participating in open source can really help you break out of your typical development patterns…
For some context, I’ve most recently been working in Android. In Android land, we tend to have some pretty common patterns that we follow which are set forth by Google, the maintainers of the Android operating system. By patterns, I don’t really mean patterns like Singletons, Adapters, etc. I mean literally going through the same motions and thinking about the same things over and over and over. In Android, one of the most common UI patterns we tend to need to implement is creating a list. That means setting up your adapter, override onCreateViewHolder(), override onBindViewHolder(), override getItemCount(), etc. etc. If you’re not from Android land, you don’t need to know what any of these do to understand. Just know that it’s a repetitive task that we always go through to get the list to work. Everyone can probably think back to their technology stack and mentally resurface a few unavoidable boiler plate items that are given to us for free as a part of the framework. We tend to establish certain routines and workflows in order to get things to work, and to make working within our teams run more smoothly. In other words, you get really good at what you do.
That’s definitely not a bad thing, but you might be thinking about how you can start doing something new and grow a little bit more than you are. The projects that are made available to you at work aren’t something that’s always in your control, there are plenty of times where the business needs might have you stuck in a technology rut. Sometimes it’s hard for you to pitch to the stakeholders to wait a little longer on a deliverable because you want to ramp up on a part of the codebase that’s new to you. The limitation might not even be just unfamiliar code, it could just as well be a programming language that’s new to you, a build system that has to handle things that you’ve never had to consider, a new library or part of a framework you haven’t needed to use until now. There really could be various things.
In getting into these routines, the actual code you write tends to look the same as well. You’ll never really know an entire programming language, but if you’ve been on a team that writes code one way, chances are that once it’s worked, you tend to keep writing the code that same way. At some point, because you’re used to working at a certain speed, you even stop questioning why something was implemented a certain way. You just know that it made sense the first time you or your teammate did it, so as you’re implementing something very similar you do it that way again. In many of these cases, it’s the way it makes sense for the platform. This means that, at least for the time being, you’ll never use any of the other language features that also allow you to do that thing differently.
This uniformity of code isn’t helping you grow. When I first started jumping into open source, I realized just how comfortable I had gotten looking at the code in my team’s codebase and being able to work in it. Looking at another piece of code, especially one that was outside of the frameworks I was used to working in, really got me back out of my comfort zone with everything being so different. This isn’t to say you or your team are currently doing things wrong, but sometimes you might re surface why you’ve been using specific tools and technologies or find a new use for a feature in the programming language you use every day. I personally focused more on projects that weren’t Android related in order to get an idea of the kinds of problems engineers faced outside of that space. In some cases, it even made working with other engineers easier because I had more empathy for how tough those challenges were.
Participating in open source can also really help you understand how your tools work…
I’m personally guilty of having used third-party libraries without knowing at least the bare minimum of how they work. The first time I realized this was an issue I was in an interview where I was asked if I knew how a certain library performed a core task. My answer was basically just…
The reason this mattered, was because the library used reflection, which is particularly expensive so performance took a pretty massive hit at runtime which could be avoided with some other alternatives. The particular company I was interviewing for couldn’t really work with that, so they had reasons to find alternatives to a library that was generally considered to be a go-to in the Android space. That day I was forced to realize how much of a detriment it could be to my growth if I didn’t understand what was really going on under the hood of all the tools and libraries I was using.
This topic could probably be a post all on its own, but for the purposes of diversifying and growing in your skill set, really digging deep into the tools that you’re using and how those “magic” tasks are implemented allows you to gain perspective on things “beneath” the frameworks that you’re using.
The end goal of this really isn’t just so that we know how the technology is working. It’s compartmentalizing a mental model for breaking down problems. In understanding how the tools we use work, not just what they do, we empower ourselves to write better code that goes beyond what we can find in the documentation of said tools, or beyond what the SDK’s we’re working with give us right out of the box. Not only that, but when these tools break, which they will, it’s not always a complete blocker. By understanding the underlying issues, you can write creative temporary work-arounds, or you might even decide that you can stop using the tool altogether because you know enough to roll your own. I’m not saying you should reinvent the wheel just because you know how, but you might be able to take the solutions that those tools were optimizing for, and then apply them somewhere else.
This concludes part 1 which covered how participating in open source projects can make you a better developer. In part 2 we’ll go over how participating in open source can help you grow your network. Feel free to continue the conversation @rmorenocesar
