I previously worked at Bright.md as a Full-Stack Python developer on a small team that built and maintained an application called SmartExam, which helps patients connect with their healthcare provider from the comfort of their own home via text-based interviews.
In my time working on SmartExam, I led the development of many new features. This involved forming a deep understanding of healthcare partner needs, collaborating closely with other teams and departments, and sometimes even working directly with third-party vendors. I also led the adoption of automated end-to-end testing of our application with Cypress, triaged and fixed bugs, participated in our on-call rotation, and helped with regular deployments of our application to customer instances. I worked in and got experience with several technologies, including AngularJS and MongoDB. Most of all though, working on an application which needed to be reliable and secure while serving doctors and patients at some of their most vulnerable moments helped me grow my understanding of designing with empathy, and taught me how to prioritize the user experience.
Additionally, I joined Bright.md when the company was very small. As a result, my tenure involved juggling and balancing many responsibilities in the face of competing priorities, including new feature work, meeting the needs of existing partners, and improving the resilience and scalability of our application. Because of the fast-paced nature of a small startup, I also got experience with responding to and dealing with changing processes, team growth, and frequently shifting product needs.
During my tenure as a Software Engineer at Puppet, I had the opportunity to work on several projects across multiple teams, the vast majority of which were open source and written in Ruby. In addition to my development work, my responsibilities regularly included interfacing with and supporting our open source community, both through hosting live triage sessions and working directly with community members to merge their contributions.
For quite a while, I worked on the team responsible for maintaining Puppet’s Domain Specific Language and related tools. During my time on the team, I built the CLI for the catalog preview and puppet lookup tools, and contributed to other language efforts. My biggest project, however, was leading the development of a new automated documentation tool called Puppet Strings. Puppet Strings automatically generates HTML documentation pages for Puppet components written in Ruby and the Puppet DSL by processing code and comments, and is an extension of YARD, a popular Ruby documentation tool. I worked heavily on this project for a few months, and mentored an intern who worked on it over the summer. Eventually the project was passed to another team, who put the finishing touches on it and released a 1.0 version of the tool.
Later in my tenure at Puppet, I briefly worked on the Client Team, which worked on the client side components of open source Puppet. While on this team, I maintained core Puppet components and helped with initiatives like Direct Puppet and the C++ port of HOCON.
I also spent a while on the Modules Team, where I helped to develop and maintain the host of modules that Puppet has developed for users. During my time on the team, I was involved in several different efforts, including 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 joined a small team dedicated to working with our open source community. This team was tasked with finding a good way to manage the growing influx of external code contributions, and explored ways to both support and engage with the community while enabling engineers within the company to focus on their own work.
In addition to working with community members to merge their pull requests and make contributions to core open source libraries like Puppet, I spent much of the summer working on a web app to collect, analyze, and display data about how well we responded to community pull requests. The app also helped to highlight contributions that were being neglected so we’d know where to improve. The app was highly customizable, which allowed it to be adopted and used by other teams at the company.
I spent my first internship at Puppet on the team responsible for maintaining and developing their core open source tools. During this time I was fully integrated with the team, and my work involved fixing bugs, developing features, and interfacing with the open source community. And since I was new to programming and professional software development, all the while I was also ramping up on new tools and languages.
I worked primarily in Ruby on Facter, a system-profiling library integral to the core configuration management functionality of Puppet. My biggest addition was the integration of external facts. At the time, Facter already supported custom user-defined facts written in Ruby, but external facts allowed users to define their own facts via basic config files or scripts.
During my time at Puppet I gave several talks related to my work there!