I learned to code on a small computer my dad brought home from work one day. I didn’t have formal training, so my experience with the computer was all explorative. Learning to code meant building prototypes. I’ve learned many of the things I’ve mastered this way. I had a similar path to learning classical guitar – music is like coding in that it demands hands-on practice, trial and error, and the application of theory. You can’t read your way of playing the piano.
My first job out of college wasn’t as a software engineer, but as it happened, my first employer wanted to build hundreds of new websites for their teams. No one knew how to do it (including me), but I volunteered anyway. A long trial and error process taught me about CMS’s, deployments, and what I consider “coding for real” in a professional setting, pushing beyond the hacky stuff I did in high school.
As a developer, the exercise of prototyping - building, gathering data about what works and what doesn’t, then iterating - is one of the most impactful ways to learn. This process is essential to move projects forward, creating better builds each time, expanding your craft, and achieving a deeper, nuanced understanding of how code works and responds.
When you’re working on a team or toward a company goal, prototyping is also an effective communication tool. It can help others across departments and with differing levels of software expertise really understand what you’re trying to achieve. On development teams, it exposes issues that have to be solved early on.
An eye for editing: When to start prototyping, and when to stop.
Teams can spend too long in ideation stages, talking about imagined challenges (real or not), or discussing ideas that are years out. It’s important to have a vision for a product or feature, and those long-term visions are good to evangelize and establish across teams. But until teams create a prototype they’re operating from assumptions, and working in the dark.
Today, there are so many tools that allow our team to create a prototype in a matter of days or even hours – and that helps us unlock really fast progress toward our goals. For example, the new Notebook feature we worked on for Pinpoint started as a prototype. We weren’t sure exactly how we needed to build it, or what the underlying tech would look like. We started down one route, got a better idea on direction after feedback, and switched to what would be a better longer-term approach. Making that change early in the process saved the team a ton of time.
Prototyping is an incredible tool when:
- You aren’t sure what the technical challenges will be
- You don’t yet know the order in which things should be done
- You need to communicate with a lot of people and rally them around the same goals before starting to build
But teams can also spend too long in this phase. Prototypes should not de facto turn into production software, which wears engineers out, disenfranchises them, and invariably promotes bad habits in production. Prototyping should end when there is clear communication around direction and understanding of that direction.
Sometimes, you have to nix a prototype.
Culturally, it’s important that engineers embrace the attitude that code is “cattle not kids” – you name your kids but you don’t name your cattle. Code should be understood as a way to express features and products and requirements; as a way to accomplish the end goal. You don’t name it or fall in love with it; you use it and you reuse it, and you throw it away if you need to. A craftsman loves his tools but recognizes that they are his tools, not his creation.
The only way to really improve at coding is to do it and do it again. High-frequency prototyping is a great method for improving engineering skills, understanding, and communication.