Coda docs are wonderful because they can start simple and grow to unlimited complexity.
Let’s use that superpower as much as possible. If you were to prototype a workflow in python, node.js, etc it would be a really expensive process and would require many meetings. With Coda, in 30 minutes we can often get a prototype running that teaches us something almost immediately.
For this reason, my approach is:
(.5-2 hr) Meet about your goals, go through some sample workflows, prototype in meeting, explore the requirements.
(1-10 hr) Implement what you asked for.
(Slack Message) Check that things are working as you expect. Return to Step 1 for next opportunity to improve
As much as possible, I like to have lots of access to ask questions so that our meetings can be shorter and the flows I implement make sense.
Standardization helps you keep track of important information as a doc grows more complex, and it helps you reason about where I might have put certain information. I use the All|Configure|In|Out standard.
A page named "Hidden" (or the like)
[All *] :: for tables with data that are frequently added to and manipulated.
[Configure *] :: for tables used in lookups that are infrequently changed.
[In *] :: for tables that are Cross-Docced into the Doc.
[Out *] :: for tables that are Cross-Docced out of the Doc.
Documentation :: to document all (non-trivial) formulas.
Helper Formulas :: for collecting frequently referenced formulas.
Of all of those pages, the most important is the
Documentation page. On that page I put a summary of all the formulas that are used throughout the doc and what each line does. This makes it easier for you to maintain the doc after I’m gone or if you can’t get ahold of me. Some people also like to follow the documentation to learn the Coda formula language better.
It’s not just for you, it’s also a really important part of my development process. Adding a line by line summary makes it faster for me to “reupload” the thinking behind my formulas after I’ve been away from the doc for a while. In the process of writing the documentation I often find optimizations I can make to save on complexity, speed, space, etc. Or sometimes I just catch bugs.
Here’s an example:
Each complex formula in your doc will be accompanied by a section that looks like the one above.
To get ahold of me reach out to connor *at* supsync *dot* com