Philosophy that has resonated:

• Why Nietzsche Matters in the Age of Artificial Intelligence
• Don’t turn of your brain
• Software Development in the Time of Strange New Angels

Things that look specifically at agentic workflows:t

• Tools on Claude
• Bitter lesson LLM extensions

I deeply enjoyed reading this article by Andrew Tsang that illustrates the flow of funds through different country’s healthcare systems.

What really stands out is how he phrases the analysis as uncovering the collective choices and values that the systems embody. This choice-based analysis works well with the visual metaphor in the Sankey diagram: each involves branching!

I like that the use of static images for the subsection call-outs in the observations on the US system. This is often done with with scrollytelling, using static images instead fits with my desires to flip between things in my own order.

To improve the diagram, I would try to stabilize the colors more: in the call-outs, sections are colored differently than they are in the combine diagram. There is some standardization between sections (nursing homes are orange..usually) but I would use that more. The worst offender is the diagram in the Workers pay at least twice, which changes colors from the main diagram but never refers to any colors to guide you! Then in the next section, the same colors are used for different things. If the base diagram could be restructured to implicitly keep those colors, it would make it easier to relate each targeted diagram back to it. I consider this a quibble, the diagrams remain understandable throughout.

Header image originally sourced from the source article. I could not find terms, so I’m the original author is OK with me posting a copy here and saying (again) that I think its an effective image and a good read.

For context, here are the database stats:

• 2M nodes
• 6M relationship
• >3K distinct node labels
• >10k distinct node label combinations
• >600 distinct edge types

My go to (in December 2025) is the JSON option: It is fast-enough and has the fewest pitfalls, but be aware that JSON import can take an order of magnitude longer than export.

Binary export

Export: neo4j-admin database dump neo4j --to-path /var/lib/neo4j Import: neo4j-admin database load --from-path=datbase.dump neo4j (Optionally, add --overwrite-destination if there is data.)

Explanation: As near as I can tell, this is basically a near-exact copy of the database as it exists on disk. neo4j-admin is a command line tool for administering the database.

Pros:

• Binary export and import are fast (wall-clock time) and space efficient.
• The commands for neo4j-admin are well documented
• It is a single command to both import and export
• Included in neo4j desktop tool in recent versions.

Cons:

• Requires stopping the database for both export and import. This requires platform-specific commands.
• Cannot merge into existing database
• Binary dumps are tied to specific versions, so if your infrastructure doesn’t match it may not be viable.

Conclusion: If you have a fresh database, this a great option.

CSV export (one-file)

Export: CALL apoc.export.csv.all("file:/database.csv", {}); Import: Process into separate nodes & relations files.

CALL apoc.import.csv(  
    [{fileName: 'file:/database_nodes.csv', labels:[]}],  
    [{fileName: 'file:/import/database_relations.csv', types: ‘’}],  
    {ignoreBlankString: True, ignoreEmptyCellArray: True});
MATCH ()-[t]-() REMOVE t.__csv_type;
MATCH (n) REMOVE n.__csv_id;

Explanation: The export produces a single csv with all of the columns needed to do both nodes and edges. I have a script that loads up that file, splits it into nodes and edges based on the _id field, reformats the list of node labels to be semi-colon separated and renames columns to use the right names. Including ignoreBlankString and , ignoreEmptyCellArray keeps the import from making all properties on all nodes/relations.

Pros:

• Relatively quick
• Works when nodes have thousands of labels.
• The raw csv export and the post-processed csv are understood by other tools
• Some additional options in apoc.export.csv.all extended documentation might make the process simpler.

Cons:

• The processing before input can be extensive. I have not included my script here because it is tailored to my specific dataset.
• There are issues around list-typed and empty-valued fields. It can take some non-trivial work to get an identical import after export+pre-processing.
• If you don’t do it right can silently drop of data on import

Conclusion: The post-processing has been a little tricky. This is a flexible and faster-than-CSV option if you are comfortable making it.

CSV export (bulk)

