CJ Eller

Thinking about tools for thinking about thinking

Imagine you are asked to take notes on everything you read on the web.

Jesuit professor Jeremias Drexel recommended such a practice for reading in the 17th century. As Ann Blair mentions,

[I]n his regimen there is no reading without taking notes, which would be idle and vain, and no time wasted because every free moment can be put to use reading over one’s notes.

While reasonable with print, the task strikes one as quixotic on the web. Why? Because of the sheer immensity of what we read. You might as well take notes while being pummeled by water from a fire hose. Virginia Heffernan put it succinctly in her book Magic and Loss:

With media, books, texts, and emails on mobile devices people are never not reading. We read while we're socializing, working, shopping, relaxing, walking, commuting, urinating. From a nation that couldn't stop eating, we've become a nation that can't stop reading. As day follows night, our current form of overconsuming might be overreading. Hyperlexia.

The goal of Drexel's regimen is to retain what one reads and to use it in study. I can barely remember what I looked at on the Internet yesterday. There might have been something useful, but searching through my History tab would be a lost cause. Our memory falls under the weight of words proliferated on the web. It doesn't matter if they come from an enlightened essay or an inane social media status.

So we have to ask ourselves how to remember what we read here on the web – how to retain what is beneficial and use it in our study and in our lives. I wonder if we even realize what we are missing out on. The only thing that gets measured is how much new content gets published on the web every day. But do we know how much of that potential energy is wasted on taxed minds who will forget what they read moments after?

There has to be a better way.

If we want to respond to a post on the web, how do we normally do so? Scroll down to the comments and have at it. Every other article has a deluge of remarks and rebukes.

Comments inhabit an odd space on the web. Both constructive and equally destructive. Both a mirror on human nature and a product of our own design. Because of this we don't know what to do about them.

But how did we get to this point? What are the predecessors to comments? What could we learn from them?

One form that particularly intrigues me is letters to the editor. Per Wikipedia, a letter to the editor is the following:

a letter sent to a publication about issues of concern from its readers. Usually, letters are intended for publication. In many publications, letters to the editor may be sent either through conventional mail or electronic mail.

An LTE is a composition that is vetted before it is published. It also ensures that the letters published are thoughtful compositions that make a point worthy of others to take note of.

Another aspect that some academic publications include in their LTE's is having the author respond to the letter. This creates a space where a worthwhile conversation can take place. One where an error is noted and corrected, where another side of an issue is highlighted.

And worthwhile conversation is the goal no? But all of this is mere speculation. A hypothesis means nothing without an experiment.

So please, if you have any thoughts concerning these posts, open your email and send over a letter to the editor at the following address.

Reading and writing blend seamlessly on the web. Sometimes too seamlessly. We take for granted that we use the same software to both read and write. But it wasn't always this way. Tudor Girba made a compelling observation about this with text editors on the Future of Coding podcast:

But code isn't text. It just so happens that we, most of the time, use a textual notation to input the code. By the way, where do we do the reading? We do it in an editor. That's interesting because the editor was not created for reading. Its main purpose was to input code into the computer. Yet this is where we'd been spending most of our time to do the reading. And I think because we have not talked seriously about how we do the reading, we [are not aware of] the most basic assumptions we have around us.

Reading and writing decoupled. It is hard to grasp because most of the tools we use are for both. This is especially so with collaboration/productivity tools like Confluence and Notion. One is expected to use this software to write the pages that others will read with the same software.

But sometimes I find this software too clunky to just write with. Notifications and dashboards beckon me to other places on these platforms. I want to rearrange Kanban boards rather than write documentation.

This is where software like Write.as occupies a unique space. It allows one to simply write. But not only that. I can then use their API to send the post I wrote over to Notion to create a page or Kanban card. Then I can read, rearrange, and use all the extra gadgets allotted to me by Notion.

Reading and writing decoupled. What benefits can come from such a decoupling? Can the benefits of this process outweigh any initial confusion or inconvenience?

When the Seventeenth Century ended, the published work of Isaac Newton amounted to little more than the several hundred copies of the Principa, most in England, a few scattered on the Continent. They were not much read, but scarcity made them valuable...

At least one student saved his money and made a copy by hand.

This image laid out by James Gleick of a student copying Newton fascinates me. Who knows how long it took. But there is more to this feat than its audacity.

Newton's Principa at that point was accessed as a printed book. According to Gleick, a bookseller sold the work for two guineas. Two guineas would get you a printed edition just like the other several hundred copies out there.

So here comes the student. What did he do? Well, he probably took one of those copies of the Principa, tucked himself in a corner, and started writing it down. What did he write the Principa in? An empty leather bound book? A journal? Pieces of loose paper? We don't know (or at least I don't).

But now the student had his own version of the Principa, different than all the other three hundred copies out there. That copy could be referenced, rewritten, and rearranged as a unique book in and of itself.

