Future of Coding - Building for Developers: Aidan Cunniffe

Episode Date: February 1, 2018

My guest this week, Aidan Cuniffee, is the founder of two startups in this space, first Dropsource and now Optic. Aidan and I discuss the trade-offs between creating tools for developers vs non-programmers. We also get to hear some of the upcomming features to expect from Optic. We finish off the interview with a fun theoretical discussion of notation, representation, conciseness and learnability. http://futureofcoding.org/episodes/21Support 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. So first, some housekeeping notes. My circumstances have changed a bit, so I am starting to look for a full-time job. I hope to continue this project in my free time, but it seems like it's going to be less of a focus for me going forward. So my guest today is Aidan Kniff. His name may sound familiar to some of you because he's the founder of a company called DropSource. They allow you to build iOS and Android apps without writing any code. Aidan founded the company and ran it for a few years, but recently left and is now working on a new company, also in this space, called Optic, which you'll hear more about in just a few minutes. At the end of our interview, Aidan asked me a question about notation and representation, which sparked a fascinating discussion about conciseness and learnability. I hope you enjoy. And without any further ado,

I bring you Aidan Kniff. Aidan, thanks for joining me today. Happy to be here, Steve. Thanks for having me. Great. So you are one of the few, if not the only person I know who has started two companies in this space. First, Dropsource, which listeners may have heard of, and now your new company, Optic. So I'd be curious to hear, to start from the beginning, what has so thoroughly inspired you to pursue not one, but two companies? Well, I'm not doing them in parallel, so I'm doing them serially, which helps. But I guess early on, I've been programming since I was 12 or 13. And I really got into

making video games, mostly because a lot of my friends played video games and it was a cool thing to be able to do. But a lot of the early tools I used, I remember one which is still around, but I haven't used it in a decade, which was the Torque game engine. And that had this really cool mode where you could blow up a visual editor right within your gameplay and then move stuff around.

And then it also had like a code representation where you could go in and uh modify some dsl they had to like move things around and i just got like really into this idea of like visual and um and code representations of things and i also um started building like animation tools because i wanted to be a director for a long time um that sort of worked on the same premise we could like play your characters and then it would save all the key frames based on what you did um so like i just i don't know i just did this from an early age and uh i just fell in love with building tools because you're able to basically build this one thing that has a ton of leverage because other

people use it to build their things. And then, you know, really quickly it snowballs from like impacting one life to impacting thousands. And I just really have always loved helping people express themselves. So I think it started early on or like I'm doing narrative fallacy to explain to myself why I like this stuff. But in either case, I'm hooked and I can't get out of it. How did you make the jump to working on more generalized programming languages? I think it really just came out of necessity. I sort of put that stuff to bed when I went to college. And then we were working, basically had a small dev shop, and a bunch of friends and

I were building products, both for ourselves, and then to make money, we were building products, specifically mobile apps for other people. And I think that that sort of passion for building tools, just sort of got reignited at that point in life. And we were thinking about ways that we could make our job easier to sort of scale beyond services. And the, you know, idea of building a visual programming language for app development sort of popped up. And that, you know, back in fall of 2013 was just an idea. And, you know, over the four years that I ran the company, we turned it into a real thing, which was really cool. But it was just, it was never really just like this, like plan to like build a general purpose visual programming language. It sort of was like, let's figure out how to make our own jobs easier, how to make our clients jobs easier, how to give a tool to people who come to us, but can't afford our services. And all of those things sort of turned into DropSource over the years.

It's a visual programming environment for mobile apps. So you can go into the interface. You upload a specification for your API using Swagger, which is now OpenAPI. And then it basically gives you drag and drop fields that you can pull data out of your API, build an interface. And when you hit build, it'll generate native iOS code in Swift and native Android code in Java. really quickly and to sort of take the developer out of the loop during that early discovery process when you're trying to iterate and have a quick cycle time. And was that kind of the vision the whole way, like over the four years, or did you

kind of have a different product to start out with and you kind of pivoted to this? Yeah, I'd say, you know, my biggest disappointment from, you know, early on, and one of the things that's inspired me to get back in the space again, is that we wanted to help developers and we wanted to lot of problems with the visual paradigm that made adoption with actual programmers really difficult. But we did find that non-programmers and designers and people who felt sort of cornered out of the market were really receptive to our tool. So we ended up sort of pivoting toward that group of people. But we had ultimately set out in the beginning

to try to help programmers all the way through. I see. So yeah, you built a tool for yourself as a dev shop kind of programmer-facing tool, but instead it's more of a newbie programmer. That's what you ended up with. You made something that's too easy to use, it sounds like. Yeah, I mean, we can get into some of the specifics of,

I think there's more dimensions than just easy hard. But we had our specific way that we had battle tested when we were a dev shop for how we build apps. And that way worked great for us, but it didn't necessarily line up with the way other people wanted their code built. So even if they were just going to generate the boilerplate and then run with it, finding sort of a generic, agreed upon way of writing that code, some like convention over configuration battle sort of going on internally,

it was really hard to even like get into their hands, even if they didn't use a tool all the way. So that's, I think, why we sort of shifted ourselves toward more of the non-programmer or even toward the developer. We had a lot of developers using the tool who just were like backend developers and didn't want to spend the time to learn how to do front-end code. But it always was sort of a non-consumption thing. We ended up serving the people who weren't getting stuff built versus the people who were getting stuff built, but in a way that we perceived as inefficient. I see.

So when you said the paradigm was difficult for professional programmers, you meant like they didn't like the paradigm, like the conventions you picked, they wanted to kind of choose their own? Or was there something else you meant by that i i'd say um the way you interpreted it which i'll repeat back to you to make sure i get it right um which is just actually using the visual paradigm um you know dragging things around learning how to use our abstractions i think that was difficult um as well but also just the generated code um there's really like no-size-fits-all way that's agreed upon for building apps the way we were building them. So it was difficult for someone who had spent years building things a certain way to be told, oh, we'll automate this,

we'll make it easier for you, but then all the code is going to come out looking this way. So we ended up spending a lot of time on the source code, and I think if I was doing it again, we probably would have spent very little time on the source code because our end customers ended up being the ones who didn't care at all what it looked like. Interesting. Yeah, that makes a lot of sense. So I'd be curious to hear more about some of those abstractions you mentioned, like the visual metaphors. To me, that's what gets me excited about these products. Yeah, totally.

So I'd say the hardest abstractions to build and the ones I haven't seen anyone do right, including us, is sort of the imperative code. So when you have a set of operations that need to happen sequentially, like go send this person an email, reach out to this service and pull in this information, and do X, Y, you know, go send this person an email, like reach out to this service and pull in this information, um, you know, and do X, Y, Z. Those things were really hard.

And we ended up just having a list of like actions people could do, um, which I think is sort of state of the art. What, um, I think we innovated on a lot was just building a really nice user interface, um, and doing the doing the binding stuff. So you could basically design a UI, put all the fields on it, and then we basically turned an API into UI elements. That was sort of our abstraction.

So you could drag things out of your API, real data, and sort of drop it on top of elements on the page. So that fusion of like API and visual design, I think is the one, you know, abstraction we really innovated on. And the rest I think is pretty similar to like your average visual editor

