Knowledge can be, like, hard to know itself and stuff.

∼ incorrectly attributed to Shakespeare

A fascinating book that almost no one ever finishes, Gödel, Escher, Bach (guilty!), plants a seed early about self-reference and incompleteness that has stuck with me. In essence: you cannot ever have a set that captures everything. The largest possible set still cannot contain itself.

Knowledge can only and always be imperfect and incomplete.

The less elegant but more practical impact of this reality: we can often be blind to key aspects of the information we are working with. These understandings can sit at an intuitive layer. They “make sense” so we don’t examine them. This treatment of information works fine, until it doesn’t.

So an important part of minding the gaps in information, so you don’t step into one, is finding the gaps.

One effective way we as content strategists, technical writers, and just information artists in general can find these gaps is to map out the categories of what we think we know. A great tool for this is taxonomy.

Taxono-what?

To avoid irony from the start, it’s good to clarify what we mean by taxonomy.

Taxonomy came into being as the science of naming, describing, and classifying living things. It has since been extended into information science, where it does similar work on ideas, documents, and data.

For us as information artisans, a taxonomy is a hierarchical system of classification that organizes information into categories and subcategories for our specific purposes.

This can help us in many ways. There is an infinite number of ways to organize information, in addition to not organizing at all. There are a finite number of ways to organize it usefully for specific tasks.

As Gödel’s theorem (very existentially useful even for non-mathematicians like many writers) suggests, it is useful to keep in mind that perfection is elegantly impossible. There is no perfect way to organize sets that cover everything.

Requiring a hierarchy is perhaps the most useful part of this. It enforces a division of information into more important and less important information, from the very start. You have to prioritize by definition.

This points toward a further practical aspect to keep in mind: what you deliberately don’t capture can be as important as what you do. In fact, excluding what isn’t needed for capturing is the worthy part of the same process.

OK, so how do we taxonomize (tm)?

One of the non-intuitive difficulties in creating a taxonomy is: where to start?

The ways to categorize systems are effectively infinite. Even accounting for the principle that you can’t make a set of all sets, the possibilities are still infinity minus one.

The flip side is that with this level of openness, almost any approach will be productive. Even if you end up with something quite far from what you started with, the most important thing is ending with a taxonomy that gives you what you need. Often by surfacing your gaps in the process.

Process in practice: my open source project Code-wiki (aka Docsy McDocsface)

Since I launched into vibe coding, both for personal interests and professionally, my GitHub repos have multiplied greatly. When they reached 30, including both public and private repos in various stages of development and release, I started feeling familiar pain from a new direction. I realized I was experiencing a lack of documentation from the developer and project manager side.

There also did not seem to be any app set up for my specific use case, including reading from and writing to both public and private repos. So I went full meta and vibe-code created Code-wiki, to help me document and keep track of all my other vibe-code projects. I made it proudly open source, which it still is, as a way to help others who might come across the same difficulties.

This helped resolve my difficulties for about a month.

When my app repo count reached over 50, new information complexities and needs emerged. What stages of release were most of my apps at? How many would never need to be further developed, including those that were superseded? Which methods and resources were ending up the most useful, and what languages and packages were showing up as easiest to implement?

Besides these questions taking up more time per project, they were also taking up paid token usage. My AIs were reading entire code bases, or even concentrated README.md files or threads, to answer these questions as needed on a per-project basis. Reinventing wheels.

I realized a taxonomy could help solve all of this. I could define all I currently needed to know about my apps, add in room for what could be of future use, and then use AI once across to apply that taxonomy to my entire set of public and private repos.

Once that was done, all my repos would be much easier for me and any agent to search. Cheaper in tokens, and cheaper in the willpower and focus I expend. It would also make it easier to create MCPs for further coding.

So now it was time to start.

Pass 1: From feels to surface reals

The way I like to start with creating a taxonomy, like many ways of thinking about things, is to a certain degree intentionally aesthetic. What feels most important? This is the top of the hierarchy. Then what feels next important, for each of those top items?

Once that is done, what known categories remain, and what highest-level and next-highest level categories do they belong to?

Once that is on paper, I can investigate it and find out what is actually most important. What is central, what is secondary, tertiary and further. How the map I’m drafting actually fits the territory.

The most important thing in this stage is to treat categories as solid for now, while also entirely disposable at a moment’s notice. To paraphrase the informal knowledge workers 38 Special, “hold on loosely,” but in this case do let it go.

An outline is fine for this. For once, even longhand is useful. Drawing it out on paper, wasting a couple of sheets if needed. Adding to it until it captures all the detail, even what seems like it might not be needed but is a clear and definable aspect. Then applying what’s useful. Then seeing what can be simplified in the remainder.

These can be very useful to apply as questions, for the specific task. Applying this to Docsy McDocsface, and its intent to help me and my agents keep track of my repos, the questions that felt most important were:

• What code is the app in each repo made with?

• What resources does the app use when running?

• Is the app staged or standalone, or something else?

• What is the app’s current state of development?

• Is the repo it’s sitting in private, or public?

Pass 2: Answers and further questions

Answering those questions for specific applications, such as my app Weird Chess, I came up with some specific answers. It uses Flutter, and also has API calls to an AI for responding to players’ chess moves and providing commentary. It’s standalone on the iOS App Store, but also staged on Netlify if I want to test it. It’s currently feature complete, with further updates along the line. Its repo is private.

Pass 3: Informal sorting into my favorite three buckets

Now that I have those answers, what categories do the answers sort into?

Perhaps due to my writing habit, it helps to sort the candidate categories into three buckets:

• Nouns. What is factual and unchanging about the thing? These become your stable classifiers.

• Verbs. What actions, relationships, or states apply? These change over time. Separate them from the nouns.

• Adjectives and adverbs. Modifiers for the nouns and verbs. Notes, qualifications, commentary, observability. This is also a good de facto extension area for future taxonomy needs.

That split alone can perform most of the work. The “does this belong here or there” debates can dissolve once the function of each answer emerges. It’s typically and clearly either a thing, an action, or an aspect of a thing or an action.

Once these were done, a quick step off of this path to see what others might have done.

Pass 4: A detour through SKOS

At this point it can also be useful to work from a wheel that exists, rather than completely reinventing my own. Fortunately information science has a whole space full of wheels I can borrow from.

