A couple years ago I was listening to the brilliant podcast Coding Blocks, in the episode they spoke about the Pragmatic Programmer, which I've since read and recommended in numerous blogs. More specifically, they talk about Prototyping. Which completely changed how I code.

What is prototyping?

Prototyping is used in a number of industries. Aircraft manufacturers like Boeing would use prototyping to try out designs for a new jet, to improve aerodynamics, to improve safety, etc. Maybe a toy-sized replica of the jet with an altered wing span could be tested in the wind tunnel, or a new design be mocked up in Photoshop. The goal is to learn something without having to build the entire aircraft. Prototyping is cheaper.

Prototypes allow you to explore unfamiliar areas, to build a quick solution, to hack a unoptimized fix. Whatever the use case, it's important to know, a prototype is temporary. It is throwaway. Once you've completed your prototype, you should be able to chuck it in the bin, without hesitation. This last bit, completely changed the way I attack problems.

When to prototype?

In software, prototypes can take many forms, but the premise being exactly the same as the Boeing example. The objective is to test one specific area, analyse the risk and determine the cost.

There are a number of scenarios for software prototyping, most of which revolve around uncertainty. You want to try out a new architecture? Add some functionality? Test whether deleting some code will improve performance? Want to try a new tool?

Whatever the scenario, you prototype to learn.

How I prototype

I tend to prototype whenever I'm not certain on an implementation, this could be simply a hairy bug fix I haven't quite understood, or a feature whose solution isn't quite solidified. With the understanding that whatever code I'm about to write isn't going to seep its way into version control, I have unshackled myself. I can attack, iterate, hack and assail without even the slightest consideration or care about the implementation details. My code can be barbaric, and that's okay. After 10-30 minutes of sheer pandemonium, I delete my code, I revert, I undo, I smile.

I've figured out the unknowns, I have won the battle, now for the war.

Now I can write the actual code with my newly found knowledge. Neural pathways have formed from my prototyping, I know how to solve the problem, implement the feature, use the new tool.

I hope you enjoyed this blog, don't forget to sign up to the newsletter - Be the first to hear when we release new content, participate in weekly coding challenges, listen to more of my drivelling.