Export: Export: CALL apoc.export.csv.all("file:/database.csv", {bulkImport: true}); Import:

CALL apoc.import.csv(  
    [{fileName: 'file:/database_<label1>.csv', labels:[]},
     {fileName: 'file:/database_<label2>.csv', labels:[]}],  
    [{fileName: 'file:/import/database_<type1>.csv', types: ‘’},
    {fileName: 'file:/import/database_<type2>.csv', types: ‘’}],
    {ignoreBlankString: True, ignoreEmptyCellArray: True})

Explanation: apoc.export.csv.all with bulkImport: true creates a separate file for each node label combination and each relation type found in the database. You need to know those names at import time.

Pros:

• Fast export
• Data is immediately ready for import

Cons:

• No generic import command: you need to know the files produced.
• Having nodes with many labels can fail because the files are split by label combination and the name length may exceed filesystem limits.

Conclusion: When it works, this is the simplest option. Applicability depends on data characteristics.

Note: The same trick used in JSON for many-node-labels might work here to. I ran out of time to investigate!

JSON export

Export:

MATCH (n) SET n.labels = labels(n);
MATCH (n) CALL apoc.create.removeLabels([n], labels(n)) YIELD node FINISH;
MATCH (n) SET n:_IS_NODE;
CALL apoc.export.json.all("file:/database.json", {compression: "GZIP"});

Import:

CREATE CONSTRAINT is_node_unique IF NOT EXISTS FOR (n:_IS_NODE) REQUIRE n.neo4jImportId IS UNIQUE;
CALL apoc.import.json("file:/database.json");
match (n) CALL apoc.create.addLabels(n, n.labels) YIELD node FINISH;
match (n) REMOVE n.labels;
match (n) REMOVE n:_IS_NODE;
MATCH (n) REMOVE n.neo4jImportId;
DROP CONSTRAINT is_node_unique IF EXISTS;

Explanation: JSON import requires a uniqueness constraint for every node label. When working with many of labels, this is impractical. For export, this method moves all labels to a property and creates on label used by all nodes. The process is reversed on import. The use of FINISH when manipulating lables reduces memory requirements.

Pros:

• Produces JSON which can be imported by a number of tools
• apoc.export.json.all can compress on export or input. I compressed on export using but decompressed on the command line before import (as shown above).

Cons:

• Slowest import of all methods checked (5x slower than the CSV). This is likely because it builds an index as it imports.
• The multi-step dance is easy to make a mistake during. If you delete the labels property before successfully creating the node labels, it can cost a lot of time.

Conclusion: Its an OK process. If there are only a few node labels, creating uniqueness constrains for each is preferable to the technique used here.

Other notes:

• Neo4j apoc.import.csv supports “id spaces”. The original database was built from multiple different sources providing different node types. Id spaces made it easier to merge those sources together since we did not need to ensure the ids were disjoint between sources.
• The GML export dropped significant portions of the data without warning. I would not advise using this option.
• We did not test the XML option because we ran out of time!

However, when you try to interpret different parts of memory it breaks into two major categories:

• Data: Immutable, meaning is derived entirely from context, separate copies are indistinguishable and interchangeable.
• Resources: Maybe mutable, carry some inherent meaning and copies might be distinguishable from each other (minimally because mutability may lead them to have different values over time).

Attending to this distinction enables some optimizations and freedoms that are often lost.

The post is instructive in how it illustrates that the distinction is latent in the Rust type system. Copy items are data. Any time you use a mutable borrow (&mut), you are treating something like a resource. Rust isn’t enforcing a data/resource distinction, it assumes everything is a Resource, but it manifests one and that might inform future language design. This is in contrast to clojure that assumes everything is data and goes to some lengths to ensure that most resources behave like that through extensive use of persistent data structures, to get a resource you use the transient or ! function variants, but it is presented as n optimization.

“…general methods that leverage computation are ultimately the most effective, and by a large margin.” –Rich Sutton (March 13, 2019)

