all too often i feel like we get stuck in mind ruts. the example i typically use to refer to this is imagine you're in the mood to attempt to read the count of monte cristo. you're stoked, you've got your coffee or whatever, and you're ready. then you open the book to the first page, and make the quick realization that the unabridged version of this book is 3000 pages or something like that.
you immediately realize that you have to make a commitment. and not just any commitment, but a time commitment, and those are the toughest kinds to make these days since things come and go so quickly. it can be so daunting to realize how much time it's going to take to finish the damn thing that you just close the book back up and continue to play some random mobile game the rest of the night.
the engineering parallel
we do this a lot in engineering i think. especially if you're a thought leader, or in the innovative space. you know how to make things right, and you try to check every tiny box that you know will help in the future because you've seen how things actually work in reality. here's an example.
i want to create an app. awesome, what does it do? wait, that doesn't really matter. is it scalable? is it highly available or fault tolerant? are its endpoints and communications protocols secure? how are you going to store credentials securely? sso? the framework, is it current and supported? what kind of ci/cd are you going to have, github actions? jenkins? do you have access to needed GPU? how long can it realistically be a monolith before we have to break it up into services? should we plan for that now?
... ok what does the app do?
the analysis paralysis problem
so you see the issue. and it's not without warrant. all the points above are valid and should be implemented correctly if the application calls for them. but even beginning to think about applications in the age of AI, we're not just thinking about single programming languages or frameworks. we're thinking about entire encapsulated environments acting as applications. it's no longer adequate to just have a preferred language or operating system. you have to stay current. you have to stay ahead of the LLMs.
that's another entire thought stream within itself.
the solution: start with diagrams
regardless, what i really wanted to say is that if you haven't yet you should incorporate excalidraw into your workflow. it's very easy to get started diagramming thoughts and vomiting up tech patterns here. when you're implementing and connecting platforms of applications together, it can seem a bit like starting with page one of the count of monte cristo. excalidraw helps reduce the anxiety of that a bit. 🤘
the key insight is that visual thinking helps break through the overwhelming nature of complex systems. when you can see the relationships between components, the path forward becomes clearer.
practical advice
- start with the diagram - don't code yet, just sketch the system
- identify the core loop - what's the minimum viable interaction?
- build that first - ignore all the fancy stuff for now
- iterate in small chunks - add one feature at a time
remember: the goal isn't to build the perfect system on day one. the goal is to build something that works, then make it better.