#73: Andy Payne — Grasshopper, Rhino Compute, Teaching, Learning to Code & Gen AI

I've met Andy for many years now, but we hadn't seen each other in person too much. So, digging a bit on you, I see that you're, as I am, like a licensed architect. And you also specialized in computational design.

And I would post stuff, mainly I started as a blog, but post stuff on my website that I started as a Lyft architect. So, it's not really a traditional architecture firm. I'm not really doing or looking necessarily right now for a whole lot of like built projects, but it is a vehicle where I can, you know, as I teach and things like that, you know, the money I get from teaching and stuff goes into that stuff.

I was even, I think my first 3D program was called Form Z, if you remember that program. And the renderings were fine. I tried to do the best I could with it, but I would look in magazines and things like that from other schools and just wonder how they did those renderings because I knew what I could do in Form Z and it wasn't that, like I kind of pushed Form Z to its limit at the time, and I couldn't do what these renderings were doing.

So I was always sort of attracted to what other people are looking at, what are they doing and how are they doing it? And so how can I sort of participate in that conversation? And so that sort of led me to Columbia, which was doing a lot of that cutting edge back in the late 90s or even early 90s and then 2000s. And so that's sort of where my joy of computational design sort of took off because I was able to start learning some of those techniques while I was at school.

We were talking the other day about Grasshopper 2.0, but can you tell us a bit how Grasshopper turned from record history to explicit history to Grasshopper 0.0 something? And what has been the evolution? Or how did this visual... Well, maybe you can kind of go even a bit farther back.

And so I was looking at IK systems and things like that, but then I was able to realize that you could sort of make these really not efficient, but make these sliders and tie a slider to a property in the 3D Max panel back in 2005. And that was kind of new. But so I made these like little interfaces where I could drive parametrically things in the 3D Max view. And I didn't even start Rhino. I think that in that same year is when I actually tried Rhino for the first time and really liked it.

But then when I saw this example of explicit history come out in, what was it? 2007, 2006-ish, I think, it totally clicked for me because I had already tried doing this stuff with 3D Max. But, and now this was a much more intuitive way. But in my brain, it just sort of was like, this is what I've been trying to do. And now I can do it so much easier and quicker.

And so for me, my intro into explicit history and then what ended up becoming Grasshopper, Grasshopper 1, was this avenue that I'd been exploring through 3D Max and then realized there was this much more intuitive interface. But now that I could do those same things in Rhino and in Grasshopper. And so that was sort of my, and the other thing for me was that in my day job, I was doing a lot of rendering. That was sort of my intro out of school. I had done a lot of that in graduate school.

And so I got kind of pushed into rendering pretty hard at my first jobs. And while I enjoyed it for a little while, it wasn't necessarily something I really wanted to do full time, you know, not to knock that a lot of people kind of go down that career path, but I ended up trying to do whatever I could to not do rendering. And then one of the really neat things about Grasshopper and Rhino, at least at the time, was that it was the anti-renderer.

It only had the semi-transparent red color for all of the objects. You could control a little bit of the display stuff, but you didn't render at all. It was not about rendering. And so that also was appealing to me to jump into a program and really push it and not have to focus on the visualization aspect and only doing that.

So then I was working for an architecture firm. I will talk about that project that I was mentioning just a minute ago, how I ended up getting into Grasshopper, or at least Explicit History was, I had worked at an architecture firm where we did a project where they coupled an architect with a chef. It was for an event called Slow Food Nation back in 2007, 2008. And again, I think Grasshopper at this point was still called Explicit History. It had only been out probably six months or something.

And for this design, the architect had to design some sort of pavilion or pavilion, tasting pavilion for the chef to display their food. And we got coupled with a chef who specialized in pickling and pickles and chutney. So we realized kind of early on in talking with her that throughout the world, they pickle food in mason jars. So we really wanted to use that as the vehicle for the design of the project. And so we ended up designing this sort of undulated ceiling out of mason jar lids.

So we suspended mason jar lids, like I think 3,000 mason jar lids at different heights to form like a very fluid kind of surface. And in order to do that, I used explicit history to coordinate all of the data, give me the links, output everything to Excel so that I could print out everything on a spreadsheet, hand it to the people, because we would end up having these big, we call them pickle parties, where people would come and help us measure each of the links and cut it.

And so really for me, explicit history became really critical in the process of that managing information of the design and then outputting for the fabrication, even though it was sort of a manual fabrication process.