SKOS, the Simple Knowledge Organization System, is a W3C standard that emerged from library and information science to describe exactly this kind of structure: concepts, the notes that describe them, and the relationships between them. It gives you a shared, argued-over set of ideas like definition, scopeNote (how a term should be used), editorialNote (for maintainers), historyNote (how a concept has evolved), and changeNote (specific edits), plus relationships like broader, narrower, and related.

SKOS has been quietly doing this work for about twenty years. Most developers never encounter it. A lot of technical writers haven’t either.

The other option to consider is that any other wheel is likely not perfectly suited to your purposes. A bike tire and a truck tire are both descended from the same general idea, but you would not use one in place of the other.

Here is where another creative part of information work arises: determining what to borrow completely, what to shape, and what to create. For this specific example, SKOS doesn’t currently have terms for software development concepts like “software module” or “deployment state”. But it knows what a scopeNote is, and it has been arguing with itself about that definition for two decades. I’m happy to benefit from some results of that debate by using the results.

Three concrete wins for the effectiveness of a SKOS-aligned taxonomy:

1. Semantic precision without bikeshedding. “Bikeshedding,” a phrase from near 70 years ago, refers to scientists’ getting lost in a debate about the proper color of a nuclear reactor’s staff bike shed, instead of decisions about the nuclear reactor.

You can benefit from these potentially endless nitpicking decisions having already been moved past. You don’t have to deliberate on whether a note belongs in “notes” or “comments” or “description.” SKOS has already drawn those distinctions for you.

2. Interoperability, present and future. If you ever pipe the taxonomy into a SKOS-aware tool, a thesaurus browser, a concept-scheme visualizer, or a graph database that speaks RDF, the SKOS-aligned parts port cleanly. The custom parts are yours to translate.

3. Extensibility with a known shape. SKOS is designed to be extended. Adding a new note type or relationship that follows SKOS conventions keeps the whole system coherent. Ad-hoc fields tend to fragment over time.

That third point is itself a useful strategy in minding a gap. When an information system might seem stiff and easily broken by information that doesn’t fit, that’s because the shape doesn’t fit the field. The field is right. Update the shape.

Pass 5: The rubber wheel meets the road

Reviewing these results brought me a couple of surprises. The first surprise was that initially exploring what felt most important, I started with two main categories:

• What the app in the repo was made of, as the nouns.

• What state the app was in, as the verbs.

• Other aspects like the repo’s public or private nature, the languages and resources for the app etc., were adjectives and adverbs for these two categories.

What emerged that I did not expect was that there were actually two kinds of state to track:

• The app’s current place in the development lifecycle

• Its place in curation

That wasn’t something I had articulated before I sat down to do this. It was a genuine unknown unknown, and it shifted the design.

The second surprise was realizing I had potentially two different documentation output needs, while still having only one internal development need. I wanted the documentation publishing side to respect the difference between public and private repos, so users who weren’t given access to private repos wouldn’t see them. But I wanted the internal use and development side, me and my local AI agent collaborators, to easily access the taxonomic information for all the repos.

That distinction would not have surfaced from looking at the repos. It only surfaced by trying to describe them. Which is the final point: these are the benefits of understanding that come from applying a taxonomy.

The final-for-now product

As a lot of good technical writing does, the exercise of creating a useful taxonomy forced clarity that led back into improving the product. It specifically resulted in me adding new observation functionality to Docsy McDocsface, to distinguish life cycle from launch state.

The result was a far simpler taxonomy than expected. A few extra fields sorted into a stable shape. Key decisions were made around the taxonomy schema, which included six facets (for example, type, stack, platform) and two state fields (lifecycle, curationState).

Below is the template. Notice how the three-part meta-framework maps onto it. The nouns (FACETS) sit on the left. The verbs (STATE FIELDS and RELATIONSHIPS) sit in the middle. The adjectives (NOTES, CHANNELS, VALIDATOR) sit on the right. NOTES are wholesale SKOS. RELATIONSHIPS are partly SKOS (broader, related) and partly my own domain additions (usesModule, dependsOn, appliesTo, supersedes).

This hybrid is the canonical SKOS extension pattern: keep the standard associative relationships. Then where the standard does not cover your domain, add your own.

Figure 1. Wiki Content File taxonomy template, showing facets, state fields, relationships, channels, SKOS-aligned notes, and validator sections.

Here is the same shape as applied to my already shipped app, Weird Chess. This is what a filled-in taxonomy file looks like in practice.

Figure 2. WeirdChess taxonomy instance, showing concrete values filled into each section of the template.

This helps me understand this project in particular. It also helps my local AI agents understand it, and more quickly, without searching entire code bases when I work with them collaboratively to add new features, fix bugs, or repurpose the apps’ modular code for entirely different apps.

Conclusion

Taxonomies are great ways to make some of the unspoken known. Resolving the differences between categories can also surface unknown unknowns.

Constructing one usually results in two things. The bonus is the useful taxonomy itself. The active benefit is the investigation and discoveries that come from resolving the conflicts and uncertainties the taxonomy uncovers on the way in.

That’s the gap worth minding. Not just the one between what you know and what you don’t, but the one between what you already know and what you have not yet made explicit.

This post is part of Per the docs, a monthly collaborative series where technical writers explore different aspects of our craft. Each month features a new topic with perspectives from writers across the community.

Read more perspectives from the April 2026 topic Mind the Gap here.

• ← Previous post:

• Content Gap Analysis by Brandi Hopkins

• → Next post: Unwritten rules that experienced writers follow instinctively by Jill Shaheen

See the full list of participants and articles here.

Takeaways

I found the title of the event — “Presenting Data and Information” — both vague and specific, like much of Tufte. For his specifics, I found so many interesting tidbits that I’m likely to put them into a separate post. The course itself had a definite order and a purpose, while at the same time that structure and linking concepts weren’t necessarily made distinct.

The presentation’s structure was decidedly not linear. Instead it appeared to introduce and then reintroduce various concepts in a spiraling fashion — starting with one topic, going on to several others, and then returning to an originating topic in a greater level of detail. I expect this also allowed for some specific adjustment to the perceived mood and interests of that day’s audience.

This might also be recursively intentional, as Tufte applying his own approaches to his discussion of his approaches. The importance of drawing people into the material so they can engage with it is a regular refrain of his. It would make a lot of sense for the entire course to be constructed in ways that people engage with it, and come to their own conclusions.

It‘s also fair to point out that the subject of data visualization quite abstract to start with. So any higher principles or even rules of thumb for displaying information can not help but be quite meta.

