A coworker asked me this morning about database design best practices–specifically, is it better to A) ensure important primary key values are consistent across environments (dev, test, prod) and store those values in constants, or B) to ensure that those rows are sufficiently unique so that the application can query the primary key values as necessary. My immediate reaction was that option A was a bad idea, because I don’t like hard-coding values, but as we talked, I agreed that it would be more performant than option B, since it avoids extra queries. I ended up suggesting a third option–make the values sufficiently unique, as in option B, but have a post-deployment process that queries the primary key values and stores them for faster retrieval when necessary.

However, this discussion got me thinking about the nature of best practices, and how frequently there are additional considerations beyond the simple “always do this” that many people apply to them. The more familiar you are with a system or process, the more likely you are to find situations where the best option–note, of course, that what constitutes best varies–involves a “violation” of the best practice.

In this case, the best practice is to never hard-code values. But if it’s a value that’s being referenced ten thousand times a day, then it’s very possible that hard-coding will have a significant, noticeable performance benefit.

Similarly, Appian best practices (these days) are to use synched records instead of custom data types (CDTs). There are many benefits for this, which I won’t go into since I don’t intend this article to be a commercial for the company I work for. But I was talking with a coworker a few weeks ago about a problem he was trying to work around; the answer was to use a CDT, but he was jumping through many extra hoops to avoid that, since “CDTs aren’t best practice any more” (paraphrasing).

Of course, this is something we run into in many aspects of our lives. In Scouting, we teach the proper procedure for handing a bladed weapon to someone else–eye contact, handle first, don’t let go until there’s a verbal confirmation, etc. But if I’m working in a tight space and I hold my hand out for a tool, I may not be able to make eye contact. Similarly, driver’s ed classes emphasize following the speed limit–but there are roads where traffic regularly goes notably faster, and actually holding yourself to the limit can make you into a hazard. And parents teach their children many things that are true–up until they’re not. Examples will, of course, vary by household; in ours, for instance, best practice for doing the dishes includes that the person who cooked isn’t responsible for cleanup–but that can change for a variety of reasons.

So, best practices are there to teach us how something should be done, the vast majority of the time. However, it’s important to recognize that the more familiar you are with a system, they more you’re going to know when it’s appropriate to do something else. The tricky part, really, is understanding when you’ve hit that point–where you know for certain that the best option is to go against the best practices. My rule of thumb for this–my best practice, if you will–is that if you have any doubt, you’re not there yet.

This week, I’ve noticed a surge of people registering for WriteTrack, many stating that they’re “Looking for a NaNoWriMo alternative”. This has been caused by the release of a statement by the NaNoWriMo staff condemning people who condemn AI, stating that “to categorically condemn AI would be to ignore classist and ableist issues”. They’ve updated the statement, but honestly, the update doesn’t really seem to help much, largely (in my opinion) because they don’t give any indication when they think the use of AI “conflict[s] with [their] values”, leaving the general impression that they are supportive of the use of AI for writing, with maybe one or two small exceptions.

My opinion: Modern generative text tools, like ChatGPT, are not “intelligent”, and authors should not ask them to write their books for them. This is not ableist or classist; this is a sober judgement from a career computer scientist. Large language models (LLMs) are effectively statistical machines, predicting what the “best” next word would be based on all of the writings they have been trained on. While their abilities to understand requests and generate well-written outputs are frequently impressive, they don’t actually understand the world the way we do. Note: Because I believe that LLMs are not intelligent, I try not to use the term “AI” when describing them.

Lack of Intelligence: There have been many demonstrations of the fact that LLMs aren’t applying any actual intelligence to their outputs. One example is asking “how many R’s are there in the word ‘strawberry’?“; ChatGPT’s default answer is that there are two. While there’s a charitable explanation (generally, people ask this sort of question when they’re not sure if they should use one or two of a letter), it’s at best lacking. More significantly, however, are the many examples of “jailbreaking” LLMs to get them to generate content that their creators don’t want them to. The simplest jailbreaks have the LLM “mask” their outputs, which make it clear that the LLM itself is often able to generate the output, but that there’s a secondary system which scans the generated output for inappropriate content which needs to be blocked. A truly intelligent system would not have that vulnerability. Finally, truly intelligent systems would not have the issues with “hallucinations” that LLMs are notorious for (such as the lawyers who have been sanctioned for citing non-existent cases in briefs that were, in large part, generated via LLM).

