One of the things I dislike the most about tech is how often absolutely horrible mantras have evolved. To wit: “move fast and break things”, the idea that there is no bad idea, so try it out and if it even works a little bit, build from it. Don’t stop to fix mistakes, just get it working and keep it working and when the dust clears, then the product can be debugged and refactored. This is kind of the same mentality behind Agile, which (in a nutshell) teaches that we should make a feature work, then build on that again and again, iterating over time until we have a complete and — hopefully — workable product. Both of these workflows get swung around by tech bros and LinkedIn townies with an obnoxious swagger, as if somehow building a product in a complete and immediate haze, never stopping to consider consequences or even roadmaps, is an actual virtue.

Of course I sometimes accidentally get into this kind of groove with personal projects. I really do love to plan, but you know what they say about plans, an adage to which I can personally attest: eventually, no matter how much I try to suss out future details, my plans always fall apart when I attempt to put them in motion. The result is that I end up ditching the immediate plans and just throw things at the wall to see what sticks. Code here; code there…does it work? Great! I’ll worry about clean-up at some nebulous later date.

I am actually writing this post now not just because I haven’t written in a while, but because I need to take a break, step back, and slap myself silly for having let my current project reach the atrocious state it currently occupies, thanks to this unintended “move fast and break things” state of mind.

The What

This isn’t a project post, so I’ll try and hit the high notes. I’m building off of my WS+API server framework which, I have to say, is making the server side of this project really damn easy assuming I can remember my own conventions. The modular nature of routes and data access is a massive improvement over the flag-planting that I usually do for API work, so I don’t really have any complaints from that side of the equation.

The website, however, is running away from me. First, I opted to roll with Firebase Auth because I didn’t want to roll my own user management system. I hate writing user management systems in 202x; they are so much more complex than they used to be when I started working on the Web circa 199x. Firebase allows me to offer authentication mechanisms from the Big Players in Auth: Google, Facebook, Microsoft, GitHub, and more (they also still advertise Twitter which shames Google for not having updated their Firebase Auth codebase and docs, but that’s not the point here). I can also let Firebase handle email and password-based accounts, so all I have to provide is a secure connection and Firebase will take care of some of the rest.

I also decided that I wanted to get into Redux by way of another state management package called Zustand. I have to admit that I couldn’t really get the hang of Zustand, which makes me sad because It’s a hell of a lot easier to work with than Redux, which has so many parts that need to be understood and deployed concurrently that, quite frankly, I am overwhelmed at the same time as I’m trying to figure out a design for the site, how to integrate it with Firebase Auth, and also to handle the main features of the site which are more fancy than my usual business-app-writing ass is used to.

The Why

I think that’s the why: too many irons in the fire and I’m trying to keep them all from from melting down and setting the workshop on fire. All of it works sometimes, and when it does, it’s only doing so through the most tenuous understanding and organization possible. There are legacy parts still in place that I know will get replaced with specific, new systems but I need to get those systems online before I can switch, so when the elder portions fail, I still have to fix them with the knowledge that it’s done on borrowed time…time I could and should be spending on getting other systems in place. On top of all of that I have to manage a workflow that I am constantly confusing myself with: where does an operation occur? On the client? On the server? And how do I sync the two? I chose Firebase because it takes some of the heavy lifting off my shoulders, but now I am bound to its black box operations on both client and server that force me to have a complete “soup to nuts” pipeline between the client and server in order to ensure that the workflows aren’t going to throw an unhandled error the moment I finally get everything squared away, and that takes more time.

Basically, every step requires at least three different system integrations, none of which I fully understand and none of which are fully implemented in the project to the point where I can actually use them with confidence.

The How

I blame my own limited success. As I stated at the outset, once I started actually using my WS+API server the way I had intended it to be used, with all the modularity and unopinionated operations, I felt like I was on a blessed path towards success with this project. If I could do something that well, I shouldn’t stop and reflect; I should keep my head down and push forward with the greater project while the gettin’ was good.

Of course, then I ran into Zustand which was mentioned in the docs of another component I’m utilizing web-side, ReactFlow, and since it was not only recommended by the component, but also because I could see its worth in the situations I was trending towards, I went down that road. When it didn’t pan out, I figured that maybe it was time to look at Redux. I had already been forced to take a breather to learn ReactFlow, then took a side-trip to investigate Zustand, which turned into a full-on detour to get familiar with Redux. I could feel the momentum of the server-side win slipping away so…maybe I panicked?

I started with ReactFlow and got it working. I added Redux in there and got a very small, very specific state bucket working with ReactFlow. But in order to associate the data with a user, I needed to be able to register, auth, and manage users, so Firebase entered the picture. One thing lead to another, and here I am, breathing into this virtual paper-bag to calm my digital hyperventilation.

The (Future) When

What now? How to do extricate myself from this quicksand of my own making without taking my usual route of destroying the project and starting over from scratch again (this is, of course, my nth time trying to get this specific project off the ground)?

I think the answer is one that I had purposefully been avoiding with great success: work on the design. I am not good at design, but since Web 2.0 has always been a visual medium even before scripting and programming were introduced, it’s the one task that has never waned in its relevance. To that end, it’s pretty cathartic for me: I can get instant feedback, can work at micro- or macro-scale, and I’ve been doing it for so damn long that I can let my mind wander to completely non-related subjects and decompress. I hope that once I get at least some of the visuals sorted I’ll be mentally ready to tear into the disaster area that is my own operational code, and hopefully I won’t have forgotten the snippets of various systems that I read about that lead me into this mess in the first place.