The Bitter Lesson is a short essay by Rich Sutton. It’s worth a read, but I’ll summarize the last two paragraphs here:

• Observation S1: Attempts to inject “knowledge” leads to early advances but rapid plateaus while search and learning compound.
• Observation S2: There are two things that scale easily when you add more computation. These same two things are driving current advances in AI. Those two things are Search and Learning.
• Implication S1: General-purpose methods (like search & learning) that scale with computation are the most valuable
• Implication S2: Minds are complex enough that seeking simplifications is ultimately a dead-end. (This last one is a bit of a logical jump… but a smaller jump in Sutton’s essay than I’ve just wrriten here.)

Sutton was talking specifically about AI advances, and how the past 6-ish years of deep learning punctuate his point. Rodney Brooks posted a rebuttal The Better Lesson. I summarize Brook’s points as this:

• Observation B1: Convolutional Neural Networks, neural network architectures and training regimes that preserve human-relevant factors are ways that humans still inject “knowledge”
• Observation B2: People need less than computers to learn these sorts of things so “something” is still missing.
• Observation B3: The free lunch is over so don’t rely on it to improve your naive algorithms.

Now for my (admittedly 5 years late) observations:

• Brooks makes a strong point that “something” is missing, but this point is weakened because the place and method of knowledge-injection is radically different from Sutton’s. Brook’s phrasing is a denial of Sutton’s thesis, when I see Brook’s arguments as fundamentally supporting Sutton’s point (that injecting knowledge at algorithm level is ultimately a loosing strategy). Brooks and Sutton BOTH are arguing that we should look for smarter, more scalable ways to introduce things that we have learned are important. (But they disagree on what “scaleable” means.)
• Insofar as AI is trying to model a mind (human or otherwise), Implication S2 is probably in the right direction (though perhaps a bit fatalist). However, when AI is trying to model/estimate something it must be assessed on a case-by-case basis. For example, physics-informed machine-learning probably still benefits from injecting simplified models (albiet, used in a different way with deep learning systems than with others).
• Search & learning are general-purpose computational methods that scale for AI. Does the observation hold for other parts of computer science? I feel echos of RISC architectures, which under-pine the modern desktop systems…but do not feel as simple as they used to. The scaling doesn’t always play out like we think, though the quest for simplicity will often be beneficial.
• Observation B1 really only works because the architectures created can be searched efficiently (relative to other stuff we’ve tried) for weights that effective. Colloquially, that type of search is called “learning”. The search/learning are facilitated by the architecture….maybe B1 and S1 are the same observation in different clothing.

Most all automations are not defined by the standard case or the typical inputs but by exceptions. – Steven Sinofsky

In some ways, programming is all about automation. BUT there are some tasks that are more clearly about it than others. While reading about the philosophy of various build/data-pipeline systems, I came across this post about what drives complexity in such systems. It’s not the “happy path”, its the “sad path”…because there are usually so many sad paths and so many ways to get onto them!

A second point the article drives home is that the exception/error cases are usually discovered incrementally through use. They almost by definition can’t be built in from the start because they often don’t even exist when the system is first created.

Having recently helped my daughter get her driver’s license, the point about many human-centered processes being focused on exceptions really drove home. I have renewed my licence many times through the years. I use a mail in form (anciently) or electronic form (recently). But a FIRST license is an exception case…and required a trip the BMV and standing in line…and going back three times for various bureaucratic (i.e., exceptional case) reasons.

The observation at the end of the article is that many successful computer tools help people to finish a job rather than start a job. The folks I know who are powerpoint/illustrator/chatGPT are capable, knew their inputs, are well versed in the non-computer skills relevant to presenting/graph-design/writing. They could do it themselves, but computation/automation helps them do it faster. The people that don’t have those baseline skills….no amount of powerpoint wizardry, illustrator fiddling or ChatGPT prompting will save their presentation/drawing/novel.

I used to just copy my utilities and modify them in place to my hearts content BUT they have largely stabilized (so they change slowly) and most changes are now bug-fixes (so they need to be propagated to other projects).

