For the last week, I’ve been modifying the checklist rather than posting individual progress updates, but with that list narrowing now, its worth checking in and discussing the thornier bits that remain.
Squirrel! Over the last day or two, the spotlight of my attention has been distracted by something shiny - getting new content ready for the FrankenTongues project. It’s content to feed a feature I’ve been wanting for some time now, and today I’ve been reacquainting myself with Frankie’s code so that I’ll be able to do something useful with that content when it’s ready. In the process, I’ve noticed that my memory for details no longer has the stamina for juggling so many projects. I can’t remember how things are organized or why things were done the way I did them, even though it was only a month ago that I did it.
But surprisingly, I think this could be a good thing.
I’ve always been a puzzle-solver in my approach to coding. To hell with careful planning, documentation, and interface contracts - solve the hard part first and take care of the rest later. After all, if it turns out the puzzle can’t be solved, then all that peripheral work is meaningless - time wasted, right? - so it’s best to figure that out up front.
Unfortunately, the nature of computer programming is that there’s always another puzzle to solve, and the lure of solving tomorrow’s shiny puzzle has always been more attractive to me than the dungeon of documenting yesterday’s solutions. When working as part of a team, this was always a strength. I could go off and scout the territory ahead, clearing brush and opening a path forward with prototypes and architectural sketches, and then let the team follow behind, paving the roads and putting up the traffic signs. If I ever needed to revisit a project later, it was easy because of all the lovely pavement and signage.
But in my solo work since those days, I’ve increasingly found myself lost in the jungle. Exactly what you’d expect from an explorer working alone who didn’t bother making maps along the way. At first, my memory was the hero, allowing me to go back to old projects and pick my way through the undergrowth by recognizing a few landmarks and intuiting my way forward from there. But that memory is no longer the champion it once was, and I can now be baffled by the logic of a tool I wrote only a few weeks ago.
Or at least, that had been my experience. When I first went back to Frankie this morning, I started off with that familiar sinking feeling: How is the data organized? I remember that it’s in a SQLite3 DB, but with what tables? Are new files loaded from CSV files? JSON? Using what fields?
Then I looked at the file structure: database code goes here, command line arguments are processed there, GUI code is handled here. I opened a few code files and found decent documentation for all the key functions, and better yet, those functions were divided into relatively small files with limited scope and obvious purpose. There was even a note file explaining the higher level logic behind the architecture. This was exactly the kind of pavement and signage I needed! But how did this happen? How did I buck the habits of my historically scattered workflow and leave such a clean and well lit trail this time?
There are two parts to the answer. First, I wrote much of the initial boring code using ChatGPT, as a way of bootstrapping myself to a functioning app quickly. And since ChatGPT always writes excellent internal function documentation, I got all that as an unexpected benefit. I also had the foresight to include my initial ChatGPT prompt as documentation in the main file, which clearly explained what I was trying to accomplish and how I wanted things organized. Pure gold!
But that still left the bigger question. What had made me save that ChatGPT prompt? Why had I even asked it to create such an organized layout in the first place? I’ve used GPT on other projects in the past and never had this kind of tended garden waiting for me when I’ve returned. What changed?
And that’s when I realized that Frankie is the first project I started after deciding to lean into my ADHD-esque project management habits. This was the first time I’d acknowledged from the outset that I was going to abandon this project for weeks or even months at a time and would need to be able to reorient myself later, so I threw a bone to future me and left a better map.
I didn’t really spend more time than usual creating the prototype - but I did make a better effort at organizing it, and at preserving what notes and sketches I did create.
For those programmers who already have a methodical approach to documentation and organization, this will feel grade-school obvious - Programming 101 - but for an aging prototype jockey like me, it’s a revelation.
And as a complete bonus, if I ever make my source code public, it will make things much, much easier for anyone who follows later.