This act is a predecessor to what the IndieWeb calls PESOS – Publish Elsewhere, Syndicate (to your) Own Site. Sure, the student did not write the Principa, but it sure as hell was published elsewhere and syndicated to the student's own paper.

In a world of publishing elsewhere, there is a power in syndicating our content and the content of others to our own domains.

What do you do with an index card after writing on it?

Tape it to the wall? File it away in a folder? Place it in your pocket? Use it to mark a page in a book?

An index card has many uses. And that's the point – an index card is only as good as its context.

Take a card with a term on one side and a definition on the other. It works well with similar cards, especially when trying to memorize for a test. Or how about a card with notes from a particular page in a book? Tucking the card away between that page would make sense. You can reference it any time you open the book.

There is a power that comes from context.

So I think of a tool like Write.as where I can easily compose posts. These posts are usually relegated to the context of a blog or published anonymously.

But the title and body of a post can act like two sides of an index card. We can publish a post and then send its contents elsewhere. That elsewhere changes the context. A blog post becomes a cell in a database, a message to a friend, a toot in the Fediverse, a card on a KanBan board, an event in a calendar.

A post has many uses. What others are there?

Kids usually begin playing baseball with no pitching at all. Instead the ball is placed on a tee for them to hit. We call this Tee-Ball.

Then a child progresses to the ball being pitched. But rather than being pitched by another kid, the ball is fed into a pitching machine. We call this Machine Pitch Baseball.

Finally, after that, we have kids pitching to other kids. Junior league baseball all the way on to the Major Leagues.

What is interesting through these stages is that, for the most part, throwing and catching is the only thing that stays the same. Kids are expected to throw and catch the ball from the start. There is no assistance like a sticky ball or glove. Only for pitching and hitting do things begin more abstractly and ramp up over time. And that makes sense. Pitching and hitting are extremely difficult to learn. We need ways to help abstract the practice before moving forward to the next level.

This reminds me of why software development is so difficult. Writing the code seems to be like throwing and catching. No matter what there has to be that core competency. And like throwing the ball around, it can be enjoyable on its own. But then we are thrown into the world of deployment. It is as if we skipped Tee-Ball and went straight to someone pitching the ball at us. Swing and miss ad infinitum. We get frustrated and wonder how anyone can deploy a website. Even meeting halfway with Docker or Heroku can be baffling. Just because a machine is pitching doesn't mean it is any easier to hit.

So I wonder, as Alan Kay did in this talk, what is the Tee-Ball of computers and software development? Like with hitting and pitching in baseball, what part of software development needs to be abstracted and slowly ramped up? Is it the deployment side of things or something else entirely?

At a meet up I recently went to, someone mentioned that he wanted to learn web development with Python. He knew Python fundamentals. Wrote an algorithm here and a script there. The problem was that he did not know how to apply these fundamentals to create a web app.

It reminded me of when I started learning how to improvise on the guitar. I practiced my scales and chords but was at a loss. I had no idea how to use them in improvisation.

The connection between fundamentals and application was broken. It is a chasm we often face. We want to take what we learned out of the context of learning and into the context of practice.

How do we do accomplish this?

Well, I remember my guitar instructor taking a simple chord progression in the key of C major and playing it for me on his guitar. While playing that, he told me to play the C major scale I learned. As he played the chord progression, I plucked out the scale.

My instructor then had me alter the ways I played that scale. Change the rhythm, play every other note, hold certain notes for longer. Sooner or later I was deviating from the scales I learned. It did not sound particularly good, but I saw the potential in how the notes interacted with the underlying chord progression. There I was, taking what I learned and hearing it applied to improvising.

With the guy who wanted to learn web development, I showed him a Python web framework called Flask. Not in any normal text editor, but within the context of an empty Flask app on Glitch. Here is a little bit about the platform from their 'About' page:

If you’re not a developer, don’t sweat it — you can make simple changes as easily as you edit a spreadsheet. Apps update live as you type. You can even share the project with a friend or colleague and they can work on the same code at the same time as you. It makes collaborating on code as easy as sharing in Google Docs.

In Glitch we pulled up the code and the app in parallel windows. I explained to him that at the core of each route in Flask is a Python function. And guess what? He knew how to write functions. So he created one for the route. It just returned a string. With the live updates provided by Glitch, we were able to go to the url of that function and see the string his function returned.

While just a string, he was creating a web app. That function was then built upon. Instead of returning a string, we made the function return an HTML document. It suddenly clicked. He could see the potential of Flask and, most importantly, could see himself using it.

His fundamentals helped him here. All that was needed was the means of applying the skills that running Flask locally could not offer. Glitch had served him in that moment just as my instructor accompanying me did. It was a way to move out of the context of learning and into the context of practice. It allowed him to see the link between what he was learning and what he could do with it.