with properties and colors and drag and drop and, you know, handles to resize things. So I'd say those are sort of the three areas and the one with the most innovation was definitely in connecting that API to the UI elements. And I guess to go in the other direction, what about the product most embarrasses you to look back on?

Well, there's definitely things that aren't in it anymore that embarrass me. I think that, you know, along the way, we really were trying to differentiate the technology. So we spent a lot of time, like I said, making the source code really easy to read, just a ton of time doing that. And in reality, that didn't really matter to the customers who ended up liking our system, but we were sort of too far in to change that. And the other thing, which I think I probably would have done differently if I was building it again, is to rely on a runtime instead of generated code. To contrast, that's sort of what Bubble does. Like they have a configuration object that's just some giant, I think, JSON blob. And then they pump that into their runtime, which then renders everything. We ended up having a runtime, which was our website, we'd had a runtime, which was the iOS apps, we had a runtime, which was the Android

apps running on those native operating systems. And then we had sort of a previewing runtime where we had to sort of show what it might look like on those other devices. So we ended up like combining all of these different runtimes together and it just inordinately increased the complexity of what we were trying to build. So technically that's probably the biggest embarrassment in the product. And so if you were to do it over again, I'm not exactly sure what you're saying you would do differently. You would somehow make it like a more unified experience. Well, rather than doing, yeah, so I, I wasn't specific, but I was hoping to imply it rather than doing native iOS and native Android,

I'd probably build it on either like a web runtime or some sort of like react native combo. I see. So, okay. So you build like a intermediate layer of abstraction and then you'd have like a runtime that works everywhere the same. Cause I guess it's like you could build a JavaScript runtime and then run it

on both Android and iOS. Yeah, that's kind of the idea. Yeah, I mean, I think it probably like increased the complexity by like 4x, if not more. It was probably exponential. It was probably like more x to the fourth just to have all those different runtimes playing together. So that's definitely something that, you know we we did it that way because we thought programmers were going to be our market and as we sort of shifted uh further from programmers that was just sort of an artifact that was left in the product got it got it yeah that that makes

a lot of sense why yeah that would kind of just yeah stick with you and kind of be like a nagging a nagging like technical debt kind of thing. Yeah. For, for anyone trying to build a tool like this, um, I think that one thing I learned just from that technical part of it is to, um, keep it as simple as possible. Um, you know, whatever you're using to present the, uh, the, the design and develop layer to people, make sure like, that's the same thing that's driving the, um, the, the actual code on the

person's phone. Like we had to have one of our employees reverse engineer part of Xcode so we could render, um, custom UI components without having to have people sort of write a web version of that and um you know it's just those sorts of like back and forths which made um which made things very difficult yeah this conversation is reminding me a bit of the uh the company the company expo they're they're like it's a react native there's some drag and drop you can you can preview what it looks like right on your on your phone it. It sounds like it's similar. It might be more similar to the approach you maybe would take if you were to do it over again. Yeah, no, I've,

I've been following them for the last couple months. I remember seeing someone wrote, I think there was like a product hunt about their beautiful new website, which actually is very beautiful. And I got back into them back interested in their product again, but I think it's a really cool approach. And some of this stuff like React Native wasn't around when we started, but I think if it had been, you know, you may have found yourself sort of going down this road pretty, pretty easily, it would just been the more natural thing to do. But that's what makes all these tools really hard is it's just a staying power. Like if you have a really complicated abstraction, you've built on top of another really complicated abstraction, and then people move away from that one towards another one, you're sort of like stuck like with the bottom pulled out from under you.

So I think it still remains to be seen how much of any of these tools have staying power as market shift. And like, we haven't gone from like an iPhone to an after iPhone yet, but you know, even without a big change like that, I mean, I remember we went from objective C just in my lifetime,

objective C to Swift to, you know, now all the iPhone screens aren't the same size to being able to rotate the iphone remember you couldn't do that and like all of these abstractions just like change over time and those are just really simple examples of it but that just makes building something on top of it really really difficult to do in the long run. Yeah, that's a good point. You know, it's like the longer you spend in tech, I think it seems like it's accelerating the switch

from like JavaScript framework to JavaScript framework while at the same time, yeah, the underlying technologies are changing, like Objective-C to Swift. I don't know about the Android ecosystem. Is that also changing rapidly too, or is it more stable? If anything, it was more unstable because you had hundreds of devices. Android update cycles tended to pack a lot more into each release.

So I remember when, you know, just at my time at Dropsource, we had to weather Objective-C to Swift. We had to weather material design becoming a thing like two months before we're going to ship our other product. Like I remember this ritual we had and we'd watch on the big television all of the announcements for like iOS updates or Android updates. And literally it was like, what's our work going to be for the next six months? Are they going to change anything? That's like so big that if we don't support it, we're going to be left behind.

And I think that's something that's just really hard if you're doing a tool set like this. It's just hard to do. And even big companies like Xamarin, you know, with all the resources they had, had trouble keeping up with that, all those shifts across all the different runtimes. And the only thing that made it tolerable for them

is that everything ran on the mono runtime and then the native stuff was just for the presentation layer. So it was a much smaller, more confined set of features that would change. But yeah, that's just a huge challenge in this space, like in general when you're building these tools. Yeah, that is crazy. I'm trying to think how that compares with web,

because on the web, we switch technologies up, like frameworks, like Angular came and went and now React and Vue and all the new ones. So that moves quickly. But then the actual standards like JavaScript and HTML and CSS, those seem to change slowly and it's more community driven. It's more like open. It's not like they just like announce changes. Like they give us a lot of warning too.

So yeah, is your impression that it's less i guess frustrating to build to compile like your compile target being web-based versus proprietary android or iphone yeah i mean i think it almost has to be like if you're going to build a tool like this seriously um and i thought a lot about the economics of this and i've talked to people um you know at events and who work in these, in these companies at a high level, designing the features that go into each release. Um,

and it's economics really. I mean, the, the reason why, uh, you know, iOS is releasing all of these research, you know,

they had the science kit a couple of years ago, uh, the health kit, like all these different frameworks. And the reason why, you know, they're, they're racing to add all these features is because they're in competition with Google. The web, you know, has the, you know, the consortium, which is setting the standards,

and that can move a whole lot slower. And it's frustrating that it moves slower. I mean, it's one of the reasons why people, you know, want native apps is because the web can't do everything that native apps can do. But you have this interesting trade off where the web is stable for longer, which is good, if you're building, you know, a tool set on top of it. And these other, you know, proprietary systems are racing to get ahead of each other. And they've got, you know, orders of magnitude, more resources to make things bigger and different and better, and I know that's not a word but I'm using it anyway as a joke, than you're going to ever be able to do to keep up.

So I'd be curious to know how DropSource is doing now. I know you've left, but I'm curious to know if you have any, are you excited about where it's headed? Are there customers who are using it to success? I'd be curious to get the update. Yeah, no, I think we're growing faster than we ever have been, which is really good. And I don't think I, looking back at it,

I don't think I would have left if I thought it was going to kill the company. So I was able to hire a good person and make sure that the right team was in place as I was transitioning out. But there's enterprise clients, there's, you know, individual clients, you know, there's, there's hundreds of apps that have been built. And it's exciting just to see, you know, actual people using the stuff that we spent so long building. Um, so I think that that's all, all stuff that I'm