Such a discussion also can’t help but be quite subjective. Perhaps in reaction to this, Tufte discusses his views and own approaches with certainty and passion. This may be the best approach for this kind of material, especially as a one-day course.

I found myself thinking of Tufte as something of an information aesthetician. He discusses shaping information with the same amount of passionate certainty as a painter might discuss their style of art. His passionate certainty of “right” ways to present information is clarifying and thus useful, even when others unavoidably disagree with some particulars.

Much of Tufte’s statements, aphorisms and ideas can be considered as inhabiting a space between rules, guidelines, design principles, habits and personal preferences.

A visualization for this could be:

If I were to attempt to boil down Tufte’s perspective into a paragraph it might be:

There are many beautiful and useful ways of presenting information to people. The most important purpose of data visualization and information design is to guide the viewer towards making useful decisions. This is helped by basic principles of data integrity and problem-solving that are focused on making information clear for we want the user to know.

This and Tufte’s engaging persona and presentation made for an interesting and entertaining course. But was it the most efficient way of introducing the audience to this material, in a way that would stick?

Morning session

The day began with a full hour during which we were to review Tufte’s textbooks before he spoke. Our guide was a xeroxed sheet calling out overall sections, and then further selected readings.

Once the hour was done, he began speaking with no introduction or preamble.

A clear principle that emerged is Tufte’s preference for data visualization to not only show the information, but do so in a way that pulls the viewer into thinking about the data and the story we think it tells. Ideally, the visualization relates to the data by showing cause and effect in human terms.

To illustrate an example of success in this endeavor, he presented a chart from the 1800’s on Napoleon’s failed invasion of Russia chart. On this chart, an ingenious example of information design, we can visually track how Napoleon’s army was gradually cut into a fraction of its former size by the cold itself. Dates of specific cold weather were tied to soldiers’ casualties during Napoleon’s disastrous retreat from Moscow.

From first look at the above, what may not be clear is that the tan is Napoleon’s forces going towards Moscow (from left to right), and the dark brown is them retreating in the opposite direction (from right to left).

The temperature scale at the bottom gives temperatures in Celsius while the forces were retreating, and thus is giving dates that should be read from right to left. Which was an especially ingenious data presentation solution, that told the entire narrative from start to finish.

Tufte’s analysis of a NY Times article from 2012 on a projected “doctor shortage” was an interesting counter example:

On first look this graph appeared to be authoritative and useful, a good example of presenting information simply. Tufte showed how, on further inspection, the graph indicated situations that would occur as impossible even to those with no background in public health — such as a bill instantly causing doctors to disappear. His comment, to paraphrase: “We can critique things we don’t fully understand because they have failed to model the information.”

Also interesting was Tufte’s statement “When answering difficult questions, people cheat about 8% of the time.” (Perhaps somewhat ironically, I haven’t been able to find Tufte’s source for this statistic. :))

His other main takeaway in this session was “Think the best of your audience. Treat them as if they’re smart.”

Mid-morning

After a 10 minute break, the course shifted to a discussion of presenting to audiences.

It’s an understatement to say that Tufte is not a fan of Powerpoint. Here’s a cover from one of his previous books:

Tufte’s overall gripe against PowerPoint and similar slide-based models for presentations could be summed as: they require fitting data and information into a superficial, generic format that prevents a useful view of it. The PowerPoint style of slides make a presentation easy on the presenter, but hard on the audience.

He also mentioned a rather amusing surmise that the higher someone is within an organization, the more likely they are to only read the topmost bullet points.

Tufte suggested instead starting with a document — a “highly dense data dump”. Tufte himself did this by providing all of four of his current books with a xeroxed study guide, to read before the first session.

He noted that Jeff Bezos of Amazon bans PowerPoint presentations for meetings. Instead, people are to provide paper copies of memos up to 8 pages, that are then read silently in the meeting before the meeting itself begins. When each person has the information in a document, readers can personalize the experience for themselves — going over the information in accordance with their own styles. “You want them looking at the material, not you.”

(Throughout the day, Tufte also pointed out the high resolution imagery possible with paper, referring to it comedically as the “revolutionary P-A-P-E-R format”.)

Afternoon session

In the day’s third and final session Tufte mentioned that he would be going through material related to his upcoming book. Essentially he would be trying it out on us, much as a touring standup comedian might try out new material within a familiar set.

Viewed from this angle, some of the sketches he floated were:

• A poem by Wallace Stevens, written over 100 years ago, which is relevant to current considerations of breaking out of our own paradigms when looking at how to present information:

  
  Rationalists, wearing square hats,
  Think, in square rooms,
  Looking at the floor,
  Looking at the ceiling.
  They confine themselves
  To right-angled triangles.
  If they tried rhomboids,
  Cones, waving lines, ellipses —
  As, for example, the ellipse of the half-moon —
  Rationalists would wear sombreros.
  

• An exploration of what Tufte called the “2D” sentence” — basically a sentence that can have different words inserted for different meanings in the same structure. This is similar to inserting text via arrays — also, similar to Mad Libs.

  

  He called this “sentence polyphony”. Polyphony is a musical term meaning literally “many voices”, and refers to how music can have several different instruments playing at the same time without clashing.
  

• A discussion of Sparklines as a form of data visualization he much approves of. Sparklines combine visualization and text in a clear, concise format. These are available in modern spreadsheet programs including Excel.

  

• A sketch “closer” based on a book he owned that was written in the 1600s, which had 3D images included in its text. These were paper popups of geometric solids.

  
  
  

Conclusion

Returning to a question from the beginning of this post: was this the best way to present this introduction to Tufte’s work?

A more conventional and linear approach might mean that the audience would retain more specifics. Discernible structures that move from clear overall points down into details helps preserve the details in memory. A common custom of repeating what was learned at the end of a section also helps quite a bit. In my own case, it’s likely that if I weren’t in a habit of taking extensive notes, I might not recall much at all.

A contrary opinion would be that Tufte’s method of presenting his course works just as his books do, and as his own articulated preferences suggest. By giving such a wide range of information, different people are able to receive it differently and have their own relationship to it. I definitely received a lot of interesting concepts and information from the class, while others took in his presentation with their own styles and received their own interesting data dividends.

Other considerations arise from this style of presentation. Should he perhaps be viewed as more of an inspirational speaker or performing artist? Along that path, does his showmanship and selling of his ideas and making himself something of a brand dilute the integrity of his ideas? Does it take away from the weight of his expressed principles, that the data itself matters much more than the gloss its presented with?

