My GitHub account can be found at github.com/rlinehan.
I'm fortunate that some of my past work has been open source. Below I have highlighted some of the open source contributions that I feel illustrate my skills.
I've worked in Clojure, Ruby, Java, Javascript, Python, Puppet, Bash, and more. I am not dogmatic about my programming language choice, and I am good at picking up new languages.
Writing code is never a solo activity; communication is one of the most important parts of working as a software developer.
One example of my communication skills is this PR, of a metrics API for tracking requests made by an HTTP client.
Designing the API for this feature involved a lot of collaboration with my teammates, and this PR was the second iteration of our design. After I began implementing the first API design, we realized that there were more requirements and that there would need to be both a Java API and a Clojure API. The commentary on this PR shows our communication to resolve the additional requirements and agree on a reasonable API for this feature.
(I also believe very strongly in the importance of thorough testing. I think this is evident in the tests added for this feature).
Being a member of a team means writing maintainable code that others can follow. When I review a pull request, I don't want to be surprised by anything, so I try to ensure the code I write meets the same standard. The version history should be broken up into distinct commits with commit messages describing their purpose. There should be comments for anything that is unexpected or confusing. It should be possible to follow the tests. The documentation should include how to run the code and the tests.
This PR, which integrates a feature I was working on with a codebase I didn't often contribute to, shows how I follow these principles.
I believe that code review is useful not just for ensuring good code quality and catching bugs before they make it to production, but also for knowledge transfer and ensuring team ownership of a codebase.
One example of this is a pull
request I reviewed which fixed a bug in some caching logic in the
server.
I was not familiar with the feature this was fixing or with this
section of the codebase, but by
reviewing it and ensuring that the tests were understandable
(especially to someone unfamiliar with the code), I was later able
to go back and work on this code myself.
(October, 2021: GitHub has changed how commit comments are displayed, and most of the contents of this review are unrecoverable in a readable format. I'm looking for a replacement example.)
One of the projects I worked on as a member of the Puppet Server team at Puppet was separating out a Clojure library used to manage pools of JRuby instances.
We knew that other teams were starting to look into using JRuby, and we wanted them to be able to reuse our pooling functionality. By separating out the most complex code into its own library, we were able to refactor it to make it more understandable, better tested, and with a clearer API.
In refactoring this code to separate the library out, we made sure to maintain the git history, because it held a lot of important context for past decisions. We added clearer interfaces so that other users could easily hook in functions when creating and destroying JRuby instances. We made a clear division between what was public API and what was private and we separated the namespaces out so that this distinction was plain.
We also were able to simplify the tests significantly. When this code had been part of a larger application, the tests had to do a lot of mocking and were full of race conditions. We were able to clean up these tests to make them more reliable and more understandable, and in doing so we decreased the test time of the application by 25%.
I think we succeeded in building a library that provided a reusable interface to a very complicated system of lifecycle decisions and concurrency problems.