Future of Coding - Blurring the Line Between User and Programmer: Lane Shackleton

Episode Date: August 15, 2019

"The world's been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one. It feels kind of broken," says Lane Shackleton, Head of Product at Coda, where they are building a new kind of document that blurs the line between users and programmers.  A Coda document starts out looking like a familiar online document, a lot like Google Docs. There's a blinking cursor, you can bold and italicize text, add images, and collaboratively edit it alongside others. But a Coda table is much more powerful than a traditional table that you'd find in a typical word processor. Like a spreadsheet, the a Coda table allows you to create complex relationship between pieces of data via a formula language. Upon closer examination, the Coda table is more structured than spreadsheets and more closely resembles a friendly relational database, like Airtable. If you're familiar with Notion, another augmented document medium, this all may sound familiar. Coda differentiates itself in a few ways. For one, it allows users to build complex (but no-code) trigger-based workflows from within the tool, such as when a table is modified or a button is pressed. For another, Coda really sells itself as an app-builder, in that teams can use Coda documents on their phones as native mobile apps. For example, a bike shop can have its employees easily swipe and snap a photo of inventory directly into a Coda table simply by creating a photo column in that table. Coda takes care of converting that column into an interface that automatically pulls up the camera on mobile. Coda was inspired by the founders' experience at YouTube, where the company "ran on spreadsheets," but now they dream of building a medium that fundamentally changes how people see themselves, as creators instead of merely as consumers, and reshapes the way teams, communities, and even families collaborate and function. It's a big vision, and Coda has a long way to go. This episode was sponsored by Replit. The transcript can be found here: https://futureofcoding.org/episodes/041#transcriptSupport us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

Hello and welcome to the Future of Coding. This is Steve Krause. Today on the podcast we have Lane Shackleton who is the head of product at Coda. It's coda.io which is a new future of programming type tool that I imagine many of you have seen or heard about. It's a lot like Notion, if you've played with or seen Notion. It was announced that they raised money, these two former YouTube executives, maybe around three years ago, and then we didn't hear much from them until earlier this year when they came out of stealth mode or private beta and they launched more publicly. So now you can go on coda.io and play around with the tool yourself. And like Notion or Google Docs or Microsoft Word, the tool starts out as a document, but then you can add in

databases, formulas, kind of like Excel, and even kind of scripty things based on triggers and resultant actions you want to have happen. And as you'll hear later in this conversation, they have a really ambitious vision, much more ambitious than I would have thought based on playing around with the product. But, you know, it's early days. And so that's why we had these conversations, because Lane detailed how they see this product as really blurring that line that a lot of us want to blur between people who make software

and people who use software. And they even one day see this product being useful for creating products, not just as a tool internally for teams to use for documentation and managing processes, like internally for a team. They see that it could be something for documentation and managing processes. Like internally for a team. They see that it could be something for creating external products too. But I don't want to steal his interesting tidbits too much.

So I will leave the rest of the explanation of what Coda is now and what it might be soon in the future to Lane. Before I do, I just have a quick message from our sponsor. Repl.it is an online REPL for over 30 languages. It started out as a code playground, but now it scales up to a full development environment where you can do everything from deploying web servers to training ML models, all driven by the REPL. They're a small startup in San Francisco, but they reach millions of programmers, students,

and teachers all over the world. They're looking for hackers interested in the future of coding and making software tools more accessible and enjoyable. So email jobs at repl.it if you're interested in learning more. Great, and without any further ado, I bring you Lane Shackleton. Welcome, Lane. Hi, Steve. Hi, yeah, thanks for making the time. Glad to be here.

So I would like to start with a bit of your background because most of the guests in this podcast I think are pretty technical and I think you come from more of a product background. Is that right? Yeah, that's right. I'm probably a bit unlike some of your other guests. I don't have a long history of programming languages necessarily. I guess my background really quickly is I studied sciences and anthropology in school. I actually didn't start my career in tech, started as a mountain guide up in Alaska

and back in 2005 drove my car across the country to Silicon Valley. There were basically two hot companies at that time, VMware and Google. I started at Google in a customer-facing role. And that was a really good introduction to how to make customers happy and learn how to balance really fast people's emotions with solutions to their problems. In a lot of cases, these were business owners who were using Google tools to grow their businesses.

And then later, kind of got to be a little bit more technical, built some internal tools for support teams, moved over to product, was really fortunate to be part of a lot of the early monetization efforts at YouTube, launching things like skip buttons on ads on YouTube that eventually kind of went from zero customers to a whole bunch of customers and a whole bunch of revenue. I guess overall my kind of journey to Coda though, Shashir, who's the CEO here, was starting

this company after he left YouTube and kind of kept showing me demos. And I got really kind of enamored with the problem space, mostly because I have a really, I guess, a deep empathy for people with the experience of knowing what they want to build and not being able to make it with software. I feel like I recall this very vividly from being inside of Google, where you have really amazing engineers, and I myself had ideas on what I wanted to make, from being inside of Google where you have really amazing engineers. And, you know, I myself, like, had ideas on what I wanted to make, but sometimes was unable to make those things.

Yeah, and since then I've just been, like, really sort of enamored with the space and been since inspired by a bunch of stuff that's probably closer to home for your listeners and you, you know, a lot of Brett Victor's work. Recently, we've been pretty inspired by Nardi's work and her book, Small Matter Programming. Also, things like Clayton Christensen and Jobs Be Done Framework. So to me, Coda is sort of like this, you know, relating it to my background. It's this way to kind of help people who are smart and capable, just the same way that I felt. So that's a little bit of my background. Happy to dig into any of that. Yeah. Yeah, it makes a lot of sense that this would be a very meaningful product for you, given your background. Particularly, I see the relevance of how your first role at Google, working with business owners, I feel like it definitely makes sense how this is kind of a similar power tool to help people with their businesses.

Yeah, absolutely. I mean, a lot of those, those folks were, you know, small and medium sized businesses. Um, and, uh, if you go look behind the scenes of many small and medium sized businesses, you see that there's a lot of tools that are kind of packed together. Um, uh, and, uh, you know, the, the businesses often have to, to create their own tools because they can't buy really expensive software. So there are a lot of parallels there.

So I think now would be a good time to do a quick two-minute pitch for Coda, like what it is and what's the promise for it. Why would people use it? Yeah, it kind of depends on who you're talking to, but I think we generally say it's a new type of document that combines the best of docs, spreadsheets, and applications. And that's maybe like the one-liner. Sure. I'd be curious to go into the different audiences.

Maybe you could pick two or three audiences and tell me how you tailor the pitch for each of them. That'd be interesting. Yeah, Yeah. Um, so I think if I'm, I'm talking to someone who doesn't know much about, um, tech or software, um, I think I often like to frame it sort of at like 50,000 feet. Um, you know, basically the world's been divided and the people who can make software and the people who use software all day. Um, and, and basically we, we think that that paradigm is not a good one. It feels kind of broken because there are lots of, you know, smart and knowledgeable people out there who don't know how to write code and shouldn't have to to make tools to solve their problems.

And so the sort of, you know, 50,000 foot, 30,000 foot thesis is that, you know, we basically just need to give people the right tools to unlock that creativity and a lot of the domain expertise that's out there. And in terms of like the product itself, if I were to, you know, be kind of demoing it to someone or showing it to someone, you know, I'd probably start by showing them that it's just a dock surface. So, you know, blinking cursor in a toolbar and something that can kind of grow with the evolution of, you know, an individual's, you know, project or a family's, you know, trip or a team's evolution, you know, starting up, kicking off, all the way to tracking a bunch of tasks, all the way sort of through the life cycle of something. So that's maybe the 30,000-foot view.