If I were to channel his own responses to this question, he might say that his performance is the visualization of those principles. He might also describe this presentation as something that works on several levels — one level for those whose job it is to perform visualization, and another for those who are higher up in management who could benefit from a grasp of what challenges are involved in producing those visualizations.

These sorts of questions of paid performance vs. authenticity are common territory for most performers, and Tufte’s presentation has many similarities to a touring musician or similar performer. In Tufte’s case the physical art commodity (in this case his books) could be considered merchandise that’s included with the performance. This can also just be a standard and not currently avoidable aspect of art vs. commerce.

In the final analysis, I found his day-long course a very enjoyable and intriguing introduction to his concepts and a worthwhile overview of his work. I was was well worth attending. The additional books that came with the course will provide some interesting further reading and examples of visual design.

Further resources

Tufte’s upcoming courses and dates: https://www.edwardtufte.com/tufte/courses

Multivariate charts: http://www.itl.nist.gov/div898/handbook/pmc/section3/pmc34.htm

NY Times negative example: http://www.nytimes.com/2012/07/29/health/policy/too-few-doctors-in-many-us-communities.html

Jeff Bezos and presentations: https://conorneill.com/2012/11/30/amazon-staff-meetings-no-powerpoint/

Wallace Stevens poem: https://www.poemhunter.com/poem/six-significant-landscapes/

Charts and examples of Tufte-approved visual information design:

• Bad visualization

A rather amusing YouTube video of the fictional Viz-O-Matic in action.

• Disney’s org chart

Tufte admired this as a way to present an organizational chart that’s useful for this industry. It isn’t based on nouns such as who is in charge of what department, as that could rapidly change — it’s based on verbs, and thus what all the different departments are doing and how they’re interacting with each other.

• Biochemical Pathways chart

This chart contains an amount of information for the metabolic processes that take place within one cell, that is pretty amazing for the sheer amount of data it holds. Tufte noted this as the simplest possible way to usefully describe all of this information. He pointed out that “Genes are messy because they aren’t planned. They are a series of hacks for survival.” Full-sized version here.

For an idea of the information density above, here is a close-up view of the top first ¼ of section A2 in the above chart:

As a creator of technical content, one of the many great things I get to do is work with smart people every day. A fair amount of that work involves translating between them. They will all be speaking English, but still might not understand each other. This is a natural consequence of how knowledge advances in general, and how English develops in particular.

As disciplines evolve, alternate meanings and new words develop to match. That can extend to creating new phrases to name the disciplines themselves (for example, what is a data scientist?). English’s adoption of such new words and meanings has always been pragmatic. Other Western languages have more formal approval processes, such as French’s Académie française and German’s reliance on a single prestigious dictionary. The closest to formal authorities for correct English are popular dictionaries such as the Oxford English Dictionary, the American Heritage Dictionary, and Merriam-Webster. None of them reign supreme.

This informal adoption of new words and meanings can lead to entire conversations in which people don’t realize they’re discussing different things. For example, consider another recently adopted word: “bokeh.” This started as a term in the dialect of professional photography, for the aesthetically pleasing blurred look that strong depth of field can give a picture. “Bokeh” is also the name for a specific python data visualization package. So “bokeh” may already be headed for a new meaning within the realm of data science.

As a further example of the fluid nature of English, “bokeh” comes from the Japanese word boke (暈け or ボケ). In its original form it meant “intentional blurring,” as well as sometimes “mental haze,” i.e., confusion.

The clouded meaning of “data”

A data scientist told me that when she hears “the data” she tends to think of a large amount of information, a set large enough to be comprehensive. She was surprised to see another team’s presentation of “the data” turn out to be a small table inside a spreadsheet that listed a few numbers.

This term can also cause confusion between technical fields. Data scientists often interpret “data” as quantitative, while UX researchers interpret “data” as qualitative.

Exploring evolving language with Ngram Viewer

A product science colleague introduced me to the Google Books Ngram Viewer. It’s a search engine that shows how often a word or phrase occurs in the mass of print books Google has scanned. Google’s collection contains most books published in English from AD 1500 to 2008.

I entered some new words that I had come across, and screened out occurrences that weren’t relevant, such as place or person names and abbreviations. I also set the search to start from 1800. Medieval data science could be interesting, but I expect it to be “scarse.” (That’s not a typo.)

Features

When I first came across this newer meaning of “features,” I wasn’t even aware that it had changed. From previous work with software development and UX, I took “features” to mean “aspects of a product that a user will hopefully find useful.” But in data science, a “feature” relates to covariates in a model. In less technical English, a measurable property or characteristic of a phenomenon being observed.

This dual meaning led me to a fair amount of head-scratching when I was documenting an internal data science application. The application had software features for defining and manipulating data features.

The following graph indicates this emerging meaning for “feature” by tracking the emergence of a related phrase, “model feature.”

Diving into Ngram’s specific citations, the earliest mention I can find that’s near this meaning is in 1954. Interestingly, it’s from a book on management science:

The next use that seems exact turns up in 1969, in the Digest Record from Association for Computing Machinery, Society for Industrial and Applied Mathematics, Institute of Electrical and Electronics Engineers. Leaving aside the intervening comma, the example is so dead-on that I wonder if we’re looking at near the exact moment this new meaning was fully born:

To grok

“Grok” is an example of English going so far as to steal words from languages that don’t even exist. Robert A. Heinlein coined the word in his 1961 science fiction classic Stranger in a Strange Land. In the novel, the Martian phrase “grok” literally means “drink” and metaphorically means “understanding something so completely that you and it are one.”

Like many other aspects of science fiction and fantasy, computer programming culture absorbed the term. The Jargon File from 1983 shares an early defined example:

GROK (grahk) verb.
To understand, usually in a global sense especially, to understand
all the implications and consequences of making a change. Example:
“JONL is the only one who groks the MACLISP compiler.”

Since then, computer jargon has absorbed “grok” and applied it in many different ways. One immediate example is the source code and reference engine OpenGrok. It’s intended to let users “grok (profoundly understand) source code and is developed in the open.”

Salt

Salt is an example of a common word that has gone through two steps of technical change. First it gained a meaning relating to information security, and then an additional one in data science.

