I currently work as a Full-Stack Python developer on a small team that maintains an application called SmartExam. SmartExam is an application that helps patients connect with their healthcare provider from the comfort of their own home via text-based interviews.
I help maintain the application and work with the rest of the team to design and implement features to continue to make the application as usable and convenient as possible for healthcare providers and patients. Our tech stack includes Python, MongoDB, AnuglarJS, and Twisted.
After I graduated from college I started as a fulltime Software Engineer on the Language Team. The primary job of the Language Team was to maintain the Puppet language and related features, as well as some server side components of open source Puppet. Initially I helped with the final stages of the migration to the new language parser, which was released in Puppet 4, but I spent most of my time heading up the Puppet Strings project, a new documentation tool.
We had an existing tool, “puppet doc”, which extracted documentation comments from various components of code written in both Ruby and Puppet. However, the tool was brittle and hacky, and also relied on the old Puppet language parser. I was charged with designing and developing the new replacement based on a prototype that had been built with YARD. I worked almostly exclusively on Strings for several months, until the project was temporarily shelved due to a shift in priorities. I continued to do minor maintenance on Strings when possible, until the project was taken over by the Language team’s summer intern, Ian Kronquist. I mentored and worked with Ian over the summer as he made significant improvements to Puppet Strings and added new features. After Ian left the project was shelved again, but was picked back up by the newly formed Puppet Developer Experience team, who put the final touches on the project and released a 1.0 in 2016.
Outside of my work on Strings, I also created the CLI for catalog preview and the puppet lookup tool, two Language related features. I also engaged with the community and helped to host regular live community triage sessions, in addition to working with community members to merge their contributions into the code base.
For a few months I transitioned to the Client Team, which worked on the client side components of open source Puppet. While on this team I continued to work with the community, maintain core Puppet components, and help with with initiatives like Direct Puppet and the C++ port of HOCON.
Due to a reorg, I soon hopped teams yet again, and joined the Modules team at the end of 2016. I am still working working with the open source community, but this time on developing Puppet modules rather than Puppet itself. I help to develop and maintain the host of modules that Puppet has developed for users, and have helped in such efforts as documenting our modules with Puppet Strings compatible comments and doing i18n work to prepare modules to be localized into other languages.
During my second internship at Puppet, I worked on the experimental Community Development team. The team was created to try and address the growing amount of community contributions, as we had yet to find a good way for engineers to have the time to keep up with them in addition to their other development work. The team was made up of myself and two other engineers dedicated exclusively to responding to community contributions and exploring ways to improve our community engagement.
In addition to working with community members to merge their pull requests and make contributions, I spent much of the summer working on a web app that would collect, analyze, and display data about how well we responded to pull requests. The app also helped to highlight contributions that were being neglected so we’d know where to improve. In developing the dashboard I tried as much as possible to make it customizable, which led to another open source team using it to track their community contributions as well.
At the end of my internship I returned to PuppetConf 2013 to give an updated version of the talk I had given the previous year.
My first internship at Puppet was after my Sophomore year of college. I worked as a fully fledged member of the Platform team, engaging with the community as well as maintaining and adding features to the open source components of Puppet. I’d only taken two programming classes (one in Java and one in C), so I had to contend with a steep learning curve with respect to Ruby, git, and a long list of operating systems, on top of the software I was working on.
Although I did some bug fixing on Puppet, I spent the majority of my summer working on Facter, a node data tool that is an essential piece of Puppet’s core infrastructure. Facter must be able to collect node data on any operating system Puppet supports, including things like Gentoo and Dragonfly BSD. As such, I spent quite a bit of my time trying to improve support on those platforms, both by helping to integrate patches from the community and writing my own. My biggest project, however, was adding external facts. Facter already supported custom user defined facts written in Ruby, but external facts allows users to define their own facts via basic config files or scripts.
At the end of my internship I teamed up with two other interns to give a talk at PuppetConf 2012 to offer our perspective on getting up to speed to become an open source contributor.