In terms of specific audiences, you know, if I were to go pitch a you know product manager in silicon valley that's a that's an easy one because i have a lot of background in that area um uh you know i definitely know this this very well having right you know writing specs and designs and stuff back at youtube and google um and i think the main observation i'd start with with someone like that is oftentimes you outgrow and have to move around your tool set and so you know if you if you take someone like that they might start with writing an idea and a doc and then eventually that becomes a set of you know structured data things things that they have to do, a set of tasks. And then there's a workflow around those tasks. And then they need to do things like launch that thing.

So oftentimes that's four or five tools with someone like a product manager and with coda the idea is that really the tool can evolve with those needs you know you can add multiple sections inside of one document one for your you know high-level goals and then that's you know right next to all the tasks that the engineer is working on and so there's this nice sort of all-in-one-place aspect of it for someone who's usually used to traversing a bunch of different tools. Yeah, I don't know if that answers your question. Oh, yeah, it definitely does.

There are a few different directions I want to go in at once, but one of the last things you said struck me the all in one place aspect of it because I definitely see how that's a really powerful there's a lot of powerful synergies of having an integrated experience

especially for people who aren't familiar with programming but even for people who are it's nice to have an integrated experience. But then it kind of, I don't know if you're familiar with the Unix philosophy, but there's this other philosophy of having a bunch of small things

that do one job and do it really well that you can kind of use all together. So, yeah. Yeah, I mean, that actually reminds me of the Rich Hickey talk, simple versus easy. I mean, I think inside the document itself, we actually think a lot about those atomic units, so, and how they compose on each other. So I think the idea of something being sort of simple and single-purpose maybe I'll use an

example from our our document so inside the document you can create a button and that button you know basically does one thing you you you press a button and and it takes an action like adding a row or refreshing data or something like that. But buttons can obviously be composed in meaningful ways with other things to do things like take an action outside of the document. So if you want to send a text message or a Slack message or something like that, you're sort of taking two hopefully simple parts, you know, a formula that takes an action outside of the document, like send a Slack message,

and we're powering that button with that formula. And so that's maybe a pretty involved answer, or maybe an involved example. There are probably ones that are simpler kind of to your question. But I think in many ways we look at the parts inside of the document as those building blocks that makers and people who need to build tools can compose um and less less of a um you know we have the answer this is the this is the single um way to do project management or this is the single way to do crm um the idea is that you can kind of take these

simple parts and build them up interesting yeah yeah i see I see what you mean. So within the tool, you give them a bunch of simple, independent or orthogonal Legos and they can make their own system. But the tool itself, I guess, needs to have a lot of those Legos in order for it to be competitive against a single-purpose CRM

versus a single-purpose spreadsheet system used in combination? Maybe. You know, I think one piece of this is that you have to have, you can't have too many kind of Legos on the table or it becomes difficult to understand which, you know, which Legos you should use when. So I think we think pretty carefully about each of those building blocks that we add. And if, you know, I think oftentimes if you decompose apps, like take a CRM for example, what you really have is sort of a database layer, which we have in our tables.

You have kind of a logic layer, which you can build up through automations and formulas. And then you have kind of a presentation layer. And that presentation layer allows you to do things like add new candidates or add new sales companies to that CRM. And each of those, I guess, with C really only three, you know, in that case, three or four things that you need to understand in terms of the building blocks that make up something like that. And obviously there are things that CRMs do that are quite powerful. But interestingly, I think when you compose things like formulas and buttons or formulas and tables, you can get pretty close. You mentioned in a prior conversation that one of the main inspirations from Coda came from yours and the founder's work at YouTube, where the company was run in a collection of

mostly spreadsheets. Is that an accurate way to explain it? Yeah. Yeah, it's kind of a fun story. So, you know, I worked with Shashir, who's one of the founders at YouTube, and Alex, one of the other founders, also worked there. Shashir ran product and design, and I helped lead some of our monetization efforts there.

Thinking about YouTube as an example, and and i helped lead some of our monetization efforts there um thinking about youtube as an example i think is is um is interesting i mean in in many businesses like when you when you look at the software that they're buying they uh you know they're buying all these vertical apps but oftentimes when you just say, hey, pull open your laptop and show me how you're running the business, oftentimes they've been exporting to a spreadsheet and manipulating that data. And that's certainly the case at YouTube. Despite having amazing engineers capable of building all types of different tools, you know, the leaders of that business chose to run on spreadsheets.

And I think the main, I mean, a few different reasons. One is, and I think this is really common, it basically enabled the team to flex like a specific perspective on how a process should run so that they weren't confined to like a specific tools way of doing things so like a few examples you know you want to run a calibration process across a thousand people you want to do comp planning across a thousand people you want to run like a OKR process for all your teams oftentimes we had a perspective on how those things should get done. And so instead of having some engineer change a frontend or change, you know, add columns to a database at our request, it's much easier to just build those things up out of a spreadsheet. So it's one of those, I think a good example of having

an opinion on how something should run. So the team basically picks up the flexible tool that everyone could access. It's as simple as hitting the share button on a spreadsheet to give people access to your tool. A lot of that I think served as inspiration for some of the things that you see in Coda. So, yeah, why is it, do you think that spreadsheets have been so successful as opposed to like docs?

Like, why wasn't things being run like in a Google doc, for example? Yeah, great question. I mean, I guess I would start by saying spreadsheets are completely amazing. Like we have a lot of folks inside the company that are wizards when it comes to spreadsheets. And I think one of the main reasons to answer your question

is that it's a very flexible thinking surface. You know, it has this kind of open grid that makes it feel like anything is possible. That comes with some positive and negative consequences later, but I think as a starting point it's quite approachable in that way. You don't really have to know anything about formulas. You don't really have to know anything about kind of the deeper parts of a spreadsheet to get started. And for the most part, it's, you know, it's based on a very, a pattern of direct manipulation. You know, you kind of highlight what you want to highlight. You touch what you want to touch.

And for the most part, you get what you expect. So I think that's part of the reason. I think the other part is that spreadsheets in their kind of upper reaches with a really flexible formula language that kind of interestingly started for accountants has grown into something that you can actually do a lot with. And I'm sure you've seen some of the crazy spreadsheets that people build.

So I don't have to go too far into that. But eventually, I think what happened is that it kind of became a tool of choice for everyone with a computer and an obvious starting point for things that were going to include, you know, numbers or calculations or, you know, basically a place where you could drop a bunch of information in and then add some structure to it. Whereas I think that historically, to go back to your question, docs haven't always been a great place to add that structure. And by structure, I mean even the most simple things like having a task with a status or really, really basic things.

The tables inside of Docs historically have been more layout-based. And so it's less of a space that can kind of grow with your idea. Yeah, I see what you're saying. Well, spreadsheets are also kind of like almost superficial in a way that like Airtable is kind of innovated in making it not. And you guys also, it's more like the table is kind of innovated in making it not and you guys also um you it's more like the table is the data and then you have also a presentation layer as well but you guys make like a clear

distinction when like a google doc is uh it feels like it's it's less semantic it's some in some ways yeah yeah so it seems like we're in a bit of a renaissance of like the next version of spreadsheets. There's it seems like Airtable and then there was also Fieldbook, which I don't think is anymore. And then Notion recently added a kind of a data spreadsheet model. And then you guys, why do you think now is kind of the time for everyone to be rethinking the future of docs and spreadsheets? Yeah, that's a great question. I, you know, I guess the first thing we're saying is like we're big fans of anyone trying to make it easy for, you know, makers build build what they need I think this is this is a really positive step forward for a lot of people who are you know subject

matter experts and knowledge workers in terms of why why we're seeing it now that's a that's a good question. I think in many ways, like, what you see is people starting to kind of take back control of the tools that they use. And this isn't necessarily a new phenomenon, but, or at least like in the last few years, but, you know, just if you look at like the IT purchasing process, it used to be that people would, you know, there would be one person who oversaw it and they would have to, you know, sort of procure software in a, in a, in a way that they distribute it to everybody inside of a company. And I think in the last few years, you've seen a lot of like bottoms up growth of some of these tools like Slack and others where people are sort of having an opinion and choosing

