On prototyping
This is something of a catch-all post, but about prototyping and simplicity. Whenever I start writing a post about this, I quickly learn it will require a lot of work. So, for now:
- "Be scrappy" should not mean "do the first thing that comes to mind."
- And, in particular, you should have an explicit idea of (i) how your system is composed from subsystems and (ii) what your basic data objects are.
- Spending hours thinking about your most important data models is really valuable. Even in an AI-accelerated world. That time pays for itself many times over faster than we think.
- Another application of (1): It's tempting to move fast by ignoring encapsulation, perhaps by taking a server response and using it directly in the front end without translating it into a domain object. This leads to either (i) failing at building anything at all or (ii) building the thing you want, but badly.
- Some solutions feel more general than others in a way that is, upon inspection, illusory. So, for example, you might avoid using AWS Lambda or similar because "we might need longer or larger tasks some day." The alternatives won't handle all possible load distributions well, either!
- Closely related: the set of applications for which Lambda is sufficient today but not in a year is smaller than people think,1 or at least smaller than they say when they are trying to say Smart Planning Things. And this example generalizes.
I'm struck by how surprised people tend to be when I tell them that Lambdas can run for up to 15 minutes and go up to 10 GB. And, in fact-checking this footnote, I remembered that Lambda Managed Instances exist. And even sort of keeping up with (say) the Python release schedule can make your code X% faster every year. Time is on your side here, at least for most things where you'd be tempted to use Lambda at all.↩