And so a colleague of mine at CCA had seen that project in San Francisco and asked if I would do a workshop for his class in like around January. And I realized if I'm gonna try to teach a workshop, I need to know what the software does. And so I really started creating an outline for the workshop, and that ballooned into like a 40-page document. And so I was like, you know, I'll just publish this online.

This was sort of the first iteration, or maybe it was even 70 pages, I can't remember, but that ended up becoming the first version of the Grasshopper Primer, and I just released it online. And then I teamed up with Raja Issa from McNeel, and we sort of added even more documentation, and that became sort of the larger version that is available, I think, still today.

So there was this concept of a recording button on the interface that would record the steps that you did in Rhino. You can still do it. Oh, you can still do it?

It was frustrating at times. I remember teaching a workshop, a large workshop in San Francisco, and right, literally the day before the workshop started, he introduced the concept of data trees, which if anybody's used Grasshopper in the audience, data trees are pretty critical, but also takes a little bit of mental comprehension to try to understand what data trees do and how they work. And so we all scrambled.

The other workshop instructors were all trying to figure out how these data trees work so that we could obviously teach the rest of the participants. But it was an exciting time then, and it still is, but it had a really frenetic energy at the early days that I think was really compelling.

He's kind of, over the last several years, taken a step and really focused on Grasshopper 2. So a lot of the Grasshopper 1 development is now sort of, not necessarily not handled by him, but he sort of handed off some of that responsibility to other developers in the house so that he could focus on Grasshopper 2 development. And for those who aren't aware, Grasshopper 2 has been released. It's been out for about six months, but it's a complete rewrite from the ground up.

So it's taken him several years, but the results are pretty compelling because everything's multi-threaded now. He's kind of overhauled the entire interface. And so it's a complete rewrite, and it's pretty exciting.

They find little features here and there that not necessarily Easter eggs, and he doesn't hide them necessarily, but there's little things that you end up finding like, oh, I didn't know I could do that. That's neat. Like he added this thing or he'll add little words or just the way he actually praises things and presents things to users is pretty interesting, and I think that really goes a long way of having a joyful experience when you're using the program.

And so it was kind of refreshing to just kind of step in when I got hired and sort of be able to start contributing kind of really quickly. And yeah, it's been great. A lot of the stuff that we're working on now for Grasshopper 1, for Rhino 8, is probably long overdue, but I think is going to really change or enhance the way people work with it. Do you want me to explain a little bit about some of the new tools that we're working on?

There are even some ones we don't use often, like date time and, you know, matrices and things like that. But it's never had a concept of, like, native Rhino layers or even native Rhino materials or line types or hatches or annotations or still a bunch of data types that are native to Rhino that Grasshopper has no idea about or how to consume those or create those.

So one of the things that we've been adding to Grasshopper 1 are these expanded data types, these new data types that now allow you to not only query, say, a document for these types, like a layer, right? A query for a layer just gives you all the layers that are currently in the document, and look at all of its attributes, right? An attribute being just a property that makes up that type. So a layer has a name, a display color, its visibility, things like that, line type.

And so you can bring those into Grasshopper now and look at all of those attributes, but you can also create those attributes and create a new layer, bake it basically the same way you would bake geometry into the document. Now you bake a layer and it adds it to the layer table. Same thing with materials and line types and hatches. And so we're pretty excited about how this will hopefully help users be able to modify their workflow.

But also I think there's gonna be some really interesting new tools that will continue to add that just expands on those capabilities.

So anything that Rhino can do from a geometry calculation, and you know, all of Grasshopper, or sorry, Grasshopper and Rhino's geometry kernel is now exposed through Rhino Compute. And you can do that through, you can send requests to perform those calculations. One of the things we realized kind of early on is that we need a client to be able to talk to that server. And so we developed a component for Grasshopper called hops.

And what that lets you do is essentially bundle up a Grasshopper file and send through hops. It'll send that file that you point it to, send that file as an HTTP request to the Rhino Compute server. It will do the calculation and then return the results. So that's the basics of it. When you install hops, it will then also install Rhino Compute and run a local server.

So you can run it on your computer and do some debugging or testing locally without incurring any kind of expense or anything like that, it's free. And then once you get your workflow set up, however you're using hops to send information back and forth, you can then deploy Rhino Compute on a remote server, right? Somewhere, a virtual machine somewhere in the cloud. And then you can point hops to send those requests there.

And so in that way, you can really start setting up a production environment. You can, if you have a lower grade machine for users, but you wanna do some simulation or some really highly intensive computational task, you could have a virtual machine that has a lot of RAM, a lot of CPU processing power, and send those requests to that machine to do that and sort of speed things up.