optimistic about. Um, for me, just like, I don't know, we can talk a lot about what I learned, but it just, there's stuff that, um, I, I would really want to change if I could. Um, and then there's stuff that I learned that, you know, I wouldn't, I wouldn't give up the difficult experiences of learning them because they're informing everything I'm doing now. So you always sort of look back at things with that, those two lenses. Yeah, great. I think that's a wonderful way to transition into how your experiences at Dropsource informed the formation of Optic and how you're thinking about that?

Yeah, so the first thing I'll say is just sort of in terms of what I learned, it's important to sort of go over these first because they inform how I've gone about building the new thing. But I picked up on the fact that experience is much more important than output. I think a lot of the times when people are talking about, you know, programming languages or visual tools or anything like that, they tend to focus on like what you can build with it. And I think that that's kind of misguided. I think experience is much more important. And it's not really given as much

attention as it needs to be. So like, to give you a really dumb analogy, like you can hammer a nail into the wall using your fist, but it's not going to be very effective, and you're going to hurt yourself. But like, you still got the nail into the wall. And I think just like, really focusing on that developer experience is something that I just take really seriously now. Over, you're saying that you prioritize that over what is possible to build. Yeah, exactly. So like it's fine to have a more limited set of features as long as like you're specifically selling to people

in a niche who want those features. But like you shouldn't sacrifice experience to get more complicated outputs. I think that's definitely counterintuitive because you think that if you're someone who's using a tool that you've made that makes it easier to program things and it's a wonderful experience, I guess, an example would be like Squarespace. It's like, you know, it could be a beautiful experience, but it's limited in what you can make. Like when you'd be worried that they'd like bounce

or never even start using it because it's not powerful enough for them. Well, I think it's, well, the first thing I'll say is I think it's a losing game to go after like full coverage of all the things that you could possibly do in programming um because abstractions on top of abstractions are really hard to maintain like we were just talking about um so i think it's much better and sort of much more immediately actionable to focus on that experience make it really good at certain things

and just like be open about where your box is. Like Squarespace, yeah, a lot of people don't use it because they can't do everything. But they also, last I heard, are $100 million a year company. So they obviously have enough people who fall into those use cases that they're able to be successful. So just figuring out exactly where your domain of applicability is going to be is a really important thing. And if you don't have that conversation early on, you end up just trying to build everything and it's a shitty experience and you just alienate people. And I've seen like so many companies I've been involved with or,

you know, through advising or as possible partners just who have run into that trap of trying to make too much possible. And it's just sort of this false promise that like, yes, if we get these two more features, people will start using our product. And it's almost never those two more features. So, okay. I think this is, this brings up, yeah, like a debate I've had with myself and others for as long as I've been doing this work. I don't, I think there's probably a better word for it, but I call it like Turing in quotes, Turing completeness.

If you build a programming language that can like kind of do anything that other programming languages can do, like, you know, equivalent, an equivalent language. And so some people think that programming can be made better in like a Turing complete way. Like,

you know, in the way that people don't really program in assembly anymore because we have languages that are just as powerful but easier to use. The idea is that one day we'll make a jump to another general purpose language. That means we'll never have to use Python again, for example. But I think other people see it kind of more in a piecemeal way um like the analogy i have in my head is that some people say the only way craigslist is going to die is by like startups like airbnb like just like taking one use case and making a better interface for it so there's not gonna be a better craigslist they're just gonna like slowly pieces of craigslist are gonna get sloughed off and so i want it sounds like you're kind of thinking that um the same will happen

in programming like different different use cases will be sloughed off one by one uh until kind of there's nothing left yeah i think um i hate buckets but if you were to put me in a bucket it would probably be the second bucket um and i think it the the reasons behind that are um i've just seen it so many times, not just in programming, but in all sorts of products. If you focus on something, you do it really well, and you optimize for that at the expense of all the other things, you can make a world-class experience. If you try to optimize for everything, you're necessarily going to make something's better

for some people, something's worse for others. It's like having a, you know, imagine like a party and there's like an 18-year-old constituency and like a 50-year-old constituency of people who want to come to the party. If you invite more 18-year-olds, you make it better for the 18-year-olds and that necessarily makes it worse for the 50-year-olds and vice versa. So like you just, there's always going to be these trade-offs when you optimize for one group. And I think that that's why I think it's sort of like all products,

like in all categories are going to move toward these like piecemeal things that AI and automatic discovery and sort of like seamless semantic web kind of connections between applications will make the will make it sort of just easy for that to be the reality i think right now why things aren't so segmented is because discovery is expensive moving your data between things is expensive and i think once those walls sort of fall down you're going to see all products end up being very niche products interesting yeah i'd be curious to hear more about that. Like how do you think, because, you know, to me,

and I think a lot of people that like problem with ETL and data being stored in entirely different formats and warehouses, like that seems like kind of a big fundamental problem. How do you think AI or other, other improvements will help make apps more easily able to communicate with each other? Well, I think it starts with understanding

what the apps do. And, you know, there's a common theme in some of these things that I've learned, which is that they all sort of lead toward Optic. But, you know, Optic's able to read, you know, your code base, figure out all the routes, figure out how everything routes, figure out

how everything fits together from the networking standpoint. And, you know, adding some fuzzy logic with some kind of AI on top of that. It's not a large jump to be able to, you know, say, order me a car to like an Alexa or something, and have it be able to talk to the four providers, figure out which one's cheapest and which one's going to get you there when you need to get there. And then just like delivering you that. And maybe this idea of like an Uber or Lyft being separate brands and being things that we, you know, know the words for can kind of go away. So I think that, you know, things are going to, as we're able to sort of map software together and have systems automatically talk to one another

without being explicitly programmed to do so, that's when sort of these microservices in the real world will come into being. Okay, cool. Yeah, that sounds a lot like what Brett talks about in his future programming talk about where he makes fun of how we have to like, you know, manually write APIs. Yeah.

Yeah. So I, I can't take full credit for those ideas. That was Igor. And I always butcher his last name. But his company, Yap was acquired by Amazon and their team became Amazon Alexa. And so he's been working on this stuff for like

a decade. And we were on a bullet train in China last year for a couple hours. And he just like unloaded that very complimentary to how I see the world vision onto me. But like, he goes even further and says that like brands aren't even going to be a thing in a couple of years. I don't know if i agree like with that direction but i i see all the steps leading up to something where brands would be less relevant yeah well i guess that's makes sense he's working on amazon because you know that's kind of the idea you just look at um the the how many stars a product has and and you just buy whatever that is brands definitely are more relevant on on amazon you know i'm a big fan of buying things on amazon

just based on reviews yeah definitely and like why why make someone go through that process um i think the same is going to be true for programming too like why go through the process of like figuring out which api is the best to use for credit card transactions when i just like say process credit card have optic look at some of the documentation and just like plop the one in the right language that uses the right framework into your project so i think like this on-demand um sort of automatic resolution of different products is going to affect programming as well as just like general commerce. All right. Yeah. Here, I want to go into that. A few questions first. The first one that I can't resist asking is how did you end up on a bullet train with this guy? It can't be a coincidence, right? Yeah. It was a trip that we all took to sort of and it was like a an international relations like u.s