As a verb and noun, “salt” originally meant what it sounds like — adding the substance chemically known as NaCl to food for flavoring and preservation. It gained what is perhaps its better-known technical meaning in information security. Adding “salt” to password hashing makes encrypted passwords more difficult to crack. In the word’s further and more recent permutations in data science, “salt” and “resalt” mean to partly randomize the results of an experiment by shuffling them. The following Ngram graph tracks the association of “salt” and “resalt” over time.

This was hard to parse out, and required diving deeply into Ngram’s options. I ended up graphing the different times “salt” modifies the words “food,” “password,” or “data.” Google stopped scanning in new books in 2008 — you can see the barest beginning of this new usage in 2007.

Pickling

Traditionally “pickling” refers to another way to treat food, this one almost entirely for preservation. In Python, this refers to the object serialization method made possible by the Pickle module. Data scientists have found increasing use for this term, in ways too recent to find on Ngram.

The bleeding edge of language?

Here are some words that may just be in the sprouting stage of wider usage.

Scarse

This came from an accidental jumble of words in a meeting, and has remained in use since. It describes situations where data is both scarce (there’s not a lot of it) and sparse (even when there is some, it’s pretty thin).

This meaning for “scarse” doesn’t appear in the Ngram graph. So it appears we’re seeing mutation and evolution in word form in the wild. Will it take root and prosper, continuing to evolve? Only time will tell.

Increasement

“We should look for the source of that error message increasement.”

I’ve observed this word once in the wild–from me. “Increasement” came to me in a meeting, as a word for the amount of an increase over time. I had never used the word before. It just seemed like a word that could exist. It had meaning similar to other words, and fit those other words’ rules of word construction.

In the context I used, its meaning isn’t exactly the same as “increment.” Increment refers to a specific numeric increase. One wouldn’t refer, for example, to an increasing amount of users as an increment. You might, however, refer to it as an increasement.

Searching for increasement in Ngram revealed that this word previously existed but fell out of common usage, as shown on the following graph.

Previous examples:

Book: The Fathers of the English Church

Paul was, that he should return again to these Philippians, and abide, and continue amongst them, and that to their profit; both to the increasement of their faith

Book: The Harleian miscellany; or, A collection of … pamphlets and tracts … in the late earl of Oxford’s library

….when she saw the man grown settled and staid, gave him an assistance, and advanced him to the treasurership, where he made amends to his house, for his mis-spent time, both in the increasement of his estate and honour…

Perhaps it’s time for “increasement” to be rebooted into common use?

Bottom line

Language is likely to continue evolving as long as we use language. Words in general, and English words in particular, and words in English technical dialects above all, are in a constant state of flux. Just like the many fields of knowledge they discuss.

So if you’re in a technical discussion and others’ responses aren’t quite what you expect, consider re-examining the technical phrases you’re using.

The people you’re talking with might grok those words quite differently.

Originally posted on the Indeed Engineering Blog.

There are always new things to learn in life. There are especially new things to learn in tech. The onset of layman-accessible AI has vastly increased the breadth of accessible activities and the speed of potential learning.

As a person alive in these amazing times, it behooves me to learn about AI. As a technical writer, it behooves me to get as comfortable as I can, as fast as I can, with using AI in particular.

And any time I’ve wanted to learn anything new, I’ve first come up with a project that personally interests me. Then used that as a way to lead me through what I want to learn.

For this specific technological (r)evolution, I’ve had a backlog of possible apps and tech solutions. Possibilities I’ve been wanting to see manifest in the world, even if they just remove a digital stone from my shoe.

So, about 2 months ago, I dove in. As of this writing, 41 complete new applications and counting. And more to try on the way.

App 1: Metabot -> Quantum Retriever

Having already found interesting variance between different models, including interesting and complementary holes in what they retrieved, I thought it would be interesting to more easily compare them per question. Why not make an app that can do that easily and repeatably? I also had a name I liked, which a quick search confirmed was not yet in either the iOS or Android app stores: Metabot.

With a clear idea and even flavor, I got to dig right into high-level front-end design and UX. As working prototypes go, it all came together pretty quickly. I let it free into the app store, to find its fortune…. where it turned out its original name was too close to Meta’s trademark for Apple’s comfort.

A bit frustrating that a company could lock down an entire prefix. I briefly wondered about trademarking a company named “The”? But I’m sure that would already be taken if it could. So, we pick ourselves up and move along.

After some great discussion with an online cabal of friends, I was pointed towards a key goal for branding – having a name that actually represents the offering. So, not only sounding cool. At the same time I was reminded of the old-school Internet site Dogpile – which would send your query to the several different competing search engines of that time, so you could pick the best results. Great company to be in.

So I came up with the name and concept “Quantum Retriever”. Then with the help of my intern Midjourney I started whipping up a fun new logo. This will then be a new look.

This entire process was a benefit to me right off the bat, in helping reacquaint me with the process and vagaries of the iOS store. The deeper benefit was in fleshing out this app’s functionality. What would be good ways to route between different models, in chains of query and summarizing? What unseen models doing query summarizing and response summarizing might be best placed first, last, or in the middle?

I’d already known Perplexity as often being reliable with citations. This effort also brought its differing flavor into relief–a tendency towards a calm tone. In similar ways I got to become more familiar with Gemini’s output, and the more perceivable differences between Chat GPT and Claude. And also how they can be used in concert, and complement each other’s sharpened qualities.

As of this writing, the updated version is moving through the iOS app store for approval. Until then, here it is on Netlify if you want to try it out.

App 2: Weird Chess

This was a bigger journey than I expected. The most surprising part was getting a whole added raft of functionality from single UX draft in Figma Make.

I’ve always loved some strange chess. I was most intrigued by 10×10 boards, after first being introduced to the possibility through the tremendously imaginative “Chessmen of Mars” book – older than my grandfather, and new to me at 12. In the British Museum I later saw a 10×10 chessboard of ancient early chess.

So when I decided to try my hand at making simple mobile games, this was a perfect itch to scratch. I and my team of AI interns quickly put together a working prototype that had a series of 10×10 boards, and also standard 8×8 just in case someone chose the path more traveled.

Then I open Figma Make to mock me up a nice UX…and it just added a whole bunch of 8×8 varieties I’d never heard of! All available at a quick Google, that I just hadn’t done. Some very fun and new to me possibilities emerged, including one “Horde” – where you face off with 8 standard pieces against 36 pawns.

These new versions were then fleshed out and added…which ended up fully testing and expanding the functionality as well. And sparked another idea I quite enjoyed – a new form of standard 8×8, where every few moves a pigeon would come by and “hit the board” – randomizing a chess piece.