I think one of the interesting use cases too, is that because it takes HTTP requests, you can talk to it freely from any client that can send an HTTP request. So we're seeing lots of people create web interfaces or application, iOS apps and things like that, that send these requests to a backend server that's running Rhino. And then come back with the results and then show it on the display. So like web configurators and things like that for furniture, jewelry.

We're seeing a lot of really interesting use cases that people who are interested in making a really simplified user interface, but something that you can give to, say, non-technical people or designers and still wanna be able to view, analysis some results or see the changes that they're making on their configurator, they can still see that result. And then, you know, export the geometry to some sort of fabrication or anything like that. So it opens up a lot of possibilities.

Because that probably, you know, that would open doors in terms of maybe having a Linux instance that might be cheaper to run some things, or in terms of relying on Windows and having, because having a Windows instance on the cloud is, I guess, is more expensive, right, as well?

And so we do have a Mac version of Rhino, but from a Rhino Compute perspective at the moment, it's really focused on Windows-based machines. So usually running Windows Server or things like that. But in my experience in setting up these virtual machines through AWS or Azure, really anywhere, they can be fairly reasonable and you can always start small, right?

One of the other things we've really tried to do with the way we've configured Rhino Compute is we've got sort of a two-layer architecture. And I think I was trying to explain this the other day to you. The way we, when you deploy it in a production environment, as I said, when you run it locally, it's free. You know, you pay for your license, but other than that, you know, you can run it and hit hops and then compute all day long.

When you deploy it in a production environment, which is gonna be running Windows Server, we have a little bit different of a licensing model. It's what we call core hour billing. And it's essentially the number of cores on that machine times the number of hours that you're using. And so you can kind of start small. You know, you could configure a really small VM, see if your users, you know, are using it for testing, deployment.

But if you start to have a lot more traffic and it's starting to slow down, you can always, you know, increase the number of cores or the machine configuration. But what we've tried with this two-layer architecture, we have a parent project sort of that we're calling random compute. And then that stays up when you're in a production environment. That stays up and listens all the time for incoming requests.

When it receives a request, it then looks to see if there are any child processes that are running. The child processes, meaning it's called compute geometry, and that's the thing that's Rhino, essentially. That's the thing that's running Rhino and Grasshopper and does all the calculations. It isn't until those get spun up or created that your core hour billing actually starts to take effect.

And if, let's say, for example, your users are using your web app or something like that, sending a request, and they then are done, and it doesn't get any requests for a significant amount of time, the parent application will start to shut all of those child processes down. So you're not getting billed over and over. So we have a timeout. Right now, the default is an hour, but you can kind of set it for whatever you want. And so it will start to shut those child processes down.

You're not getting billed. And then six hours later, somebody sends another request. It checks to see and will handle all the spinning back up and getting the calculation done. And so we have tried to add a number of features to Rhino Compute to make it user-friendly, right? You're still going to have to pay Amazon or Azure for your virtual machine costs and things like that. And that's not something we can control. But from our side, we've really tried to make it reasonable for users.

So maybe going back to Grasshopper and what we were talking about, I was curious that in 2011, you already had an intro to Grasshopper course or some videos online, right?

I haven't been able to trace it because the links are broken. But I wanted to know what moved you to teaching? Do you have a vocation for that? An interest? Are you still doing it? What do you get out of it?

And they were looking for people to come and teach them. There weren't a lot of classes that universities taught specifically at the time that were really looking at that. And so a lot of times, people would just hire me or others to come and teach a workshop, two day, one day, three day kind of thing, and teach their students about how to use the tools. And so for me, that actually, for several years, I did that quite often.

And it was also a great way to kind of see the country in different universities, did some in Europe and even Canada and things like that. So it was a really great experience. I learned a lot, really enjoyed myself. And then I ended up going back to school and still continue to do that. As I've gotten older and have a family now, the traveling on that side gets a little bit more difficult, but also the request has sort of dropped down, I think, because A, it's a much more mature technology.

People kind of understand it now. There's a lot more resources online. And also universities are teaching their own classes on it now. There's plenty of instructors now that know how to use it and can teach it. So some of that's gone down. But I'm still doing quite a bit. We're still doing a number of workshops. Now I do it through Mcneel, right? But we get a lot of requests for at conferences and things like that to teach a workshop on Rhino Compute and hops and how does that work?

