Foreword
In my quest for a good way to motivate myself to write regularly, I decided to examine my daily activities in search of some “gold” that I could write about, thus solving the problem of finding topics đ Generally, I couldn’t find any specific subject to describe because things keep changing for me. I fall in love with one tool and it becomes the cure-all for me, only to find a better alternative a month later. I am constantly searching for my ideal tech stack, where I could settle in and know this is for me, and that from now on, EVERYTHING I do will be in this tech stack.
However, I found one common feature in all of this: constant analysis and testing of new tools. So, I decided to make this my bootleg mine of topics and will try to exploit it as much as I can đ
Today, we take on tools that allow me to prototype quickly. Roll the introâŚ
THIS WEEK IN “ANALYSIS PARALYSIS”: ADAM AND HOW TO QUICKLY PROTOTYPE, AND THE FUTURE OF CODING <2x thunder strikes>
Hyperfocus and the Issue of Returning to Projects
Being the person that I am, I can focus intensely on a given topic, but for a very limited amount of time. Itâs an interesting combination as during those 5 minutes, or sometimes 5 hours, or sometimes 5 days, the only thing I can think about is that one single topic spinning in my head. At the same time, when my dopamine levels drop to the point where I start looking for something new, I can only watch as my previous goal drifts away, and all the ambitions and visions of conquering the world with that idea move toward the graveyard of ideas.
Over the years, I have learned to “park” ideas a bit earlier, before completely exhausting them, and have implemented what’s called âslow multitaskingâ â I keep 5 projects open and jump to where I currently feel more dopamine.
This is troublesome because returning to a project half-finished, where part of the functionality was in my head and the written code resembles traditional Italian spaghetti, is quite challenging. Hence the need to create an SVP (Shittiest Viable Product â trademark pending đ ) as quickly as possible. Below, I present the results of my experience, which â if you have this special brain wiring, giving you the focus of a Navy SEAL sniper but the attention span of a squirrel on coke â might come in handy. Generally, I’m writing this for my past self⌠though I know back then I probably wouldn’t have listened to myself, but what can you do? đ
Programming Language
For a long time, my main language was C# (previously it was JAVA, but that was ages ago and not worth mentioning), a very nice, comfortable language, but also extremely expansive, and tools like Visual Studio or Rider add their overhead. Itâs hard in this configuration to sit down, spit out a few lines of code, run it, and have something ready.
If C# is a large, heavy two-handed sword, I concluded that I need⌠a 9mm Glock. I pondered for a long time about to what colors should i change my club colors to. JavaScript (or even TypeScript) seems very tempting due to its easy runnability in the browser and general flexibility; I had a brief fling with GO, which I highly appreciate, but Python is much more established, has greater support, and above all, in Python 1+1=2, not 11 ;). Point for the blue-yellow.
Philosophy
After deciding to move from C# to Python, I realized the problem wasnât just the programming language (besides, I usually conclude that I am my own problem and always want to blame the tools⌠but letâs not get ahead of ourselves ;)). The issue was also the habit from C#, where starting a new project meant it had to begin with at least 5 different files and 300 lines of boilerplate. “Because it had to be clean code and nice and maintainable.” In reality, that number of files and initial code didnât result from my needs or patterns, just from “it has always been that way,” “it should be that way,” and that was the default template.
So I ditched all templates. Now my projects start with main.py and thatâs it⌠okay, maybe also .env đ Only when I feel comfortable with a given solution do I start creating my âframework,â generic enough to fit all my mini Python APIs, and personal enough to be fully understandable and minimally expand the project. For example, I have a hand-written (by ChatGPT) class for sending logs to OpenObserve, which I simply copy into new projects.
Development Environment
An unpleasant experience switching to Python was managing packages. Doing a single project is clear â you install everything in the system, and itâs done. But when a second project with different packages appears (and programming in Python is effectively assembling various packages into one program :D), you step into the realm of battles for dominance. Packages conflict, require different versions, and pollute the system.
I tested environments in PyCharm, Jupyter Notebook, played with venv â it was all somehow “not right.” I forgot commands to activate the environment, or setting up a new one required more than 3 clicks, which is too much for my attention span, and finally everything landed in global packages. A lot of fluff instead of one âclickâ and a new sandbox for developing.
Devcontainers turned out to be a savior â they integrate very pleasantly with VSCode, creating a new container is 2 clicks (which is one less than my maximum đ ), and cooperation is really convenient. And the application becomes more “docker friendly.”
All cool, but itâs still a lot of work
Thereâs nothing worse for me than catching a block at work â not because I donât know how to handle something, but because my knowledge of the language limits me. The fact is, the LLM revolution made it much easier and ChatGPT with its buddies solves 90% of my problems.
I also tested Cursor, and maybe I burned through $10 on LLMs in 10 minutes, but at least I had no idea what was happening in my code and why it wasnât working ;). Sadly, from my experience programming with LLMs, it turns out you still have to be the programmer. An LLM is merely a very patient senior dev standing behind you and pointing out what to do. You can ask for the best solutions in your situation, copy code snippets, but never let it do too much for you â because youâll quickly lose orientation in the project. Handling an error that the LLM no longer comprehends and proposes the same wrong solution repeatedly will take you longer than if you wrote everything yourself (with minor help).
Okay, I complained a lot, but whatâs the alternative?
Quick and simple: No-code/Low-code. If on the frontend side my love for such solutions (FlutterFlow) has already been revealed in previous posts, on the backend side I cannot overestimate n8n and recently discovered LangFlow (Iâll probably write a separate article on AI agent frameworks).
I have an excellent real-world example of how n8n can save time: my daughter’s kindergarten entered the 21st century with a bang, they have a website⌠and thatâs it. No Discords, Facebook groups, or mailing lists. All the news from the facility must be checked manually on the website â like an animal. So I decided to write a simple scraper (I was learning GO then, so it was a good test). Making it took me maybe 3-4 hours plus a few fixes, plus configuring a container with cron running twice a day â about 6 hours total. It works, great. Around the same time, I discovered n8n and decided to do the same in it. Besides a one-time n8n setup (about 2 hours), creating the same flow with cron, sending notifications via NTFY, etc., took me MAYBE 30-45 minutes. Any change, e.g., sending messages to Discord instead of through NTFY? another 5-10 minutes.
The ability to quickly set up flows, and in a visual form (Iâm very visual-oriented), is invaluable and very intuitive. Additionally, returning to the project after a few weeks is much easier because the visual representation serves as documentation. n8n has many flaws and sometimes annoys me, but itâs undeniably irreplaceable for creating POC and SVP. You can quickly iterate and validate new ideas, and if you already have something running in âprod,â you can always rewrite it in ârealâ Python code and deploy it in a container â and sleep well knowing youâre still a real programmer đ
The Future of Programming
Okay, since “How to Quickly Prototype” can be reasonably inferred from the above, whatâs with this “Future of Programming”?
I believe that in the future, everyone (by everyone I mean myself because I am everything Iâve been to myself â so when I say “everyone,” I mean my own world, and if you feel the same way, You are welcome to it đ ) will create using low-code. I have appreciated this while playing with n8n. True, n8n isnât super-optimized, you canât easily export the flow to a separate application or to âfull-code,â but itâs still a step in the right direction. The ability to quickly deliver a solution in a fairly transparent form is priceless.
I wondered if I should create something like programmable blocks, similar to the nodes in n8n but with custom code inside. I could create individual modules with inputs and outputs, connect them, and generate one âfull-codeâ application from that.
This brings us to LangFlow, which â aside from building AI agents â somewhere underneath is precisely such a system: a collection of code blocks where you can write whatever you want and then build an application from it in a simple, visual way. For me, it’s a perfect match â I get a clear representation of the flow while maintaining full control over every line of code and using ready-made components.
Summary
I’ve noticed that thanks to continuously testing various tools and approaches, my “analysis paralysis” is decreasing. Every subsequent experiment limits the sense of helplessness because I no longer have to guess what will be a good and efficient solution for me â I simply know from my own experience. At the same time, I’ve realized that the journey itself, this endless cycle of discovering alternatives, testing, and checking what works, is valuable in itself. This perpetual chase and the joy of pursuing it give me a lot of satisfaction. Maybe my dream “ideal stack” doesn’t exist at all, and the beauty lies in the search? I’m increasingly feeling that the constant discovery of new tools is my true path, not a transitional state to one perfect solution. And I think it’s time to accept that đ
TL;DR
- Language: Python
- Philosophy: “Write, don’t worry” â minimalism rules
- IDE/Dev Environment: VSCode + DevContainers
- Future: no-code/low-code (n8n, LangFlow, and probably some other no-code tools that are yet to emerge)
Thank you for your attention, and see you in the next episode of “Analysis Paralysis” <2x thunder strike>!
