Throwaway Prototypes

For the past couple of years I have grown fond of prototyping as a way of getting my ideas across to other developers. As part of my role at CapitalOne (Software Engineer - Internal Tooling), I've had the opportunity to come up with innovative ways to improve the developer experience at the company in a creative and fun way; it allowed me to explore new technologies and paradigms, and inherit new ways to architect and design products. Prototyping is not a topic that comes up often in my sphere, and it is definately not something I bring up often in conversations, however a recent Twitter post surfaced made me think a lot about the perceived value of prototyping as an engineer:

Working in a DevTools team, the customers I often created solutions for were other developers who were having a hard time; they were using tools that were slow, unstable, or sometime just plain unpleasant. Due to the size of the business, it meant that there was often a variety of pain-points that I could chose from to explore and solutionize. Some of my most recent successes include:

• Designing and Implementing a Chrome Extension that summarizes CI/CD logs and surfaces solutions to those problems
• Creating a centralized package manager that simplified onboarding and setup of new development environments
• Creating an SSO wrapper that gave developers a drop-in solution to add Single Sign-On to any of their Lambda and Express applications

Prototyping isn't always going to lead to buy-in, however it almost always comes with other benefits which enable upskilling and exploring new technologies. Its also worth noting that building prototypes in an enterprise is obviously going to be easier that in smaller companies where resources are limited; however, I would say whenever possible prototyping is a valuable practice. It allows software engineers to explore and experiment with new technologies, methodologies, and ideas. By creating a prototype, engineers can quickly validate the feasibility of a concept, identify potential challenges, and gather feedback early on. This iterative process of building and refining helps to minimize risks and making informed decisions before investing significant resources into development.

Moreover, prototypes serve as powerful communication tools. They allow software engineers to effectively convey their vision and ideas to stakeholders, product managers, and other teams. A lot of the solutions I brought to life at CapitalOne originated as a simple proof-of-concept prototypes. These prototypes helped me imagine up the solution, and solidify the implementation details that were floating in my head; and once I had a tangible solution, it helped me convey the value to other parts of the business. This visual representation also helps bridge the gap between technical and non-technical stakeholders, fostering collaboration and alignment throughout the development process.

I encourage my mentees and more junior colleagues to create proof of concepts for ideas they might have, and so far both them and I have seen an increase in not just their confidence, but their skills. In addition to facilitating communication, prototypes also enable upskilling and knowledge expansion. As engineers work on prototypes, they gain hands-on experience with new technologies, frameworks, or approaches. This provides an opportunity for professional growth, allowing them to stay abreast of the latest industry trends and sharpen their skills. Furthermore, prototypes often act as a playground for experimentation, encouraging engineers to think creatively and explore alternative solutions that might not have been considered otherwise.

Overall, prototyping and building proof of concepts offer numerous advantages. From solidifying implementation details to garnering support, these early-stage artifacts help shape successful software solutions. By leveraging prototypes, engineers can validate ideas, communicate effectively, and foster a culture of innovation within their organizations. Embracing the practice of prototyping ultimately leads to more robust, user-centric, and successful software products.

---

P.S. At the time of writing, i'm attempting to prototype a Toy React server to better understand how it works at a meta-framework level; and so far I have learned a lot about React Server Components. I plan to do a write-up on this soon!