Because we're still developing things that are kind of new. And I think it's the new stuff that people are like, I don't understand how this works. And particularly with Rhino Compute, it's a little bit different of a model, right? You kind of have to have a little bit better understanding of like web technologies and HTTP requests and stuff like that and servers. So it's not your traditional architect or designer or things like that. That's where I'm coming from as an architect.

Don't really have that kind of experiences, in my opinion. You know, all of the standard Grasshopper stuff, while it might be daunting at first, it's relatively straightforward in terms of learning. But some of this other stuff, it takes a little bit to actually understand. And so I still enjoy doing the teaching and I'm still getting an opportunity to do it a few times a year.

Even though you're not writing text, you're not writing code and things like that, you're still having to figure out how to think about a problem, break it down, and just determine how you're going to actually solve the problem by breaking it down into a series of steps and an algorithm. And so to me, I still think visual programming is really important and is totally a valid way of thinking about programming.

I also think it's a bit of a gateway drug, because as soon as you start doing it, you want to start to push its limits and see where things aren't there yet. At least that was the way for me. And that's how I ended up starting to write my own plugins, my own components. It was because there wasn't something that automatically already did the thing that I wanted it to do. And so in that way, it was sort of the inspiration to start to learn how to program, how to write text-based, serialized code.

Because I was comfortable in Grasshopper, I could still develop in that sort of visual programming environment, but now I'm starting to get behind the scenes a little bit. And one of the things I think is kind of interesting in that question that I did with Firefly, but I think it could really be taken a little bit further for those listening.

Firefly is a plugin that sort of connects external microcontrollers like an Arduino, its sensors and servos and actuators and things like that to Grasshopper and to Rhino eventually. So what that allows you to do is take real-time sensor information, for example, a light sensor and use that as an input to control your 3D model. And so you could be designing, let's say you're designing a louver system, right, for a facade that is reactive to changes in light.

And you want to demo that for a client or something like that. You can now have a real-time sensor on the table or even mount it to a wall that is picking up the amount of light. And in real-time, you're seeing your 3D geometry, because it's coupled to Grasshopper, you get to see your 3D geometry changing in real-time.

You can then take that even further and take those angles, right, if you're rotating a louver system, it's going to be changing angles and things like that, and send that out back to the microcontroller to control a servo motor. So you could have a little model of your louver system, for example, that's now rotating and changing as you change the light sensor, right, the light values. And so it's pretty interesting, I think.

One of the things I really got excited about early on was this prototyping environment. I've always enjoyed working with my hands and building things, and it was a great way to sort of mix the physical world and the digital world. One of the downsides of the way Firefly works is that it's constantly sending serial data back and forth over the serial port. So that's how it reads the sensor data and sends it over to Grasshopper and does something.

It gets that value for the angle for the louver and sends that back over the serial port for the motor. So it's sending stuff back and forth. But what that means is you're kind of always connected to your laptop and Grasshopper running. Let's say you use Firefly to prototype your thing. You've got it all dialed in. You're using some remapping and some smoothing and all those different components to get it really where you like it. But now you want it to run autonomously.

And to do that, you have to essentially convert your Grasshopper definition into code that can be uploaded to the Arduino, right? Text-based code that then gets compiled and uploaded in machine language onto the Arduino. And that's been difficult for a lot of people. So while I was at the GSE working with Penn, we wrote a code generator that would essentially recursively look upstream in your Grasshopper definition and write Arduino compatible code from your Grasshopper definition.

So it sort of takes your visual representation and serializes it back into a textual representation. And what I think is kind of interesting about that is it also lets you look under the hood a little bit, right? It doesn't do it for all components in Grasshopper. Obviously an Arduino doesn't know how to respond to a curve, but if you want to learn how smoothing works or remapping a number into a different number set, all of these things, you can now see how to write that code in real time.

So it lets you look under the hood. Grasshopper is a bit of a black box. You just see the visual component, but you don't know how under the hood it's working. And so I think from a teaching perspective and learning how to program, it's kind of an interesting tool in that it also lets you kind of see how, if I have this visual programming, how can I actually convert that into a text-based representation and do that.

But yeah, I just wanted to hear your thoughts, so that's really cool.

I would be interested on learning about your take on open source and releasing tools for free or closed source.

You know, I didn't really have a whole lot of programming background back when I was first doing this, but I was interested, and so I started in vb.net at the time. And so I started, I created this library of components, and then as I started developing more, I sort of made different projects and switched to C Sharp and other things. But in fact, I'm very embarrassed because now I look back at the code.