the tool that they wanted and then bringing that to their business or to their families or whatever. I mean, I think it's hard to look past some of the other big innovations that got us here. So bringing something like a spreadsheet from your machine to the cloud was a big one. It made it possible for this to be a truly collaborative surface. And I think that was a big step. And then to kind of go beyond that, I think everyone kind of has their own take on what it is and what it should be.

I kind of like to think about it as they're kind of like three big buckets in the landscape. You have people that are starting with a doc or a doc or a wiki like environment, which I think Notion started with. You have the table, which obviously Airtable has done a great job with. And then you also have this kind of bucket of apps, you know, everything from like small niche apps to big things like Salesforce. And so we end up competing

or we end up kind of in the space of all three of these tools, depending on how the user chooses to use Coda and what they're trying to do. So, some people use this just as a simple document surface. It's interesting, we were pulling some stats the other day and it looks like about half of our documents are basically used without a table.

So, people really kind of just leaning into the document with multiple sections to structure kind of prose and written text. That seems surprising to me. Why aren't these people using Google Docs? In theory, I would expect Google Docs to be more full-featured as a document than Coda. Yeah. Yeah, that's a good question. I mean, Google Docs is certainly, and Word, are certainly very mature document surfaces. You can do all types of formatting, you can do things that I think you would need to if you were printing regularly, if you're writing a novel, things like that. But I think the reality is that a lot of the prose that's written nowadays is written sort of for collaboration. It's written to send out to a team. It's written as a plan or a goal or a spec or something like that.

And so some of the more mature features of something like docs become a little less important in that world and i mean to to kind of go directly at the question i think one of the reasons that people pick us up is because um you know i love the like alan k quote of simple things are simple and complex things are possible um i think you know in our case the simple things are simple and complex things are possible. I think in our case, the simple things should be simple. You should be able to just start with some prose or an idea and write some text. And then you should also be able to sort of grow and evolve that. And I think that more and more people are choosing alternatives to things like Google Docs because I think in some senses you you end up outgrowing

just in the life cycle of like one project or one you know family trip or one whatever it is you end up kind of outgrowing the capabilities and migrating to a spreadsheet or using what we really commonly see in businesses when we first talk to them is this like um this combination of docs and spreadsheets where you have like docs that are pointers to spreadsheets and and back and forth um which i've i've like definitely lived through that world and it's um uh i think there's there's probably a better way so that makes sense it i find it um i guess it's impressive um that you're able to sell the vision of like even though you only need a doc right now like you know start with us because we'll grow with you because i feel like most of your value add and like the the exciting features you bring to the table, they might not

get to them until like they've already written a couple of docs. So that's what I'm impressed by. Yeah. Yeah. I mean, I think one, one thing that goes a long way in that respect is just having a template gallery that has lots and lots of examples of things that our makers have built and like submitted to us or templates that we've made for them. So it kind of cues you into the fact that, like, oh, this later can have a table of tasks that I can use to track things. But right now, you know, all I have in my head is an idea. So you kind of, I hope that our users glean that from seeing a lot of the examples that we put out.

Yeah, that makes a lot of sense. So, based on the conversation we've had so far, I get the feeling that this is a tool that is very easy to sell to a product manager. But I'd also be curious to hear what other sorts of initial users you're targeting now. Of course, it's a very general purpose tool. Everyone uses spreadsheets, so in theory, everyone would use this. But are you focusing on some initial people? Another thing I'll add to the question is it sounds like you're focused on companies and teams collaborating as opposed to more individual use. Would that also be accurate?

Yeah, so definitely, like you said, it's a very horizontal tool. So it's always kind of challenging to define a specific target. But we do see a lot of success in teams. And I think that that just comes back to the fact that it's a document surface, it's collaborative, you can see the avatars and the people that you're working with in there, and they can collaborate in real time. I also think that we have a fairly deeply held belief that these makers can kind of come from anywhere. So I think we're careful not to label or categorize people too much. And I think we've been inspired in part by Jobs to be Done and Clayton Christensen's work there. I guess, so just some other examples to make it more tangible. Maybe, so just to interrupt, can you talk more about Jobs to be

Done? I haven't heard of that. Yeah. So I guess the general thesis behind Jobs to be Done is users hire or people hire products in their daily lives to solve specific jobs. Um, and, uh, that's sort of in contrast to, uh, you know, this set of demographics will buy this product, um, sort of causally because of their demographic. Um, and kind of the classic example that he uses is, uh, a fun one. It's, it's the milkshake analogy. I don't know if you heard this. No. So I think they were doing, I may butcher this story, but I'll recount it as best I can from memory. So basically they were doing some research for, I think it was like McDonald's or something.

And they were trying to figure out why people were buying milkshakes at, you know, between like 7 and 9 a.m. And this is sort of confusing everybody. And what they figured out was that people were buying these to take on their commute. And so he uses this analogy of jobs and commuting with the milkshake. Basically, the job or the task that a user or person needs an answer for is something to keep them occupied on their commute. And they could solve this with like, you know, a banana, but that's only like two minutes on a 30 minute commute. And they could solve this with like a glass of water, but that's kind of boring. Nowadays, people probably use like podcasts on their phones

to keep them entertained. But the general idea is that... Like right now. Someone's listening right now. This is a job being done. But the general idea is that a milkshake solves this job really well because it's sort of this slow burn of happiness to the person who's commuting. It takes them 20 minutes to drink this milkshake. And so this sort of presents as a nice metaphor for other instances where people have like a very specific job or a very specific task. And it's sort of unimportant what their demographic is. And what's more important is that they have a specific job to solve. Yeah. Cool, thanks. And just to remind you where you were going before I interrupted you, you were maybe going to give some examples of specific people and the problems they're using Coda to solve.

Yeah. Yeah, so on kind of like what you might call like consumer side, I think we have people doing everything from organizing trips to planning weddings to splitting expenses with their friends. Actually, more recently, some of our community has been really into building games. So people sort of go all over the map

on that side of the house. In terms of businesses and teams, I think, you know, obviously engineering teams, design teams, product teams, salespeople, recruiting teams, those are sort of to name the like laundry list. Just to like maybe dig into one of those for a second. It's kind of a story that I really like. So one of the first times I feel like I realized we were kind of onto something was when I sat down a few years ago now with a 23-year-old recruiter and um like he he started the conversation by saying uh i'm not a spreadsheet person i don't know how to code um and i was like it's okay um let's let's let's see what you you know what you need to do um and and i kind of like watched and

helped him build a tool for his team to track at the time this was engineering candidates. And it's, you know, the tool is basically like an editable database with a bunch of views for each person and like a few controls like select lists where you could kind of like let people filter. And interestingly, you know, I guess there's a few interesting parts to me about this example. One is almost three years later, they're using the same tool. So it was custom and sticky for their team. And I guess more personally, the neat part for me was watching him roll out this tool and the sense of pride that he had in rolling out this tool and and like the sense of pride that he had and rolling

out this tool and Clayton Christensen again talks about how every great product has kind of like a social functional and emotional aspect and this was it was really neat to see sort of like the pride emotion of him making software for the first time like really really presenting a tool that he had made. And then sort of the social aspect of his team really feeling like, oh, this person's capable and really valued and contributing to our team. And so I think that, you know, when we do our jobs right, that's the result, right? Like people feel like they can take their subject matter expertise or domain expertise and present it to their teams

and build, you know, what feel like perfectly customized tools to that group of people. And actually to maybe take that example a step further, what's really interesting to me is like, you know,, to maybe take that, that example a step further, what's really interesting to me is like, you know, in a traditional software model, what would have happened when that team evolved? So like that team ended up going from, you know, like five people to 20 people over the last three years, um, is like that, what would have happened is like, they would have had

