#42 - Blurring the Line Between User and Programmer: Lane Shackleton

08/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, compelling vision, and Coda has a long way to go.

Transcript

Transcript sponsored by Repl.it

Corrections to this transcript are much appreciated!

SK:

Welcome, Lane.

LS:

Hi, Steve.

SK:

Hi, yeah, thanks for making the time.

LS:

Glad to be here.

SK:

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?

LS:

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, 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.

LS:

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 went from zero customers to a whole bunch of customers and a whole bunch of revenue. I guess overall my journey to Coda, though, Shishir, who's the CEO here was starting this company after he left YouTube, and kept showing me demos. And I got really 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.

LS:

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, but sometimes was unable to make those things. Yeah, and since then have just been 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. A lot of Bret Victor's work, recently we've been pretty inspired by Nardi's work, and her book, A Small Matter of Programming. Also, things like Clayton Christensen's and Jobs-Be-Done framework.

LS:

So to me, Coda is sort of like this... 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 take you into any of that.

SK:

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.

LS:

Yeah. Yeah, absolutely. I mean a lot of those folks were small and medium sized businesses, and 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 hacked together. And the businesses often have to create their own tools, because they can't buy really expensive software, so there are a lot of parallels there.

SK:

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 problem it's for. Why would people use it?

LS:

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.

SK:

Sure.

LS:

I guess that-

SK:

I'd be curious to go into the different audiences, like maybe you could pick two or three audiences and tell me how you tailor the pitch for each of them? That would be interesting.

LS:

Yeah, yeah. So I think if I'm talking to someone who doesn't know much about tech or software, I think I often like to frame it sort of at 50,000 feet. Basically, 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. Because there are lots of 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 50,000 foot, 30,000 foot thesis is that 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.

LS:

And in terms of the product itself, if I were to be demoing it to someone, or showing it to someone, I'd probably start by showing them that it's just a doc surface, so blinking cursor and a toolbar, and something that can kind of grow with the evolution of an individual's project, or family's trip, or a team's evolution, starting out 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, if I were to go pitch a product manager in Silicon Valley, that's an easy one, because I have a lot of background in that area. I definitely know this very well, writing specs, and designs and stuff back at YouTube and Google.

LS:

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 if you take someone like that, they might start with writing an idea in a doc, and then eventually that becomes a set of structured data, 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 can add multiple sections inside of one document, one for your high level goals, and then that's 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.

LS:

Yeah, I don't know if that answers your question.

SK:

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 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, just it's nice to have an integrated experience. But 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 altogether.

LS:

Yeah.

SK:

So, yeah.

LS:

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, 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 document.

LS:

So inside the document you can create a button, and that button basically does one thing. You press a button 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, 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.

LS:

There are probably ones that are simpler 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, and less of a, "We have the answer: this is the single way to do project management." Or, "This is the single way to do CRM." The idea is that you can kind of take these simple parts and build them up.

SK:

Interesting. Yeah, yeah, yeah, I see what you mean. So within the tool you give them a bunch of simple, independent, orthogonal legos, and they can make their own system.

LS:

Exactly. Yeah.

SK:

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 single purpose spreadsheet system used in combination.

LS:

Maybe. I think one piece of this is that you have to have... You can't have too many legos on the table, or it becomes difficult to understand which legos you should use when. So I think we think pretty carefully about each of those building blocks that we add. 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 a logic layer, which you can build up through automations and formulas, and then you have a presentation layer, and that presentation layer allows you to do things like add new candidates, or add new sales companies to that CRM.

LS:

And each of those, I guess, with Coda, is sort of right on the surface for you. And so in that sense, there are really only three, 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 are formulas, and tables, you can get pretty close.

SK:

You mentioned in a prior conversation that one of the main inspirations from Coda came from yours and the founders' work at YouTube, where the company was run in a collection of mostly spreadsheets. Is that an accurate way to explain it?

LS:

Yeah. Yeah, that's kind of a fun story. So I worked with Shishir, who's one of the founders, at YouTube, and Alex, one of the other founders, also worked there. Shishir ran product and design, and I helped lead some of our monetization efforts there. Thinking about YouTube as an example I think is interesting. I mean, in many businesses, when you look at the software that they're buying, they're buying all these vertical apps. But oftentimes when you just say like, "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.

LS:

And that's certainly the case at YouTube. Despite having amazing engineers capable of building all types of different tools, 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 a specific perspective on how a process should run, so that they weren't confined to a specific tool's way of doing things. So a few examples: you want to run a calibration process across 1000 people, you want to do comp planning across 1000 people, you want to run 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 front-end or add columns to a database at our request, it's much easier to just build those things up out of a spreadsheet.

LS:

So it's sort of one of those, I think a good example of having an opinion on how something should run, and 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. And a lot of that, I think, served as inspiration for some of the things that you see in Coda.

