In consulting, lulls between assignments are an excellent time to investigate a new technology or language. Sometimes, that effort leads to being able to contribute fixes or new features to a software community. Doing so creates the opportunity to expand our skill-sets and deepen our understanding in new areas of software development. I recently had just such an opportunity.
Armed with that information, I turned to the project itself. I started by reviewing the project documentation and code base to ensure that my contributions would fit well within the whole. This is a valuable skill to have, regardless of whether the project is open or closed, internal or client-driven. Discussions with other users in the GitHub discussion threads provided additional insight into what other people hoped to see in the new feature. These points gave me a set of goals that could be used as acceptance criteria. At this point, writing the code for the new feature was fairly straightforward. Once I was confident that my solution was ready to share, it was time to submit the code to the project.
I wrote up an addition to the documentation covering the new feature and submitted a pull request to review and include my code. The review process was an excellent learning opportunity, as the primary developers for the project were able to point out a couple of improvements to my coding style and uncovered a sneaky bug that I had introduced. It was very clear that they appreciated the time investment that my contribution represented, and they wanted to make sure that the result was high quality code. We went back and forth several times with new suggestions and updated code commits. Within about a week we had improved my code submission significantly, adding new functionality and reducing complexity. The back-and-forth communication was key to this process; I learned nearly as much from the review as I did from writing the solution in the first place.