I wonder how tools like Glitch can continue to be applied in this way.

A number can evoke a jolt of adrenaline. Excitement surfaces just by seeing it.

This platform is as minimal as it gets, but one affordance that is carried over from bulkier CMS software is stats. How many views does my blog get over time? What post gets the most views? Where do these views come from? Even these are minimal.

At first I thought the stats would not get to me. This is a new writing experience. Focus on the verb, not the noun. Over time, however, I found myself going back to older posts. Not to increase their quality through editing. Not to add supplemental content.

None of the above. I went back to look at their view count. Did they increase from the last time I looked? How much more could they go up? Questions and dopamine around a little number in the top left corner.

How little we need to get that fix.

Regardless, the minimalism of Write.as is primarily a virtue, especially in configuring one's experience. So what I decided to do is go into the Custom CSS and add the following code:

.views {
    display: none;
}

Nothing more and nothing less.

It allows me to revisit a post without wondering about its view count. Instead I think about building on its ideas, how it relates to things I have heard and read, what I could do to make it better with the feedback and information I now have.

The post itself should be the primary concern. Not the artifacts attached it like view counts or likes.

We have to focus our energy on the nouns that are most important to us. Why not make that the writing itself?

Why do I not have the data to see how many times a person views the email I sent to them?

Because applying stats at that scale is a wasted effort. Either the person will see and respond to the email or she won't.

How about when I send a message to an internal email group like “All Staff”? No statistics still. Either the people in the email group will respond or they won't.

This starts to change when we get into the realm of email newsletters. Then we start to care about open rates, impressions, and the like.

Why? What is the line between a dashboard of statistics and simply walking up to a co-worker's desk to ask if he got your email?

When sending out smaller scale emails, the mode of communication is one to one or one to a few people you know. Scaling up, the communication becomes one to many people who you know (and a lot more you don't know well enough if at all).

This changes the rules of engagement. More processes need to be put in place in order to understand who exactly is responding to your messages. From newsletters and blogs to podcasts and social media, any form of one to many demands view counts and impressions and SEO and meta tags. An inquiry post drives the point home:

Seems to me “the web” doesn't do diddly in terms of bringing one to many without a whole lot of other gunk from crawling to indexing to the content being sufficiently important to those who crawl/index to rank it such that it has a chance in hades of turning up high enough in search results to maybe be seen by probably not a lot of people – who still have to follow the link depending on how clickbaity the title and/or content selected for display in search, etc., etc.

It makes one wonder how far back the need for said gunk goes. Jaron Lanier made a good approximation in this interview:

The original idea was to make the internet just super bare bones. So the initial internet had no representation of people. There was no membership concept. There was no identity concept. There was no sense of authentication. There was certainly no implementation of commerce solutions. There was nothing. It was just very, very raw. And in that spirit of keeping everything as minimal as possible, the web protocol committed a primal sin of not having backlinks.

And not having backlinks, Lanier stressed, would make one to many communication even more difficult.

Something could point at something else to get at that thing's data. But the thing that was pointed at didn't know it was being pointed at, and that created this web where there was no provenance for data. No way of knowing what was real. No way of knowing where it had come from, and therefore no way for people to accumulate personal achievement.

So enter the gunk:

Turns out Google filled in the backlinks. That's essentially Google's core function. Or it was at the start. Who's going to create these accounts? Well, initially, firms like MySpace, but ultimately Facebook. And so all the things we left out deliberately turned into these giant monopolistic companies.

It makes one wonder whether this gunk buildup is an inevitability on the web. Can there be alternatives brought about through decentralized networks, peer to peer protocols, and other means?

I want to be optimistic. Even if it means using a toothbrush, I will do my part to scrub off what little gunk I can.

Learning to write, something magical occurs to you. People can understand what I am writing.

Another magical thought follows that. If someone can understand what I am writing, I can choose who I write to.

Then comes writing papers. Then comes passing notes in the classroom. Then comes penning love letters. Forms of one to one and one to to many communication.

Then comes the web.

One to one? Sure. Private message away. Shoot an email.

One to many? That is the web's specialty. 'Many' does not begin to describe the multitudinous masses that can read and respond to your work. While the number is vast, it is also indefinite. You are never sure who reads your work. Impressions? Views? Likes? Those never tell the whole story.

Rather than handing a message to a person you are putting that message into a bottle and throwing it out to sea. Perhaps someone will read it. Eventually.

So when peer to peer and decentralized protocols like Dat and ActivityPub come into the picture, I see something that tries to face the above problem head on. It fits snuggly between one to one and one to many, trying to scale the intimacy of communication found between a small group of people.

And perhaps that is the sweet spot we are looking for, regardless of the protocol or platform – to be both understood individually and part of something bigger than ourselves.

How to find that middle ground?