My work: Calculations in Coda
Why I use Coda instead of Excel
“I set up calculations” is my close to standard response when asked what I am doing. In Dutch: ‘Ik maak sommetjes’ and then people gaze at me. Let me explain what this means: ‘sommetjes maken’.
Most people use spreadsheets, Google Sheets but more often Microsoft Excel. For good reasons I would argue and if you are not convinced by the super powers of Excel, have a look at this blog.
I use Coda.io instead
Super powers come with great responsibilities and the reality is that most users cannot handle them well. Excel permits you to use any cell as starting point in any tab and so it happens. In the end most users get lost.
Excel’s flexibility and power is a double edged sword. Unlike many domain specific SaaS applications, Excel lets you do just about anything you want. Excel is not very opinionated software, nor is it constrained to prevent the user from doing things that might get them in trouble.
Coda and the likes are less flexible. In Coda you create a page, you give it a name, you add a table, define columns names and types and you start building. Although it all starts with a blinking cursor, it is a bit more difficult than typing something into a cell. Using Coda requires reflection on what you want to achieve. Reflection of this type is counter intuitive, but if you — for what ever reason — simple get started, you soon regret it. Like in Excel, things get messy and complicated. In this regard, there is no difference. More about this in my blog:
Taking a bit of time to look at your project, reflect on possible outcomes and then defining the smallest parts as pieces of a puzzle will permit you to construct a robust logic that works fast and can easily be adapted.
Scenario Planning
In my line of work it is a lot about scenarios. What happens if the fuel price goes form 1 Euro to 2 or even 3 Euro, what happens when the salary is getting 10% higher (inflation & indexation) and so forth. For each parameter we use simple elements like sliders, drop down menus or date pickers. My users can play with them and define for example their worst case scenarios (like fuel for 3 Euro and salaries increased by 25%, or the interest rates on investments go from 1% today to 10% in two years). Indeed you can do more or less the same in Excel, so why Coda?
— Structure —
By defining for each element date & time sensitive information in tables we proceed faster and maintain better: we have an overview we can easily update. We can also add documents (like invoices) and images. If set up well, it takes no more than a few minutes. No need for complex integrations (Packs or Make or Zapier), simple uploads do the job. We show stakeholders the elements (assumptions) on which the calculations are based — often linked to historical data we found via invoices they can open in Coda — and they can play with the variables. This to avoid typical spreadsheet problems.
We present the outcomes nicely (graphs) and use the doc logic of Coda to express verbally what we did and how we evaluate the outcome of the calculation and why we assumed certain values. Take the fuel costs, without a cristal ball we still can anticipate on lower and higher price levels, even per period, for example between June 1 and August 31, between 01 sept and early Nov and so on.
— Coding Coda —
Coda provides a rich coding language that permits for building solutions of all sorts. In my experience it is easier than the Excel language, but also more rigorous. In Coda everything is a list and while in your early Coda days, this might hinder you to speed up, over time this list logic becomes your best friend. The Coda Formula Language (CFL) shows great creativity — WithName() comes to mind and is good to learn due to inventions as:
The dot operator. Another subtle, but very impactful choice we made was to introduce chaining into the formula language, modeled after the popular pattern we see in JavaScript (among other languages). Chaining allows you to combine a series of functions together in a linear progression like a sentence, rather than count parentheses inside out.
My clients don’t care about Coda or any other software I use (AirTable, Excel). All they want is actionable data they can rely on. They are not interested in the collaborative logic Coda provides, nor do I want to bother them with the inconveniences this still young and immature product has.
Last, for each vertical I am active in, I create a template. Not in the strict Coda sense, but more a doc that over time and which each new client grows and improves. I polish tables, refine assumptions and improve formulas.
Is Coda as powerful as Excel?
Not yet when it comes to specific financial functions. Take the example from the blog I mentioned on Internal Rate of Return. In Coda you have to develop this logica before you apply it and with all my love and respect for Coda, this is not easy. In Excel this is simple and straightforward. Most calculations I come across do not require this. Net Present Value and alike formulas are not common terms for most SMB owners, but if you need these formulas, Excel is easier.
In the community we debated a solution related to a Compounded Annual Growth Rate (CAGR). I proposed a structure as you see below.
Instead I noticed a preference for a more Excel alike approach:
I am not against this, but this way of working with Coda blocks out a lot of potential.
Excel can handle more data than Coda and on top calculates faster with large data sets. In my work the tables of my clients have never more than 10K rows and with this, Coda works very fine.
Interest rates and alike examples
Coding Coda makes thing easier once you see through the Coda glasses. Accounting and data management today is largely shaped by Excel and so is the visualisation of book keeping. On top ledgers work with a left and right sides fitting the Excel approach perfectly (although with the column logic in Coda it can be done as well).
In Coda you structure and present you data differently. I wrote a blog about interest rates to show the differences. The insight that in a table you should follow a table logic and not a spreadsheet logic, is still for many users difficult to grasp seen questions and solutions in the Coda Community. Nevertheless there is a lot to gain if you are willing to use Coda in the Coda way. Have a look at calculating a moving average or a rolling total in Coda, a bit more difficult than in Excel, but very wel doable and most importantly it is stable, very stable. You add a row and the values update automatically.
This advantage cannot be overestimated and is why I Coda.
I calculate with Coda
This means I order data and clean it up if necessary. Once the data sets are ready I look for ways to distill meaningful information. LookUps (which permit chaining) and filters play an important role. My job mainly consists in finding the right data sets (business owners often have no clue) to connect them intelligently. By using sliders, data pickers etc. I help my clients to gain a better understanding of what might happen (scenarios). Together with my clients we look into the future to spot opportunities and to avoid traps.
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter
My name is Christiaan and I support SMB with calculations (budgets and planning) and I am mainly using Coda to get the job done.
Not to forget: the Coda Community provides great insights for free once you add a sample doc. Paid consulting is often not the way to proceed.