SK:

So yeah, why is it do you think that spreadsheets have been so successful, as opposed to docs? Why wasn't things being run in a Google Doc, for example?

LS:

Yeah, great question. I mean, I guess I would start by saying spreadsheets are completely amazing. We have a lot of folks inside of 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. 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 the deeper parts of a spreadsheet to get started.

LS:

And for the most part, it's based on a pattern of direct manipulation. 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 upper reaches, with a really flexible formula language that, 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 numbers, or calculations. Basically, a place where you could drop a bunch of information and then add some structure to it.

LS:

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 grow with your idea.

SK:

Yeah, I see what you're saying. Well, spreadsheets are also almost superficial, in a way that Airtable's kind of innovated in making it not, and you guys also. It's more like the table is the data, and then you have also a presentation layer as well, but you guys make a clear distinction, when a Google Doc is... it feels like it's less semantic in some ways.

LS:

Yeah. Yeah.

SK:

So it seems like we're in a bit of a renaissance of the next version of spreadsheets. It seems like Airtable, and then there was also Fieldbook, which I don't think is anymore. And Notion recently added a kind of data spreadsheet model, and you guys. Why do you think now is the time for everyone to be rethinking the future of docs and spreadsheets?

LS:

Yeah, that's a great question. I guess the first thing we're saying is we're big fans of anyone trying to make it easy for makers to build what they need. I think this is a really positive step forward for a lot of people who are subject matter experts, and knowledge workers. In terms of why we're seeing it now, that's a good question. I think in many ways, what you see is people starting to take back control of the tools that they use. And this isn't necessarily a new phenomenon, at least in the last few years, but just if you look at the IT purchasing process, it used to be that there would be one person who oversaw it, and they would have to sort of procure software in a way that they distributed it to everybody inside of a company.

LS:

And I think in the last few years, you've seen a lot of bottom's up growth of some of these tools, like Slack and others, where people were 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.

LS:

And then to go beyond that, I think everyone has their own take on what it is, and what it should be. I kind of like to think about it as there are 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 bucket of apps. Everything from small niche apps to big things, like Salesforce.

LS:

And so we end up competing, or we end up 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 us 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 prose and written text.

SK:

That seems surprising to me. Why aren't these people using Google Docs? In theory, I would expect Google Docs to be full featured as a document than Coda.

LS:

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 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.

LS:

And so some of the more mature features of something like docs become a little less important in that world. And I mean, to kind of go directly at the question, I think one of the reasons that people pick us up is because, I love the Alan Kay quote of, "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 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 end up outgrowing... just in the life cycle of like, one project, or one family trip, or one whatever it is... you end up outgrowing the capabilities and migrating to a spreadsheet. What we really commonly see in businesses when we first talk to them is this combination of docs and spreadsheets. Where you have docs that are pointers to spreadsheets, and back and forth. I've definitely lived through that world, and it's... I think there's probably a better way, so.

SK:

That makes sense. I guess it's impressive that you're able to sell the vision of, even though you only need a doc right now, start with us, because we'll grow with you. Because I feel like most of your value-add, and the exciting features that you bring to the table, they might not get to them until they've already written a couple of docs. So that's what I'm impressed by.

LS:

Yeah. Yeah, I mean I think 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 submitted to us. Or templates that we've made for them. So it cues you in to the fact that, "Oh, this later can have a table of tasks that I can use to track things, but right now all I have in my head is an idea." I hope that our users glean that from seeing a lot of the examples that we put out.

SK:

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 be also curious to hear what other sorts of initial users you're targeting now. Like of course it's a very general purpose tool, so you know, everyone uses spreadsheets, so in theory everyone would use this, but are you focusing on some initial people? And 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?

LS:

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 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 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-be-done and Clayton Christensen's work there. I guess, so just some other examples to make it more tangible-

SK:

Maybe... sorry, just to interrupt... could you talk more about jobs-be-done? I haven't heard of that.

LS:

Yeah. So I guess the general thesis behind jobs-be-done is users hire, or people hire products in their daily lives to solve specific jobs. And that's sort of in contrast to, this set of demographics will buy this product sort of causally, because of their demographic. And the classic example that he uses is a fun one, it's the milkshake analogy. I don't know, have you heard this?

SK:

No.

LS:

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 McDonald's or something, and they were trying to figure out why people were buying milkshakes between seven and nine AM, and this was 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.

LS:

And they could solve this with a banana, but that's only two minutes on a 30 minute commute. And they could solve this with a glass of water, but that's kind of boring. Nowadays, people probably use podcasts on their phones to keep them entertained, but the general idea is that-

SK:

Right now, someone's listening right now.

LS:

Exactly.

SK:

This is the job being done.

LS:

This person, yeah. But the general idea is basically that a milkshake solves this job really well, because it's sort of the 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 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, I don't know if that makes sense.