to go back to, if that tool was built, you know, in code, like they would have had to go back to, if that tool was built in code, they would have had to go back to some engineer and ask for changes continuously. And instead, they were able to actually change that tool themselves as the team evolved. And so there's a really concrete sense of agency that I think is quite powerful when we do it right. Yeah, that sounds like a really obvious value proposition, like, you know, impress your coworkers with your superpowers. Yeah, I and I think many engineers feel like feel like you know we feel that sort of pride all the time it's like a lot of what drives us um so it's cool that you get to democratize that like i built a thing that you can all use and you'll think of me fondly while you use it yeah and and i think you know i think there's something really impactful about having someone, like, think about themselves differently in that way.

You know, think, oh, I'm just as capable as other people at making things again. The analogy I like to use is, you know, when you ask a group of, like, four-year-olds, you know who's an artist like everybody raises their hand um but then like you know you get the same group at like you know 40 and like zero people raise their hand and and i feel like in in general like the artist has kind of been beaten beaten out of people when it comes to to like software and tools and so I, and so far as we can like reinvigorate that, that, that makes me happy. So do you find that the story you told of someone starting this new system from scratch and growing over time to being central to the business, that that's kind of more the approach? Or do you also find people migrating existing spreadsheets or CRM systems into Coda?

What's like the breakdown? I don't know if you have the number than that. What's like the breakdown of from starting from scratch and growing or migrating into it? Yeah, I mean interestingly that process was, I think if I recall correctly, that process was run out of like a custom tool or like a, a like kind of a niche vertical tool that then they realized that that tool kind of didn't fit them. And so they ended up migrating that into a spreadsheet and then from a spreadsheet into, into Coda. So in terms of the numbers and where we see migration

from it's, it's really all over the map. There's no simple statement to make there. We see people migrating from docs. We see people migrating from project management tools of all kinds, vertical apps like little mini CRM systems, specific recruiting recruiting tools and a lot of spreadsheets. And are you, I don't, I don't exactly know how to ask this question in a precise way, but I guess how often are people customizing things versus just using them, like customizing them once, customizing things, like, I wouldn't be all that surprised if people customized things, like, kind of once a year and then maybe made a few tweaks here and there, but mostly we're just using it as an app or app slash spreadsheet.

Yeah, that's a good question. I mean, I think this is sort of worth pointing out that it depends on the type of doc that you're talking about. So, you know, as I was mentioning before, half of our active docs don't don't have tables and so in that sense like they they're constantly being customized because like people are writing meeting notes or people are you know writing uh ideas or designs or whatever um but but sort of maybe more to your question for for like more involved more involved docs that might wholesale replace another system or a workflow that the team previously had, oftentimes what we see is this pattern of two or three makers kind of co-creating the tool for their team. And this, like, makes sense, you know, given a role, like, you know, something that's probably familiar to your listeners is, like, if it's a product team, like, the product manager and the engineering lead

or the product manager and the design lead are kind of, like, building the ideal workflow for their team. And that's basically a general setup process process and so the doc kind of goes through like lots of iterations in that that early phase and then like you said it may get used for a period of time and then some something changes right the project like winds down or the team grows and the effort like expands considerably and then you go through like another iteration of that that building process to use like a real example um there's a customer a set of set of folks at uber that used us to to

redesign the driver app it was kind of like the largest redesign of the driver Uber that used us to redesign the driver app. It was kind of like the largest redesign of the driver app that Uber has done. And that followed a very similar pattern. Like, you had really two people setting up a construct for, like, hundreds of engineers to go work. And so, you know, for a week, they were kind of building out the perfect system that's actually in our template gallery, kind of in that top row, if you're curious. They were kind of like building up this perfect system so that like all these teams that are distributed all over the world could then, you know, enter their information about like how that project is going and kind of break apart this massive project into, to like, you know, coherent parts. And then, and then they kind of like let, you know, hundreds of engineers, hundreds of people loose on that tool.

And then over the life cycle of the project, they ended up building out, you know, other aspects of it later. So, so sort of like at the midway point, they built this really neat pie chart, which is basically a progress of how close they are to code complete. And that became the thing that they started every meeting with. It was like, how close are we to actually shipping this thing? And that's kind of what i mean by like this this i this is ideally a tool that can

evolve with the life cycle of you know a really small project or a really small set of tracking requirements to um to something like very very large um and even within that project kind of evolve with it yeah and so i'd be curious to know like what what sort of agency people like uh have like down farther down the food chain like if certain engineers you know wanted to customize things um like do they have the permission to do that and how do they make sure they're not like stepping on other people's toes or like messing with other integrations that are core yeah yeah it's definitely, it's a tough question when you're organizing like hundreds of people.

It's almost like the flexibility of the tool is working against you here because like there's certain things that you want to have be like, no, no, these are like rigid that like we're kind of top down deciding for you as the organizers. And then, but you know, we also want to give you flexibility

on things we don't care about. Right, right. Yeah, there's probably a couple things to say about that question. Maybe the first is that because it's a document, you have what you're used to seeing in documents, which is some basic set of permissions. So you can give people view-only access.

You can give people comment- know, view only access, you can give people comment only access or edit access. And, you know, so in this case, like for the executive team, I think they only gave you access because like they didn't want executives going in there and changing a bunch of things. But to your question on kind of like further down the chain and, you know, if I'm an engineering manager in Dublin, what does it look like to change this tool? One of the things that we see really commonly is people creating kind of their perfect view of a set of data. So in this case, you know, you might have one, one like Uber like task table, or like one, one features table or something like that. And, and then an individual team goes in and creates a section. And that section is sort of, they title it like, this is our section as the, you know, design team or something like that and they all they're doing is like creating a filtered view of that larger data set but kind of importantly

it's all the same data set right so it's kind of right through from that view to the the core table and back and so the the part you know if you were to ask the folks from Uber, I think that they have said to us, this is sort of the central piece of this. There's one source of truth for all of this data, and yet I can have as many different views of that data as I want, and I can add controls on top of that to do additional filters, and I can add buttons to make it easy for people who are just contributors to that document to come in um and and add a new feature or whatever it is

so like a quick quick idea um let's say so we have a single source of truth for features for the whole uber company and then we're in dublin we have a filtered view for just the the features we're responsible for and let's say for whatever reason we want to add a column to because we care about some extra piece of metadata on features that isn't in the source of truth table yeah um i guess the question is two part one could if we added a column would it like accidentally like would we kind of unintentionally add a column to the whole table and then people at HQ would get upset at us? And then the second question is, is there a way to add that attribute in a way that doesn't, other people don't even see it? Yeah, this is a very deep question, but I'll do my best to kind of summarize a few parts of this. So I guess to maybe start from the concrete,

in this case, like one of the first things that the designers of this document did was go off and get all the trackers that each team wanted to use. And so there was a common understanding of like which columns are important. And interestingly, like the alternative that they were looking at was like you know literally dozens and dozens of spreadsheets

and all of those spreadsheets like had slightly different column names but effectively representing the same thing right and so there's sort of like one obvious win for them as the designers of this tool that i now like don't have to reconcile all these like different you know slightly different names that represent the same thing across all these things so as the as the designers of the the tool for 300 you know plus people what they did was they did like the column reconciliation if you will um and and like agreed upon that. Sort of down a level from that,

like let's say that they still missed that column for the person in Dublin. That person, you know, if they have edit access to the document can certainly add that column. And it turns out that that's actually really important and useful too, because like they may want to branch some variant of that features table in a way that's, like, helpful for them. And so as long as they're not, quote, like, polluting the other views by, like, forcing that column to be added everywhere and all the other views then that mostly gets out of the way for everybody else at certain points I think