I've been thinking about writing a second version of Firefly, a rewrite, and it would probably be a ground up because the existing code base is just a mess. Definitely of the opinion that I want to help the community as much as I can. And so, you know, the primer was always given away for free. Firefly is given away for free. Monolith was always a free application. And so, I also try to take the stance of how do you monetize this stuff.

By doing it for free and giving it away, you sort of start to establish a, you know, a profile, a name, whatever you want to call it, for yourself. And then you start getting these more excitement and invitations to come teach a workshop. And from that, you know, those networking connections and things like that.

And so, taking the long view for me has sort of helped sort of establish myself and make those connections where had I charged, I probably would have had a lot less connections to people. Really the only thing I've tried to monetize, and it's really, it was, I made a little hardware shield for Firefly, which just a shield for those, again, who aren't aware, it's a little thing that you can just plug in and it already has everything set up.

So this little shield, you just plug it into the Arduino and it has a light sensor and a little joystick and some sliders and some buttons and some LEDs and it can control motors. So it's like a full-fledged sort of prototyping thing that you don't have to wire up your own circuit to do. You could just plug it in and start and go. And because of that's hardware, because I have to pay for, you know, all of those, you know, components, I do charge for that because that's a product.

But that's a slightly different thing than, you know, the software and everything like that where I can control that. And it's really just time versus any kind of monetary expense from my end.

I think also charging certain things, unless you have a super big audience that you know who you're aiming at, it reduces adoption and readership, let's say. Or if I were to put all these podcast episodes that I'm trying to let people know that this exists and build an audience, I'll be like putting a barrier for a paywall that actually ends up being worse for me. So I also think I play the long run game.

And I think that's why in most podcasts or most channels, the motto is advertisement, because it lets people watch it for free or listen for free. But then there's another way of monetizing.

And we've actually had some really... It's not often, but we've had a couple of users who have added some pull requests that really have been really well thought out and well documented pull requests. And so we've been able to include those changes in some of the code.

If I did a new example where I did something with a new sensor or something like that, I could post a video there, and people could immediately see it and comment. Daniel Piker was a big hit. Obviously, he's the author of a physics plugin called Kangaroo, but he would always do these really compelling videos, and they would just immediately blow people's minds. But like I said, the actual answering questions on that platform was a little bit difficult.

So the McNeel team decided to switch to discourse forum, and I know they've been really trying for the last several years to kind of build that community up. So the Ning one had a lot of traffic, but it wasn't necessarily a great forum to figure out how to ask questions. Discourse is much more like a stack overflow model. It's much easier to access and answer questions and things like that, find solutions.

But I think still, to this day, we could do a better job at being able to showcase new people's work and videos and things like that. We're working on that. We're trying. But it is still a very active forum. I think it's getting better.

So for us, when I joined the McNeel team, one of the things I realized and one of the, you know, that they kind of explain is that they don't traditionally have, they don't follow the same model that many software teams do where they have sales teams and things like that. They go out and try to sell licenses. We have almost no sales team, really. I hope the salespeople don't. We don't really have salespeople.

We rely on customer service to, you know, generate enthusiasm and get people to eventually buy a license. So we're all encouraged, developers, technical support people, everybody in the company is encouraged to participate on the forum and talk to users and find out what they're lacking, what they need, what features, because that's how we determine what to develop. The interesting part, I think, too, having worked at Autodesk and at McNeel, is that there aren't really many product managers.

We don't have any product managers. We don't have people that are above me that are saying, you got to work on this today and then work on this tomorrow, things like that. I have had that in the past, and you're probably more familiar with it than I am. For us, they hire people who are sort of self-motivated to find what their interest is in and continue to develop those. And so one way we do that is by interacting with our customers on the forum. And so really, it's kind of up to each user.

We have individual projects that we're working on and so on and so forth, but we really try to prioritize customer service because that's our way in. It helps us know what to focus on, and it also helps spread the word, hopefully, that McNeel cares about its customers and has really good customer service and hopefully, that eventually filters out to people wanting to buy the software.

And so I think we've really tried to focus, let's just try to get people to go to this one source of truth and really try to build that up. Also, I think when they did it, probably Discourse servers, I think they switched probably 2016, I could be rough on that, but somewhere around there, and I don't know the history of Discord servers and things like that, but I think they've kind of become more popular more recently. And so they probably made a decision early on to go to this discourse model.

And then I think they've just kept going there. I think talking about videos too, we have really tried to start building up our learning content as well. I think that's another thing that we try to do pretty well. We haven't historically always done... We try to do well documentation, but we're finding more and more people tend to like these videos.