Training: A huge problem, when thinking about using LLMs for writing, is that the outputs they generate are based on the texts they’ve been trained on. This is different from the old “in order to write well, you should read as much as possible” advice, because while a human who reads extensively develops a sense of good writing, understanding of allegory, and determines for themselves what is beautiful, LLMs simply know what words are most commonly used together. LLMs can be “tuned” by tweaking their learning sets, but their very nature leads to the conclusion that they are ultimately just really powerful plagiarism engines. I know that’s a sweeping, controversial statement, but LLMs generate their text based on many sources, without the ability to show attribution. And that’s before we even get into the fact that many, if not all, LLMs are trained on texts without the original authors’ express permissions, including from pirated eBooks, scraping websites, and so on.

Acceptable use for LLMs: Given the above, you might think that I’m totally opposed to using LLMs. And the answer is, not really. There are use cases for them; as I noted above, their ability to understand questions and generate reasonable outputs is often impressive. In my day job, we use an LLM to extract data from large documents, note patterns in data, and, yes, create a first draft of communications. I’m proud of the fact, however, that our company emphasizes a “human hands on the steering wheel” approach–while the LLM makes suggestions, a human reviews, revises, and fixes the output. I’d recommend a similar approach to applying a LLM to writing: work with an LLM to flesh out a general story outline; pose problems from your story to the LLM and ask it to suggest a list of possible solutions; ask an LLM to suggest reasons your main character has a specific flaw. Then take those outputs, think about them, and take your story in a direction that speaks to you. But don’t ask the LLM to write a scene for you–that’s not going to be your work, and won’t reflect you as a writer.

Having gone through NaNoWriMo, I can attest that the challenge of putting as many words on paper as I could each day forced me to turn off my internal editor, freeing my creative side. There were genuine moments where I paused and said, “I don’t know where that came from, but I like it.” Using an LLM would prevent that from happening. Is this ableist or classist? Hardly! It’s not a question of are you able to write without an LLM; the only thing that using an LLM would help with is your ability to write a specific number of words in a given timeframe. There’s nothing magical about “50,000 words in 30 days”; some people need a lower (or higher) target, and they need to find what works for them to push the internal editor out of the way. And NaNoWriMo’s “classism” argument seems to be aimed at the review/editing process, rather than the writing process, which is really odd given that NaNoWriMo’s focus is supposed to be on, well, writing. (Incidentally, the statement that some communities would need to pay someone “for feedback and review” is striking; do they assume that there are communities where no one is able or willing to read a friend’s work for free?)

In summary: NaNoWriMo was wrong to call protests against “AI” “classist and ableist”. Large Language Models can be useful, but are no substitute for the creative genius that a human can provide when they turn off their inner editor. Letting a LLM write entire scenes (or more!) for you is not very different from plagiarism, and should not be encouraged by an organization aimed at encouraging everyone to write.

Edit: Since the time of my post, they updated the statement again, so I’ve updated the link to an archived copy for context. I feel that the newly updated statement is as weak as you can get–“AI is simply too big and too varied to categorically support or condemn”….”We made mistakes in our initial expression of this position”, with no boundaries or examples at all. There’s also an undated “letter to our community” that tries to walk back much of what they said, including the language about ableism and classism, but I find it unimpressive and unpersuasive. You can judge for yourself, of course.

I’m learning a lot through this, and again, hope to be able to go faster as I become more familiar with everything. Each problem that I solve is a lesson learned!

Now I just need to learn how to do that. But that’s programming, rather than finances, which is much easier for me to deal with. So I’m making my goal public: I’m hoping to have a WriteTrack mobile app developed by NaNoWriMo this year.

It may not be as full-featured as the website (and probably won’t, in all honesty), but my minimum viable product will have these features, at least:

1. The ability to log into your WriteTrack.cloud account, or register a new account
2. The ability to create a challenge or access your existing challenges
3. The ability to adjust calendar weights and track progress
4. Daily notifications of your adjusted targets

Thanks to everyone who has donated to WriteTrack over the years; this simply wouldn’t be possible without your support!

I recently decided to change web hosts, and in the process decided to start with a clean slate, since I hadn’t actually maintained my blog in about four years–and most of the content that was there wasn’t particularly relevant to me anymore. My apologies if you’re looking for some of my old content on Oracle APEX; rest assured, most of it is out of date now, and you should be looking for more recent content.

My name is David. I’m a husband, father of three, outdoor enthusiast, and a programmer. This blog is for my own opinions, and does not reflect those of my employer (or anyone else).

I’m also the creator and maintainer for WriteTrack, a free tool for authors to set goals and track their progress. What makes WriteTrack special is that it adjusts around your schedule–you set your goal and timeframe, and then adjust the days as needed. If there are days you can’t (or just don’t want to) write, set them to zero; if there are days where you want to write more, adjust those higher. WriteTrack then tells you how much you need to write each day to reach your goal. And it continues to adjust as you go, so if you get ahead of schedule, your daily goals will go down.

I’ll be adding more as time passes, so please do feel free to check back!