folks are finding the tool very useful and adding lots of columns and so I think that there is this question around like oh is there a different level of permissions here where we can say you, people should only be able to add rows and edit rows, but not, you know, change, change the columns or like, you know, the formulas and some of the existing columns and stuff like that. And that's, that's something that we're certainly thinking, thinking about and have been prototyping some answers to. But, but, but at its core, I think, you know, in a place like Uber, that's super collaborative and trusts, you know, trusts people to do the right thing, the ability to add columns as that engineering manager allows you to evolve the tool in a way that's helpful to you, right? And ultimately, that's probably a good thing.

Yeah, that makes a lot of sense and then if we wanted to do it it occurs to me that the Dublin team could create a new table that just references the old table and then has as many columns as we want Yeah, that's right if it actually became if it was materially different

in its data structure or it sort of felt divergent enough from that first features table or or it was um it sort of felt divergent enough from that like first features table or whatever it was um that's right they they could also create a table and then you know look up from the other table yeah cool yeah um so you the the tagline seems to be docs as powerful as an app is that right or not am i did i miss say it uh no that's right i mean the i think the thesis is that you can build a doc as powerful as an app um and so uh you know we haven't really talked talked much about mobile but um we've spent a bunch of time on mobile um making sure that it actually felt up.

I think we've been saying this phrase for a while, and before we launched mobile, people would sort of hold up their phones and say, oh, you mean like this, this mobile app on my phone? And we'd kind of say, yeah, eventually. And nowadays, we can kind of more confidently say, yes, it's something that feels just like an app on your phone. And there's a couple, I'm happy to go into it, there's a couple things that we do to make that feel like an app.

Yeah, how'd you pull that one off? Yeah, we're really kind of just getting started on pulling it off, I would say. But our first version of it does a couple of things. I mean, I think the first thing that's probably noticeable is we take the section list that's you can add effectively multiple pages or multiple different spaces to the same document. And so what we do is we take that section list and then we flip it and make it feel like native navigation on iOS and Android. And that kind of gives you the sense right away that you're in an app. And so you put it at the bottom? Is that where you put it? That's right.

Yeah, like on iOS, it's just a little tab bar on the bottom. And where is it in Android? I don't even know where Android is. I have navigation and I have an Android phone. Yeah, in Android, it's sort of similar. Oh, okay. Yeah, and then there's some material design choices that were in the midst of finishing, but sort of generally the same principle. So yeah, that's sort of like the first noticeable thing is that you get this experience of like, oh, I opened this up.

I opened one of these docs, and it feels kind of application-like because the navigation feels native to the platform. I guess some of the other things that we do that are noticeable. So one interaction that feels very kind of app-like is in tables. When you have buttons, and especially multiple buttons, we allow you to kind of like, first of all, we create a card that is a nice sort of clean summary of that row.

And then we allow you to like swipe the card, you know, interaction, most people are probably familiar with from stuff like Gmail, where you can swipe to archive. But in our case, maybe to use a customer example, we have a customer who built an inventory tracker to track bikes from a bike shop. And the realities of being in a bike shop all day is that you're not behind a computer all the time.

And this particular set of people were like out in the field. And so they were kind of constantly on their mobile device. And, you know, if you want to like check in or check out a bike or say like this bike needs repair, on desktop, there are kind of like three buttons. And this is also in the template gallery if you want to go look at how this works. But on desktop, this is kind of like three buttons that say like check in, check out, and needs repair.

And on mobile, when you pull up like that same list of bikes, you get like a nice little picture of that bike and some of the details about the bike and its status, and then you can kind of like swipe to take those actions. And that feels sort of native app-like. And interestingly, like as a person who created that dock and configured that dock, is like you don't really have to do anything.

We just take those actions from buttons and transform them to those swipe actions on mobile so it's yeah so so swipe right is one of the buttons swipe left is the other and what's the third button um we actually we split this the swipe right right now it's only swipe right um we split it into kind of like three actions if you've seen i think this is also a fairly common pattern but you you swipe and then you kind of get like three options yep and've seen i think this is also a fairly common pattern but you you swipe and then you kind of get like three options yeah and you press one yeah yeah yeah okay yeah cool um yeah so that's that's i guess that's a couple ways that we've done done so far have a bunch of

other ideas um i guess one of the other ones that people have really started latching on to recently is like you know imagine you're you're doing that same inventory um tracking and you want to take a picture of every bike um so you can kind of like just be out in the field and take a picture of the part that needs repair or whatever and upload it directly to that row um from the phone's camera um so you have like a sort of nice entry point to native things that you're used to doing on your phone all the time. A camera, a image column. That's right.

Like presents itself as a camera button and you can either upload or take a photo. That's right. Yeah. Oh, I see. There are all these little clever things you can do that just like automatically behind the scenes adapt the interface to mobile. Yeah, that's right. That's right. Yeah, that's right. That's right. Yeah, exactly. And I mean, that's sort of like the fundamental premise here is that like, you shouldn't have to be an app designer app developer

type person. You know, we we do most of that automatically for you. You know, we switch the tabs for you, we we switch buttons for you, we we take abstractions like the image column and do that for you. So I'd be curious to hear a bit about where code is going, like the fuller vision. So right now I get the impression that it's an internal tools product. Like we spoke about before, you have to have a certain amount of trust with the people you share edit access with. They're like on your team.

They're not going to be nefarious agents. And it feels kind of like like google docs or like spreadsheets you know like use it with your friends and your co-workers do you ever see it as being you say the word app do you ever see it as being something that like a company would make as an external app that you know like sell things on it or or have external users? Yeah. Absolutely. I mean, I'll get back to the full vision piece in a second, but just to answer your latter question. I mean, we ran, recently we ran a kind of contest called MakerFest with Product Hunt.

And the idea behind that was to to get people building app like things um and you can see i mean there's just a crazy array of things that of very application like concepts that people built um on that and that you know those are sort of purpose built to be um external in the sense that like they those people weren't building it for their internal company and in many cases like they were they were an individual person with no with no company or you know doing it on the side so for sure we're already starting to see this pattern of people you know building tools for other people. Could you give me an example of something?

Yeah, yeah. Probably like the, let's see, let me see what the most interesting examples are. I guess like a couple of the examples that were interesting to me. First, you know, people building, like, very basic kind of, like, things that are first instances if you were to, like, pick up a programming language. So, it might build, like, a to-do list or something like that. And then, you know, to take it a step further because we have things like a now formula and, and you can write, you know, complex functions. People started building, you know, Pomodoro style techniques where I can like start a timer and, and, and like time my to-do list all the way to some fairly crazy games people built. More recently, someone kind of had four buttons that control like up, down, left, and right, where you can kind of like walk

a rectangle around. And like some of these examples start to feel very much like apps that people want other people to use. And right now, I think we still have a lot of work to do on the publishing side of this. How do we make it easy for those people to take one of those concepts and really publish it broadly. We're starting from a nice foundation in the sense that sharing a document is really easy. You hit the Share button, and then you decide who should have access to it. But there's probably a lot more that we can do.

I know that there's a bunch more things that we can do to make it easy to take one of these app-like concepts and distribute it more broadly. I think the other interesting thing is when you start to have derivative work, and we see this in the template gallery a lot, where someone will take a template, to use a simple example, like my to- do list is in there. They'll take a simple example like that, and then they'll sort of build upon it. And then they'll like resubmit it to us. And they'll say like, Oh, this is like a variant of that. So you kind of get this

like interesting branching effect of being able to have someone else's perspective layered on to other people's. Do you have a story for managing variants and merging things that are kind of similar together? Yeah, so we've thought about this a bit, and we have some prototypes. We don't have a perfect answer for it right now, but it's certainly something that we're thinking about. In many ways, like you, the merging the variants sometimes feels unnecessary because like someone has taken kind of a different perspective on it.

And what we want to see is kind of the breadth of these different perspectives so eventually when you're you know searching in the template gallery or you're searching for a solution really you can you can sort of see all the permutations and and get to you know play with each of them and then decide which variant kind of works for you um so in some sense like we we could go solve that problem um we have some ideas of of how we might do it um but you know it probably starts with kind of fundamentally questioning the problem that's that's an interesting point um so i think when I asked the question of the full vision

