As more and more people enter the software industry each year, companies can benefit from learning how to bring out the best in their engineers. To that point, this is the story of how my team at Formidable and I quickly built something ambitious and valuable, without compromising my learning, support, and autonomy along the way.
Choosing problems worth solving
As a software consultancy, most of our time is spent on client projects. However, we sometimes have opportunities to work on open source software (OSS). At any given time we are supporting up to 70 OSS projects, and we also keep track of problems we encounter that don't yet have an established solution.
One such problem was identified by Luke Jackson's research about build-free single page applications. Browser support for ES6 modules is rapidly improving, and while the unpkg CDN provides infrastructure for taking advantage of them, there was no user-friendly way to explore these scripts and their dependencies.
I was part of a small Formidable team tasked with coming up with a solution. We affectionately gave this project the code name "Dora The Unpkg Explorer," which eventually became runpkg. My teammates, Luke and Kara (read Luke's intro to the problem, and Kara's write-up about the CI/CD strategy we chose on this blog), have already written about the project's technical aspects. This post describes my first experience with a professional open source project.
Idea to execution
I was pleasantly surprised how much autonomy I was given on my first project. I jumped straight in and built a basic proof of concept. I cloned Luke's es-react boilerplate—the obvious choice for a project focusing on ES6 modules—and got to work. A few lines of RegEx, a couple of React Hooks, and a fetch request later, we had a working prototype that allowed us to click through the imports of the lodash-es package.
After quickly validating this solution, Luke, Kara, and I spent a two-week sprint with the aim of producing something useful to share with the wider developer community for validation and feedback.
Even in the short sprint, we found quick feedback cycles proved effective for directing our development. After a few days of work, we showed our work-in-progress version to our colleagues, whose questions and insights unearthed new feature ideas, identified UX issues that we were blind to, and helped us to prioritise our remaining tasks.
Despite feeling like we were 80 percent complete after the first week, the end of the second week rapidly arrived, and we still had dozens of features and refinements in mind. However, we were all well aware of the trap of feature creep and the fact that nothing is ever completely finished. Instead of pushing back the release, we documented what still needed to be done and used our remaining time to tackle edge cases, update the documentation, and send Dora out to explore the world wide web.
Concept to production in two weeks
We launched the project (runpkg.com) on Twitter, and quickly received positive responses from Michael Jackson (the creator of unpkg) and Dan Abramov from the React core team. After a half hour of basking in the warm, fuzzy feeling of a successful launch, we got to the most valuable part: addressing the feedback we'd received in the form of tweets and GitHub issues.
The community raised helpful, constructive issues that we've used to address the accessibility of runpkg, as well as improving syntax highlighting and the mind-bending recursive dependency fetch, which we rely on for discovering all of a script's dependencies and computing its "true" size.
Learnings
I had always wanted to contribute more to the open source ecosystem but, as many other developers are, I was quite nervous about getting my teeth into a significant OSS project. My experience building runpkg provided me the perfect opportunity to experience OSS project stewardship, and I'm excited to continue to improve the product we have, build out more features, and learn much more along the way.
Jumping right into a challenging project with interesting technical problems proved rewarding. It's been gratifying to receive enthusiastic feedback from users across the world on something I worked on.
The balance of autonomy and support I received meant that I felt trusted and empowered to voice my own ideas and put myself forward to solve difficult problems, but still very comfortable to ask "stupid" questions. My teammates Luke and Kara have been invaluable to bounce ideas off and pair program with, and it's through their collaborative attitudes that I've felt as comfortable as I have.
My advice for employers is to work hard on fostering a culture where developers are challenged, trusted, and made comfortable enough to ask questions.
My advice for newer developers is that open source isn't as scary as you think; you can contribute in a meaningful way, and create something cool sooner than you might think.
The best way to get started is to dive in head first.
