Hello y'all,
I find myself deleting half written tweet chains very often. I think its because I don't really dig the medium. I'm not saying I need a lot of space to express myself, but you know, a tweet chain seems to not cut it most of the time.
So at the request of a strong few, here's a newsletter. This could be the middleground between a tweet and an essay. Less often than daily, more often than monthly. Maybe once a week? Let's aim for that. Hold me accountable to this.
But what exactly will I write about? I think the broad strokes are more or less these:
And probably things that I'm teaching myself as well.
But enough meta-conversation. Let's kick off the newsletter with a topic that's been really bugging me lately. Enjoy!
I run into a lot of people that think prototyping basically means building shitty software that sort of gets the job done.
Don't get me wrong, it does bring business value and everyone's better for having that thing running.
But did it have to be built like this? Seriously? And is this because we didn't know it'll stick around or some other constraint? Is it because we had to ship it fast?
I really would love to argue that we can build software fast and with pretty high quality.
So I will. Sort of. Lets go for medium quality.
Most projects we build have a way of taking some signals from the outside world. They split the good from the bad, filter out the noise. What's left we can turn into something that makes sense for the internal program. And then we are the people sending garbage to the next piece of software.
Not much more to it than that. Really. Just boxes and wires.
The question is, how big should a box get and should we maybe route the data to another box instead. The bigger the box, the more stuff it does, and the harder it gets to work with it.
So why do I see programmers make big boxes when prototyping?
Is it a matter of performance? I'd doubt it. Most software that you are just prototyping doesn't need to be insanely efficient.
Can't the programmer think of a separate box? Possible, depending on whether they've thought of the domain before or not. Depending on how much code they've read in their lives, they may never have seen these 2 things split into separate boxes. This is fine. It is overcomable with training, and getting people to read more code.
What if they do know how to split the boxes but it is expensive? Also possible. Some languages make it awfully hard to split pieces of code into separate modules.
Are the programmers so lazy? We are, but I don't think anyone is lazy enough to willingly make more work for themselves in the near to mid-term future.
Here's what I think is going on.
I see people prototyping in a dynamic language like Elixir, and they stuff a bunch of maps with data.
Then they write more and more code around a few spots that accidentally became the best source of knowledge on what the hell is in those maps. Then they rename one field and the entire thing breaks. Brittleness.
The same thing can happen with any language, even in typed languages like OCaml or Rust. Minus the compiler helping you do the filed renaming.
You'd think you'd be more sensible than to use a single massive record for all your state, but if Redux convinced millions of Javascript developers it was a good idea, who am I to tell you not to. It works, actually.
So this is my take: relying on programming language idioms instead of building our own domain vocabulary in the language is what makes prototypes suck.
Python was not meant to be used to talk about Real Estate, but to talk about tuples and objects.
Elixir was not designed to talk about Video Streaming, but about structs and processes.
Rust was not designed to talk about CLIs. I actually don't know very well what it was designed to talk about, lets say memory management.
But you as a programmer are paid to prototype a system that deals with Real Estate, or Video Streaming, or a CLI. And most languages allow you to build vocabulary of some form to talk about your thing more directly.
So start writing a module named after the thing you're gonna work with, and wrap it in some nice functions that your Product Owner could read out loud and say "yeah that seems about right". Use whatever data structure inside the module, whatever's most natural for your language.
Abstract your language idioms in domain specific language.
Abstraction is a good tool to use to make fast prototypes because it shields some code from the rest of the system.
Code that is "less coupled" is code that is easier to think clearly about.
And thinking clearly is everything these days.
So thanks for subscribing and let me know what would you be interested in reading about next!
/ Leandro