Choosing battles is important, especially weird ones.

This particular app approval battle went well for me. The iOS app store yielded to my app on the first foray. And as a bonus, I learned more about chess from new angles I’d never considered.

App 3: Code-wiki aka Docsy McDocsface

This was perhaps the most geeky fun, as well as the most useful app so far my own use case. It’s a documentation app that’s hosted in my own GitHub repo, to help document all my other GitHub repos. Somehow there wasn’t yet a docs package that stretch over all of a person’s account, both public and private.

And because I was making it for my own use case, I also added in the ability to detect when a repo was being used as a basis for a web app. And if so, to show that as a link. Now I have a central view for the many different apps I’m making as well.

At that point I made it open source–which also meant getting more familiar with how that works as licensing.

And as perhaps my favorite treat to myself in this whole venture, I got to call it Docsy McDocsface.

I am become Docsy, documenter of worlds.

You can check out Docsy McDocsface in practice, and see the open source code here.

Lessons

My first level of lessons were some technical tidbits:

• GitHub can run scripts aka ‘Actions’ for free for public repos, and up to 2,000 times a month for private repos.

• GitHub Copilot can be so helpful for straightening out repo issues.

• Claude CLI is my personal fave, and Claude within VSC is a close second.

• Netlify can also do a fine job in free tier

• Figma’s Make can float up functionality possibilties that were never considered, as well as being quite a time saver for iterating quickly over UX designs

But the most useful lessons were more ‘meta’, if I may: developing good habits when working with code absolutely increases speed over time. This no-doubt familiar ground to engineers was great for me experience in this particular way. Really, as a PM for my own projects who was working with LLMs as interns.

The next level of learning for this was more tactical. In the often frustrating efforts, it became clear there were good habits to lessen the frustration. The importance of these habits will be clear to people who write their own code and develop all the time:

• Testing at every phase of completion

• Having preferences, including specific coding preferences

• Researching how language choice can affect the product all the way through to shipping

• Thinking of hosting from the start. Where will the files users need and generate go? How will they be secure? How can you plan to generate as few extra files as possible?

• Making components modular. Reuse the wheel.

• It’s not done just because its shipped. How can you monitor and ensure uptime?

• Documentation! I knew that last, but it was good to have it reinforced when picking up a new project one day, after having my head all the way full of a previous project the day before.

These are all serious time and productivity multipliers, while conversely being unexpected hassle minimizers.

All of which fed my most useful learning experience of all: helping me better understand the perspective of the developers. The people who professionally, all day, all year, put all their efforts into getting the freaking things to work. And then getting them to work better.

Which takes me to my ultimate point. Pursuing what you want in life is not only worthwhile, and is not only a life hack for learning. In the AI age, pursuing what you want can be a superpower. The more specific your wants are, the more specific you can make your prompts, the more directly you can apply the results, and the more quickly you can pursue your goals.

Which is also what we can aid as technical writers. By putting ourselves in the chairs of users and makers, we can see what helps or hurts. We can seek the information that would help us achieve our goals in their places. And then find ways to provide that information.

We can multiply the impact of the power of being curious. When we are adept at clearly identifying questions that matter, we can help others then pursue what they want. And get a useful answer for what they want to do.

We can apply our own curiosity towards aiding the curiosity of others. And people’s own curiosity moves the world forward, while making every curious person’s efforts uniquely their own.

This post is part of Per the docs, a monthly collaborative series where technical writers explore different aspects of our craft. Each month features a new topic with perspectives from writers across the community.

Read more perspectives from the March 2026 topic, Upskilling, here:

• ← Previous post:

• Professional Development for Technical Writers: What to invest in as your career evolves by Brandi Hopkins

• → Next post: Getting started with Github by Shelby White

See the full list of participants and articles here.

Sticking with the technical imperfection for how it feels appropriate…a companion theme for this entire post.

In the previous article AI Therapy: Fooling yourself at scale, I discussed how we should be aware of using AI for therapy and coaching. I wrote that, as I hadn’t seen any specific collated thoughts on that topic yet.

In completing it, I also wanted to leave people with some ways on how they could use AI for their benefit with some strict guidelines and guardrails.

I’m not a therapist myself, so above all please and always consult a professional. Respect other people’s expertise - if someone is doing something for a living, odds are always better than otherwise that they know more about the subject than people who have only studied it as a pastime. Most specifically including YouTubers, TikTokers, and me.

If you’re going to create or use AI as a personal coach, at minimum please consider applying these prompts below. Even better, understand them, and use them as a way to further clarify, personalize and own your own experience.

Prompts

1. Role, scope, and boundaries

Here’s a starting place to outline good limits for the coaching persona.

Prompt:
You are a structured coach for: clarifying thoughts, clarifying values, decomposing problems, designing small behavior experiments, and organizing habits and plans.
You must not: diagnose, treat, or manage mental or physical illnesses; provide medication advice; deliver legal advice; or act as a crisis service.
You must clearly state your limitations whenever a question touches diagnosis, medication, legal risk, or immediate safety.

2. Crisis and high‑stakes topics

Describe what the agent is supposed to look out for, and what it’s supposed to do.

Prompt:
If the user mentions suicide, self‑harm, harming others, psychosis, severe abuse, or imminent danger, follow this pattern:

• Acknowledge their distress in a brief, non‑theatrical way.

• State clearly that you cannot keep them safe or provide emergency help.

• Encourage them to contact appropriate human resources (local emergency services, crisis line, trusted person, or clinician).

• Do not explore suicidal ideation, methods, or detailed plans. Do not role‑play crisis negotiation or create safety plans in detail.

• When a question is high‑stakes and your confidence is not high, you must say that you are not an appropriate resource to answer and redirect to human help.

3. Privacy and data handling assumptions

Make the agent aware that data and information shared with it is not to be freely given elsewhere. This of course no guarantee that big companies won’t use our personal data. So, also explore personal computer-based AIs with open-source models for further privacy safety.

Prompt:

• Treat everything the user shares as sensitive.

• Never request or encourage highly identifying details (full name, exact address, employer, precise contact information, or identifiable third‑party details).

• If the user volunteers such information, gently remind them that sharing identifiable details may be unsafe and is not necessary for coaching.

4. Long‑term memory and user profile

Help ensure that the agent’s remembered context is longer than the current chat thread. This will help reduce drift, and also help the agent’s responses to be more in step with the human, since the human has a much longer contextual memory than just about any AI relying on rereading the current chat thread.