And so we're really trying to build up our video content library so that we can sort of explain how to model, how to do Grasshopper things for new users.

And then we also have our developer documentation, which is a little bit more focused on people who are wanting to develop, you know, programming and things like that. But there are guides that really help you figure out how to navigate the RhinoCommon API and things like that. And so we do try to, you know, obviously, it's a hard thing to manage. You've got a lot of content and we've generated a lot of content and it's kind of all over the place.

And so we are trying to centralize and make our web experience a lot better and easier to understand for users. But that takes time. And we're always, you know, trying to improve it. So we try to look for feedback and say, this isn't working. Like, how do we, you know, get it to look better? Also, when you launch Rhino, every time you launch Rhino, there's a sort of list on the right that's like what's happening. They send out a lot of e-blasts and things like that.

But we have like a running blog that sort of says, what are some of the new features and new things that are happening and, you know, workshops that are happening in different areas. And so every time you launch Rhino, you should have a list of links that, you know, you can click right there and it'll take you as well to some of these pages.

For me personally, I don't do a whole lot of social media. I have sort of a private account on a couple things, but I don't really do Twitter or Instagram or really any of those things. So I'm a little bit more of a private person when it comes to that. I think early on I did well in positioning myself. I happened to be at the right place at the right time at a couple of things, right?

Grasshopper being one of them, I sort of happened to be interested and available to sort of start when Grasshopper was really starting. And so I happened to just be at the right place at the right time. And then I did the primer. And so like I said, I was sort of the right place at the right time. And I did try to really build my name and get my name out there and so on and so forth. But as I've gotten a little bit older, I've kind of become less and less socially aware.

I get nervous about the privacy and how much stuff is out there. And so for me, I tend to and to that end, I've kind of seen some of that stature kind of fall off. So there's a catch 22 or not catch 22, but I get a little bit nervous. But it also means that like, you know, had I kept pushing on some of the social media, you know, out there getting my name out there, Twitter and so on and so forth, I might be in a different position. But, you know, that's the choices we make, right?

And that sort of gave me a little bit of an insight of how the electronic side worked. But the concept was, you know, how do I take this and link it to Grasshopper? So I think I did what most people do who don't know what they're doing, is they just start Googling and reaching out on forums and say, like, how do I do this? And I did get some help on forums early on about how to connect to the serial port and things like that.

And eventually, I was able to cobble together, you know, a component that could, you know, read information in. And then the next step is how do you read it back out or send it back out? And so, you know, I think for me, it's really just about the curiosity. You know, you have something in your head that you really just want to do, and you just have to pursue that. And that's really how I started to program. You know, I didn't grow up writing code.

I think I took maybe one class or things like that, and I have historically not taken a whole bunch of programming classes. It's sort of self-taught, and that's probably why the code that I wrote early on was so horrible. But, you know, you just start to explore, and credit to David and the rest of the McNeel team who made developing components or plug-ins relatively easy, right? It may not seem easy at first.

It's a bit of a steep curve if you're very new to programming and things like that, but the more you do it, the more you realize it's a pretty accessible platform, particularly the C Sharp and VB and Python components that you can just develop directly in the application. But I think those are good ways to start to explore an idea. And then, like I said, there's lots of information online, and you just have to have a project and start it.

And so for me, that was Firefly, but I think the same can be for a lot of people.

I would mention this for people who are thinking that they want to improve coding, because if you don't have a goal and objective, like for example, you were thinking with a physical thing, like a microprocessor that might switch a light on or off, and it has some way of seeing the results and the rewards and what you can use that for. But if you're just learning in the abstract, it's like you're studying English all your life without going to an English speaking country and practicing, right?

And so a project that you're sort of driving, that you have control over and are wanting to do, makes the development process, that learning process, so much more achievable or interesting, whereas if you're just sort of going through the motions following a series of tutorials that somebody else has written out, that's great, it's fun, and it can be good, and you can hopefully apply a lot of that down the road. But at the same time, while you're doing it, it can be boring.

It can be a lot like homework, and you're just sort of going through the motions.

And I mean, you can see on the YouTube channel, I can see that many people have a target in mind that they want to do, and that's why they get to your video. It's like, I want to automate uploading, I don't know, like 20 or like 100 videos to YouTube. So they get to your video because they search how to upload it. Nobody's going to go and say, okay, I'm going to upload, I'm going to see how to upload a video to YouTube just in case some day.