and for if you build externally facing tools, I thought that was the same question, but apparently there's a different, there's a distinction between that question and what's the full vision for Coda. Yeah. I mean, I guess like the full vision might be a little more kind of back to where we started.

I guess I kind of like to think about it in two ways. Like there's basically the kind of micro level, and there's sort of bubbling back up to the macro level. On the micro level, I personally really like to think about, like, the individual stories of, like, how we change people's lives and how we have the opportunity to make them feel, you know, different about themselves in a really positive way.

Taking like that domain expert, that subject matter expert and enabling them to actually build the tool that they need and like have a thinking surface that can evolve with their thought process like that on on an individual level i think is is is our our kind of core aim um and it's it's a little bit back to the story i was i was telling you about that that recruiter um like on an individual level um i mean i think if we bubble like all the way back up to the the macro level, I think we have a really unique opportunity to marry something that is really approachable, i.e.

a doc, with the power of application-like concepts. And the punchline there is that we can change how teams and communities and families can grow and evolve. And, you know, that I think is incredibly powerful if we can do that right. Actually, it makes me think a little bit of my oldest son. So I have a four-year-old who's finishing preschool at a Reggio Emilio school. Are you familiar with Reggio philosophy? I guess maybe just give us a brief overview.

Yeah. The basic idea behind Reggio is that kids' learning should be self-guided and rooted in, you know, experience and exploration. And kind of importantly, they're equal members to the broader community of adults and kids. And so a lot of like learning environments, teachers are viewed as like the ones that hold all the knowledge. And like they impart that knowledge to their students. But Reggio sort of like flips that um and i think that you know in a reggio philosophy like kids are meant to construct knowledge through exploration and observation and discussion um i don't know if you want to add anything anything to that based on your your knowledge of i i didn't actually quite realize that it was so, anyways, I knew that it was a very progressive feel to it, but that sounds very similar to my own educational philosophy.

So that's kind of interesting to find out. It sounds like very constructivist, like Seymour Papert. Exactly. Yeah, it's very constructivist. Yeah. Yeah. So like to make that kind of abstract concrete, like an example for my son is he's basically their class has been following this thread of an artist named Martin Puryear that they found like in the SF MoMA and like one of their early visits. And so like basically what started as an observation of this particular sculpture became like a six month kind of observation, exploration, discussion about like this artist's work and it kind of followed the kids' interests, which is kind of the important thing. And I think, you know, if I were to think about like the grand vision for Coda, I think that there are actually some

parallels here both like externally as a product and internally as a company. So, from an external kind of like product standpoint, you know, concretely in line with Reggie, we're kind of saying that the tool maker knows how this should work. Like the kid should be the guide, right? The maker, the subject matter expert can create and discover and like create knowledge.

And so concretely that means something like, you know, starting with the pros of an idea that grows and evolves and their kind of like knowledge evolves as they like structure data or like manipulate that data and and from kind of maybe from the other side I think you know as someone who's like building building a product and design team I think about it you know from a team standpoint and I think there are parallels as well namely that like we don't act like we have all the answers. We hire really smart and curious people, and we kind of treat everyone as equal members of that community.

And the idea is that they can observe our users and explore and discuss and kind of like learn together. And so the combination of those two, we think create, you know, the right conditions to make a great product. And so I think, you know, I think a lot of people identify with this idea, especially probably in your audience, identify with this idea that our tools have like failed, you know, some large class of people.

And so the way I personally like to think about, you know, the grand vision of Coda is, you know, we kind of need to do what Reggio does and flip the existing paradigm. You know, you shouldn't have to know what Docker and React are to make software. We think it can just start with a simple doc and people can sort of evolve their knowledge with it well said, I agree with you that it's a common feeling we all have that this should be the way the world is especially our virtual worlds, they're infinitely moldable and yet so many people can't mold them. Uh, so, but, but what well said, um,

so I, I, I feel like we could end there. That's like a, like a very high point to, to be like, okay, well,

get back to work. You know, that sounds useful. Um, but, but I, I also wanted to drill in, drill into a few,

uh, specific like product choices, particularly because that's what you work on, the product stuff. So I wanted to drill in there. So one of my personally favorite features is the formula bar in Coda. And there are a lot of things I like about it. For starters, it um very concrete uh where like if there if there's live data uh to be had it'll evaluate it with some live data like kind of pick

a good default so you can see what's going on immediately um or if there's like some evaluation to be had it'll like partially evaluate whatever can be partially evaluated which is also really cool um and then another thing i really like is that the the types of various like the structure of the data of various variables using expressions are are explained via um like an icon so like a calendar icon for times and yeah personal icon for for users and then where i think it gets really cool is um they're even subtle things like if you're dealing with a list um it'll kind of look like a list. It'll look like there are multiple things of that type.

And then also even more subtle, but I like it, if you have two things that have the same exact type, but they're from different instances, they're from different objects, they'll be colored differently. So I like it too. So anyways, I mostly just want to compliment you, but also I'd be curious to hear about how the product and design work went into that.

Yeah, I mean, I won't take credit for that. Back to the internal teams and creating kind of the right conditions for those types of things to happen. We had a formulas team that really obsessed over the details. And I'm, I'm happy to hear that you picked up on, I think you, you pretty much ticked the whole list.

So, so nice, nice, nice investigation. Yeah, we had a, we had a product and design engineering team that really obsessed over a lot of those details. And, and I, I guess I could go into a couple of them, but I think you did a great job of explaining. I think, you know, one of the ones that I was really excited to see was this, you know, this idea of like previewing or intermediate values.

And I think mostly because I often come at, you know, writing formulas and programming from a fairly naive standpoint. And so to me, it did a great job, as you identified, of kind of giving you a clear sense of where you were and the shape of the data that you were holding. So when you're holding an array, you can kind of see a comma-separated list in that intermediate value. And you kind of can make sense of what you might want to do next because you're seeing that intermediate value. And a lot of this work, I think, was inspired by some of Brett Victor's work. And just this idea

that you shouldn't have to play computer in your head. And so the formula space for us has always been pretty important because it's been, in many ways, the glue or the interface between the blocks. And so the things, an example of what you mentioned, you know, the type icons placed on the chip itself is a very specific decision because we saw users who are trying to make things like equivalency statements with types that were different and running into problems. And so we could, in many ways, preempt some of that confusion by showing, you know,

oh, these actually have two different icons. I wonder why that is. Let me go inspect some of these items to figure out why I might not be able to write equals here. So they're born both from sort of a philosophical viewpoint on you shouldn't have to play computer in your head and a very practical one, which we have lots and lots of users every day asking us questions on intercom, saying, why can't I write this formula?

And so we, you know, we try as best we can to marry the two. But yeah, major, major kudos to that team for really digging deep and chunking up what is a very difficult set of problems. So another thing that I noticed that I liked, but also thought was a curious choice was that you seem, especially in that, like the documentation of the tutorial videos to be pushing the dot operator instead of prefix based functions that people are used to from Excel. So like the dot operator, like it's kind of like method, like a method operator,. I think people see it a lot in Ruby, almost infixing. Why did you choose to kind of show people this new way of... Because I think both work in Coda as far as I saw it.

You can use the prefix function or you can use it infix with this dot operator. Why are you teaching people this new way of doing things? Yeah, that's right. That's a good observation. Basically, both should work. So I think the idea is that if you want to stick with your familiar pattern, you should be able to. That was a pretty intentional choice. I mean, I think when the team created the formula language and sort of the first formula builder years ago, they certainly questioned, like, the current method of prefix functions.

And I think that, you know, they have all kinds of challenges. So maybe I'll frame them as kind of the positives on the dot operator side. The main one, I think, is, or I guess there's probably two or three main benefits. The first one is readability. So you just have less characters to confront. And so there's a compactness argument to that readability. The other one is like, you just have less grammar. So you don't have to like, the thing that you're used to doing in Excel