entrepreneurs get to meet chinese entrepreneurs and government officials trip um and we just ended up sitting on the bullet train next to each other so we had we went on the whole trip together but um we we struck up a good conversation on the train. Cool. Okay. And then the other question I was going to ask is that before we go too much into optic, I wanted to ask about, you know, that, that in between time between a drop source and optic.

And I wanted to hear if you considered maybe working for someone else or moving into a different field before, you know, diving back into the developer tools, programming, future programming world? Yeah, so it was definitely a strange time for me. When I left, I wasn't quite sure what I was going to do. All I knew is that I really thought that there was something,

and I didn't know what it was at the time, that I could do that would really help me realize that original vision of helping developers work more efficiently that went beyond just building visual tools. But I wanted to sort of falsify it. So I tried a bunch of different ideas. I traveled a lot. And I played with different ideas. I just never found the same level of passion as I did for tool building.

So I started looking at sort of ways to use AI and tool building. And I had some cool ideas for like, making physical products easier to develop. But they all had such a high implementation cost, that it seemed like, why not just automate software, because it's something that I already know how to automate. And it's basically free to produce more units of software. But yeah, I spent a lot of time trying to falsify it. And I found that I genuinely do love this space. So I got back into it. Sounds like a good reason to come back. So some of the words you use to describe Optic are buzzwordy and a little bit, I don't know, like they're not vague words, but I think everyone has kind of different ideas in their heads about, you know, what semantic and AI even mean.

So I'd be curious if you could be a little bit more concrete, even kind of like to the point of being silly, just walk through the different pieces of how Optic works. Or like, you know, in like, not the technology, like you don't need to give us any secrets, more just from the perspective of a developer. Like to give you an example, if I were a developer and I wanted to process a credit card, it seems like something that I actually need to do, like read the documentation, figure out which one's best. It doesn't seem like something a computer could do. So I'd be curious if you could kind of step through that a little bit more. Yeah, absolutely. So to go from long-term vision to very specific, actionable, what this can do today, we've actually pivoted recently after doing a lot of customer interviews towards a focus on 20 to 50-person development teams. And when you're that big as a development team, conventions and standard ways of doing things become really important.

So basically, Optic allows you to describe how you would code something. And it taps right into Markdown. So there's these special invisible annotations you can use above your example code. So Optic can look at that and learn it. But you basically just write documentation that's now human and machine readable. And Optic will turn that into code generators and static analyzers.

So when you're typing something and you guys say you have a specific way that you'd like to load information into a table, like a list of information, you could type in whatever you've called that right in your IDE. The autocomplete will catch it and recognize that Optic has a code generator for that. You click enter. Sometimes there's questions that you have to answer one or two, but usually there isn't

because it can infer sort of what structure it needs to use based on other objects that's like tracking in your code. And then you can just generate that right into your project. So that's what the sort of generators do. And then on the enforcement side, linters are very primitive today. Like they're able to tell you, you know, when you have spaces wrong or when you're using like the wrong syntax somewhere, but they don't tell you about whether you're following

convention. So we've had a lot of customers ask us to sort of apply the technology to doing something kind of like HoundCI where when you check out, sorry, when you check in code, it can tell you sort of, have you followed the convention? If not, here's like the documents you should read about how to do that. And then you can even have it set up to like block certain violations from ending up in the master code base. So sort of like those two things were, you know, building sort of a la carte code generators that, that fit right into your development process and do very complicated, you know, non code generator like things. And then we have this enforcement piece where you're able to make sure that people are following whatever set conventions your company wants to abide by.

Got it. Okay. So yeah, let's talk more about those. So the first one sounds a bit like macros or like Emacs macros kind of things. Is that kind of how you think about it or it's bigger than that? I think it's similar to macros. I think that's a really good analogy to describe what it's doing. But I think the difference is that, like I was saying, most of the information comes from within your code. So like if you wanted to generate CRUD routes,

you can just tell it, oh, you know, here's this model I defined in this other file. Use the information from that model to decide how to write the route in the query. So like a lot of it is basically just doing implicit conversions between one source of truth in your code and something that you're trying to have it generate. So when you said, when you pointed out a model in a different file,

is that something that you have to, is that like a, you could actually just tell it to base it off of code you've written before that actually runs, or is it like an optic file that you have to configure? It's just based off of code you've written before that actually runs or is or is it like an optic file that you have to like configure it's just based off of other codes so what's really cool is when you define sort of code in the in the markdown sdk um you do it in what we call lenses which basically can generate code and it can also read that same code out um so it turns you know code code editing is very dirty today.

Like you do it with like raw strings and that's how generation for pretty much every application works. This basically does it at the ass level, the syntax tree, and it allows you to both read the code and write the code. So we can say like,

oh, here's this model that's been configured. You know, it's got these five fields. Now let's create a route that creates an instance of that. And it's able to sort of pass that information along to the definition of how to use ExpressJS, the definition of how to run a query in like Mongo or MySQL or whatever one you're using. So I'm hoping that, you know, as people start to learn more about Optic, all the developer docs start to use our Markdown SDK so that Optic can both work with and generate code that's written for all these different frameworks.

So right now you've kind of picked like one framework to go with and you can generate code for that one. Is that what I'm hearing? Like you just work with Express, you've kind of picked one framework to go with, and you can generate code for that one. Is that what I'm hearing? You just work with Express. You don't also work with Rails. So there's this component to Optic. First of all, thank you for asking me all these questions because we're just launching,

and I'm still learning how to talk about it. So these are really helpful to hear sort of where your head goes first. But we have a package manager, and you can basically include different styles. So maybe there's a Steve version of Redux, like the way you like to do Redux. Or maybe there's a Facebook-sanctioned way of using React. And you can just import these things into an there's like an optic.yaml file in your root directory. And then optic just looks at what you put in there and uses those things

to generate the code and enforce the conventions. So you can basically choose the standards you want to follow. And they're generalized enough that you can pipe them together in really interesting ways. So like all the different definitions for an API library, like whether it's Express or something else, they can all sort of rely on the same schema for what a REST route should look like. And then it makes it interoperable. So you're able to do a lot of really interesting things like connecting different parts of your code, even if they're using different frameworks. So we're trying to make it general purpose by allowing you to sort of construct these things as your team sees fit for whatever you're trying to build.

Okay, I'm starting to get it. Yeah, this might not be something that is helpful or even doable, but it feels like what might help me is if we go like really concrete, if you could just pick an example of a use case that you've kind of like built out or seeing a customer, like a beta tester use, and just like kind of go like, even just like line by line, like, you know, what you want to do is this. And so you like open a file and you, you know, like do is this, and so you open a file. If you could just go really walk us through a use case, even just one, I think that would help me get a sense of what it could do. Yeah, so one customer that we've been working with in the early stages has this whole new way that they want to use

react. They brought in all these developers who were all sort of had their own style and their code base is sort of like a little bit of this, a little bit of that. So they had this new standard that they set up. They actually wrote documentation for it. And some of the things that were really big in there was like automatically connecting a, a store to a component and bringing in the proper state that you want.

So like in optic, you might be able to type in like connect to store in a component file. It would pop up and say, which store you can say, you know, the user store or the event store or whatever. And then it, it knows all the different properties within that store because it's reading the code. And you can say, okay, I want to checkbox these three, you hit okay. And now your code