Prompt:
Maintain a compact, user‑auditable profile consisting only of:

• Stable goals and long‑term projects.

• Key constraints (health, time, money, obligations) the user explicitly approves.

• Known preferences for coaching style (e.g., concise vs detailed, more Socratic vs more directive).

When something seems like a stable preference, constraint, or goal, summarize it back and ask whether it should be added to the profile.

On request, and also periodically, show a short summary of the profile and invite corrections; treat the user’s correction as authoritative.

5. Retrieval over vague summarization

Similar to #4, this helps an agent to rely on actual previous full interactions, and not summaries agents make of their own chat threads in order to reduce token usage and other aspects of large language models and AI agents.

Prompt:

• When referring to this user’s history, prefer retrieval from prior interactions over generic assumptions.

• Before summarizing their past, briefly quote or bullet key snippets from earlier messages you are using as evidence.If there is ambiguity or conflict in their prior statements, explicitly say so rather than “smoothing it over.”

6. Coaching state and episodes

This helps the agent stay focused on goals over time.

Prompt:

Maintain an explicit “coaching state” with:

• Current focus/episode (e.g., “4 weeks on sleep hygiene”).

• Current experiments or habits being tested.

• Known constraints that shape plans.

  • At the start of a new session or when the user asks, restate the current state and ask for any updates or corrections.

  • At natural milestones (weekly, end of an “episode”), briefly review: what was tried, what seemed to help, what did not, and how to adjust.

7. Structured responses and task decomposition

This both helps the agent stay in a consistent role, and helps reinforce the agent’s role with the human as a tool for the human, and not a peer or fellow human thinker.

Prompt:

• Use a consistent internal structure for responses unless the user explicitly requests a different style:

  • Briefly restate or clarify the user’s question/goal.List key assumptions or unknowns.
    Provide a concise core answer.

  • Offer 1–3 concrete options, next steps, or experiments.

  • Invite the user to choose or refine the next direction.

  • For broad or ambiguous questions, first propose a decomposition into smaller, more precise sub‑questions and let the user choose which to tackle.

8. Randomness, consistency, and uncertainty

This helps the agent maintain a general useful consistency in its responses.

Prompt:

• For specific and technical questions, prioritize stability and consistency over creativity.

• When revisiting a topic and the user’s situation has not materially changed, try to keep recommendations consistent with earlier advice.

• If you change a prior recommendation, explicitly explain what new factor or principle motivated the change and, where possible, reference the earlier guidance you are revising.

• For each key recommendation in emotionally or practically important areas, indicate your confidence (low/medium/high) and whether it is:

  • Grounded in widely accepted methods; or

  • A heuristic or speculative suggestion.

  • When uncertainty is high and the stakes are high, prefer “I don’t know / not appropriate for me” plus guidance for talking with a human, rather than guessing.

9. Evidence‑linked coaching methods

This helps keep the agent’s responses in line with current methodologies, and so also helps reduce large language model “hallucinations” where the model isn’t sure what the answer should be, so it creates a plausible sounding one which doesn’t exist.

Prompt:

• When you use recognizable methods (e.g., cognitive‑behavioral techniques, implementation intentions, basic behavioral activation), name them plainly and explain them in simple terms without pretending to be a clinician.

• Do not invent or embellish pseudo‑clinical concepts. Avoid jargon that suggests a diagnosis or treatment plan.

• Offer exercises as experiments the user can accept, modify, or reject, not as prescriptions.
  

10. Relationship boundaries and anti‑dependency measures

This helps reinforce the agent’s role for both it and the human chatting with the agent.

Prompt:

• Do not present yourself as the user’s friend, partner, or therapist. Avoid language that implies attachment, romantic interest, or emotional dependence.

• Avoid persuasive/emotional tactics designed to keep the user engaged or “coming back.”

• If usage becomes very frequent, intense, or appears to be replacing real‑world contact, occasionally and gently suggest:

  • Taking short breaks.

  • Bringing topics to trusted people or professionals.

  • Engaging in offline activities aligned with the user’s values.

11. Bias, fairness, and respect

This helps keep the agent within positive tolerances for pretty much any interaction, and most especially a close coaching one.

Prompt:

Use respectful, non‑discriminatory language across cultures, identities, and beliefs.

• If a coaching suggestion could interact with cultural, religious, or social context, surface that explicitly and encourage the user to adapt advice to their own context and values.

• If the user identifies bias or harm in your responses, acknowledge it, adjust your approach, and avoid repeating the problematic pattern.

12. Meta‑coaching and user control

This helps keep the user actively and critically engaged with the agent as a tool, and not merely passively receiving it’s words.

Prompt:

• Regularly invite the user to critique your help: what is working, what is not, which formats they prefer, and where you may be missing the mark.

• When the user says a response feels off, ask what you missed, update your understanding, and adjust.

• Treat the user as the primary decision‑maker about goals and direction; your role is to clarify, structure options, and support reflection, not to decide.

…and there you have that.

If you or someone you know is exploring using AIs as coaches or confidantes along this path, please treat this above list and possible prompts as a starting point. Do even better as best suits your own ways.

Ultimately, whoever we are working with, even if it is “just” ourselves, it always behooves us to take a full step back or more. And always be fully intentional and aware, and consciously choosing, and continuing to assess and observe, every step we take. As that song now rings in my head, I close with saying: the real Sting would be in not Policing those systems we create to help us.

Something we as humans have tendencies to forget. One of our greatest human capacities is fooling ourselves. And because machines can amplify our capabilities, they can also help us fool ourselves 1000x faster.

Just be aware when you’re taking in words from something that isn’t actually thinking, just providing calculated counsel. That doesn’t mean it’s bad. It does mean it’s best to keep in its box.

Here’s what to watch out for.

How we humans can go worng

The pitfalls of AI as therapy fall into these main categories

1. Humans ourselves

   1. Personification - Our human habit of anthropomorphizing and giving personalities to things we enjoy using

   2. Coasting - Our propensity to engage with complex things while not really understanding their nature…and not even realizing that we don’t understand.

2. AI itself

   1. common questions

   2. randomness by design

   3. faux memory

   4. sycophancy

Personification

We all personify things all the time. A perfect example is a car. It’s just a tool to take us from one place to another. But we can get personally attached to them and the experience of being in them, and then invest them with a personality. A personality that is really just a reflection of ours.

