I’ve almost finished the API server migration and getting Findka Essays back up; ETA is a couple days.

My article for this week is basically a personal mission plan. I’d like to make more connections with people who care about the same kinds of things as I do, so I’m trying to condense my main ideas and goals into a single, short document (which I’ve linked to from my home page). I plan to revise it continually. A lot of the material will be familiar if you’ve read some of my previous articles.

One of the interesting results of running The Sample is that I see a lot of newsletter subject lines. This one caught my eye last week. It’s the prologue of a new book called Wanting, which discusses the idea that often, people desire things mainly because other people desire them, not because the things are actually worth desiring. I bought the book, got 10-15% through, and then gave up because it wasn’t dense enough. (The common should’ve-been-a-blog-post problem). Instead I recommend reading this encyclopedia entry on René Girard, the philosopher upon whose ideas the book is based.

The weekly plug: I’m available for freelance web development.

What I’m trying to do

Read original on jacobobryant.com

There are currently three big things I’d like to do with my career. I’m describing them here so that I can connect with more people who are interested in the same things. If you’re interested in any of this, send me a link to your blog/newsletter/Twitter account so I can follow you: hello@jacobobryant.com.

1. Help build a career path for software inventors

I spent some time in college doing undergrad research. After I graduated I spent a year as an employee (software engineer), and as of writing this I’ve been an entrepreneur for 2.5 years. In each case I’ve concluded that the role is fundamentally misaligned with my motivations.

My ideal role is “software inventor.” To illustrate, consider the success criteria for each role.

• Research: discover knowledge.
• Invention: create valuable things.
• Business: make money.

There’s plenty of overlap: both research and business can and often do involve building new things. But in these domains, invention is a second-class citizen. If a researcher builds something interesting but doesn’t produce any novel insights, they’ve failed. If an entrepreneur builds something useful but doesn’t figure out how to monetize it, they’ve failed. Moreover, you can be a successful researcher or entrepreneur without doing significant invention.

I think the field of software would progress faster if there was a dedicated career path for invention, so those who wanted to could focus on building valuable things without hard research or business constraints.

Further reading:

• We need a career path for invention
• Reflections on 2020 as an independent researcher
• Shifting the impossible to the inevitable
• On the use of a life
• Roots and branches: centralization and the role of software startups

Progress

I’m still working on doing this myself sustainably (savings and cheap living will only go so far). I’m bootstrapping a business which will hopefully provide income at some point, but I’m not sure how long that will take. I’ve started passively looking for freelancing clients in the mean time but am still mainly focused on the business. I might shift more weight to freelancing later.

Once I have my own business working (whether it’s the product business or the freelancing business), I’d like to expand by hiring people part-time, following Gumroad’s model. That article mentions how one employee used his part-time position as an opportunity to build his own business until it was mature enough to warrant quitting the day job. I’d like to recruit people who want to do that, so we can make a network of part-time only companies. Ideally the network will grow fast even if individual companies within it don’t (compared to VC-backed startups).

The goal is that anyone interested in software invention can get a part-time job within a community of inventors. If they like, they can try to start their own business or get patrons, or they can stick with part-time labor. Actually I think part-time work could be a fruitful source of ideas anyway.

2. Help good information spread faster

Information overload is one of the most important problems of our time. The flip side is that it’s also a great opportunity. If we could optimize the way we route information through society, the benefits would be enormous.

To make that more concrete, think of some problem domains that partially reduce to “match the right bits of information with the right people.” For example:

• Politics
• Networking (including job search and recruiting)
• Product distribution (including for independent creators)

The fundamental obstacle here is that information spreads when it’s good at spreading, not when it would be beneficial for society. It’s characterized by evolution. There are many ways this plays out suboptimally. For example, rage spreads like wildfire. Another problem is simply that it takes resources (followers, connections, money) to make information spread. The person doing the spreading has more effect than what’s being spread.

So, the question is: can we alter the fitness function for information? Can we make it so information reaches people if and only if it would benefit those people, regardless of where it comes from?

Further reading:

• Search, discovery and marketing
• The Big Promise of Recommender Systems

Progress

This is the focus of my not-quite-a-business, Findka. Mainly I’ve worked on recommender systems (one for newsletters and one for essays), where users rate items and the system presents new items to rate. I like recommender systems because I think they represent the ideal combination of human and machine: humans are good at judging individual items but bad at coordinating information at scale. Software is the opposite.

In practice, recommender systems are hard to get right, and they need a lot of data. So they’re just one tool in the toolbox. In the long-term, instead of focusing on just one product, I plan to make lots of little apps—anything that makes sharing and discovering information easier is in scope. But I’d like to get some revenue before I branch out too much.

3. Help make the web more interoperable

Instead of a few large platforms, there should be many small apps that “do one thing and do it well,” relying on each other for the features they don’t provide. These small apps should interact through common interfaces (protocols) so that they can be easily replaced. Then entrepreneurs (and inventors) can improve on a single feature (small app) without having to recreate an entire system. More competition, faster rate of improvement.

Further reading:

• The Web’s Missing Interoperability
• Protocols, Not Platforms: A Technological Approach to Free Speech

Progress

Something like Solid is the right approach in my opinion. You should have all your information in a single database somewhere, and apps should use that database via an API (with proper access controls). Any app you write this way will be default interoperable; you don’t even need to publish your own API. (There will be extra work in schema design though, otherwise apps won’t be able to understand each others’ data).

There’s an interesting analogy to functional programming: it’s better to have 100 apps operate on 1 database than 10 apps operate on 10 databases.

My plan is to morph Findka into this. Currently, The Sample and Findka Essays each have their own database and algorithm implementation. I’m in the middle of setting up an API server that will store all the rating data in one database and provide an API for recommendations. The two apps will then become front ends for this API server. After that, there are a few steps left:

1. Build more front ends for the API server. These can be more recommender systems (like a book recommender) or they can be simpler CRUD apps for interacting with preference data (like a bookmarking app).

2. Have the API server include an authentication service, so users can have a single Findka account which owns their data from the various Findka apps.

3. Open up API access so that other people can make apps that interact with your Findka preference data (again, these could be recommender systems or not).

4. Somehow let apps install their own schema so that they can store more kinds of data than just content preferences. Handle authorization granularly so that apps only get access to the slice of the database that they need.

5. Move Findka’s recommendation code into a separate app, then open-source the rest of it (code named “Hubert”). Define a protocol for Hubert so that apps can work with either Findka’s Hubert instance or self-hosted Hubert instances. Make sure the recommendation API follows the protocol and works with self-hosted instances. (For this to have maximum impact, it needs to be a public good).

I’ve done a little prototyping on this, but I’m restraining myself from further work at least until I have revenue.

View discussions