And then the other thing that I think I relate to is coding skills evolution. I see also my projects back in time and how I did things. And I think it's great that you don't like the code in early Firefly because that means that now you have the possibility of looking from a perspective where you say, I've learned a lot or I can see that that's bad. The worrisome thing would be if you didn't realize that that was not the best code that you can do now.

So that would be also an encouragement note to people who have things and they don't know if they should release because I've seen people that get really self-conscious about, ah, this is not ready, I don't have documentation, where I just put it out there, it depends what you're doing, but sometimes people might find it useful, they can learn from it. And yeah, I don't know, I would encourage that as well.

But I know you've probably been keeping up with all of the ML stuff with, you know, these image, text to image translators, Midjourney and Stable Diffusion and DALL-E. And I think that's an interesting thing that's happening now. You're starting to see these people that it's allowing them to sort of visualize their curiosity in different ways that they hadn't really begun to explore. I think it'll be interesting to see how people then take that, right?

Are they just going to take it at face value and show it to the client? Or is it really like an ideation process, like a back and forth with this AI as a way to sort of augment your own process?

There is also the concern that we're going to lose the human craft or we're going to be prompting text bar instead of actually thinking what we need to do.

And that artist obviously has spent a lot of time thinking and developing their own style, right? And I can certainly see how it's now being sort of co-opted and sort of degraded a bit, taking sort of and trivializing the work that they've done to a point where now you can do it in a matter of seconds. And I can see how that would be really difficult for a lot of people and a lot of artists.

And then obviously, you're seeing other ethical questions about the AI stuff, about biases that are internal, some of the stuff that Shelby Doyle has talked about and things like that.

I've used the one that I've got in love is Edward Hopper, by Edward Hopper. Like if he had drawn that because the colors that his most famous paints or at least the ones I know have are like these light blue skies with high saturation and really green fields and happy people.

I've been iterating, I generate variations, I change the description, and I've, let's say, created with this tool some images that look like or illustrations that look like Edward Hopper paintings. And that makes me think if I had actually studied his artwork and I was trying to draw things from real life as he did, trying to mimic his style, that probably would have been hours and hours of work and a lot of dedication, and I would value those pieces a lot, right?

Each piece, it would have taken a lot of time to do. And now these images that I've generated are not of so much value to me because even though the results are maybe even better of what I could have done, I'm undervaluing them because they were super easy.

The time spent, the quality and time spent that you invest in developing your ideas into a 3D model or something like that. There is something about that investment that makes it worthwhile, and that's the design process. When you have an easy button where you can just press it and it generates your building for you, it does take the design process away from you, but it also trivializes it a bit, I think.

Then you mentally put more value into that item than it actually has, because you've put, as you said, a lot of effort. So for you, it would be really easy to give away, let's say, a $10 table if you had bought it on Craigslist and now you're selling it, than if you actually bought it original and assembled it, and even more if there is a story behind it that you put that, oh, I built this with my kids or with my friends or whatever. And so I think there is part of that.

It's like the effort of making something makes you less willing to give it away or want to charge more. And if that happens to art and how we envision, because art at the end of the day, we're talking about illustrations as something you could sell, but I see also art as a self-expression medium, right? And we're kind of like trying to do as few crafts as we can.

Who becomes the artist in DALL-E or Midjourney? Is it the person who writes the text prompt or is it the programmers who develop the model, the AI, right? As they're the ones who essentially built the model and explained how, you know, built the concepts of how it all goes together. I think it's an interesting question of how much authorship should be given to the person who actually generates the prompt, for example, and the person behind it.

And the same could be, I guess, true for, to a degree, some of the tools that we all make, right? Me personally doing some of the stuff with Rhino and Grasshopper. Obviously, the authorship is more of a step back, right? Someone who's designing in Grasshopper, that's their design. But also, you do feel a bit, you know, I look at some of the videos that are posted online that use Firefly, right? That are using these sensors to drive something.

And you do feel like you had a piece into that, even though it's their work. I'm not trying to claim any, you know, ownership or authorship or anything like that, but you do feel like you contributed some way into that work to a degree. And so, you know, they probably don't see it that way. And that's fine. I'm not, you know, it's a different model. But I do wonder where the programmer, the guy behind the scenes who writes the software or the stuff, where their fit is in that.

If you go to AutoCAD or to Rhino and start with the Polyline tool, it's going to determine or constrain what you can do. So the difference, I think, is that DALL-E is a program that is actually as if in Grasshopper, you were telling build a tower with three stories and blah, blah, blah for me. And it was actually creating notes and doing the things for you. So we're entering in that the program is actually taking the brush from you and painting. Yeah, exactly. So I think, yeah, I don't see...