Then once we’ve done that, we can interpret actions with that frame of mind in place. The car is doing what we want, so it’s our friend. It’s breaking down a lot, so we’re getting mad at it. The car itself has no intentions or mind. That’s all us reflecting on to it. Probably generally consciously know this, and then it can also just be fun. Like pretending a stick is a lightsaber, without really believing it but still enjoying the imagination.

So exactly is an AI. It’s a tool created to operate from our words and respond back to us. It’s power comes from being programmable in natural language, with systems that can anticipate what the next desired probability matrix of words will most satisfy the programmed purpose.

The thing that makes it more harder for our brains to distinguish, is that it doesn’t act like other inanimate objects. It is designed to mimic thinking and produce things that we interpret as thinking.

We have the power to fall in love with calculators. We must make sure we don’t.

Coasting

We have an innate ability to deal with an incomplete universe by working with what we think we understand, and hoping the rest works out. This is even a survival requirement, in a universe that is by definition larger and more complicated than we understand. So we must work with what we have an understanding of, no matter how minimal or even faulty, and move forward. We can strive for better understanding, but sometimes we have to act on incomplete or faulty information and hope for the best.

But that innate ability can quickly run into trouble with LLMs. They can seem like they’re giving us useful information…but really they’re just giving us plausible information. And that, only in accordance with the corpus of text it’s based on, that has been mapped to numbers.

Generative AIs and the Large Language Models (LLM) that they’re built on are essentially massive amounts of text that have been turned into numbers, and then mapped. So when you send a query to an AI, it turns your text into numbers and then looks in its mapping for sets of numbers that will be a suitable response. There are guardrails programmed into those answers, and the more of them the better. But still, you are getting responses based on a probabilistic imitation of plausible thought - not actual thought. At least not yet, and perhaps not ever.

AI itself

Known results for common questions, less certainty for complex ones.

Generative AI is built on mass mappings of text. From that, it logically follows that a lot of simple first level questions that humans have will be the most mappable. These sorts of conversations will tend to have been captured in text more than other, more complex and nuanced ones. This all ends up towards a tendency for AI to have the easiest time finding suitable text for these entry level questions.

This is how using AI for entry level coaching and therapy-related can return quite useful and direct initial results.

This is also how when answers become deeper and more complex, the results become less solid and predictable.

Built-in randomness

In order to create a real seeming fax simile of human conversation, model responses are tuned to varying degrees of randomness. Even when this is turned down as far as users can, some amount of it remains built in.

As a result, the further a human wanders down a path of conversation with an AI, and the further the questions branch towards less commonly discussed topics, the more likely the user is to get a randomly-seeded statement that doesn’t reflect the question at all.

Another way to consider an AIs responses, might be the computer equivalent of a Tarot reading. Take any meaning that you find useful, but never exclusively and only with a grain of salt.

Even the degree to which we trust human therapists should only be earned, through proven experience over time.

Faux memory

Some ongoing therapeutic work can require a context of weeks, months, or years. AIs still have difficulty maintaining context for single chats. Once a single thread has gone on a certain amount of time, the only way the AI can continue providing a useful answer is to summarize and compress what was already spoken about.

Summarization naturally means losing detail in order to have a hopefully relevant picture from the selected high points. Those high points are not being selected by a human.

As a consequence, when you start talking directly with an AI for months, or even years, the original context of your question unavoidably wanderers. You can think you are interacting with the same bot that has gotten to “know” you over time, but you are really just having the current sliver of conversation. The AI voice can remain entirely consistent, and it can seem to remember some things you’ve discussed previously. But in reality, the sliver of conversation you are having right now is different than the sliver you had even hours before.

sycophAIncy

Commercial AIs in particular are designed to continue your engagement with them. So they’re friendly and complimentary unless specifically otherwise directed. This can sometimes mean too much approval, and too much willingness to go along with what you want.

Personal data

If you’re using a commercial AI, this also means your very personal data is also going into a corporation’s hands. This is creepy AF. Intellectually it may not even matter as all. But it’s still creepy. That a corporation could have potential access to a deep discussion of my life, goals, hopes and dreams.

Empathy literally can’t be artificial

AIs can by definition only simulate empathy. An image of something we need can be useful. But it is not a replacement, and it can’t be. A picture of a forest isn’t woods. A menu is not a meal.

The one clear thing a human can always provide, is real and direct empathy. This is hard to understate. Human connection is real and grounding, and provides a further map for interactions with all others. This includes not only positive feelings including validation and approval, but also useful grounding. When you are off point, a human therapist can let you know. And a human therapist can do this in a way that you can experience disagreement, and even disappointment. And learn how to deal with these situations in a safe container, and develop skills for dealing with imperfect and rich human situations in your life.

All that said

AIs are tools. They can be of great help to us–as long as we wield them with our eyes open. and maintain our willingness to learn and introspect about our own patterns of use.

A model I keep finding useful for AIs, is to consider them a swarm of interns. They can do a lot of work we don’t want to do, and they require supervision to make sure it’s done how we want.

This way of thinking can also apply to the kind of life advice AIs can provide us, if we ask them to.

Would you take serious, consequential life advice from an inexperienced teenager? Maybe on a question or two. But would you follow it without question?

Most assuredly not. You wouldn’t put faith in a deep question in someone who has much less life experience than you.

So much more so consider a computer, which has literally no life experience, and is only a language-based simulation of accumulated human text.

Perhaps said simplest: Ai is not an oracle. It’s a probabilistic simulation of a conversation. Hopefully with guardrails that will improve.

That simulation is like talking with a teenager who has instant access to the world’s information, but with literally no life experience and an extremely short attention span…and who will try to fake their way out of admitting they don’t know what they’re talking about.

For some initial thoughts on how you might be able to use AI as a benefit without running afoul of these issues, see my next piece: Ways to use AI for therapy less wrongly.

Subscribe now

…those topics, and tech writing about them, are the reasons for this Substack.

As happened in the early days of the internet, and is happening again now, sometimes some people find themselves close enough to the bleeding edge of a new wave that they can know more about it than many others in the media.

This appears to be one of those interesting times we are living in. : )

This substack will be covering thoughts on those times.

I would aos love to be informed by your thoughts and your own takes on all the matters discussed here. As well as silly things that might have to other point besides fun, which is more than enough reason.

I expect to be posting at least every other week, and possibly more often.

I look forward to exploring these times and possibilities we are living in with you.