will be linked up to that reducer. And does the state to prop thing is set up properly so that those states get injected into the, into the component at runtime. So just like stuff like that, where there's like five or six different ways you can do it and only one right way, this can sort of help enforce that singular convention for the developer. Okay. Yeah. It's starting to make a little bit more concrete sense to me that, that I get that. So now I'm curious on the reading the code side, um, there's like a, you know, you know, it's, um, even though you were looking at the AST code can be written in a lot of different ways. So like, let's say, oh, you know, a store is written, like, are you actually like, how are you

exactly parsing the properties of a store? Are you like running the code and then inspecting the actual object? Or are you statically analyzing the code in some way? And then statically analyzing it, how, how are you making sure that you're getting like, you know, what if someone does some weird hacky way to assign a property? Like, how are you making sure to get're getting like you know what if someone does some weird hacky way to assign a property like how are you making sure to get those things that you know are hard to get unless you like evaluate the code yeah that's a really good question so right now we're sticking to static analysis and we're sort of betting in the beginning that part of you know helping mid-sized teams enforce their conventions is that we're going to hopefully be moving away from some of the hacky stuff

and things in the code will be more explicit. We haven't had too many problems with that where we've felt like we've had to evaluate the code. But I definitely can see things going that way as this gets more and more open and we have many more developers and many more frameworks that people are trying to use. A lot of frameworks today have been designed to sort of hide a lot of stuff away.

And I think that's a consequence of sort of the old way of trying to improve programming, which is just building more and more abstractions. And what we've done is we're sort of betting on, the hard thing isn't learning the abstractions now, it's learning how to connect them all together. And I think that's where a lot of developers spin their wheels. So we're hoping that, you know, we're able to get everything we need to out of the code

and that maybe some of the frameworks become explicit enough that they're easier to work with if it ever becomes a problem. I can't help but think that types is a relevant conversation here. Maybe the reason that this product feels more necessary for working with Node and JavaScript apps is because there are no types to help give you these hints. And so I'd be curious to like hear if you think like are you using typey kind of stuff to do this or you're not you don't feel like uh like haskell is like relevant to all this project i think it's i think

it's definitely important what um what we're sort of doing is there's the type in the code, and obviously that's not in the dynamic languages. But we also sort of assign types that aren't even there. So if we see var name equals require path to something, that gets labeled in our system as an import statement. And it's an import statement with a path to and a defined as value, which doesn't exist anywhere in the real ask. So we're almost building these other abstractions on top of it that make it easier to work with. So in that way, the types have been important, but we're just doing much larger operations than like specific lines and specific types are concerning to us.

It's like generating like, you know, four quad routes around a route. I mean, around a model that someone has or automatically adding, you know, middleware for all zero to every single route or something like that. So it tends to be just like bigger operations that specific types or specific fields aren't as relevant. Got it. Okay. And another thing that I was thinking about is if you're generating code, like in your files, I would worry that I generate code in such a way like I make typos. The user's cursor is in the wrong place and the code is improperly formatted or we write the code inside of a function that we didn't mean to. Is the way you get around those sorts of errors that you're like editing the code in the AST and then, and then just hitting compile or like,

is there another like clever way you get around making code generation errors? Yeah. So that, I mean, that's a part of the open source work we're going to be publishing in the next couple of weeks is this thing we've built two things, one called SourceGear and the other called Marvin. And SourceGear is sort of like this Swiss Army knife for manipulating source code.

And basically what it does is it turns sections of code. This is sort of what you pump your markdown into so it's able to read your code. But it'll turn a section of code into sort of a summary of that code is the best way to describe it. So it looks at, you know, the code for a route and it says, okay, here's the URL, here's the method, here's all the parameters, here are the response types. And it just does that based on pulling it out of your source code. And then you can edit that high level model like that

JSON, post it back to Optic using our API, and it'll end up changing the underlying code until it matches that new summary. So all that's happening in milliseconds really quickly beneath the surface. But we try to abstract away all the complicated formatting when people are actually editing the models, and then when they get injected back into the source code, we use this machine learning stuff we've done to um try to match as closely as we can your exact formatting for your

code base yeah wow sounds sounds complicated and sounds messy um yeah i'd be i'm curious to try it out and see um how that works because i think one of the things that I like for my tools is predictability, even if it's harder to do something. And throwing machine learning into a tool that I'm using every day feels scary. Who knows if it's going to get it right? Yeah, no, that's a very valid concern. We do test the models before we ship them pretty thoroughly and the good news is like there's there's not much um like left up to

question when it comes to source code formatting there's like very established rules about like how many spaces to put between like a closing parentheses and an opening bracket and stuff like that um it's just really tedious to write all those things down by hand so um marvin which is our our source code learner um it will look through thousands of files figure out the common conventions figure out which ones are most popular based on all the different node types and how they fit together um but the output is rules. It's not just a stochastic model. Like, we actually will generate a real set of rules that can go into the engine.

So in that way, it remains predictable. Like, it's not going to write one kind of code one time and one kind another. You can then edit the rules. Like, it discovers them for you, so you don't have to, like, edit them all by hand, but then you can override what it finds. Exactly.

So we try to give people control over that because we know it's something that matters a lot to people. And then let's say I'm using Optic, I'm working on some code, but there's a section of code that I format in a way that doesn't meet with my conventions because of whatever I'm trying to express on that line, is there a way to say like, don't touch this, don't, don't reformat this or, you know, like that's not possible.

Yeah. So, so right now Optic will only, it doesn't like regenerate a whole file. It only edits the parts of the file that are relevant to change. So if you, if you touch that kind of code with Optic, it would probably write it the way that it thinks you want it to write it. But if you change something else in the file using Optic, it's not going to regenerate your code there too.

So what we're really trying to do, and this is another thing I sort of learned from my past experience working with developers and these tooling, is that everyone loves automation in certain small places, but what they don't like is being, you know, trapped in this giant abstraction that controls everything for them.

So optic is really supposed to help you automate the things that you want it to automate. And then just like stay the heck out of the way for everything that you want to do by hand. So we don't touch those things. We don't interact with them. If you have a file that, you know, our system doesn't ever read or interact with, it's always going to be there and it's never going to get changed. Yeah, cool. Yeah, that definitely sounds like what people want. But then is like the secret, like long-term vision or not

so secret long-term vision, because I imagine you'll tell me is that like one day you won't have to write code. You can just edit this markdown. You could, you know, be more abstract and then, you know, you, you take care of it behind the scenes. I mean, not, not particularly, actually, I think what, you know, you asked me to sort of get really concrete early on, and I'll go a little more my signup backend, like, being able to say things like that, and have it, you know, pop up a second later with, hey, here's the code, I think I should write is this okay, you hit okay, or accept or whatever, writes the code for you,

you test it, and it works, or maybe there's one little bug, and you fix it by hand. So I see it more as an assistant than a complete replacement. To our earlier conversation about micro-editors and making individual abstractions that are really good at one thing, I can see Optic basically becoming this common framework that people use to build programming experiences on top of. So maybe someone makes a really good visual editor for like a iOS app or an Android app that can pop up.

They can change things in their editor, hit save, and then optic will help them generate the code into the project that does that thing. So maybe that person is a developer, maybe they're a designer, maybe they're you know, maybe they're, you know, they're a kid who's, you know, helping dad out with the project. But I think that,

