Automating What's Annoying to Do Manually
What's REALLY annoying to me when drafting a blog post is formatting, as I go.
Markup that doesn't look quite right to me. Grrrr. I just want a command line HTML formatter that makes the output look the way I like seeing it. Online web apps to do this abound. Tidy comes VERY close but is not quite right. Beautiful Soup does a fantastic job providing structural manipulation capabilities (and is core to my static site generation engine), but the formatters leave one wanting. So, naturally, I felt compelled to write my own.
I went around and around thinking that, since I've seen so much HTML over the years, writing a Python script to format it to my liking would be trivial.
I sat down with a blank IDE window (in the past I was an unabashed JEdit devotee but lately have become legitimately enamored with VS Code), dumped my approach into rough pseudocode, and, from that, wrote ugly code that spit out a few print statements before encountering a fatal error. I did some back-and-forth, trial-and-error, pure "feel" mode coding. This got me to the point of reformatting very simple HTML sequences. I worked my way in the general direction of ultimately processing a real page from this blog, but ran aground once I encountered multi-leveled tag indentation and text between tags.
This was my clear signal to go away and do something else.
Over the years I've grown past merely being annoyed by this part of my process, to actually embracing it as essential. As my life responsibilities have increased and evolved over time, there is ALWAYS something else I need to get done that is not related to programming.
My first choice is always exercise. This inevitably leads to a relevant algorithm coming to mind, which I get out of my head and either on to paper or whiteboard, into a draft in the ProtonMail app on my phone, or into a text editor, depending on how far I've roamed from my desk. I am always tempted, at this point, to just go straight back to programming, setting breakpoints, and running the program in the debugger, fiddling with things as I go, to narrow in on the desired output and the code that generated it. BUT, if I'm able to be a little patient, and run through my pseudocoded algorithm by hand (aka utilizing the "old school debugger"), I find flaws in my logic MUCH faster.
Once I've convinced myself it (probably) works, I copy my pseudocode over from my scratchpad text doc to comments in the IDE, translate to the language-I'm-using's syntax to actually code it, and run it to confirm it works.
If it "works" perfectly the first time I am suspicious, but can be (eventually) convinced. :)
When refinement eventually yields a working program, I refactor it to remove blatant duplication and any lingering (and now irrelevant) commented-out nonsense that accumulated along the way.
Most importantly, I call this version done! Endless polishing has wasted so much of my time in the past. There is always vN+1 for something that actually needs to be fixed or TRULY warrants improvement.
This approach ultimately serves me well, if I'm willing to follow it, because I both get my code to a working state faster and minimize frustration in the process!
So..that's the origin story of "Markurr", with a side of my process thrown in for seasoning. "Markup" plus "GRRRR" led to "Mark...grrr", so eventually, once the rough edges were sanded off, the result is "Markurr." Markurr it is (at least until I decide there is something more clever to [re-]name it).