SK:

Cool, thanks. And just, I guess, 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.

LS:

Yeah. Yeah, so on what you might call the consumer side, I think we have people doing everything from organizing trips to planning weddings, to splitting expenses with their friends. There's sort of a very wide... 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, obviously engineering teams, design teams, product teams, salespeople, recruiting teams. Those are sort of, to name the laundry list. Just to maybe dig into one of those for a second, it's kind of a story that I really like.

LS:

So one of the first times I feel like I realized that we were kind of on to something was when I sat down a few years ago, now, with a 23 year old recruiter. And he started the conversation by saying, "I'm not a spreadsheet person. I don't know how to code," and I was like, "It's okay, let's see what you need to do." And I kind of watched, and helped him build a tool for his team to track... at the time this was engineering candidates. And the tool was basically an editable database with a bunch of views for each person, and a few controls, like select list, where you could let people filter. There's a few interesting parts, to me, about this example.

LS:

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. Clayton Christensen, again, talks about how every great product has a social, functional, and emotional aspect. And this was, it was really neat to see the pride emotion of him making software for the first time. Like really presenting a tool that he had made. And then this social aspect, of his team really feeling like, "Oh, this person's capable and really valued, and contributing to our team."

LS:

And so I think that when we do our jobs right, that's the result. People feel like they can take their subject matter expertise, their domain expertise, and present it to their teams, and build 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, in a traditional software model, what would have happened when that team evolved. So that team ended up going from 5 people to 20 people over the last three years. What would have happened is, 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 was a really concrete sense of agency that I think is quite powerful when we do it right.

SK:

Yeah, it sounds like a really obvious value proposition: impress your coworkers with your superpowers. Yeah. I, and I think many engineers, we feel that sort of pride all the time. It's a lot of what drives us. So it's cool that you get to democratize that: I built a thing that you can all use, and you'll think of me fondly while you use it.

LS:

Yeah, and you know, I think there's something really impactful about having someone think about themselves differently in that way. Think, "Oh, I'm just as capable as other people at making things again." The analogy I like to use is, when you ask a group of four year olds who's an artist, everybody raises their hand. But then you get the same group at 40, and zero people will raise their hand. And I feel like in general, the artist has kind of been beaten out of people when it comes to software and tools, and so far as we can reinvigorate that, that makes me happy.

SK:

So do you find that the story you told of someone starting this new system from scratch, and it 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 the breakdown? I don't know if you have the numbers on that, what's the breakdown of starting from scratching and growing, or migrating into it?

LS:

Yeah. I mean, interestingly, that process was... I think if I recall correctly... that process was run out of a custom tool, or 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 Coda. So in terms of the numbers and where we see migration from 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 tools, and a lot of spreadsheets.

SK:

And are you... 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... I wouldn't be all that surprised if people customize things once a year, and then maybe made a few tweaks here and there, but mostly were just using it as an app, or app/spreadsheet.

LS:

Yeah, good question. I mean I think this is, it's sort of worth pointing out that it depends on the type of doc that you're talking about. So as I was mentioning before, half of our active docs don't have tables, and so in that sense, they're constantly being customized, because people are writing meeting notes, or people are writing ideas, or designs, or whatever.

NS:

But sort of maybe more to your question, for 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 co-creating the tool for their team. And this makes sense, given a role, like something that's probably familiar to your listeners is if it's a product team, the product manager and the engineering lead, or the product manager and the design lead, are kind of building the ideal workflow for their team. And that's basically a general setup process, and so the doc goes through lots of iterations in that early phase, and then like you said, it may get used for a period of time, and then something changes, right. The project winds down, or the team grows, and the effort expands considerably. And then you go through another iteration of that building process.

LS:

To use a real example, there's a customer, set of folks at Uber, who 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. You had really two people setting up a construct for hundreds of engineers to go work, and so for a week they were building out the perfect system. (That's actually in our template gallery. Kind of in that top row, if you're curious.) They were building up this perfect system so that all these teams that are distributed all over the world could then enter their information about how that project is going, and break apart this massive project into coherent parts, and then they let hundreds of engineers, hundreds of people loose on that tool, and then over the life cycle of the project they ended up building out other aspects of it later, so at the midway point they built this really neat kind of 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, "How close are we to actually shipping this thing?"

LS:

And that's kind of what I mean by this is ideally a tool that can evolve with the life cycle of a really small project, or a really small set of tracking requirements, to something very, very large. And even within that project, kind of evolve with it.

SK:

Yeah, so I'd be curious to know what sort of agency people have farther down the food chain. If certain engineers wanted to customize things, do they have the permissions to do that, and how do they make sure they're not stepping on other people's toes, or messing with other integrations that are core?

LS:

Yeah. Yeah, that's definitely... it's a tough question when you're organizing hundreds of people.

SK:

It's almost like the flexibility of the tool is working against you here. Because there's certain things that you want to have be like, "No, no, no these are rigid, that we're top down deciding for you as the organizers, but we also want to give you flexibility on things we don't care about."

LS:

Right, right. Yeah, there's probably a couple things to say about that question, like 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 only access, or edit access. And so in this case, like for the executive team, I think they only gave view access, because they didn't want executives going in there and changing a bunch of things.

LS:

But to your question on further down the chain, and 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 their perfect view of a set of data. So in this case, you might have one Uber task table, or one features table or something like that, and then an individual team goes in and creates a section, and that section is, they title it, like, "This is our section as the design team," or something like that. And all they're doing is creating a filtered view of that larger dataset. But kind of importantly, it's all the same dataset, right, so it's kind of right through from that view to the core table and back.

LS:

And so the part, if you were to ask the folks from Uber, I think that they have said to us that 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 and add a new feature, or whatever it is. So-

SK:

I just want to-

LS:

Yeah.

SK:

A quick, quick idea. 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 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. I guess the question is two part. One, if we added a column, would it 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?

LS:

Yeah, that's 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 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 which columns are important. And interestingly, the alternative that they were looking at was literally dozens and dozens of spreadsheets. And all of those spreadsheets had slightly different column names, but effectively representing the same thing, right, and so there's one obvious win for them as the designers of this tool, that they now don't have to reconcile all these different, slightly different names that represent the same thing across all these things.

LS:

So as the designers of the tool for 300 plus people, what they did was, they did the column reconciliation, if you will, and agreed upon that. Sort of down a level from that, let's say that they still missed that column for the person in Dublin, that person, 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 they may want to branch some variant of that features table in a way that's helpful for them. And so as long as they're not "polluting" the other views by forcing that column to be added everywhere in all the other views, then that mostly gets out of the way for everybody else.

LS:

At certain points, I think folks are finding the tool very useful, and adding lots of columns, and so I think that there was this question around like, "Oh, is there a different level of permissions here, where we can say people should only be able to add rows, and edit rows, but not change the columns, or the formulas in some of the existing columns," and stuff like that. And that's something we're certainly thinking about, and have been prototyping some answers to. But at its core, I think in a place like Uber that's super collaborative, and 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. And ultimately, that's probably a good thing.

SK:

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, additionally.

LS:

Yeah, that's right. If it actually became, if it was materially different in its data structure, or it was, it sort of felt divergent enough from that first features table or whatever it was, that's right. They could also create a table, and then look up from the other table. Yeah.

SK:

Cool.

LS:

Yeah.

SK:

So the tagline seems to be, "Docs as powerful as an app." Is that right? Or did I missay it?

LS:

No, that's right. I mean I think the thesis is that you can build a doc as powerful as an app. And so we haven't really talked much about mobile, but we spent a bunch of time on mobile making sure that it actually felt app-like. 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 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.

SK:

Yeah, how did you pull that one off?

LS:

Yeah, we're really 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 on the left, if you're on desktop, and the whole idea behind the section list is basically 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 this sense right away that you're in an app.

SK:

And so you put it at the bottom? Is that where you put it?

LS:

That's right. Yeah, like on iOS it's just a little tab bar on the bottom.

SK:

And where is it in Android? I don't even know where Android navigation is, and I have an Android phone.

LS:

Yeah, in Android it's sort of similar.

SK:

Oh, okay.

LS:

Yeah, and then I mean there's some like material design choices that we're in the midst of finishing, but sort of generally the same principle. So yeah, that's sort of the first noticeable thing is that you get this experience of, "Oh, I open this up, I open one of these docs, and it feels 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 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 clean summary of that row. And then we allow you to swipe the card, an interaction most people are probably familiar with from stuff like Gmail, where you can swipe to archive.

LS:

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 out in the field, and so they were constantly on their mobile device, and if you want to check in or check out a bike, or say, "This bike needs repair," on desktop, there were three buttons. (And this is also in the template gallery if you want to go look at how this works.)

LS:

But on desktop this is three buttons that say "check in", "check out", and "needs repair". And on mobile, when you pull up that same list of bikes, you get a nice little picture of that bike and some of the details about the bike and its status, and then you can swipe to take those actions, and that feels native app-like. And interestingly, as a person who created that doc and configured that doc, it's 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 kind of-

SK:

Yeah, so swipe right is one of the buttons, swipe left is the other, and what's the third button?

LS:

We actually split the swipe right. Right now it's only swipe right, and we split it into three actions. If you've seen, I think this is also a fairly common pattern, but you swipe and then you get three options.

SK:

Yep, and you press one, yeah, yeah, yeah. Okay. Cool.

LS:

