Listening to SE Radio 655: Charles Humble on Professional Skills for Software Engineers, it discussed many useful or necessary skills for new programmers. But what caught my attention later in the podcasts was that it talked about writing blogs and contributing to open-source projects. More specifically, it showcases the person’s technical prowess (when contributing to an existing code base), and most importantly for me, how you adapt to other people’s coding style (when contributing to other people’s code).
Technical Prowess
May it be fixing bugs or adding a feature, contributing to an existing code base show cases that you can learn the complex codebase of other people and apply the needed changes.
For fixing bugs for instance, it shows
- that you are able to debug properly and find the problem
- apply the solution
- write the required test (most projects often require this)
Why a codebase of your own is not as impressive (for me at least)? The concept under a project code be some very complicated domain that you know such a software to initiate nuclear fusioin (is there a code base for this?), but it does not really show case how you work with a team. It show cases initiative, which is great, but I have hired people who are very good at creating projects from scratch and work on their own code, but for the love of god, have never developed the muscle to read and analyze other peoples code. It is sad and I have to let them go.
Lesson, contribute on other peoples code. You are bound to work with other peoples project as a dependency. These projects often have bugs or limitation you want to expand upon with a new feature.
Coding Style
Above section, Technical Prowess, already kinda covered this. If you are able to analze a code base to apply your own fix/feature, you were probably able to figure out the coding style of that project and able to work with it. Being able to learn and apply people’s coding style is very important in opensource project, and in an enterprise organization (where you are finally paid).
Being able to contribute means not just having a fix/feature, but writing such fix/feature in a way that conforms with the convention with that specific project. These convention could be (but not limited to):
- Location of tests
- Location of src
- Are tests required?
- Are documentation required?
- File name style?
- Do they prefer Object Oriented?
- Do they prefer functions?
- Do they love globals?
- Naming convention of globals?
- Do they love stateful programming (OpenGL)?
- And so on and on…
You probably have your favorite style for depending on the coding language for your own projects, but contributing to opensource, you will learn to be able to change your style depending on the project.
Conclusion
Contributing to opensource projects makes you more attractive to hiring managers. From a simple demo of technical prowess, to showing that you can work with different coding style and not hold your preferred style in some philosophical superior level and force it on people creating frictions (trust me, I have seen people make 1000 file commit, calling a change from snake case to camel case, a refactor, thank god it is not my project). Hope you find this interesting and I’ll now drown my head with Tequila in my Friday night.