or at least I am is like counting the parentheses at the end of a function and figuring out like you know sort of scope wise where I am the dot operator also allows you to chain functions which can be helpful in certain cases I think the main one that i like

and and you a little bit alluded to this um and in your uh observation on the formula builder but um it allows us to do some pretty elegant things with auto suggest um and projections so you know if i just type table so if i'm in the mindset of like, oh, yeah, what was that table called? It was called to do's. And I type, you know, to I get, you know, at the global document scope, I get a list of tables, I tab into that I hit dot. And now I have a list of all the columns. So I don really have to remember uh the shape of all those things um and um some of that's possible in in prefix uh in the prefix world but um i think we you know the combination of um improving that auto suggest um uh and and readability um make it

something that we want to push. Yeah, that's a really good point. I hadn't thought of the auto-suggest improvements. But that's great. Yeah, I think a lot of, I mean, the way that we view formula documentation is that auto-suggest should really be the formula documentation that you use as opposed to having to to having to like have two tabs open in your browser um so there's there's a bunch more we can do there i think

we do a decent job today i would agree i in my experience using coda uh i was very impressed with the the way the autocomplete worked and also the documentation in the formula builder was the same as the documentation. I didn't quite realize that for a bit. I opened up the documentation in a separate tab and I was like, oh, wait, it's the same. I can close this tab. It doesn't give me any extra information.

The only time that I actually used the separate tab of of things was when i tried a few autocomplete things for function to find functions and the ones that i was expecting to be there weren't there didn't do what i expected so i was like hmm like which one of these will do what i want i had to kind of like look through them all right so it's kind of hard to build around that yeah yeah it's a it's a nice way to kind of like discover the superset yeah and kind of like chunk them up into groups if you're looking at you know currency numbers or whatever yep yep exactly yeah yeah yeah because i can like ignore the currency ones like that's not what i'm trying to do right now i'm trying to do something with like grouping

you know whatever right right so um the way I just framed the question about the dot operator, I think was, I guess, kind of similar to the, sorry, the Rich Hickey talk that you brought up of simple made easy. It's a distinction I've actually been thinking a lot about in the last day or two because someone else told me that I need to rewatch it because the way I've been talking about it got a little bit blurry. And so the distinction between, I guess, the distinction I want to make now is kind of different than his distinction um the distinction between um like the dollar operator it seems definitely based on the way you described it and and in that context to be like the where like where you want to take people but potentially

it's less familiar and so you you have to you know decide if you want to just like go with what's familiar for people or give them the more powerful slash better slash simpler option in the long run and so i think that's like an interesting tension to look at and so yeah there are a few places in the tool where i feel like you potentially went with the easier route um or more familiar route you took you instead of the more powerful in the long run but also less familiar um i don't know if there are any places that come to mind immediately. I have a few if you want me to provide one. Yeah. Maybe I'll sit. I'll just say like one, one thing about that. And then I'd love to dig in wherever. I mean,

I think that we end up doing a lot of investigation on kind of like the familiar versus like what, what we think could be like the more powerful, the more kind of like the familiar versus like what, what we think could be like the more powerful, the more kind of like right model going forward. And, and like, there, there are big choices like that. So, you know, the first obvious big choice is like, instead of having, you know, a productivity kind of tool or like a, a tool for building other tools be like three or

four different tools like this is this is one tool um uh and that was sort of like different different than the familiar um all the way down to you know the the things that we're we're talking about now so i think in many ways like that's what we asked our product and design and engineering teams to do is, like, go look at this particular component. Go look at all of the jobs that it needs to serve for, like, a very horizontal set of users. Sort of try to distill it down to its essence of, like, what it's sort of functioning as, you know, is like a simple atomic, like single threaded thing. And then decide which direction we should head. So it's I think that's very that's like that's like part of our DNA as a company. And so far as anyone's interested in doing that on a regular basis you should you should come join us there were two that come to mind of instances that i'd be curious to hear more of the

the like calculus the internal calculus and why you went one direction instead of the other um so one one thing that made me laugh is um how you have uh buttons that often put can push other buttons that's like a core feature or core like interaction paradigm that that i saw people using and you talking about and so my first reaction to that was like i think i laughed because it's just like a funny idea of buttons pushing buttons yeah and then my second reaction was like oh like that like how clever you know people already know what buttons are they already know what pushing buttons are like it's so concrete like one button can go push pushing buttons but then when i was using it um it it's for some reason it just it didn't feel so elegant

or it didn't it it didn't feel as powerful as um i i think to be more concrete, I think what I was trying to do, maybe you can give a better example, is I wanted one button to change all things about all rows in a table. But the pattern to do that, at least when I tried to do it, seemed to be you have to create a column in that table and a button column in that table. And the button column of that table will actually mutate each row. And so you have one button press every button in a column in that table and a button column in that table, and the button column of that table will actually mutate each row. And so you have one button press every button in a column. Is that, did I forget something? No, no, that's right. I mean, I can give you like in practice why this ends up working quite well. Sure.

Like from a user perspective. So like a common thing that we see um people doing is uh with buttons is um sort of pairing this like this single unit of a button with um uh what behind the scenes is actually a function to call to call slack so like um concretely the case is, you know, I've got a, I've got like a list of things that like my team has to do. And I want to post an update, like individually to each of them to say like, hey, can you, can you come update this, this task? Like this is sort of a typical like project management, you know, thing that you have to do in a team. And the analog way of doing this is walking over to everybody's desk, but everyone's not in the same office.

And so the next way I can do this is copy paste from a browser, go over to Slack, write my message, paste the row in, and rinse and repeat this like 20 times. But interestingly, like what I end up doing is not necessarily like, I don't ping everybody all the time. I ping like some people some of the time. So like maybe there are three people

who have like outstanding stuff and they haven't updated that task in a while. When I have a column that is a button that sends a Slack message to that person, in practice, like, what we see is people, you know, sort of periodically hitting one, two, three, four of those buttons, right? Saying, like, oh, these three things need to be updated, but I don't want to ping everybody. And then you sort of, like, pair that with the the case of like, all right, it's like, you know, Monday morning and like, we need to develop a plan for the week. And so like, I'm going to hit the like Uber, you know, the Uber button, which is basically going to go,

go push all the buttons and like ping everybody. Um, so, so in practice, like, you know, it, it, it, it was interesting. It kind of felt funny to me at first but it ends up to solve the problem quite well um because you you sort of come at this idea from like two different places as a user um wanting to kind of you know in this simple example like wanting to ping everybody versus wanting to to sort of individually um uh update things. Yeah, yeah. I see that perspective. It starts very concrete. You build a function to just ping one user,

and then you abstract over that to all users. Exactly, exactly, yeah. Yeah, that makes a lot of sense. I guess, to be fair, where I was coming from is, like, what's familiar to me is being able to like speak more abstractly as a programmer. So I was, I was, you know, expecting to be able to, you know, just start from the abstract, but I was like, Oh no, wait, like I have to go and do this other thing that, that feels too too concrete or whatever.

But I guess that's just my bias and not actually inherent to the problem. Yeah. I mean, it's always like challenging sort of figuring out the right way to take a concept like that, that these should be atomic parts, um, uh, so that you can like understand them and reason about them individually. Like I don't, I don't actually have to understand the, um, you know, the, the broader button that pushes all the buttons. I can understand like the, the single button column. Cause that's what I ended up using in my view. Well, so I guess maybe what my criticism would probably be, or my question really, would be a column that's a button, like I think of that as being a function of type whatever the row is. So it's like a function that operates in a row. And so sometimes I would wanna use that row in a more like basically first class functions i

