Hi, I'm working on ways to improve documentation and explanatory tutorials for software projects. The proposition is to make it easier for both newcomers and seasoned programmers to learn new tools and build up a coherent picture of how complex, interconnected systems fit together.
I'm currently looking for someone to co-found and submit a Y Combinator application with, so if this sounds interesting to you please reach out and introduce yourself (email below). This document details where the project is so far, how we might work together, and roughly what the next few milestones might look like.
The first goal is to verify that we're compatible and have similar interests, skills, and goals, and agree on a way of working. Then we would:
- Refine the idea
- Build a demo
- Submit the demo to YC. The summer '22 deadline is March 24th so this will most likely be the winter '23 round.
The first product would be a platform for creating documentation. Here's an answer I drafted for the "What is your company going to make?" question on the YC app:
A platform for user-submitted documentation driven by connection-building, honest discussion of projects' purpose and design trade-offs, and examples that refer to individual lines of code and traverse project, process, and stack (as in TCP/IP) boundaries.
For example: describing what Apache does is hard, because as soon as you start saying "it serves HTML files", your description is incomplete and you have to step back and generalise to the point of obfuscation. Describing what happens when Chrome 94 requests this particular HTML file from Apache 2.0, running on Ubuntu 20.04 (etc...), is easy, rewarding (people like knitting things together), compelling (there's always more to add), and collaborative (you can elaborate on parts that other people don't know and vice versa).
These highly detailed, specific examples will form a connected graph and encourage self-directed exploration from the reader by allowing them to choose their own path through the layers of abstraction and go down rabbit holes as they see fit, while grounded by the specifics of each example.
Exploring and generalising from examples is what the human mind does best: example-driven docs will leverage that.
The following questions from the app also nicely serve our purposes here, so I'll just list what I've drafted for them as well:
Q: Why did you pick this idea to work on? Do you have domain expertise in this area? How do you know people need what you're making?
Confusing documentation is a significant source of frustration in my daily activities as a developer, as it is for many or even most others (https://opensourcesurvey.org/2017/#insights). Bad docs can be the deciding factor in switching to otherwise less-suitable technologies, as this Hacker News thread on Hugo indicates: https://news.ycombinator.com/item?id=30527884.
I've written some (e.g. https://npmjs.com/package/svelte-view-engine) and read a lot of documentation, so I'm aware of the challenges involved and what makes for good and bad documentation.
Problems with docs are pervasive and any significant improvement to the situation will be enthusiastically welcomed by developers at all skill levels.
Existing efforts to improve the state of documentation, such as the four-mode model of https://diataxis.fr, focus on persuasion; trying to convince people of the benefits and persuade companies and maintainers to adopt a new way of writing docs.
These efforts will be up against strong incentives for official docs to tend toward certain characteristics -- like emphasising the selling points of the company or project -- as well as inertia, and so are unlikely to move the needle much. Instead, we can just build the docs we want and these will naturally tend toward complementing the official docs, resulting in a healthy self-correcting balance and acting as the go-to source for anything that the official docs don't cover well.
Good documentation has the potential to dramatically speed up the onboarding process, saving large amounts of money in developer time for companies with inhouse software teams. One route to monetisation would be to offer a SaaS version, similar to Stack Overflow with Stack Overflow for Teams. Stack Overflow for Teams is $6 - $12 per month per teammate. Assuming 1,000 organisations x 50 teammates at $9, this would be $450,000 per month.
I envision working with one or two co-founders with a focus on quickly prototyping and iterating on a product. I'm an engineer, and since the area of business -- improving technical documentation -- is tied to engineering, I expect that co-founders will also be engineers. We would both/all work on both the ideas and the implementation.
This idea is in the early stages and I haven't done a significant amount of development work on it yet, so almost all of the equity is still available. To perform the split, we would use a calculator tool such as Slicing Pie (https://slicingpie.com). This takes into account the relative value of each type of work (as decided by the team) and how much each person has done. I propose doing this at least 2 weeks before submitting the YC application, but otherwise as late as possible.
In order to draw a clear, if somewhat arbitrary line, "work" for the purposes of the equity split would be anything you do, including thinking, while at your desk. Anything else (thinking about the problem while not at your desk) would not count, as it's hard to quantify reliably. Specific, executable ideas, however, will count towards the split (regardless of where they were had), so you should be sure to document these. This "at the desk" distinction should encourage early-stage work to focus on creating a tangible product and getting to a prototype quickly.
Most of the ideas I've had are distilled in this document. I've also spent around 3 hours playing around with gdb to look at the possibilities for enabling easy-to-use breakpoints on an entire Linux installation. This would be factored into the equity split using the same method as for other contributions.
I'm a full-stack engineer from Hull, UK. I like working on large problems that will have a broad impact, like creating better docs or designing a better editor.
Outside of tech, I like going outdoors (especially in boats of some kind), building things out of atoms instead of bits (converted a Transit to a camper with solar panels etc in 2017), playing chess and doing cryptic crosswords.
I'm currently looking for a full-time job. Depending on the company's position with regard to side projects, I expect to be able to put somewhere between 5 and 10 hours a week into this project.
If this sounds exciting to you, I'd like to hear from you and figure out if we might be a good fit to work together on this project. Send an email to gus@gushogg-blake.com with a brief introduction and we can go from there!
- Gus