Yeah, so that's, I guess, that's a couple ways that we've done so far. Have a bunch of other ideas. I guess one of the other ones that people have really started latching onto recently is, imagine you're doing that same inventory tracking, and you want to take a picture of every bike, so you can 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 from the phone's camera. So you have a nice entry point to native things that you're used to doing on your phone all the time.

SK:

A camera, an image column-

LS:

That's right.

SK:

Presents itself as a camera button, and you can either upload, or take a photo.

LS:

That's right, yeah.

SK:

Oh, I see, there are all these little clever things you can do, that just automatically, behind the scenes, adapt the interface to a mobile.

LS:

Yeah, that's right. That's right. Yep, exactly. I mean, that's sort of the fundamental premise here, is that you shouldn't have to be an app designer, app developer type person. We do most of that automatically for you. We switch the tabs for you, we switch buttons for you, we take abstractions like the image column and do that for you.

SK:

So I'd be curious to hear a bit about where Coda's going, 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, you know, they're on your team, they're not going to be nefarious agents. And it feels kind of like Google Docs, or like spreadsheets, you know? Use it with your friends and your coworkers. Do you ever see it as being... you say the word app, do you ever see it as being something that a company would make as an external app? That they'd sell things on it, or have external users?

LS:

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 "Maker Fest" with Product Hunt, and the idea behind that was to get people building app-like things. And you can see, I mean there's just a crazy array of things that, of varied application-like concepts that people built on that, and those are sort of purpose built to be external, in the sense that those people weren't building it for their internal company. In many cases, they were an individual person with no company, or doing it on the side. So for sure, we're already starting to see this pattern of people building tools for other people, and-

SK:

Could you give me an example of something?

LS:

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

LS:

And some of these examples start to feel very much like apps that people very much 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's fairly 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-lite concepts and distribute it more broadly.

LS:

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, 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 resubmit it to us, and they'll say, "Oh, this is a variant of that," so you get this interesting branching effect of being able to have someone else's perspective layered on to other people's.

SK:

Do you have a story for managing variants, and merging things that are kind of similar together?

LS:

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, the merging the variants sometimes feels unnecessary, because someone has taken a different perspective on it, and what we want to see is the breadth of these different perspectives. So eventually, when you're searching in the template gallery, or you're searching for a solution, really, you can sort of see all the permutations and get to play with each of them, and then decide which variant works for you. So in some sense, we could go solve that problem, we have some ideas of how we might do it, but it probably starts with fundamentally questioning the problem.

SK:

That's an interesting point. So I think when I asked the question of the full vision, and for if you'd be able to 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.

LS:

Yeah. Yeah, I mean I guess the full vision might be a little more kind of back to where we started. I guess I like to think about it in two ways. There's basically the 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 the individual stories of how we change people's lives, and how we have the opportunity to make them feel different about themselves in a really positive way. Taking that domain expert, that subject matter expert, and enabling them to actually build the tool that they need, and have a thinking surface that can evolve with their thought process. That, on an individual level, I think is our core aim. And it's a little bit back to the story I was telling you about that recruiter, on an individual level.

LS:

I mean I think if we bubble all the way back up to 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 sort of punchline there is that we can change how teams, and communities, and families can grow, and evolve. And that, I think, is incredibly powerful if we can do that right. Actually, it makes me think a little bit about my oldest son.

LS:

So I have a four year old who's finishing preschool at a Reggio Emilia school. I don't know if... are you familiar with Reggio philosophy?

SK:

Mm-hmm (affirmative).

LS:

Yeah.

SK:

But I guess maybe just give us a brief overview.

LS:

Yeah, yeah, yeah. So the basic idea behind Reggio is that kids... Like, learning should be self guided and rooted in experience and exploration, and kind of importantly, they're equal members to the broader community of adults and kids. And so a lot of learning environments, teachers are viewed as the ones that hold all the knowledge, and they impart that knowledge to their students, but Reggio sort of flips that. And I think that in a Reggio philosophy, kids are meant to construct knowledge through exploration, and observation, and discussion. I don't know if you want to add anything to that, based on your knowledge of...

SK:

I didn't actually quite realize that it was so... anyways, I knew that it had 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.

LS:

Oh, cool.

SK:

It sounds very constructivist, like Seymour Papert.

LS:

Exactly. Yeah, it's very constructivist. Yeah. Yeah, so to make that kind abstract concrete, an example from my son... Their class has been following this thread of an artist named Martin Puryear, that they found in the SFMOMA on one of their early visits. And so basically, what started as an observation of this particular sculpture became a six month observation/exploration/discussion about this artist's work. And it followed the kids' interests, which is kind of the important thing. And I think, if I were to think about the grand vision for Coda, I think that there are actually some parallels here, both externally as a product, and internally as a company.

LS:

So from an external, product standpoint, concretely in line with Reggio, we're saying that the toolmaker knows how this should work. The kid should be the guide, right, the maker, the subject matter expert, can create and discover, and create knowledge. And so, concretely that means something like starting with the prose of an idea that grows, and evolves, and their knowledge evolves as they structure data, or manipulate that data. And maybe from the other side, I think as someone who's building a product and design team, I think about it from a team standpoint, and I think there are parallels as well. Namely, that we don't act like we have all the answers.

LS:

We hire really smart and curious people, and we treat everyone as equal members of that community. And the idea is that they can observe our users, and explore, and discuss, and learn together. And so the combination of those two, we think, create the right conditions to make a great product. And so I think a lot of people identify with this idea... especially probably in your audience... identify with this idea that our tools have failed some large class of people. And so the way I personally like to think about the grand vision of Coda is we kind of need to do what Reggio does, and flip the existing paradigm. 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 evolve their knowledge with it.

SK:

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. But well said. So I feel like we could end there, that's a very high point to be like, okay, well get back to work. That sounds useful. But I also wanted to drill into a few specific product choices, particularly because that's what you work on, the product stuff, so I wanted to drill in there.

SK:

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's very concrete where if there's live data to be had, it will evaluate it with some live data. Like I pick a good default so you can see what's going on immediately. Or if there was some evaluation to be had, it'll partially evaluate whatever can be partially evaluated, which is also really cool. And then another thing I really like is that the types of various... like the structure of the data of various variables used in expressions are explained via an icon, like a calendar icon for times, and a personal icon for users. And then where I think it gets really cool is there are even subtle things. Like if you're dealing with a list, it'll 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 that too. So anyways, so I mostly just want to compliment you, but also I'd be curious to hear about how the product design work went into that.

LS:

Yeah, I mean I won't take credit for that... Back to the internal teams and creating the right conditions for those types of things to happen. We had a formulas team that really obsessed over the details, and I'm happy to hear that you've picked up on... I think you pretty much took the whole list, so nice investigation. Yeah, we had a product and design engineering team that really obsessed over a lot of those details, and I guess I could go into a couple of them, but I think you did a great job of explaining.

LS:

I think one of the ones that I was really excited to see was this idea of previewing your intermediate values, and I think mostly because I often come at writing formulas and programming from a fairly naïve 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 see a comma separated list in that intermediate value, and you 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 Bret Victor's work, and just this idea that you shouldn't have to play a computer in your head.

LS:

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 an example of what you mentioned, the type icons placed on the chip itself, is a very specific decision, because we saw users who were trying to make things like equivalency statements with types that were different, and running into problems. So we could, in many ways, preempt some of that confusion by showing, "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 a philosophical viewpoint on, you shouldn't have to play a 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 tried as best we can to marry the two, but yeah, major kudos to that team for really digging deep and chunking up what is a very difficult set of problems.

SK:

So another thing that I noticed that I liked, but also thought was a curious choice, was that you seem, especially in 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 is kind of a method operator, I think people see it a lot in Ruby, almost infixing. Why did you choose to show people this new way of... Because I think both work in Coda, as far as I saw. You can use the prefix function, or you can use it infix with its thought operator. Why are you teaching people this new way of doing things?

LS:

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 the current method of prefix functions, and I think that they have all kinds of challenges. So maybe I'll frame them as the positives on the dot operator side. The main one, I think is... or I guess there's probably three, two or three main benefits.

LS:

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, 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 counting the parentheses at the end of a function and figuring out scope-wise where I am.

LS:

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 you a little bit alluded to this in your observation on the formula builder, but it allows us to do some pretty elegant things with autosuggest, and projections. So if I just type table, so if I'm in the mindset of, "Oh, yeah, what was that table called? It was called 'todos'," and I type "to", 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't really have to remember the shape of all those things, and some of that's possible in prefix, in the prefix world, but I think the combination of improving that autosuggest and readability make it something that we want to push.

SK:

Yeah, yeah, yeah, that's a really good point. I hadn't thought of the autosuggest improvements, that's great.

LS:

Yeah, I think a lot of... I mean, the way that we view formula documentation is that autosuggest should really be the formula documentation that you use, as opposed to having to have two tabs open in your browser. So there's a bunch more we can do there. I think we do a decent job today.

SK:

I would agree. In my experience, using Coda, I was very impressed with 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. Like, I opened up the documentation in a separate tab, and it was like, "Oh, wait, that'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 things was when I tried a few autocomplete things 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. Which one of these will do what I want?" I had to kind of look through them all.

LS:

Right. Right, yeah.

SK:

So it's kind of hard to build around that.

LS:

Yeah. Yeah, it's a nice way to kind of discover the super set. Yeah, and kind of chunk them up into groups, if you're looking at currency, numbers, or whatever.

SK:

Yep, yep, yep, exactly. Yeah, yeah. Yeah, because I could ignore the currency ones, like, "That's not what I'm trying to do right now. I'm trying to do something with grouping," you know, whatever.

LS:

Right, right.

