Rapid Prototyping Mindset

[00:00:00]
>> If you've ever done any kind of prototyping, think about being in a room, having those discussions about like, hey, we're gonna build a prototype. We're gonna build a proof of concept. And try to remember the conversation, and think about what limiting beliefs exist around rapid prototyping. And there are a ton of limiting beliefs.

[00:00:34]
I think one of the biggest ones is, should we even do a prototype? Should we see if this is indeed what the user wants? Or do we just go ahead, roll the dice, YOLO, you only launch once, literally, and just build it and hope people buy it. Or do we build a prototype?

[00:00:59]
And so once you get beyond kind of that initial threshold, there are a myriad of, I think, beliefs that kind of exist around rapid prototyping that I want to kind of walk through or just cut through this a little bit. So when we think of prototyping, the most basic form is pen and paper.

[00:01:25]
And then you have wireframes, static mocks, interactive mocks, and so this is where things get super fancy. Something like InVision or something that you can go a long ways with an interactive mock. And I am not criticizing any of those, but once you get up to kind of like that InVision style interactive mock, there seems to be this barrier that just kinda comes in.

[00:02:00]
And what the barrier is that, do we build a high fidelity prototype? And I have just encountered a ton of criticism, or even resistance around, hey, why don't we skip all of these pieces here? Pen and paper, wireframes, etc. Or let's do just an abbreviated version and let's go straight to building something.

[00:02:31]
And I think the reason this is, is that there's a perceived high level of effort, that if we were actually going to build this, that this would take more effort than it is worth. The reason being, is that code is hard. I think as well there is this, I've had variations of this from engineers, tons of them, that just to be clear, this prototype must never, ever be put into production.

[00:03:13]
We'll throw this away and we'll replace it with real code. And so that is a huge limiting belief. And I believe it's probably one of the largest barriers to entry for people, especially business stakeholders to getting on board with just building the thing as a prototype. The reason being is that historically, prototypes are designated as disposable or throw away because they're not written to production standards.

[00:03:51]
And so this is where, just to be clear, if we do this, we got to throw it away. We're simply doing recon, and they think of it like, I don't know, like a Trojan horse in a way of like we're gonna build something that looks like a horse.

[00:04:09]
We're gonna basically go on this journey, see what everybody's doing and then we're gonna come back, and then we're gonna get on real horses, and then we're gonna go and invade. And so mentally, the distinction between a prototype and real code, that distinction or that chasm that exists between the two is, I think this is what prevents organizations from leaning in to building high fidelity prototypes.

[00:04:41]
And here is a another big idea. So this is number two for the day. Prototypes, they should be disposable because they are immutable and not because they are inferior. I feel like I need a little Twitter icon in the corner for the things that I think are probably something that I would tweet about.

[00:05:06]
And so this is where when we think about prototypes, that they should be disposable because they're immutable, and not because they're inferior. And I'm drawing heavily on this idea of immutable architecture or infrastructure. So immutable infrastructure, it's an approach that components are replaced rather than changed. So an application or services is effectively redeployed each time any change occurs.

[00:05:44]
Now in the cloud infrastructure space, this adoption of immutable infrastructure or an immutable infrastructure approach has absolutely changed the game. This allows high velocity organizations to sometimes have 20, 30 deployments in a day. And the reason being, is that they're not pulling something down, trying to fix it, and then push it back up, in terms of infrastructure, that we simply just redeploy another instance of it.

[00:06:25]
And so this idea is cattle, not pets. And I believe that we would go with service well as application engineers to think of our code, at least major pieces of it as immutable infrastructure. In the sense of these are the things that we're just going to redeploy, regenerate.

[00:06:57]
And we can focus on the things that change. So I'm gonna do a quick interlude around expertise. So specifically experience and expertise. And the reason why I bring this up is because we're talking about skill and effort. I don't wanna do a rapid prototype, because it's hard, it will take too much effort, it's too much time, too much cost, too much investment.

[00:07:31]
And so there's one point that I'd like to just call out here, this is a bonus section but it's important. There's a book called The Business of Expertise, I highly recommend it. And within the first couple pages, he says, intelligence is essentially pattern matching. And so remember what I said about mastery being reductive.

[00:07:55]
Pattern matching is possible when similar scenarios are presented, ideally over a long period of time. And so it's actually repeated exposure to similar scenarios that's going to allow you to be in an environment that you can start to establish patterns within that context. And when enough scenarios are presented, pattern matching turns into insights.

[00:08:28]
And so I believe that a domain expert has been described as somebody who's made every possible mistake within a specific domain. And so this idea is that when you've been presented with enough scenarios and you have started to converge on the most dominant patterns, all of a sudden now, guess what?

[00:08:57]
You're probably, if you have applied those patterns and converted them into insight, that you're probably a, quite possibly, a senior engineer, an architect, a staff engineer, whatever it is. Because expertise is the ability to convert these insights into valuable outcomes. And so when we are exposed to, The same scenario over and over and over, we have an opportunity to start to notice patterns.

[00:09:36]
From those patterns, we start to gain insight. And from that insight, we are able to convert those insights into valuable outcomes. And so back to mastery. I believe that true mastery is the ability to transfer mastery. And so my opinion is that you do not truly know something until you can transfer that thing, that idea, that concept, to somebody else.

[00:10:12]
And for efficiency sake, that at least for me, The gold standard for me, for mastery, is being able to transfer ideas to small children. Because when you can do that or in a way like the mom test, that's how you, I believe, really know something. And it's not that you are condescending towards, let's say a small child or your mom.

[00:10:43]
More importantly is that it is amazing the amount of effort and energy and discipline that it takes to take something you know and reduce it into such a way that you could explain it to a small child. And they would understand the concept that you're trying to communicate.

[00:11:06]
And so I have a super, super fancy graph here, and just for math reasons and scientific purposes is that skill and effort are inversely proportionate. That your first repetition of anything is going to be very high effort. But as you start to acquire skills, so let's say on your 1,000th rep, all of a sudden now your body starts to adapt, and it becomes easier.

[00:11:52]
And then on your 1,000th rep, then it becomes much, much easier to the point it's your 10th, 10,000th rep that all of a sudden now the effort that you are trying to or the effort that you are expecting to accomplish a goal is almost negligible. And so, one, that do not be afraid to do the hard things.

[00:12:21]
Because in doing so, the hard things become effortless things. And in the context of rapid prototypes is that it's not that coding is hard, relative term, or rapid prototyping is hard. It's that we simply need to commit to gaining the reps and the exposure to the right context and the right environment to reduce the effort that it takes to produce these artifacts.

[00:13:00]
So this is not so much a philosophical idea, but I just want to really pin this particular thing, patterns are important. So, if you've heard of the saying, DRY, what does that mean? Don't repeat yourself. Well, how do we know if something has been repeated? Think about that.

[00:13:37]
Well, it's pattern matching. And so patterns are really important. And so if you've ever stopped and you're like I've done this before. On some level mentally, you've realized that you have repeated yourself or that you've already implemented something that this pattern over here, this output, matches this thing over here, and this is important.

[00:14:00]
And I want to encourage you as engineers to be very sensitive to that. When you start to get the Spidey-sense, I think they call it the Peter tingle in the movies, hilarious, is that all of a sudden, you're like I've done this before, something doesn't feel right, or I feel like this could be easier.

[00:14:19]
That is on a subconscious level, possibly a conscious level that your brain is trying to tell you this is a pattern, I've seen it. And so do not underestimate the importance of patterns.