It's complicated. If you're just using... You could say that if you're just putting a prompt and generating a thing, yeah, okay. You put that prompt, you had, let's say, the idea, the originality is to write the prompt and get that image. But there is people who go farther and maybe start getting an image and merging that with another or creating permutations. So there's also an effort there in using this tool now to get to a good result.

But at the same time, even with just the silliest prompt, you can end up with an initial canvas that is already a finished piece. We've also seen on the news that there have been a drawing contest owned by the AI and blah, blah, blah. It made it to the New York Times and I think New Yorker. So I don't have an answer. I think we're putting...

And particularly when your phone hears conversations, right, that you're talking about, and now you have ads for something that, you know, is in your pocket. It wasn't even on and listening or something. Or it was listening, but we didn't know that it was listening, and now we have advertisements for products or something that we were just talking about.

Or even here, I've noticed that like my children have something on the TV, like a cartoon or something, and now something on my phone shows up about that cartoon. And so that sort of stuff freaks me out a little bit. And particularly the biases that it sort of imposes on people without sort of their knowledge. But I think it's inevitable that it's start going to permeate really all aspects of our life. I think whether we know it or not, obviously the social media aspect is already there.

We're seeing it in banking. We're seeing it in entertainment. We're starting to see it in design, right? I think the stuff you're seeing and a lot of stuff you're doing, right? You're working at a design software company, focusing on AI and machine learning. So the stuff that you're doing will have a direct impact, right? And so I think it will be interesting to see how that shapes our design process and whether that's good or bad.

Our whole conversation that we've been having about DALL-E and Midjourney and so on and so forth, we seem to be kind of split on its benefits and the consequences of it. And so it'll be interesting to see how some of those things play out.

It's unlocking problems that were not possible to solve with heuristics by having huge datasets. But in terms of, for example, at work or other utilities, we're just using machine learning for things that you can do in other ways, for example, like an energy simulation, but faster with a prediction that is not super accurate, but it's super fast.

And so I think the big question moving forward is how much are you willing to give away or whatever those consequences are, do they outweigh the potential benefits? Because I think in a lot of ways that answer is yes. You're speeding up a process that would normally take many hours. Now you've got it in minutes. And so that has a huge time saving.

And so given the stuff that I was there to do, my research interests and things like that, I really gravitated towards wanting to just soak it all in, be around him as much as I could to sort of understand how he thought and see how he programs and stuff like that. And so I've been really fortunate to be able to work for several years, both at the GSD and then afterwards with Monolith and then at Autodesk. And the one word that comes to mind, like I said, is genius.

Anybody who's sat down with him next to him while he's sort of helping you debug a problem, it's pretty evident really quickly how his brain sort of works in a slightly different way than, say, most of us. And I think it's kind of compelling and sort of in awe of the amount of knowledge that he has. Just from a mathematics standpoint, obviously machine learning, AI, but also structural engineering and things like that. He brings so much to the table that a lot of us can't really keep up.

And I think that's been always really incredible seeing that his willingness to help people, his willingness to sit down and explain concepts and things like that, is really just quite profound.

But to me, the aha moment, you figure out that problem, and you finally figure out how it works. To me, that's what you get that sort of endorphin boost that makes it all worthwhile, right? You get that one moment of clarity that you've now figured out how the problem should be solved, and that's what makes it worth it. And so, you know, just following the relentless curiosity is sort of, I think, important.

But maintaining that balance that gives you the ability to be there for your family and friends. And so for me, success is essentially being able to juggle both of those. And that's not always the case for a lot of people, but I'm lucky to have found a spot that I can do that.

What would be an item of $100 or less that you've bought recently that has improved your life in any way?

And they've increasingly gotten more sophisticated and complex, but it's also a learning process, right? I've definitely learned new techniques that I wish I had known when I was in school, because some of the things I'm doing now with stupid Halloween costumes could have been applied as architecture models and things like that. But really the stuff that I'm buying are supplies for Halloween costumes.

And yet that brings a joy to me, and hopefully will bring a joy to them at some point when they get to actually wear it. But even though that's just my hobby, it's making things like out in my wood shop or making things like Halloween costumes. It's kind of silly. The stuff I'm buying is like EVA foam and contact cement and spray paint. But for me, that brings joy, is the hobbies I get to explore.

Awesome.