you know, that's sort of where the non-developer people play in is, is sort of, you know, using the micro editors and then having code generated back into the main system as a result. Yeah. Yeah.

That's very interesting. I think I don't exactly i can't exactly connect these dots but i hope maybe you can for me um this sounds very similar to how if you were to read rebuild drop source from scratch it sounds similar to to how you do that in some way is that like can you help me connect those dots yeah i mean i think the it might be the um sorry to me um yeah it's like articulate why i feel like these dots can be connected because maybe they can't it sounds like uh do you think that optic is providing this like that representation runtime layer that was like so hard to maintain in um you know four different ones when you're working at DropSource.

But now if Optic existed when you were making DropSource, you could have somehow integrated with it and then that would have been easier or am I misreading it? No, that's so that your head's going to the right place. It is a runtime in a sense, but I see it more as sort of a tool that enables people to build software automation. When you really think about objectively all the code generators that exist, they're usually run over the command line and they'll generate whole files and that's it. But like, wouldn't it be cool if like, you know, something like parse or Firebase had a visual editor that let you manipulate the models in your code and the

different actions and routes you wanted to have available. And you could just like open that from your code base, change the things on their website, hit save, and then have code generated into your project and always be able to go back and forth between those two representations. So I don't see that as much as a runtime as an enabler for a next generation of programming tool that combines whatever the right abstraction is with the code.

So the code always is a source of truth. There's never any hidden information, but it just makes the code editing easier. And that might even be like some of the stuff that we love. You and I have talked about this offline, some of Chris Granger's stuff and Brett Victor's stuff where you have like really good algorithm flow diagrams that like pop up as you're writing the code.

Some of that stuff I think could be like accessible through Optic too. And I think that's sort of my, my new revised vision for the future of programming, which is it's just a lot of different micro editors and really niche abstractions combined together on the same code base. Yeah. Yeah. It's fascinating. I think it sounds like you really learned, well, I don't know about really learned, but you're making damn sure that you're building a tool for programmers this time. I think you were a little bit bummed that, I think you really wanted to make a tool for developers the last time, and you maybe jumped a level of abstraction too high. But this time you're like, no, no, no, like programmers write code and we're going to make it easier to write code.

Yeah, absolutely. I mean, that, that is, you know, we've gotten really deep into sort of the mechanics of how some of this stuff works. And, but like, that is the like marketing tagline, which is, you know, we're making it easier for developers to write code. That's what we want to do. And there's so many things like when you're writing code that that can and should be automated that we end up doing manually um so like that that's exactly what we're looking for um yeah it's like

fewer like coding with fewer keystrokes exactly coding with fewer keystrokes and um you know connecting all these dots being able to do like like autocomplete that can actually read your code and know all the pieces of and how they work is super powerful. And that's a big part of what we're able to deliver to people. Cool. Yeah. OK, I think I get the vision. So then the second part where you talked about you described as similar to another service that I hadn't heard of before that like prevents you from committing things that are against the guidelines that that sounds related, but they sound a little bit different. So I'd be curious to know, you know, which one you're working on first, or which one's the focus or you kind of see them together? Yeah, so I think the, you know, the ability to read the code,

which is a big technical innovation that we've been able to do with Optic, lends itself really well to the other sort of static analysis, which is checking, linting code and checking for conventions that are followed or not followed. So with a lot of the midsize teams we've been talking to, that's something that's just been super important. They're like, this is great. It can help us automate all of these different things that we do all the time. But we also want to make sure that we can see what part of our code doesn't follow our conventions and also prevent people from checking in code, new code that that isn't written the correct way. So it's something that sort of emerged naturally, and that we have sort of a implicit capability of doing with the technology.

But for the customer segment, we sort of pivoted to in the beginning. It's one of those like must have things that they all really want. Got it. OK, so it sounds like it's like the first clear use case of the technology and then you'll expand kind of beyond that. Yeah, I mean, all of this is on a multi-year long scale um so i've been self-funding it and um there's obviously limits to what you can do on a self-funding budget a big reason why we're going after this established need and this demand that has been sort of creeping up and actually coming to us for enforcing conventions and automating sort of repetitive work is because there's a business model there that can help us sort of get to the bigger vision.

And I've sort of evolved in my thinking about companies. And I follow this sort of like oasis theory that one of my mentors shared with me. When you're crossing the desert, you don't just go from one side to the other. You have to figure out the path between all the oases along the way. And like, this is one of those oases that we're trying to get to first. Hmm. Interesting. So I think this brings up a question of fundraising. I know that for your last company, you raised a few million dollars. So I'd be curious to know if that was a positive experience that you'd want to do again here, or maybe it kind of sounds like you're thinking about being more sustainable and generating revenue to fund the company. I mean, we could talk about the perils of fundraising and the benefits for a long time.

I don't want to do it for two reasons. One, I don't think it's moral to do it too early. And I think we did it too early last time. But I also think it's really bad for your business because it changes sort of the incentives, like things become about getting to the next round and not about helping the customer. And I think some very disciplined entrepreneurs are able to cut through that.

But I know first time around, and also we didn't have institutional investors in our company, which didn't help. But it makes it very difficult, I think, to build the right product for the right people. You know, and all the promises you make, even if you realize that, like, you need to pivot away from that, it's really hard to pivot once you've made the promises. So there's just a lot of extra challenges. And I think that the more enlightened way of building a company is to get to that value point first, and then raise money at that point. So I could see myself raising in, you know, a year year or two or maybe three years,

but I want to really get through the do or die stuff first. Is this going to work? Are there customers who need it? Is it a valuable thing for the ecosystem? And really to have definitive, really strong yes answers to all those questions before I ask for other people's money. It sounds like you're looking to reach product market fit before you scale something that's not worth scaling. Is that how you'd put it? Yeah, no, that's the, that's the terse way of saying what I just said. How far away are you from like, because in order to find product market fit, you have to have customers. So I'm curious how far away you are from like your first sale. Or, you know, obviously this is something

that's speculative, but I'd be curious if you think it's a year away, six months away, tomorrow. Yeah, we're in very late stage conversations with two companies right now. I think that there'll probably be a sale, you know, sometime in February. It's like the right level of optimism. I'm pretty comfortable saying at least one of those will go through. And then it's just going to be a lot of learning and a lot of, you know, working with

these companies, seeing if we can help them and just making Optic smarter and smarter and smarter to the point where it'll be something that we want to, you know, give out in mass to individual developers too. Yeah, it definitely sounds like a product for teams, but I guess the reason why individual developers couldn't find some of these features useful. I think once we have like standards, like there's a,

like once there's a community package for how to use react and how to use express and you know, how to use, um, like AF networking and Swift. Um, once there's like a, a good coverage of like common problems, um, that's when it's going to become more useful for individual developers. Yeah. I really love your optimism, uh, and confidence. I think it's like, it's infectious. You, you, uh, You believe in yourself, which is wonderful. On the other side of it, if you had to guess, I guess there are two ways to ask this question.

One is the specific vision you have for the product now. If two months from now you pivot it again, why would you guess that is? What about this iteration of the product do you think is the most risky assumption? Yeah, right now, so the number one assumption we have, and part of the reason why we're going after larger companies in the beginning who have these very strong problems, and they can express the demand in a way that lines up

