[ot][coding-therapy?] Moronism And The Thorough Code Review
One of the huge changes I've experienced was strong inhibition around thoroughly reviewing things. Before all this, I would read an entire chip spec from from to end, every word on every page, before coding for that chip, and I wouldn't have to read it again: not because I had any kind of eidetic memory, but because I noted each thing that seemed useful somehow, with similar useful things I had already been exposed to. Nowadays, I so fervently want to quickly dip through something, and have an AI or a bunch of enslaved social network users do most of it for me. "If you want something done right, do it yourself," goes right out the window. Trying to be thorough now gives me chest contractions, amnesia, etc etc . The moronism seems too strong for me. This is a huge part of why I make so many bugs when coding, and it gives my other personality, the one planning what bugs to make, so much space to act in. Security reviews are ridiculous now: I add and hide more vulnerabilities than I address. But I'll be sure to address one, because I'm trying to! And then you trust me! It's so bad it's hilarious, like everything else. Another thing that gets much harder with this issue is things like optimization and creative hacks. I used to read all my APIs just like those chip specs, from front to back, and pick the very best solutions for every problem I encountered. Similarly language specifications. Now, like any good influenced person, I only easily see tiny things that engage my influence, and everything else takes great effort and raises my triggers. Often I call this blindness, because I literally do not see physical visual things right in front of my face. I've been dealing with that for years. But suddenly it occurred to me that _calling it out_ in this way could give me an avenue to work on it. And then I see how it describes so many of my issues. It's a really basic one, that I can engage almost anywhere. What tasks, I wonder, are really conducive to practicing thoroughness? Simply the act of methodically engaging and including every part of something, maybe in a software context, and maybe sidestepping things like working memory challenges a little.
It was while revisiting some static initialization order issues with the spdlog log library that I finally noticed I could think of these things this way. It's somewhat sad that I'm engaging spdlog, which I mostly value because of its use in the BrainFlow library, a small MIT-licensed brain signal interface by a lone developer in Russia. I wouldn't be using BrainFlow if I could get myself set up with OpenViBE, a much larger LGPL-licensed brain signal environment from France, but with OpenViBE I get the chest contractions and amnesia and such more strongly, and then with the amnesia I forget it exists, and stumble on BrainFlow, and the rest is timelines. Anyway, BrainFlow inherits design flaws from its dependency on spdlog, which has static destruction order issues in its implementation, resulting in patterns of using static objects but having to jump through hoops to output log information in their destructors. The static destructor issues in spdlog are multi-fold, moreso for me because the C++ specification has had many new revisions since I stopped reading written text. Some of them relate to quirks of DLL unloading on different versions of Windows. I first made myself visible to spdlog on 2021-02-20, looking for details regarding the DLL unloading concern. Things happened and were raised by different people, time has passed. A new issue was opened for a more core part of things. Not much action. On 2022-08-16, tfiner made a comment more experienced than others, on the new issue thread, at https://github.com/gabime/spdlog/issues/1738#issuecomment-782632346 . tfiner basically proposes to redesign the parts of the library involved, rather than to address the issues in the current API. tfiner speaks in line with my own original concern when saying "It is an unusual library that can't be called from a static object's destructor deterministically and safely." Today, I had some casual interest in resolving this, not knowing of the new developments. Usually, I would go through all the options, pick the best one, bang it out, and contribute it. And I'm still used to assuming I can do this! Nowadays _all_ the options is more like ... "uhhh how many intergalactic amnesia bubbles do I have to send autonomous time traveling robots from in order to bring these things together, and what patterns do the autonomous time traveling robots need to collect before they unite?" which may make no sense to you but is hilarious and sympathetic for me when I write it. Another thing I notice is that it is again incredibly hard for me to consider, design, and write code, and this difficulty is in some new ways that I'm not expecting. When I experience severe coding trouble, I remember a number of years ago, when coding was even harder for me (although in different ways) and then how I returned to coding in some years between. This memory is always inspiring for me, although I'm not quite certain of how much to rely on it. Big large questions with the spdlog situation might be: - What is the best solution or solutions? - What is needed to implement it or them? - What are the details of the problem and its systems to find obscure options and obscure concerns? My usual approach would be to consider every possible option, and then pick among them. When it can take navigating convulsions to explore exotic, low-return options, part of me can get kind of angry at other parts of me, to spend my time that way. I'm never quite sure. But for thoroughness, I expect that continuing to try can make things easier. It can take a lot of intentional and ritualised repetition to get to that point. Areas I might need more information on might include: - Revisions of Windows that have DLL unloading quirks and the specific details of those quirks - Possible avenues present in whatever the latest C++ specification is that the project supports - The static construction and destruction rules specified by the standard, and separately the rules adhered to by every mainstream compiler the project supports - The preferences and norms of the users and developers of the project, and of experienced C++ programmers in general Ideally, there is a solution that retains backwards compatibility, but if the project is conducive to an upgrade that solves all the problems at once and deters future ones, then simply implementing an approach like tfiner's makes sense. But one can never know for sure without a thorough review. There's always a little nook of options that can yield a lot of fruit. Every hacker knows this.
The difficulty, involving having to send sublight grunts to different galactic amnesia bubbles where they assemble and dispatch autonomous time traveling robots that collect preset patterns before uniting, is similar to the difficulty I'm engaging with my ongoing design project around append-only storage and random writes. The talk about galactic bubbles is an analogy for what I find myself doing internally to observe, combine, and infer from information that crosses my numerous dissociations. With the random writes, this is a project I'm more familiar with, that I already have information memorised in parts of me, regarding its different parts. Less thorough review needed: it more directly engages the idea of successfully and creatively combining information that wildly dissociates when held and used. Pros and cons to different puzzles here.
Another issue around thorough review is the idea of noting down parts of a novel abstraction. This is very hard for me, long story short. Quite hard. But, when pondering the spdlog project, I realised it was a helpful step for learning thorough review. One might avoid note-taking to practice one's memory: but if the problem is in the actual behavior, i.e. simply spending time sustaining a behavior, then notes are a useful tool one wants to be able to use, and can increase how much success one gets. Success can help a lot with learning things, now, for me, and when the number of psychological issues I'm coping with at once is reduced, I can make much more progress. Having written some parts of thoroughly solving a software problem in my second post in this thread, I may be able to draw on those parts a little so as to make thorough notes about a software system, when severely struggling to engage it. Maybe thorough review + notes could help me engage random writes? I'm not sure. But I've really spent a lot of time trying to defend my habit of practicing building logical things, and it's something that's often ready and interesting for me to do.
Kind of a micro-thorough-review: In the world I am exposed to, there has been a severe drop in design quality, many redundant implementations and maintenance blocks, in the same codebase. I experience this myself. I get all wonky when I try to methodically go through a codebase, line-by-line, integrating everything into a norm. Seems like a good challenge! Tasks of value include: - porting a codebase to another language - factoring a codebase into organized components - and integrating new information It's very hard to review and transform something in its entirety. But, this gets easier as the work gets very short. So we can start small, and rebuild skill.
participants (1)
-
Undescribed Horrific Abuse, One Victim & Survivor of Many