For example, I have a tool that lets me edit JSON files using python lists and dictionaries in a path-like syntax. I find it more convenient than using jsonpath for queries AND it lets me edit things in a way similar to glom but covering a very important case that I could not get glom to do. In the process of making my edit-tool, I DID NOT cover a lot of cases that glom does…so this is very much a tool-for-me…but it is a tool I’m using in 5 different projects now.

Pretending my tool is called json_tool and pretending that its git repo url is ssh://git@fancyserver.org:somewhatuseful/json_tool.git…

The repo structure follows the current practice of a pyproject.toml file and the package source files in a directory with the same name as the project (json_tool today).

root
├─ json_tool
|  ├─ __init__.py
|  ├─ find.py 
|  └─ edit.py
└─ pyproject.toml

The package source directory (and all other directories under it…if they existed) has an __init__.py to indicate they are regular packages (I did not test with namespace packages).

To install, pip install git+<normal-repo-checkout-url>. If the package name (specified as name=<package-name> in pyproject.toml) does not match repository name, you might use at the end of the URL used in pip install git+<URL>#egg=<package-name> for the install. (This fragment fixed a problem…that I couldn’t reproduce using the fragment-free URL after it was fixed once.)

To update after bug-fixes, I use pip install --force-reinstall --no-deps git+<normal-repo-checkout-url>. This forces the re-install of my custom package, but does not stomp on the other dependencies in my environment. (The --no-deps might be removed in the future as I learn more about proper control of dependencies in pyproject.toml or if I-learn-how/conda-gains-the-ability to install from git in a way that isn’t just calling pip under the covers…)

The article is called “visual programming” but it only treats construction-of-a-program-via-visual-means superficially. The only type of visual programming examined is basically alternate-syntax. The issues that they point out are fair, but it not really a look at visual programming.

That being said, their argument to support traditional programming through visuals caught my attention.

Context

How is this codebase structured now and how has it evolved? What has been retained? What is it related to? Examples used include:

• SourceTrail: Sort of an automated UML-class diagram made automatically. The strength the author points out is that it is presented NEXT TO the source code, so it is truly context for source editing. Used in that way, and automatically generated, I think this is a good idea.
• Code retention diagram: How long has this been around? Though the shelf-life of code itself is not one of my particular interests, looking at historical information in this way may help understand who to talk to or how careful to be with some code regions.
• Computer-network/service-topology: For slices of a network, I have found these valuable in my work. For small networks they solve a navigation problem that is hard to trace out the json files they come from: What is interconnected? (I don’t think they scale to large networks well, I’ve never tried!)
• Treemaps of source code: This is at the bottom of my list because I don’t find these diagrams terribly readable or compelling. The observations being made are usually achievable by sorting a data table appropriately and reading the top 3(+/-2) lines.

Execution Artifacts

How does the codebase achieve its intended result? NOT the result itself, but the process that led up to that result. Examples used included:

• protocol visualizations
• “swim-lane” diagrams
• State machines
• Memory layout (but not global, for select data structures)
• Memory traces (but not global, for selected values)
• Value ownership

I think this is an important area. The amount time/mental-effort it often takes to move program-execution trace information to a visual often exceeds the time/mental-effort to use a step debugger (except in parallel/distributed systems). Reducing the effort to cross this bridge is a recurring daydream…but then I need to go do my actual job.

Wikipedia says “A material is brittle if, when subjected to stress, it fractures with little elastic deformation and without significant plastic deformation.” That is to say, brittle things won’t bend, they just break.

Fuses are an example where brittleness is used to benefit an electrical system. Rather than slowly degrading, they trip…and the whole system stops before worse things can happen.

In Haskell, types introduce useful brittleness. They are compiler checked assertions about the program. If the types don’t match up, the system stops. In Python, tests are a deliberately brittle point (when written regularly, run often and issues routinely addressed)¹

The trick is to hit the right amount of brittleness in the right places. What constitutes “stress” to the system? Where can breaking under stress prevent worse issues?