This is the 6th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.
As an employer, or even a fellow developer, I want to see your passion for this industry. One of the best ways to do this is to have some of your favourite projects’s code open to view by me and others.
What is Open Source?
Open source is a term used to refer to codebases that anyone can view and propose edits to. Most notably for our industry is the website GitHub, which hosts almost all open source projects.
Open sourcing projects is a great way to get involved in the community — it lets you interact with other developers, it lets you learn to code better, and it even can help you become familiar with large code bases, something often quite daunting for junior developers.
How do you start?
But how do you start? First, I’d try something really, really simple. Go find a project you like, maybe it’s your favourite ruby gem or or an npm package and start reading the code. We’re not looking for logical flaws here, we’re looking for typos. Yes. Typos. Typos in comments. Your first pull request to an open source will be a typo correction. You will change reuturns to returns. You will change him to them. You will change whatever you can find that is trivial and safe.
But the change isn’t important. What is important is how you them propose the change. Look around a bit, and you’ll most likely find a contributor’s guide or a section in the read me. These sections will tell you how you make a change to the code base. How you check out the code, run it, branch naming conventions, PR conventions etc. You might also want to read last week’s Code Reviews blog for a good read on how to create a great PR. Also it’s a great time to interact with the maintainers of the project, and start that relationship that will be helpful to have as the intensity of the PRs increase.
Now that you’ve learnt how forking and creating pull requests works, it’s time you open source something of your own. But what Sam? Well, do you have any projects from Uni or bootcamp? How about that script you wrote one weekend for a laugh? How about that code you wrote a hackathon?
The code doesn’t necessarily have to be good (whatever that means?!) just get it online. It doesn’t have to be finished. We just want to see you’ve done something. And yes, you don’t have to get fancy and write a contributing guide like the one above, but a simple yet effective ReadMe will be helpful.
What a Great ReadMe Has
So what goes into a great ReadMe?
- A description of the project. What does it do? What does it solve?
- Installation of the code into your own, or how to run it on your computer
- Common (trivial) examples of usage
- Comments about how to contribute. This can be simple
- A link to more information, documentation or support
- A list of known bugs, limitations and/or a To Do list of features. Although these should also be issues in the GitHub repo
- Optionally, a list of people using this code inside theirs (in the case of plugins etc) or top contributors
- If no LICENSE.md, an indication of the license of the code (MIT, Apache etc). Use Choose a License to determine this
What a Great Repo Has
So that’s a great open source ReadMe. What else should a great repo have (apart from code)? (Yes, I know, some of my projects don’t have all of these)
- A ReadMe
- A Contributing Guide
- An Issues template
- A PR template
- A License
- A Code of Conduct
So go on, set up your GitHub account (they’re free). Learn the fundamentals and get started! Look at you go! Open sourcing is a really great way to get involved in this community and it will really help you grow your technical skills as a developer. I wish you the best of luck!
This is the 6th post in my Junior Developer Diaries blog series. I’m writing more every week, and you can sign up to hear more and read previous posts on my website.