I have the extreme privilege of working with Jamie on client projects, and I absolutely love his approach to development. Rather than deliberating over lengthy conversations about what can and can’t be done, Jamie dives in, plays, and prototypes. As a result, we’re quickly able to find where the challenging spots will be around any given technology, but we’re also able to unlock opportunities we may not have ever known if we spun our wheels in meetings and requirements documents.
Prototypes are also a fantastic way for developers to become a core part of the design process. Jamie explains:
That output could help to define an API or prove technical feasibility or check a scary task. Where it’s particularly impactful is with designers and internal design teams — they love to work this way because I’m very quickly in the weeds with them, figuring things out. I produce higher-quality, more custom, less error-prone work. Because everyone gets used to seeing rough work, there’s no risk that a prototype that fails will alarm a client — some stuff not working is just an expected part of the process.
This is how I operate as a developer, but as I float around to many organizations I notice this open-ended, prototype-driven “oh that seems interesting; let’s try it out!” approach to development is completely absent. When all development work is thought of as final, cross-browser tested, production-ready code, teams miss out on so many creative opportunities that can be driven by technology. So three cheers to Jamie for showing us how prototyping and playing in code can and should be a part of everyone’s process.