The 3 Reasons Your First Open Source Project Will Be Your Best.
Learn why your first step into the open source world isn’t as scary as it might seem, and why it is of the utmost importance.
How does one learn programming? Most would say through online research, tutorials, and extensive reading. This method has been proven effective time and time again, yet is it efficient? If you read a book on programming in python, will you really be able to remember all the syntax and distinct traits of the programming language years from now? How many times will you have to review the original text before you are considered an expert? Because it is so difficult to engrave this vast amount of knowledge into our brains, hands-on learning is a must. Only through making countless mistakes can we learn how to efficiently and effectively write well constructed code in a given language. Yet this begs another question, how do we know when we make these mistakes without going back to the books? This paradox of needing to understand your mistakes to grow, yet not being able to find your own mistakes is what makes learning programming such an arduous process. So how can we speed up our learning rate or reduce the amount of time we spend sifting through our code? Due to this whole learning system hinging on how fast we are able to find and correct our mistakes in our code, one of the best solutions is to have as many eyes as possible review it. Yet you can’t just give your newly created project to your siblings or parents and expect them to understand it, you need a very specific audience to review your code. This is where the true advantage of open source lies and why your first project will be your best. Your first open source project will give you…
1) Better code than you could write yourself
2) An Improved rate of Personal Development
3) An Outlet to Establish Yourself as a Programmer
Better Code
The most apparent and important thing that your first open source project will give you is a taste at what it’s really like to program. It will be your first experience coding with tens or hundreds of people, and will make you realize that you’ve been missing out by going at it alone. Better code is generated not only by experienced programmers, but also by minimizing the number of mistakes in it.
Because we’re not all veteran programmers, the thing we have to focus on is reducing the number of mistakes we make. One of the most effective ways to do this is follow a standardized process. Just as if you were writing an English paper or drafting a sketch of a piece of art, there is a revision process required to get from your draft to the final published work. Fortunately, It is a simple and widely known process: write, review, edit and many of us use it when we write code by ourselves. We first attempt to write some code that tackles a certain problem, we then test it and if it breaks review it for the syntax errors, and finally we edit the code so that the program can function. The problem lies in the fact that searching our code is tedious, and how will we know where we made a semantic mistake?
Your first open source project will introduce you to the advanced version of this process: Correct, Circulate, Criticize. First we find a problem we wish to correct in our lives, and code a solution that we think will patch it up nicely. Second, we post our solution and explanation as to why we believe this will solve the problem on a public open source repository such as Github. Finally, our work is criticized and reviewed by other programmers who find the same problem intriguing, allowing us to not only find our mistakes faster, but also have our semantic errors pointed out. Then we cycle back and once again correct and publish our code, leading to a fast paced iterative review process. In this fashion not only does our code become better syntactically and semantically, but we also reach the exact level of coding expertise we need. For instance, if you are just writing a hello world program maybe one of your equals could point out that you forgot the semicolon at the end of the line. However, if you are creating a fully built application to manage your personal finances, someone who currently works developing in the financial sector might give you some pointers. The scope of your project will reflect the scope of your contributors. In this manner as your project’s code grows and becomes more focused so will your contributor base, generating syntactically and semantically sound code.
An Improved rate of Personal Development
Your first open source project will not just give you better code, it will give you a different perspective on your current skills. Developing and publishing your first open source project will introduce the ability for your work to be questioned for the first time. This inquisition comes not only from the contributors to your project, but as you continue to develop your open source code, your own questions will arise about previous personal design decisions. This initial questioning of your own work will lead you on tangents of great personal development. For instance someone could simply comment that your documentation is visually very hard to look at or understand. In doing so you will feel obligated to seek out the latest and greatest methods to improve this weakness. You will be exposed to new tools you haven’t ever heard of before, and gradually learn how to adapt and incorporate to new tools quickly.
In publishing my first repository I found that my work looked very different compared to that of other repositories out there. Not the actual code even, but just the way my README file and documentation were presented on GitHub. I quickly learned that other developers were not writing README.txt files but README.md files. A Markdown file (.md) is something very different from a simple text file (.txt) and many online repository providers support this file type due to its ease of editing. Essentially Markdown is, get this, a markup language, which is just way of writing files where you place in-line instructions on how to format the actual context of each line. Markdown specifically is preferred by a large portion of the opensource community as it allows for much more efficient documentation formatting. If I had never questioned my own work or had another question me, I may never have learned about this useful markup language. Along with this README tangent I looked to improve other areas of my documentation and stumbled upon tools such as Coveralls, for displaying code test coverage accurately, Asana, for project management, and much more.
Long term you will learn not only how to adapt and incorporate these tools in a meaningful way, but you will also develop a style for generating and managing your repositories. The more you read about these tools and different programming practices the more you will find what works for you. Remember there is no “right” way to do something in a programmers world, as everything can be done from a very microscopic base level given enough time. Yet, you realize that there are tools tailored for certain jobs and utilizing them to their full potential makes your work much more efficient. On top of that the more you familiarize yourself with the current tools out there the more you can draw parallels and see potential benefits and pitfalls of new tools. This experience is exactly what makes a developer tailored toward certain company roles and will streamline your on-boarding process at any organization.
An Outlet to Establish Yourself as a Programmer
One of the most beneficial things about the open-source world is that it doesn’t matter why you are developing something. Be it personal, educational, or professional reasons what matters is what you can gain from doing it. On top of pleasing your boss or learning something new their is another reason that open-source development is so important. It allows you for the first time to build coder’s rapport and define why you matter in the ever changing tech world.
You build coder’s rapport by being exposed to all the terms and tools that coders use each day, and in doing so establish a basis for the common language between developers. You will learn to collaborate better in groups and have plenty of talking points when asked what you are working on any given day. On top of building rapport your analytical worth can be evaluated by other individuals just by looking at your GitHub profile page. If you didn’t already know, the numbers matter when it comes to proving your worth in an enterprise environment. Ironically one of the biggest things many organizations look for in job candidates today is experience, one of the hardest traits to quantify. If they view your GitHub profile page to see that you have made numerous contributions to all sorts of projects, it is going to go a long way in establishing you as an experienced programmer. As finally there is a metric you can provide that traces the road-map of your personal experience as a developer.
Whether your first open source project is a funny joke generator or a complex solution to analyzing algorithms, what you take away from it will be more valuable than any other project you develop. In opening yourself up to the open source community you will see rapid improvements in your code, your toolkit, and your reputation. You will be able to finally talk the talk with your newly found rapport and walk the walk with numbers to back it up. The only question about open source you should have left is: what are you waiting for?
