Connor McCormick Coda

Explore

My Approach to Coda
My Approach to Coda

Design Process

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.

Design Philosophy

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.

Doc Structure

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.

Documentation

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.

Contact Information

To get ahold of me reach out to connor *at* supsync *dot* com

Read
`About Me`⁠
⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.

My Approach to CodaMy Approach to Coda