Skip to content

Latest commit

 

History

History
44 lines (26 loc) · 5.48 KB

rapid-prototyping.md

File metadata and controls

44 lines (26 loc) · 5.48 KB

Lots More Rapid Prototyping

Sometimes, when I think of testing something I’m unsure about, or developing a little demo, maybe as a proof of concept – a prototype, really – a part of me just goes “ugh, can’t be bothered”.

I’m talking specifically here about making something very temporary, maybe even deleted. It’s a mental barrier that I have to climb over. A lot of the time it ends up stopping me from taking any action at all. To be honest, most of the time that initial mental barrier is more problematic than any issue I’ll encounter once I actually start doing the thing.

But y’know what? Every time, pretty much – with so few exceptions so as to be negligible – I have either learnt something new, consolidated my (probably tenuous) existing understanding, or realised a misconception I held. It’s a really worthwhile endeavour, and almost never a waste of time or effort at all.

Yet still, every time I need to give myself a small push – a tiny spark to overcome the activation energy inhibiting me.

I think a part of it is just the perfectionist in me. We can’t make something half-baked or unpolished. It just isn’t right. Maybe a tiny bit of it is also being scared we won’t be able to make something good? But more than all that, we just can’t bear the thought of throwing away work – we put time, effort, debugging and ingenuity into that, and now you want to delete it?

Interestingly, this doesn’t happen with writing, or maths – for instance, as soon as I started pondering the topic of this piece, my mind went straight to “write that down write that down”.

I suppose it’s cuz code, writing and maths are very different. Maths is ephemeral; the working is an adventure, and unless it’s something like an integral for Integrity, I don’t really feel a need to save or do anything with my working. It’s so much more about the journey of discovering and executing the steps of a solution.

With writing, everything I write has value, or can have value. At least to me. You can see this in Assort. Even the most waffly, incoherent and shallow messes become invaluable insights into who I was at the time, and are like snapshots of the past that show how I’ve grown. There’s no need at all to throw it away; you can leave it, and it will still hold meaning. In fact if anything, its value increases with time.1

But code is a lot more dynamic. The code you write today may and in all likelihood will become obsolete in a few year’s time. As requirements and structure change, so must the code. Its value doesn’t lie in the raw text at all, but in the product it produces, and how the code slots together into the larger context of the software.

So in a prototype, much of the ‘good’ code I might strive to write, won’t hold any value beyond the context in which it’s used. And that can be saddening, since good, well-structured, polished and aesthetic code takes a damn lot of effort to write.

A significant part of getting over this – and I suspect this is a somewhat rarely mentioned but perspective-shifting step in growing from a coder to a software developer – is coming to terms with the fact your value isn’t in the code you write. Anyone can write code. Some people might even be able to write good code. The value is in your skills, logic, experience, all that decision-making and problem-solving, which you can’t literally see but instead viscerally feel through the essence of the code. And that, is built from experimenting, going outside your comfort zone, and learning from it.

I’ve come to really like Codepen and the Svelte REPL They’re really perfect environments for rapidly testing stuff, and the important thing is that it’s so much easier to detach yourself from the work you’re doing, because of that mental abstraction that it’s just a playground. There’s no saving or executing commands, it’s just like you’re drawing stuff on a whiteboard and can rub it out at any time to draw new stuff.

Rapidly throwing together mockups with HTML and CSS is actually kind of fun. Just like how solving integrals (even those you immediately know how to) makes you so much better at integration, speedcoding HTML and CSS really irons out the kinks in your web-dev-fu. In fact, I realise I’ve always loved IDLE. And IRB, and Node. It’s so cool to be able to pull up a quick interactive session and test whatever you want.

Honestly, prototypes aren’t too different from that, it’s just that you devote a little more time on them.2 I merely need to grow more comfortable with prototyping as an ‘extension’ of testing in a REPL.

To future Sup, keep experimenting. This sandbox has levels, and we’ll never reach the higher ones if we don’t try jumping more.

(wack analogy :P)

Footnotes

  1. Mathematically, the curve will sort of dip then slowly rise again, with respect to time.

  2. I remember reading about this in The Pragmatic Programmer, actually. They recommended always prototyping in a different language to force a proper, thought-out re-implementation, instead of being lazy and just straight-up using the prototype code. Fire book, btw.