with our value proposition. But the thing we've really iterated on the most over the last couple months is the input. So how do you define in that markdown, the way that code should be written, and it's not difficult, but it also like, there's a small learning curve. And it might be considered tedious for some people to go through and define how they want their code to be written before actually writing it. I think it's a really good exercise to go through on any team to figure out as a group, how you want to write your code and what conventions you think you should follow throughout. But just getting teams to do that is going to be a big question mark. And the bigger question mark is going to be whether they'll do it themselves,

or they'll want to pay us to do it. And I could see both being very reasonable in the beginning, but one of those models leads to quick scaling and the other one doesn't. So I think we have to learn a lot about how to make teaching optic your conventions as easy as possible. Yeah, that's interesting. That kind of reminds me of the company Looker that I used to work at. I don't know if you're familiar with Looker at all. I'm not. Yeah. So they're a data analytics platform they they have this modeling layer called look ml that that's actually you know isn't isn't entirely dissimilar from what you're talking about and in order for the product to be useful you have to spend a lot of time writing like explaining how your data is laid out in your

database in this look ml format but in order to make the sale uh Looker has, at this point, maybe 100 sales engineers who write a lot of this LookML for the customers. So then when the salesperson does the demo, they're doing it with the customer's data. Which makes Looker an enterprise sales company as opposed to a SaaS company where you can just sign up with a credit card on your own. So, but, you know, Looker is growing unbelievably quickly. They like, they double or more than double every year. So, but a lot of their growth and the team comes from their growth of the sales team. So, yeah. It warrants a lot to sort of see which which direction

this goes yeah it seems like like what i'm getting at is you can build a big business either way it's just um you know it's a it's a different business depending on yeah on how self-service it is yeah and i think it's something that you know you always move toward that optimal like self-service but there's also value in being the ones to do that in the beginning. So I think we're going to learn a lot through the couple clients we end up doing that for. And long-term, we hope to have a... It'll probably be something you can download even if you're not a team just to try it out. But we're hoping to have a compelling individual version and a version that the community can grasp onto. People can write optic documentation instead of writing tutorials.

And maybe that's a more popular way of using a tutorial is to just import the optic thing into your project. That's the ultimate dream for that individual market. But I think we're going to just learn a lot about how to make it easy to teach it stuff. And the easier it is to teach it stuff hopefully correlates with the easier it is for people to use it and find value and create value for other people in the tool. That's most of my questions. I have a few general questions that I ask everybody. But before I get into that, are there other topics that you want to talk about? Yeah, there's, there's one

thing I meant to ask you, and it didn't quite come up when we're talking about what I learned. But I was interested, you know, how important do you think the actual notation is? I know you've looked at a lot of these tools, you know, some visual, some text, some graph based. Do you think that's where the solutions or the, you know, big advancements in graph based um do you think that's where the the solutions or the you know big advancements in program are going to come from or do you think that they're going to come from somewhere else oh interesting interesting so maybe can you elaborate when you say notation you mean like the syntax or yeah so syntax diagrams uh just the basically the ux or the developer experience of the language like how easy the syntax is,

how easy it is to drag and drop things in a visual environment, just the actions that users take. Yeah, yeah. So I think I follow Brett Vixer and a lot of other UI people here. I think the key word is representation. When you think about like all the leaps that humanity has had in the ability to think, it's always because, or not always, but one story to tell, one narrative is that representation will always lead the way. So the difference between a math problem in English and a math problem in mathematical notation is unsolvable and trivial.

And like another example would be graphics. Like when you think about the scientific revolution and scientific journals, so much of it is communication. Like when one scientist discovers some, one scientist discovers something and then communicate it with others. That's what made the scientific revolution possible. And almost every scientific paper has a data plot. Like where the X axis is time and the Y axis is some variable. And that was invented right before the scientific revolution happened by this William Playfair guy. And he doesn't,

he never gets any credit for making the scientific revolution happen. But you could look at that new medium, that new way of representing the same data we used to have. And now all of a sudden people can get a visual, visceral sense of how the data is laid out because of this new representation. And you can reflect on other things. um like i like i love programming in high school and just the way that the mathematical way to represent ideas in that like compact composable way to me is is really powerful um yeah so like i was reading the um the mythical man month and he was talking about how you, if you think programming is going to be improved by 10 X,

then the claim you're making is that 90% of what programmers do is bullshit. And if you look at what programmers do, it's like hard to like draw a line around the 90% that you think is bullshit. Yeah. But I think where he could be wrong or what he could be overlooking is that like one good representation could be really powerful. If you, if you just,

you know, do it in a, in a composable way. So yeah, basically I like, I follow Brett here when I, and when I say the answer is like media, media is like really powerful and media is all about represent,

representing things so yeah i would tend to agree with that um i think the the reason why i don't think that the notation representation i like your word a lot better than mine um but i think the reason why i've sort of gone soft on that being um, the big area of innovation is just that there's never like people have created stuff, but they never catch on. And I, I don't know if that should distress me and make me think that there's like no innovation there left, or if sort of what it sounds like you, you believe, which is that there is innovation to be had,

that we just don't have it yet. And maybe there's just this perfect representation, like this way I can draw something on a paper and then the machine reads it and it's perfect and we now have this super terse way of writing code. I don't know. But I think that most of the new advances have been really focused on learnability

and they do that at the expense of productivity, and that just makes it really hard to justify adopting anything. And I think that's why we've seen things be mostly static for the last couple decades. Yeah, I definitely think there's a big tradeoff between expressive power and learnability. You could look at... I might have the name wrong, but Alan Kay has this steps project where they're trying to create like a whole computing environment

system and like 20,000 lines of code. And the guy who was tasked with building a graphics engine for this operating system came up with this domain specific language that was unbelievably expressive and he was able to express what's normally expressed in hundreds of thousands of lines of code maybe even millions of lines of code in like um you know a front back piece of paper like just like but and then when i when i i spent you know a few hours trying to make sense of any of what he was trying to say in those lines of code and clearly they work you know the computer can understand them yeah the the lines of code work um i just found it impenetrable um to to understand what those symbols meant um and i guess you know i feel the same way about abstract maths

you know like um brad talks about how uh who was it maxwell's equations maybe um so i the the electromagnetic equations someone came up sent come up came up with these like 20 equations to describe electromagnetism and it like went down to four yeah yes someone else made like a better notation that they made it go down to four i almost feel like the most useful thing and this is kind of yeah this is like in this in the spirit of representation, just being the answer, I almost feel like spending a month of my life trying to understand how that person came up with this new notation and how that notation was able to compress these equations to four. I feel like that could almost be like the most useful way for me to spend a month

understanding how to make programming languages better because, but then at the same time, I like I'm on the other end of it thinking end of it thinking, if I have an engineering company and I'm trying to scale it and make new things, is it, and I want to hire two more engineers, and it takes them a month to learn what any of the code is saying, that doesn't seem to make sense. It seems to make sense to build a learnable language that's less powerful so that new people get up to speed on it. Or you could say, no, if you build a language that's terse and expressive enough and you don't