guess the thing that i felt myself wanting yeah but um so i don't do you plan to add like those sorts of those sorts of more superpowers but but are also like much harder for people to get their heads around? Yeah, I mean, some of that is actually happening kind of in the background. And I think there's a question of how much we end up exposing to users. And I think probably in the future, we'll continue to expose more and more. But I think right now, we want to make that as accessible as possible at the moment, but definitely have the option to change that in the future. So one other one to just run by you is

I was importing some data in coda from spotify i wanted to do some like analytics on yeah on like different things like that and um i found it to be very challenging to add the data i pulled into a table yeah i like had to do it i'd like yeah it was just what i really wanted was a function called table that would take a list and then like make a table right but i had to like imperatively add like create a table first and then like add things one by one yeah yeah absolutely this is um this is one that uh we're we're thinking a bunch about actually um right now and and have some prototypes. I mean, I think what you're basically seeing is like the underlying,

some of the underlying building blocks that we haven't created the right abstraction on top of to make it a bit easier to do. So I won't say exactly how we plan to do that, but it's something that we definitely have some really concrete ideas on how to solve. But I agree, like, you know, when we built PAX, that's, I guess, for your listeners, like PAX is sort of what you're leveraging when you use an integration. And PAX are basically a way to, pull data in from the outside world and push data out to the outside world.

And we've been talking about Slack and, in this case, like, Spotify. So, you know, interestingly, packs are basically, like, sort of have two parts. Like, there's an authentication side of this which is like it makes it possible for you to not understand like oauth to and and quickly auth into your spotify account um and then there's like a there's an execution side of this which is that spotify pack comes with a set of formulas um and a couple um buttons that are driven using those formulas. And so we kind of launched the primitive parts, but there are definitely rough edges, and especially this edge of I just want to sync a set of data

and I want to be able to declare that from a formula and have it kind of materialize um is something that you can't can't do yet but um definitely thinking about it yeah I see so right now you can kind of import data once but but the two-way sync thing isn't well the the um the the so like refresh actually works um and, and one way sync works in the sense that, um, uh, I can like take, take a row, you know, let's say, um, uh, take an individual song. Yeah. And, and have that like stay up to date and like continuously refresh the metadata about that.

Um, now if I want to like, kind of go the other way and like update the metadata about that. Now, if I want to go the other way and update the title of that song if I was the artist, not able to do pieces of that yet. But there are other examples where you can do one time updates. But the thing I think we're thinking about is how you do that continuously. Cool. Yeah. So I guess the last question I have for you, I feel like is,

I'm not exactly sure how to ask it. So here, I'll give it to you in two different ways, and you can take either or both. So I find that people, that vision you laid out of blowing the distinction between people who create software, people who use software, that's a fairly common vision for people who listen to this podcast. And I think some people come at it from academia and other people come at it from like the world of startups um and so a lot of the questions i ask you know or a lot of things you talk about you like even the formula bar for example um you kind of like iterated on it from like a startup product design perspective and you came up with something that's pretty great and and you and you ship it and On the other hand, people in academia think about problems from a more fundamental perspective, like a less practical perspective.

So I'd be interested to hear you talk a bit about the trade-offs and why you think that the... I guess the main question is, why are you confident that this will scale like the people in academia kind of have like you know they move slower but they kind of get their foundations right and people in startups move quicker but then the risk might be that you you kind of corner yourself in a box and and you don't actually build something that can be as flexible as you want or as easy to use as you want?

That's a good question. I mean, I think in a lot of ways we have to kind of a little bit fight the like mentality that I think a lot of startups have, which is, you know, just like rush something out the door or just um uh you know do exactly what the customer says um in this case um uh i think what you see you know hopefully what comes through in the tool is that there's actually quite a lot of kind of deep thoughtfulness that have gone into a lot of these choices um and uh and so i i don't i don't think that like we actually fall sort of squarely on on like one side of that dichotomy or the other necessarily i think that um you know we have uh folks you know maybe i'll cite we have we have folks from um uh bre lab, Michael Nagel, who's in this community and continuously pulling us into some of the research and grounding us in that way.

And I think the early team that built a lot of the foundation of the product, Alex and Shashir and Matt and Himanshu and Phil, like these, these guys have, have a very long history in, in the space of like, you know, programming and file systems and everything else. And so it, it, it was sort of atypical in that sense. Like we, we had a a long longer runway to get the foundations right um we actually spent like a few years in stealth um and that was you know iterating both on the ideas behind coda um and and kind of with a small set of customers so really trying to balance that dichotomy of like thoughtfulness um uh, uh, with the kind of practical.

I remember, um, hearing about Coda, like raising money four years ago and being like, Oh, that, that sounds neat. And then like two or three years later being like, okay, that, that probably never went anywhere. And then, and then a couple months ago being like, Oh, they're back. Glad we were able to pleasantly surprise you. Yeah, I think, you know, I guess the other thing I would say is it probably comes back to like the rituals of a team. You know, if I like looked inside of a team and looked at their rituals, I could probably get some understanding of like, you know, where they might fall in a dichotomy like this. So, you know, concretely, a researcher may spend a week or a set of years like thinking about the same problem. And for us, one kind of like fun ritual that we get to kind of step out of like the, you know, what can be a crazy day to day is we do code-a-thons or hack-a-thons basically every quarter or two.

And the idea is to like spend, spend two or three days and really get to like see the teams like crazy creativity applied to like some really tough problems. And, and a lot of times like the work that comes out of this is either inspired by research or, you know, folks like Brett Victor or, like, is very adjacent to it. And the fun thing is that you get to see it materialize, like, really quickly, or at least, like, an instantiation of it really quickly. So to give you a few concrete examples,

in the first hackathon several years ago, the team was really inspired by Brett Victor's dynamic drawings, and so they built a simple way to do geometric shapes like rectangles and circles in the formula language and then plot and draw those. And then the obvious next step is to like bind those shapes to actual data and a table. And like what you get is like a composition

that's sort of dynamic. And like at the time we like quickly applied that to we were tracking all our bugs in Coda. It was at the time it was called Krypton. And so we wanted to, like, we created a little status chart that was basically like rectangles drawn from the counts of bugs. Like another example is when we built, we built actions.

So, you know, we basically used actions and taking action is kind of like the basis behind what we talked about with, you know, buttons that take action and automations that take action in the world. So I think, like, to kind of tie it back to your question, like, we're fortunate to have a big base of users that have like really practical and important problems to solve every day. But at the same time we have like very concrete rituals to like step back and, and, and be creative and invent and, and, and make sure that we're, you know, applying the appropriate level of thoughtfulness to the problem space. Cool. Yeah. Sounds like getting some of the best of both worlds.

Yeah, hopefully. So I guess that's a good note to transition to my last kind of meta question, which is you alluded to that you're hiring. So you can talk a bit more about that and any other ways you want to suggest people reach out or get involved or any other links or places to mention. Now's the time for that. Sure. Thanks. Yeah, so I guess in terms of hiring, you know, we're always hiring engineers. We're also hiring kind of on the go-market side as well. And you can just go to kind of our jobs link in the footer

if you're interested there, feel free to like hit me up. And then in terms of other places to get involved, one really interesting place actually is our community is like very active. So community.coda.io. You can kind of see the range of things that people are building and showing off there. You can see the questions. And our team makes a big effort to stay very involved with the community.

And so that's another place. If you end up building something neat, submit it as a template. We usually work with people and really try to understand the problem that they're trying to solve and how we can get that out to more people. But yeah, we're definitely looking for people interested in this space

and I think we have a handful of people who are really steeped in, um, uh, probably what your audience, uh, uh, is, is doing and thinking. And, um, those, those people are really important to us. So, and so far as there are others that are interested and, um, want to contribute to a, to a sort of greater vision like this, uh, we'd love to talk to you. Cool. Well, thanks so much. This was a lot of fun. Yeah., we'd love to talk to you. Cool. Well, thanks so much. This was a lot of fun. Yeah, thank you.

This was awesome.