SK:

So 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. I guess the distinction I want to make now is kind of different than his distinction. The distinction between, the dot operator seems, definitely, based on the way you described it and that context, to be where you want to take people.

SK:

But potentially, it's less familiar, and so you have to decide if you want to just go with what's familiar for people, or give them the more powerful/better/simpler option in the long run. And so I think that's an interesting tension to look at, and so there are a few places in the tool where I feel like you potentially went with the easier route, or more familiar route, instead of the more powerful in the long run but also less familiar. 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.

LS:

Yeah, maybe I'll just say 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 the familiar versus what we think could be the more powerful, the more right model going forward. And there are big choices like that, so the first obvious big choice is instead of having a productivity tool, or a tool for building other tools be three or four different tools, like this is one tool, and that was sort of different than the familiar, all the way down to the things that we're talking about now.

LS:

So I think in many ways, that's what we asked our product, and design, and engineering teams to do, is go look at this particular component, go look at all of the jobs that it needs to serve for a very horizontal set of users. Try to distill it down to its essence of what it's sort of functioning as, as a simple, atomic, single-threaded thing, and then decide which direction we should head. So I think that's very, that's part of our DNA as a company, and insofar as anyone's interested in doing that on a regular basis, you should come join us.

SK:

There were two that come to mind, of instances that I'd be curious to hear more of the internal calculus on why you went one direction instead of the other. So one thing that made me laugh is how you have buttons that often can push other buttons, that's a core feature, or core interaction paradigm that I saw people using, and you talking about. And so my first reaction to that was, I think I laughed, because it's just a funny idea of buttons pushing buttons. And then my second reaction was like, "Oh, how clever." People already know what buttons are, they already know what pushing buttons are, it's so concrete. One button can go push some buttons.

SK:

But then when I was using it, for some reason it didn't feel so elegant. It didn't feel as powerful as... 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, 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?

LS:

No, no, that's right. I mean I can give you in practice why this ends up working quite well, from a user perspective.

SK:

Yeah, sure.

LS:

A common thing that we see people doing with buttons is sort of pairing this single unit of a button with what behind the scenes is actually a function to call Slack. So like, concretely, the case is, I've got a list of things that my team has to do, and I want to post an update individually to each of them, to say, "Hey, can you come update this task." This is sort of a typical project management thing that you have to do on 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, past the row in, and rinse and repeat this 20 times.

LS:

But interestingly, what I end up doing is not necessarily... I don't ping everybody all the time, I ping some people some of the time. So maybe there are three people who have outstanding stuff, and that 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, what we see is people periodically hitting one, two, three, four of those buttons, right? Saying, "Oh, these three things need to be updated, but I don't want to ping everybody," and then you pair that with the case of, "All right, it's Monday morning, and we need to develop a plan for the week, and so I'm going to hit the uber button," which is basically going to go push all the buttons, and ping everybody.

LS:

So in practice, it was interesting, it kind of felt funny to me at first, but it ends up to solve the problem quite well, because you sort of come at this idea from two different places as a user, wanting to... in this simple example... wanting to ping everybody, versus wanting to individually find and update things.

SK:

Yeah, yeah. I see that perspective. It starts very concrete, you build a function to just ping one user, and then you extract over that to all users.

LS:

Exactly. Exactly, yeah.

SK:

Yeah, that makes a lot of sense. I guess to be fair, where I was coming from is, what's familiar to me is being able to speak more abstractly as a programmer. So I was expecting to be able to just start from the abstract, but I was like, "Oh, no, wait, I have to go and do this other thing that feels too concrete," or whatever. But I guess that's just my bias and not actually inherent to the problem.

LS:

Yeah, I mean it's always challenging figuring out the right way to take a concept like that and explain it to an end user. And I think the product design philosophy here is that these should be atomic parts, so that you can understand them and reason about them individually. I don't actually have to understand the broader button that pushes all the buttons, I can understand the single button column, because that's what I end up using in my view.

SK:

So I guess maybe what my criticism would probably be, or my question really would be, a column that's a button, I think of that as being a function of type whatever the row is. So it's a function that operates in a row, and so sometimes I would want to use that row in a more... Basically, first class functions, I guess, are the thing that I felt myself wanting.

LS:

Yeah. Yeah.

SK:

So I don't know, do you plan to add those sorts of more superpowers but are also much harder for people to get their heads around?

LS:

Yeah, I mean some of that is actually happening 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.

SK:

So, yeah, one other one to just run by you is I was importing some data in Coda from Spotify, I wanted to do some analytics on different things like that, and I found it to be very challenging to add the data I pulled into a table. I had to do it, it was just... What I really wanted was a function called table that would take a list, and then make a table.

LS:

Right, right.

SK:

But I had to imperatively add... like, create a table first, and then add things one by one.

LS:

Yeah. Yeah, absolutely. This is one that we're thinking a bunch about actually right now and have some prototypes. I think what you're basically seeing is 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 planned to do that, but it's a-

SK:

Keeping us in suspense!

LS:

It's something that we're definitely have some really concrete ideas on how to solve. But I agree, like when we built packs... I guess for your listeners, packs is what you're leveraging when you use an integration, and packs 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 Spotify. So interestingly packs basically have two parts, there's an authentication side of this, which is like, it makes it possible for you to not understand OAuth2, and quickly auth into your Spotify account. And then there's an execution side of this, which is that Spotify pack comes with a set of formulas and a couple 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 materialize," is something that you can't do yet. But definitely thinking about it.

SK:

Yeah, yeah, yeah, I see. So right now you can kind of import data once, but the two way sync thing isn't supported.

LS:

So refresh actually works, and one way sync works, in the sense that I can take a row, let's say...

SK:

A song on Spotify?

LS:

Take an individual song, yeah, and have that stay up to date, and continuously refresh 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.

SK:

Cool.

LS:

Yeah.

SK:

So I guess the last question I have for you I feel like is, I don't know, 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.

LS:

Sure.

SK:

So, I find that people... that vision you laid out, of blurring the distinction between people who create software and 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 the world of startups. And so a lot of the questions I ask, or a lot of the things you talk about, even the formula bar, for example, you iterated on it from a startup, product design perspective, and you came up with something that's pretty great, and you ship it. Where like on the other hand, people in academia think about problems from a more fundamental perspective. A less practical perspective.

SK:

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? The people in academia kind of have... they move slower, but they get their foundations right, and people in startups move quicker, but then the risk might be that you corner yourself into a box, and you don't actually build something that can be as flexible as you want, or as easy to use as you want.

LS:

That's a good question. I mean, I think in a lot of ways, we have to a little bit fight the mentality that I think a lot of startups have, which is just rush something out the door, or just do exactly what the customer says, in this case. I think what you see, hopefully what comes through in the tool, is that there's actually quite a lot of deep thoughtfulness that have gone into a lot of these choices, and so I don't think that we actually fall sort of squarely on one side of that dichotomy or the other, necessarily.

LS:

I think that we have folks, maybe I'll cite we have folks from Bret Victor's 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 Shishir, and Nat, and [inaudible 1:00:31:44], and Phil, these guys have a very long history in the space of programming and file systems, and everything else. And so it was sort of atypical in that sense, we had a longer runway to get the foundations right. We actually spent a few years in stealth, and that was iterating both on the ideas behind Coda, and with a small set of customers. So really trying to balance that dichotomy of thoughtfulness with the practical.

SK:

I remember hearing about Coda raising money four years ago, I thinking, "Oh, that's sounds neat," and then two or three years later being like, "Oh, okay, that probably never went anywhere." And then a couple months ago being like, "Oh! They're back."

LS:

Glad we were able to pleasantly surprise you. Yeah, I think I guess the other thing I would say is, it probably comes back to the rituals of a team. If I looked inside of a team and looked at their rituals, I could probably get some understanding of where they might fall on a dichotomy of this. So concretely a researcher may spend a week, or a set of years, thinking about the same problem. And for us, one fun ritual that we get to step out of what can be a crazy day to day is we do code-a-thons, or hackathons, basically, every quarter or two.

LS:

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

LS:

To give you a few concrete examples, in the first hackathon several years ago, the team was really inspired by Bret 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 bind those shapes to actual data in a table, and what you get is a composition that's sort of dynamic. And at the time, we were tracking all our bugs in Coda (at the time it was called Krypton) and so we created a little status chart that was basically rectangles drawn from the counts of bugs.

LS:

Another example was when we built actions, we basically used actions and taking action as the basis behind what we talked about with buttons that take action, and automations that take action in the world. So I think to kind of tie it back to your question, we're fortunate to have a big base of users that have really practical and important problems to solve every day. But at the same time, we have very concrete rituals to step back and be creative, and invent, and make sure that we're applying the appropriate level of thoughtfulness to the problem space.

SK:

Cool. Yeah, sounds like getting some of the best of both worlds.

LS:

Yeah. Hopefully.

SK:

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 to reach out, or get involved, or any other links or places to mention. Now's the time for that.

LS:

Sure, thanks. Yeah, so I guess in terms of hiring, we're always hiring engineers, we're also hiring on the go-to-market side as well, and you can just go to our jobs link in the footer if you're interested there. Or feel free to hit me up, and then in terms of other places to get involved, one really interesting place actually is our community is 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.

LS:

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 probably what your audience is doing, and thinking, and those people are really important to us. So, insofar as there are others that are interested and wanted to contribute to a greater vision like this, we'd love to talk to you.

SK:

Cool. Well, thanks so much, this was a lot of fun.

LS:

Yeah, thank you. This was awesome.