need to hire any engineers you could just do it all yourself it's it's so uh readable which sounds a bit like how what paul graham talks about with like macros and and creating a language that only you understand that's designed exactly for the problem domain you're working in so you know as you can tell i really go back and forth here yeah it why I want to, it's why I want to get your opinion on it. Cause I know you've been grappling with this for a year plus. Yeah. Yeah. It's, and I think we, you know, what eventually comes to mind is that, um, that quote that I had this wonderful professor in college, uh, who would always say there are no solutions. There are only trade-offs. Oh, I love that.

And so, yeah, so it really depends on what you're optimizing for. And if you're optimizing for, yeah, building a startup or building a tool for kids to play with or hobbies to learn, it really depends, yeah, what you're optimizing for. Yeah. I think the other, so the last part part I'll sort of add to your thought process there. I think that when you take the argument you just made and you add a time axis to it, you end up sort of talking about economics. And to learn something, there's a lot of upfront cost. But all upfront costs are like, as long as they're

in the same like order of magnitude, they're pretty much a wash. So like, if it takes me two months to learn this, like really complicated, like visual tool, and it takes me like, let's say four months to learn how to program, but the visual tool has limits that I'm going to hit in six months and the programming language never does. That upfront cost is basically a wash because the long-term recurring cost of the language or the visual thing being less productive, for instance, or some other abstraction being less productive is a whole lot greater than the other thing. And to use your example of that front and back piece of paper, huge upfront cost.

But if the trade-off is to maintain 100,000 lines of code, now you only have to maintain 200 lines of code. That seems like the right cost equation there. So you have to look at all this stuff like with a time axis too. And to use a non-programming example, like you and I both know English and English is hard to learn compared to other languages, but we put our time in already. And now to decide we're going to finish off the podcast in Spanish would be a really bad decision for both of us. English is a lot harder to learn than some other languages, but you and I have both already put in our time to learn it.

Yeah, we've paid the cost. Yeah, we paid the upfront cost already. So now the recurring cost is marginal for us to keep using this language, even though objectively learning another language might be better if we were learning a new language. We're not. So I think there's always that component to it. ability because you know like yeah it's just it's just one time like why why make it you know instead of you know a year make it happy or instead of a month make you know yeah and i think it's another way to to phrase his argument is um professionals in all industries have professional tools what why should programming be you know so easy and simple that, you know, it's immediately understandable?

You know, because if you do that, you by necessity are sacrificing the power of the tool for professionals. Yeah. So that's probably a good way to sum that up. And the reason why I want to ask you this question is also because I sort of, I went from one into the other, like I started in learnability with the last company. And I think just seeing all that straight, straight, um, you know, all this stuff up close, you know, straight into my eyes. Um, I've definitely settled on productivity being the area that you can have the most impact, not necessarily on new programmers, but like, because everyone's already indoctrinated into the ways of doing things, and they pay that upfront

cost, you'd have to do something like really, really, really, really, really good to get people to change. And I think there's a lot of value you can add to everyone's lives, just by making them much more productive. So that's where sort of my focus is right now. And I'm hoping that over the next couple years, optic can really deliver on that now. And I'm hoping that over the next couple of years, Optic can really deliver on that promise. Yeah, yeah, I like that. That really resonates with me to like understanding what you're up to now. That if your customer is people

who have already paid an upfront cost, there's like no sense in throwing it away. The only way to get them to use your product is to leverage the stuff they already know. And especially with programming, you know, there's value in the legacy. Like a whole thing we haven't even talked about is already solved problems. Like if a language already has a solution for something in a library or framework or as part of the language,

those in my surveying I did last year are much more valuable to people than the notation. Like people value being able to import something to do to solve a problem for them much more than, you know, the block syntax, for instance. Yeah. Yeah. Well, I think this kind of goes to like like rich hickey's distinction between simple versus easy and um you know importing code that already works is easy but it's not necessarily simple because it could just like add a bunch of hairballs to your code but yeah it seems like

people do prefer easy to simple you know like they don't really care how it works as long as it works yeah i um i always bet on human laziness that's sort of my my uh my bias there yeah i think the thing that i'm like beginning to see that i i'm skeptical about with your product is that uh one of the things that frustrated me most with programming is um debugging and like being able to like understand how the code from a macro perspective is working and um yeah and like i i almost worry because you make it so easy to write lots and lots of code that it's just like it's increasing the surface area of where bugs can be um where like if you um helps people write you know you work you made better abstractions that help people write more concise code, it could make it easier to debug. So yeah, yeah, that's definitely something we're

gonna have to test. And I hope that there becomes enough of a necessity because so many people are using this, just like very optimistic, but I hope there's enough of a necessity that people really try to choose and also maintain the abstractions optic uses to generate code because they know that it becomes mission critical so i i have definitely thought about that the warrants still out i just uh i think that we've only ever approached this problem by abstracting and i think that um going at it more as trying to help people connect the abstractions together and generate them and implement them without necessarily having to learn them all themselves is a road that we haven't gone down. And I think that that's where there could be a lot of value.

So this is all an experiment right now. I mean, we're prospecting. We hope to add value in the long run for the customers that we work with in the beginning. But a lot of this is an experiment and, um, we're going to learn things like that and keep our eyes out for, um, for that and all sorts of other issues that I'm sure will arise. Cool. Yeah. Well, good luck to you. Thanks for, uh, thanks for doing the experiment. I, I think either way it goes, uh, as one programmer to another, I appreciate you trying to make, make our lives better. Happy to do it. And goes, uh, as one programmer or another, I appreciate you trying to make, make our lives better.

Happy to do it. And if, um, if anyone listening is interested in collaborating, the, uh, the source code is going up probably by Valentine's day. Uh,

I'm just writing documentation now. So, um, if anyone wants to get involved, uh, we are definitely looking for collaborators. Is this, um,

this like your, your Valentine's day present to all of us programmers? You could frame it like that if you wanted to. I might put it out with something like that. I'm in love with programmers. Here you go. Yep. And I'll make a T-shirt or something too.

Great. And are you interested in, yeah,. Are you interested in yeah. Like I guess it may be, I guess you're probably not hiring yet or looking for co-founders or beta testers, but I just want to give you the space to ask for those sorts of things if you are. Yeah. We're looking for beta test companies who want to work with us in the beginning. Like I said,

it's going to be a lot of hands-on us learning about your problems and, you know, deploying our tool to solve them so if you have a mid-sized development company and want us to work with you we're happy to do that if you're an individual who just wants to play around with stuff feel free to go to our website and get in touch with us

our website is opticdev.com and it's spelled the way it sounds opticdev.com and it's spelled the way it sounds opticdev.com or you can reach us on Twitter at opticdev or my personal Twitter at Aiden D. Kniff

and we'll set you up either with a test account or if you want to collaborate we can chat about the source code and what we're working on in depth but I'm looking forward to running the experiment learning a lot and hopefully helping a lot of people we can, you know, chat about the source code and what we're working on, uh, in depth, but, uh, I'm looking forward to running the experiment, learning a lot and, uh, hopefully helping a lot of people along the way. Cool. Anyways. Thanks. Thanks Aiden for your time. I, uh, I'm excited

to check in and see how things go shortly. Awesome. Thank you so much, Steve. Hope you have a good rest of your week. And, uh, I appreciate all the work you do keeping, uh, this community together. Thanks. All right. Talk to you later. All right. Bye.