Exploring the Evolution of Computational Design

A This episode is sponsored by Monograph and Arc IT. You'll hear more about them later on in the episode. I'm Evelyn Lee. And I'm Janine Chastain.

B We're collaborating on curated conversations to explore how the industry of architecture is changing.

A Together, we'll find ways to create new solutions to current challenges while elevating the value of architects.

B Welcome to Practice Disrupted.

A Hello, listeners. Hello, Janine.

B Hi, Evelyn. Hi, disruptors.

A Today, we're moving back towards our ongoing conversation on technology and its impact on industry change. We are excited to welcome a new disruptor to the show, one who brings an entirely fresh perspective on technology and its relationship to architecture.

B Today's guest speaker is Andrew Heumann, an architectural designer and software developer with a passion for building the next generation of software tools for designers. Before joining Highpar, he was a senior researcher at WeWork where he focused on integrating automation and AI into design and delivery processes.

A Highpar is a next generation platform for designing, generating, and sharing building systems. Highpar helps designers generate, visualize, and analyze buildings to make better decisions faster. You can quickly combine different building systems that intelligently interact. Highpar includes analysts and simulation tools created by industry experts to predict and drive performance.

B Andrew is well known in the AEC computational design community for his contributions to plug ins for Grasshopper and now his work with Highpar and coding. My hope for this conversation is to understand Andrew's perspective of the evolution of computational design, the niche of coding that supports the tools architects use every day, and to make this conversation accessible on the ideas of trends and technology that our broader audience of listeners can benefit from. Andrew, welcome to the show. We're so glad to have you today.

C Thanks. I'm so excited to be with you.

A Tell us a little bit more about who you are and some of the well known programs you've designed and what you're working on right now.

C Thanks. So, my name is Andrew Heumann. I'm an architectural designer, and now I work as a software engineer. I work at the moment at a company called Highbar, which is a small software startup where we're building the next generation of design tools for architecture, engineering, and construction. And before HeightBar, I was probably best known as being, like, a giant Grasshopper geek. I've been an active member of the Grasshopper community for over 10 years and have written a handful of plugins like human, human UI, and MetaHopper.

A So for those, I'm gonna just back it up a little bit more because there are listeners who might not know who what Grasshopper is. Can we can we go there?

C Yeah. So Grasshopper is a scripting language that sits over the top of Rhino, which is a popular three d modeling application. And, basically, what Grasshopper allows you to do is write algorithms or sets of instructions that drive how the tool generates its geometry. So architects really like Grasshopper because it lets them build instead of modeling something manually over and over and over again, modeling a facade panel, and then the next one, and then the next one, you can set up a set of rules that guide how that facade is supposed to work and easily make tweaks to it and have it sort of regenerate or re execute over and over again. So it can be a huge time saver, and it's also enabled architects to pursue more complex forms that otherwise just would have been impossible to do through manual modeling.

A I wanna almost say, like, it's the array command on steroids.

C Yeah.

B I think it's interesting, and I wanna pause there because while some of our listeners are gonna be, you know, deep in this world of technology, we also have, like, a entire group of listeners that this is this is a new conversation for them. So I wanna orient them into it. And and I think maybe you could tee up for us, like, programs like Rhino and Grasshopper. How did that emerge into the industry? Was that, you know, because architects were designing and they felt like they needed these tools in order to achieve the designs that they were seeking? Or, you know, what really drove that?

C Yeah. It's a good question. And I I mean, I probably won't do a great job as far as the, like, actual, like, history of it and, you know, specific things. But but my my understanding is that, you know, there were a few pioneer architects in, like, the nineties that were really interested in pursuing, like, radically different formal strategies. And they started turning to tools like Maya, which is like a 3 d animation software, and even even maybe predecessors to Maya at various points to build these, you know, crazy new forms and shapes. And then in order to actually realize them, the architectural tools like AutoCAD that were available at the time just couldn't handle these complex forms. And so architects like Frank Gehry started looking at tools like CATIA, which is has been used for a long time by, like, the aerospace design industry. It's a tool you use to design, like, airplanes or, you know, complex ships or other machinery.

C And so they found that by using tools like CATIA, they could model these more complex forms. And so gradually, other practices wanted to be able to adopt these sort of same sets of techniques, but maybe didn't have access to expensive tools like CATIA. And so various other tools emerged on the market. And Rhino was originally actually, AutoCAD plugin for doing 3 d modeling and eventually became its own piece of software, and it was designed for modeling these complex free form shapes. And then gradually over time, an interest in sort of scripting or programming over the top of these tools became almost a necessity. Because when you're building complex forms, inevitably, the pieces and parts that you're actually going to build with are going to be different. If you're building a box, you can kind of repeat the same square element over and over again. If you're building, you know, a swoopy form, you know, like a Zaha Hadid building, then every piece needs to be bespoken custom.

C And you could either model that manually, which is incredibly time consuming and complex, or you can write rules and logic that take the forms that you've modeled and automatically generate the more detailed components that make up those things and help to solve problems of, you know, how is the structure going to work and how are all of these parts going to fit together? So over the last, like, 15, maybe even 10 years, we've seen this explosion of various scripting tools that permit basically, like, writing code to drive the software that you're already using. So in Rhino, it's Grasshopper, in Revit, it's Dynamo, and other programs like Blender also have their own version of this where you can kind of make custom rules that generate the designs that you're trying to work on.

A And then a lot of people who use this, I would say they refer to kind of the architecture forms that come out of it as parabolic. But I would argue, and I'd love to hear your your perspective that it doesn't all have to be, quote, unquote, parabolic architecture.

C I mean, yeah, there's this conflation that I think is really common in folks who are sort of adjacent to this space between the tools, which are parametric and support certain kinds of mathematical and scripted operations, and a sort of like parametricist form making where it's designed to do like, you know, it has to be a swoopy form. It has to be, you know, perforations that change size. There was kind of this moment, you know, in the 2000 tens where everything had to look this particular way, you know, Zaha Hadid's firm and especially Patrick Schumacher has been sort of a leading theorist of this sort of actually promoting the idea that because we have these tools and for various other reasons, we have to make spaces that are like blobby and continuous and smooth and all these other things. Whereas in my personal opinion is that there's actually no fundamental reason for the tools that permit these kinds of things to necessarily be put to that use. You can build totally normative, boring buildings if you want with these tools, and you can also build, you know, buildings basically in any style utilizing these techniques if you're interested in saving time and, you know, saving yourself from repetitive tasks.

B It's just interesting because I think that the people that gravitate towards this kind of design, it amazes me that they they will pursue it at such a deep level to figure out exactly which plug in or if it doesn't exist in your case, you're someone who's interested in actually creating those tools to create the idea or the design that they're trying to output in in the computer program or or software. So your background is in architecture. You've worked at architecture firms. If for listeners who wanna hear more about your career, I'm gonna reference them to the show notes, where you can listen to interviews that cover that. But in this conversation, we wanna get deeper into this topic. And so currently, you're working at Highpar where you are coding and you are creating some of these additional plug ins. So let's start with, orienting the audience on Highpar, its intended use, and where you see architects really using it.

C Yeah. So as a sort of broad introduction to HighBar, I would say HighBar at a simple level is just a web based architectural design tools. You might use it for the same kinds of things you would use Revit for. But in order to understand why it's different maybe from these other tools, I like to use a sort of extended analogy, which is that I feel like HighBar is to Revit as Revit is to AutoCAD. So I'll explain what I mean by that. AutoCAD is, or just CAD generally, doesn't really know anything about architecture. It's a tool for drawing lines, and you assemble those lines in various arrangements and produce drawings out of those lines.

A So I think, actually, like, the the architecture industry's use of Autodesk is, like, such, like, such a small use of, you know, all the other industries that actually use it.

C Yeah. I mean, it it gets applied for any sort of technical drawing application. Right. But fundamentally you know, and and there are plugins and other things that that teach AutoCAD a little bit more about what buildings are, but fundamentally, the revolution of tools like Revit or BIM, generally, was to introduce ideas about what buildings are, are, what they're made of, into the software so that instead of drawing a series of lines, you draw a wall. You in a BIM package like Revit, you are placing or drawing or drafting elements, which are actual meaningful parts of a building. A floor, a door, a window, you know, a beam, a duct, whatever. And ultimately, you produce a big model composed of all of those elements. And from that, you can output your 2 d drawing.

C So you you kind of get your CAD out of the model that you've produced. And so when we talk about HIPAR, and what I mean by this that, you know, sort of the next level up of complexity is that hyper lets you bring together entire building systems, whole sets of logic and rules about how building systems work and go together, and it generates entire BIM models out of those systems. So on the one hand, this is sort of, you know, this is sort of oriented around automation. You can express your intentions as a designer at a higher level, at a higher level than you can in something like Revit. So instead of placing individual elements saying, put a desk here, put a desk here, copy, copy, rotate mirror, you say, this space is an open office. And HighBar has a piece of logic, which says, okay. I know that an open office is kind of composed of this certain arrangement of desks, And so I'm just gonna lay out the desks for you. So you can express your design intent at this higher level of abstraction and let Highpar's built in automations sort of try to execute that intent for you.

C And 2 additional things are important. 1 is that, Hyper is built around the assumption that any automation we build is probably not going to be exactly right. So we know that the desk layout that Highpar gives you is not gonna be a 100% of what you meant. It might be 85%, and so we also afford you the tools to get in and make fine tune adjustments and and, you know, adjust and finesse the thing that you're trying to achieve. So even though there's automation, it's not like we're taking away your ability to control the individual elements as well. And the other really critical thing is that HighBar is built as an open platform, which means you don't have to rely on the HighBar team to build that logic about how those desks lay out or how the structural system is deployed. Anyone can build and basically encode their expertise into what we call a hyper function, which is basically the logic behind any building system. And there can be many different design strategies or systems that are published by our community, and anyone can deploy these.

C So it's as if, like, anyone could just add a new button to the Revit toolbar, and it immediately showed up for anyone, and it encoded an entire, like, strategy for some piece of a building system.

A So I think some of our listeners might be listening in and thinking, okay. You know, there's definitely people who are like, why even use CAD when there's Revit? So now there's, I think, there's a few people who is like, well, why even use Revit if there's HIPAR? So who do you do you find as the ideal kind of user of high par and what, you know, what design firms gravitate toward it or or tend to be using it. And and I I would even go as so far as saying, you know, are these sole practitioners? Are these large firms? Give us the whole picture.

C Yeah. I mean, it's actually our customer base is pretty diverse. We have small practitioners. We have really large firms. You know, I think firms who are, you know, sometimes we say it's just like anyone who has to make a $10,000 or greater decision about a building. Right now, probably the most popular workflow on Highpar is one around office space planning and test fits. So we have a lot of users in interiors or architects who just like wanna get some quick test fits out for a corn and shell design. And Hyper makes this really fast and easy.

C You can you know, a skilled user on Hyper can pull in a core and shell model and get a fully realized 3 d test fit with furniture, metrics, diagrams, multiple options, and everything in, like, literally 30 minutes. So a lot of our users are kind of operating in that test fit space, but we also just we also work and partner with a lot of different practices who wanna build out internal tool sets around automation. They have their way of deploying, you know, this is how we do warehouses, or this is how we lay out retail floors, or this is how we do some building product. And we just wanna be able to deploy it on the fly according to a set of logic that we encode. So High Bar is really for any practice that has sort of reusable strategies that they're deploying over and over again. But, you know, it's not limited to repetition or repeated strategies either. It's intended to be a design tool that works for anyone who's just tired of doing the same things over and over again in whatever design software we're using today.

B Yeah. We talk a lot about this on the show that, you know, I think that what we get excited about in terms of technology is eliminating some of the inefficiencies. And so one of the things that I think your clients and customers really love about this tool is the speed and, like you said, the quickness, the agility to move through, especially, like, if you're in that early concept development phase where you're trying to come up and generate a lot of different ideas. The ability to move quickly becomes really valuable in in coming up with your different concepts and then continuing to tweak it very easily over the development of that design. So I think in my mind, that's really where I see it as an extremely valuable tool. And I can imagine, like, you were we I think that what kicked off this conversation was we were on Twitter, and you posted a quick little video of a plug in that you had created, I'm assuming, or maybe this is just how the tool works, of basically an axon of the building that moved so fast that, like, it blew my mind. I was like, oh my gosh. I remember the days of, like, just painstakingly trying to come up with those kinds of, diagrams of buildings and just slogging through it.

B And I think that really wowed me. So tell me more about your point of view on that.

C Yeah. I mean, so that the feature you're alluding to is something we we just released. It's actually it's sort of a built in platform feature. So any building project on HyperArc can just, like, have an exploded axon view right away. And one of the cool things about it is you can actually edit in that view. So you can, like, explode your plan and start playing around with the blocking and stacking of spaces and programs and stuff, and then just collapse it back together as the model. And, yeah, I mean, I think from a from a personal standpoint, you know, I've I've worked for architecture firms. I've worked as a designer.

C I'm really interested in finding those kinds of interactions with a design tool that bring designers joy. For me, it's not all about let's just make your job faster or let's take away the TDM. Like, one of the things that I feel like the whole industry reacts to with tools like Revit especially is just the frustration. This feeling that it's fighting you at every turn. This feeling that, like, it's just not a joy to use. I think there are probably some people out there who would say, oh, I I love Revit. But I think most people in the industry I've talked to have this sort of like begrudging relationship with Revit, where it's like, I gotta use it every day. It drives me insane, but I can make it work.

C And so I'm really interested in crafting tools that people have a loving or joyful relationship with. It should feel like especially in the realm of creative tools, your tool should be your partner. It should be your assistant. It should be your collaborator. It shouldn't be something you have to fight all day long.

A I think what is so interesting about those of us who have who are working in what we would classify as, like, architecture and or architecture plus or alternative careers, you kinda touched on it. It's, like, we're really here to support the broader architecture community in a way. So it was just interesting for me to hear you talk about you giving joy back to architects when it comes to some of the tools that they they are using. Is there anything else that kind of, you know, drives you and and the work that you do on on this side?

C I'm just fascinated by this question of, like, creative conception and design process. I'm interested in what the shape of a productive collaborative relationship between a human designer and a machine looks like. And I think there are all kinds of versions of this future, and some of them I don't like very much. Some of some of the ways in which we as creatives might relate to automation are not that appealing to me. The idea that you just, like, press a button and get a design out the other side is, like, doesn't feel realistic and doesn't feel rewarding to me. I want to craft tools that are creatively meaningful, where you feel like you're empowered by them rather than restricted by them. You know, I I think a lot of this also like, my fascination with design process also just goes back to, like, when I was a freshman in architecture school, I was kind of bewildered by how, like, highfalutin and conceptual everything was. And I kept asking people like, okay, well, how do you actually design a building? Like, what does this process actually look like? And, you know, we got, you know, told all these concepts and, you know, talking about theories and phenomenal transparency this and all this other stuff.

C And I was like, I don't know what any of this means. Like, just help me figure out, you know, what are the steps that I need to follow to design a building? And the reason why it was so hard to come by an answer is, you know, partly there's a cloud of bullshit, but I think also because it is fundamentally not a step by step process, crafting something creatively, especially architecture that has to operate functionally at the same time as being sort of conceptually or aesthetically meaningful requires learning this high level conceptual vocabulary, deploying a repertoire of techniques and approaches and agendas and attitudes operating at different scales and levels of abstraction and how you negotiate a project brief and summon a concept out of thin air and imagine 3 d form in space and craft a toteal detail and present it to a client. You know, it's just like all of these things operating at once rather than being this kind of like linear process. And I think sometimes technology falls into the trap of trying to impose a linear process over design. I'm really interested in understanding what creative tools, creative software tools that can that can work well with the sort of messy vitality of real creative thinking and work, what those what those might look like.

B Oh, I love that. That's so it's such a fantastic explanation of, like, what motivates you. I I think as architects and designers, like, we all latch on to this one angle or one perspective into this industry. And so it's it's really cool to hear yours because it's a new angle that I haven't heard yet. When I was listening to your interview with Evan Troxell, he was talking about this idea of layers of design. And I do think that what you're interested in is almost like the inception of architecture. It's not the building necessarily. It's like the tools that design the building and the the ideas that go into developing those tools.

B So I was curious. Maybe you could walk us through, like, what draws you to this level of design? And maybe this is, like, a continuation of what you've just said, but it's not just this output of the architecture itself. But for you, it's like this whole step through, the design thinking and the processes that lead up to that.

C I think it's tricky to answer. I think I mean, I I am really interested in in architecture and the actual physical products of the work that we do. And, you know, there it's, you know, the few projects I got to work on in my early career, it's incredibly rewarding to visit them in their physical reality and and feel the space that's produced by those things. So I am still really, you know, excited by that. But I also, I just like, I'm fascinated by how architecture operates in the world on all of these different levels, politically, culturally, socially, aesthetically, economically, all of these other things. And I think it's one of the things that's magical about architecture as a skill set is this ability to kind of like synthesize all of these conflicting sets of demands and requirements and intentions and distill them into something real. And, you know, and I guess I guess to some degree too, I guess it emerges a little bit from like an insecurity arising from my time in architecture school and in practice, which was like feeling like I wasn't very good at any of those things. Like feeling like I wasn't a very good designer.

C And so trying to, oftentimes when I'm confronted with something I feel like I'm not very good at, a problem I don't know how to solve, I try to approach it by turning it into a kind of problem that I do know how to solve, turning it into a problem that I know how to get some sort of footing on. And so I think to a degree, I kind of did that personally with design generally. That was part of what me to Grasshopper and other computational approaches in the first place was that it turned it from this problem that I just didn't know how to operate on or grapple with into maybe more of a technical problem or maybe more of an analytical problem that I could distill down into parts. But I it's important to me too to, like, do that without sacrificing all of the other components that make it rich and complex and difficult. You know, I think there's a there's always a risk of reductionism when you try and take these complex processes and turn them into, you know, a rule set or something that's that's a recipe or a, you know, an algorithm. And so it's also important to me to to gain a a broader understanding

A Let's take a break from this conversation to talk about our sponsor of this episode, Monograph. We're proud to partner with Monograph because they are helping to transform the practice of architecture, one design studio at a time.

B Tired of using dated and clunky software to manage your firm, or do you feel frustrated wrangling all of your spreadsheets to get a clear view of where your project stands today? Monograph is here to help.

A Designed by architects for architects, Monograph allows you to track your time, your projects, and your budgets in real time. With our awesome MoneyGantt, you can immediately understand project performance across your entire firm portfolio.

B Need to adjust your projects week to week? Their new tool, resource, allows you to reallocate your team's time and track its impact on your remaining budget.

A Be proactive with Monograph. Our friends at Arc IT are helping architecture firms with their technology solutions, including fighting back against ransomware and cybersecurity attacks. They recently told us about 1 San Francisco based design firm they help who had 3 ransomware attacks in a span of 6 months. Their latest hit took their generic IT provider over 7 days to recover the data.

B Yikes. Imagine not having access to your project data for over 7 days. For a midsized firm of 40 people, that's a lot of people not having the ability to do work on their projects.

A Cyberattacks are a growing challenge in the hybrid world, and they are costly. The firm leadership estimated that the pure financial cost of the business was just over a 100 k, not accounting for the tremendous mental pressure the team experienced during the attack and subsequent recovery. However, it's important to mention that proactive architecture firms can get ahead of these type of technology threats.

B As you consider your technology infrastructure needs for your business, be sure to check out Arc IT. They're a trusted IT provider who is in the business of helping architecture firms, and they offer tailored solutions for design studios small, midsize, and large.

A Arc IT is offering a free 15 minute cybersecurity assessment to help you determine how secure your business is. During the assessment, Arc IT will help you identify your top three highest risk areas in your business.

B Speaking of risks, Arc IT is also sharing some helpful tips with practice disrupted listeners that you can implement tomorrow to ensure your business is secure from cybersecurity threats.

A Their latest tip is to use different passwords for every service and use a password manager such as LastPass to keep track of them.

B Tune in next week to hear the next tip from Arc IT. To take your security solutions further, contact Arc IT at www getarkit.com/pd to set up your free 15 minute cybersecurity assessment or speak to them about custom solutions for your design firm.

A So I'm imagining that there may be especially some younger listeners who are like, how do I follow in your footsteps? And you were coding Grasshopper before, like, YouTube. It was actually before I think you could, like, you know, go on YouTube and watch how to write all of these things. So how did you develop your skill? And now given YouTube and the other resources, how would you recommend that others begin diving into that?

C I think the way that I learned is just by really participating in the online communities that had sprung up around Grasshopper. I was really active on the forums and people would post example scripts or even post, like, questions or problems that they had. And I would observe and participate in people helping each other, people suggesting better ways to do things. It was this incredibly rich ongoing conversation where people were sort of sharing knowledge and ideas about how computation could work. And that was very attractive to me. And that was basically how I learned. I just like sat there and downloaded other people's scripts and tried to piece them apart and figure out what they had done. And I think, you know, maybe touching on some of the earlier questions too.

C One of the things that was appealing about that community to me is that I felt like there was a level of this kind of, like, brass tacks, like, how to do it sharing that actually isn't really present in architecture, in design. Like, you know, there are there are millions of YouTube videos, which are just like tutorials about, like, not just how to do a thing technically, but, like, how to think about a web design problem, how to think about, you know, creating a responsive design, or how to think about accessibility for your design. And I, you know, I think this is starting to change. There are a few like content producers, and I certainly think, you know, podcasts like this one and others are doing great work in kind of like unpacking what the processes and practices look like and having real open public conversations about that, but that was not always the case. And so I feel like the sort of grasshopper community or this sort of computational community sort of paved the way for other higher level architecture oriented conversations to happen too. And and that's that's really exciting to me. So that I don't know if that actually answered your question, but, Yeah.

A Well, I I I mean no. But you went down a very fun tangent and, you know, that Janine and I have talked about before, and and I've kind of related from being in tech. So, like, what astounds me in technology is how supportive the community is, how much, you know, how much they learn, like, even not well, I mean, you could talk about we have our competitors too. Right? But so much of what we learn from each other is what pushes one another forward. You know, it makes me think how did this evolution of secrecy and privacy and no other firm has a secret sauce kind of evolve evolve into architecture. I used to work at a firm that had you sign an NDA upon entering. So

C Yeah. I mean, there's this there's this crazy notion in so many architecture practices that, like, how we do our work, the design that we do is like our special sauce, our IP, and we have to guard it incredibly carefully. And we see this all the time at Highpar because we're a platform that supports people like encoding a design strategy and making it available to the world. And people are like, oh, we would never do that. Because our approach to laying out a stair core is so much better and different from how anybody else is gonna lay out.

A Even if the stair core ends up being the same. Right? That's the approach to the

C the same. I mean, we we have we have sort of an internal term for this, which is we call it the stadium bowl problem. Because there's this in sort of the grasshopper world, there's this cliche that everybody builds a stadium seating generator script. It's like a it's a really good problem for computation because it has all these rules and you can sort of vary some parameters. And rather than there being this sort of like collective growth of sort of strategies and tools around stadium bowl generation, everybody reinvents the wheel. Everybody builds their firm's special stadium bolt generator. And so, part of the bigger vision for Highpar is that we should be able to support a more open community where instead of there being all these scripts and plugins floating out there in the world, stuff can live on Highpar and evolve and grow and be accessible to other people. And you don't have to worry about, oh, do I have this version of this plug in in order to open this and run it? But I think there's also significant cultural barriers to making that vision a reality.

C I think we have to get over this mindset that our design approach is this, like, secret IP that if somebody just, you know, peeks over our shoulder, they'll be able to reproduce it. I think that's not the level at which architecture's value operates.

A I guess back to the earlier question then, you know, who is the ideal user of Highpar? Do you tend to or do people who gravitate towards this kind of open source sharing tend to be a part of the community? Or do you find yourself, like, working with firms and then asking, yeah, can we post that to our library? And I'm going, I don't know.

C It varies like crazy. We have a wide range of these kinds of interactions. There's a there's a vibrant of community of people who are just making tools and putting them on High Bar and making them available to everybody for free, which is really exciting to us. We wanna foster that community as much as we possibly can. We also have special partnerships with various firms. I mean, and I should say, anybody who builds a tool in hyper, you can just have it be private by default. That's not a problem. You can you can protect it or make it only available to your collaborators or whatever.

C And so a lot of folks use it that way. A lot of the firms that we work with build out an internal tool set, which is sort of their patented approach to, you know, facade design or HVAC or whatever, and that's kind of their thing. But we're about to release a new kind of market place layer on HighBar, which will function a little bit like an app store, which is sort of the sweet spot in the middle there where a practitioner or a firm could put together some logic, say, this is our stair core tool, make it available on HighBar, but people who use it on HighBar have to pay some small amount to take advantage of it, and then the creator of that tool gets income from it. So it remains to be seen what kind of effect that will have, whether people will gravitate towards this, and all sorts of things will start springing up or what. But I'm excited about the possibility that there's a way to sort of like share, but not feeling like you're giving away your labor for free.

B I always think about, like, the people that gravitate towards this type of work. Like, what what motivates them? And so you've touched a little bit about that. But I'm also interested to know, like, when was it that you made the jump away from being part of that computational design group in the studio? Like, what pulled you into actually fully transitioning into this direction that your career has gone?

C Yeah. I mean, I I think it happened gradually over time. Even my first job at NBBJ in Seattle, you know, I was working on design teams. I was a part of designing specific projects in a studio, but I was also building, you know, firm wide computational tools. And I think the thing that kind of drove my shift more and more to the the kind of generic was recognizing that, like, I could have a greater impact by really focusing on stuff that was stuff that was reusable. And first, you know, that meant when I moved to Woods Baggett in New York, I was, you know, only firm wide, only building sort of tools for for teams, and and the intention was that those tools would be available to all studios and and accessible that way. And, you know, I just I you know, there's this funny push and pull because I still I still like like the idea that, you know, my specific design intention could be realized in some final physical form, that I could design a thing and it could be manifested. And I've had to step away from that a little bit as my career has transitioned in this direction of code.

C But I also think there's this, you know, I've always had, I guess, a sort of unusual idea about what constitutes architectural authorship. And I feel like in some small way, being the author of a piece of code or a tool that was utilized to realize some project means that, you know, in a tiny way, I can be a part of all of those buildings. Like, everything that was realized using some of those tools or every project was conceived that way. And, you know, granted, no one's gonna look at that building and say, oh, yeah. That piece of software was, you know, involved in this one thing. But I still really like the idea that I can have a a greater impact on the built environment by furnishing tools to a wide community instead of just being limited on the impact I could have as sort of a singular designer working on singular projects.

A It's been interesting to hear your story because I relate so much to it. Like, I was never the best designer in school. I was never, like, winning top awards in studio for design. And I was trying to figure out where I fit in to this world of design. I worked at an architecture firm, and I revisit. Every time I'm down in Southern California, I just, like, swing by the last building that I actually, like, touched because I just, like, I you know, I there was there is a sense of, like, I did that. Like, I really left my imprint there on the community, you know, with that community center that I was a part of. So I do miss that.

A You know, so much of kind of what I feel like all of us do is for the love again back of the profession and moving it forward in a more meaningful way and finding our own path of how to do that within within the profession. Now I totally get, like, that sense of, oh, we left. We we made a choice to kind of leave the the physic like, the the pure physicality of of what architects do. And in a way, to to to support all architects more going forward.

C I think it really is about a a reframing of this kind of old school notion that the value in what's produced is like, oh, it's the it's the lead designer who made the napkin sketch. They're the one whose work this is, and the rest of us are all just helpers that made this thing happen. Like, I feel like everybody involved in the conception of a building, you know, should should feel some ownership over that as a as a product. And so, I mean, product is maybe the wrong word there. I just mean the sort of product of what they've created. So, yeah. I mean, I think that in general, it sort of follows from, I think, a more modern notion of kind of ownership and authorship that isn't stuck in this kind of black cape fantasy about what it means to be an architect.

B I totally agree. I mean, I relate too because I did marketing for so long. And, like, for example, every time I fly into SFO, I have 2 projects that I helped win there. And while I didn't work on the drawings and I didn't have to do all of the construction and CA, I still identify them as my projects because I helped I helped the firm get them. So, like, I'm like, those are my buildings out there. I wanna come back to coding because I I I hope we could touch on it briefly before we run out of time, but it's something that we always ask people who take these transitions into careers that are adjacent or outside of architecture about the skill sets that transfer. So I'm curious. Maybe we look at it both ways, but what skills do you see coming over from architecture that really transfer into the coding work? But, also, as a programmer designing tools for architects, I'm curious, like, what additional skills or point of view do you have that you're able to pull from that would be good for other programmers to know about the way architects think or they build?

C Yeah. Totally. I love this question. I think because there is. There's a ton of crossover. There's a lot that architects can learn from programmers, and there's a lot that programmers can learn from architects. I think, in general, the architectural skill set really excels in the areas of abstraction and synthesis. So architects are really good at abstracting this whole series of these, like we've talked about already, these complex conflicting requirements, and then kind of distilling them into salient details, building a mental model of how they all fit together, and then synthesizing them into this thing that unites them with a conceptual framework and makes it real and makes it work.

C And you absolutely have to do that in coding too. You have to be able to kind of operate at multiple levels, operate at multiple levels of abstraction and multiple levels of detail, and keep in your head a high level overview of the entire system and then also specific functional details, and and then be able to communicate it to others. I think, like, one important architectural skill that I find myself leaning on all the time is communication and visual communication. Like, I really love building diagrams of the algorithms that I write and putting them in the code changes that I submit to my team. It's like, okay. I'm gonna build you a diagram that sort of, like, expresses how all of this fits together and how it works geometrically. So I think that's a that's a really useful skill. In the in the other direction, I do think that, like, you know, for for architects to learn from from coding or from technology, I think there's a there's a skill of kind of systematizing, but architects are often kind of bad at.

C I think we have I already referred to it a little bit earlier, but this this tendency to wanna reinvent the wheel and and rather than recognizing a system that we built already and kind of building on it or improving it. I, you know, I I remember working as a designer, we would start the InDesign package from scratch on every project, like, every single time. And it was like, no. Let's let's understand, let's weigh the the actions we're going to take, the work we're doing going to do against the impact it's going to have. And I think architects often get sucked into a desire to design everything, reinvent everything, do everything better than we've ever done it before, and spend a lot of time on stuff that just ultimately doesn't matter. You know? Some nuance in a rendering that a client is just never gonna notice or care about or, you know, some specific aspect, even of the built work that, you know, maybe is meaningful to an architectural audience, but doesn't mean that much to almost any occupant of that building. So I think both systematizing and weighing the choices you make in terms of impact, trying to sort of assess the impact of what you're about to do before setting out to do it, and making decisions sometimes not to do particular things, or to do things maybe a little bit less perfectly than you would have wanted if it's gonna give you 95% of the ultimate impact.

A That's really great. I wanted to delve into kind of what where you see this is all headed and where the future is. My mind very quickly goes to web 3.0 and machine learning and AI, and how do you introduce whether, like, environmental systems into the computational design? You know, how do how do your test fits get smarter over time? Where where do you feel this is all headed?

C Yeah. I mean, so I have a gazillion things to say on this topic, but I'll try and keep it short. I think one thing which we at HighBar as a company are is sort of part of our long term vision. If we can succeed in building a tool that people adopt and start using, and if we can bring a community to that tool, then we have a massive opportunity, which is to actually use this platform to promote better building. We can, you know, highlight functions that are oriented towards sustainability, or we can give grants to creators who are going to bring in solar analysis or whatever, and make sure that, you know, software is always about making certain things easier than they were before. And if we can focus on making the right things easier, then we can actually have a huge impact on the built environment. We can make Piper the platform where it's easy to create good buildings in the world, and we can distribute that expertise to parts of the world that maybe have been underserved by this kind of architectural expertise by virtue of encoding, putting it on Hyper as some set of logic that you can interact with. So that's one piece of the answer I think is like the the future is definitely like getting opinionated about what's good and and leveraging a computational platform to make that happen.

C And then I would say stepping back from Highpar a little bit, you know, you mentioned ML, and, you know, I think this is a topic that I'm super fascinated by because I think there's also a lot of misconceptions about what AI or machine learning means for the future of architecture. And and I always try to have a nuanced conversation about this because I think some people's vision is, you know, the push button architect that, you know, architect robot that takes everybody's jobs away. And I just, you know, despite incredible advances in ML, I don't see that happening exactly that way. What I what I see changing is the way in which we communicate our intentions and decisions as designers to the tools we're using. So to give an example, not from architecture. As a programmer, I'm writing code all day. And I have a tool that just came out called GitHub Copilot. It was it's a little add on that was added to my code editor, and it is a machine learning model trained on this vast body of open source code.

C And with Copilot, I can just write like a plain English language comment, something like I literally did this this morning. This method should convert HSV formatted colors to RGB or whatever. I just write the comment, and Copilot predicts the body of the method and writes it for me. And shockingly often, it's correct. It actually produces viable code, and it does so. It's not just copying and pasting something. It's actually doing that in a with contextual awareness of my whole project that I'm currently working on, calling on all the right methods and tools. And it's moving incredibly fast.

C A new paper I was just reading came out where similar techniques to this are now enabling, ML techniques to fully solve competitive programming problems, like the kind, programmers get in interviews just by reading the English language instructions. It reads the instructions. It comes up with a code solution, and that code solution right now is performing at the level of the average human competitor. That's astonishing. And so, again, I don't think that necessarily means we just sit back and let the computers do all the work for us now. I think what it means is we have to get really good at expressing what we want in a concrete and unambiguous way, and that might be through text. It also, I think, might be through sketching. I think sketching and loose modeling is going to be an increasingly important part of how we interact with design software.

C Say, I want it to kinda shape like this and, you know, give me 3 variations on an 8 story mixed use project on this site with different program mixes, and then run the financials for me. And again, the output of that is not going to be a good building. It's probably gonna be a somewhat realistic building, eventually, but that doesn't mean it's gonna be good because inevitably, there are going to be aspects of what matter that just aren't gonna be encoded in the software. It's not gonna have enough information about the problem. This is what architects are good at. We're holding all of this conflicting and competing information in our heads, and we're not gonna write all of it down. So I think the trick then becomes, how do we how do we drive it? How do we steer it? At what point do we have to make specific manual corrections? At what point can we kind of rely on certain sorts of automated decisions on our part? And how do we still maintain control and intentions such that the spaces that we design really work, really work for people, really work for, you know, our clients and so on.

A That's really interesting. I do think there's this whole no code movement, like, outside of architecture. Right? Like, that all of these tools are being made so much more accessible to people who, like, just, 1, don't wanna take the time to code or, 2, like, have an interest but don't necessarily have the mind to wrap around the coding coding languages. So I guess that goes back to 1. But, anyways, Janine, do you wanna help us close out with the last question?

B I do. But I also wanna say that I'm sure there were some architects that were listening that are, like, sighing relief knowing that machine learning is not gonna take their job. They can still drive the design. I I do

A I mean, you know, so much of the work that I did was, like, community outreach and understanding, like, the their individual needs at that particular point in time. And I don't like, that that's never gonna be taken by machines. Right? And that context has to be reintroduced into the building, I think, you know, even after you quote, unquote press press the button.

C I will say because I also don't wanna be I don't wanna make the mistake of being a Pollyanna about this either. Like, this is gonna be radically transformative for the industry and, you know, there will be job loss of various kinds. Certainly, the the kinds of jobs that are rote and routine and are always exactly the same thing over and over again, those are at risk. And so I also think that professionals who refuse to engage with the new technologies are the ones who are gonna be made obsolete, you know, as as scary as that sounds. Like, I think if you can find a way to engage with this stuff productively and make it a part of your process, it's not any scarier than auto complete on your phone. Like, it really doesn't have to be. It's just there to sort of like guess your next move, and sometimes it'll guess wrong and sometimes it'll guess right. It'll save you some time.

C And I think if you are willing to embrace that, then you'll be in a better position to move as these things sort of evolve.

A Love the autocomplete reference and also kind of all of the, like, the means and stuff that evolved from the bad autocomplete. Right? So, not to say that this is going to remove frustration with software, but but I think understanding its limitations and how it can assist you is gonna be important going forward.

B I guess I have one more question before we go to the close. I'm so sorry. This is so interesting to me. Knowing some of the architects that I speak to just to the point about embracing or or resisting change, Evelyn has talked about, like, architects being at risk of being irrelevant if they don't embrace change. I'm just curious from your point of view, like, if our industry can embrace this, what do you think the growth potential is? Like, do you see this as like, if if as an industry, we embrace technology and we're willing to lean into it and we become leaders in this area. What growth do you see for the future of architecture?

C Yeah. I mean, for me, I see just the massive need around the world for quality. Let's just sit let's just focus on housing, like just quality housing or in general quality spaces, and especially in parts of the world that have been historically underserved by architectural expertise. It's not that buildings don't get built there, it's that they often, you know, because hiring an architect is too expensive or impractical, buildings get built worse. And so I think the growth potential is in being able to scale up the kinds of work that you do much, much more effectively. Being able to do quality design work at scale by only having to make the sorts of high level decisions that matter and leaving the rest of it to a machine to handle. And and things matter at all different scales. That's not to say, you know, just high level decisions.

C Decisions matter at all different scales, but, there are lots of decisions that are that ultimately follow from a few critical ones. And if we can just focus on the critical ones, then I think we can deliver a better built environment to the world much more effectively.

B One question that we like to ask all of our guests is what is your one idea that you wanna share with our audience, which includes architects, emerging professionals, and other industry disruptors listening? What is one lesson on change that's needed in the practice of architecture that you'd like them to think about today?

C One of the biggest lessons I've learned from the work that I do at High Bar and from, you know, the people that I work with is just and I I alluded to it earlier a little bit, this sort of relentless focus on impact. Like, really consider every choice that you make, every decision that you make in terms of what do I actually want to come of this? Because I think it's so easy to fall into the trap of doing this thing because it's cool or doing this thing because I like it or doing this thing because, you know, the client said whatever. And being able to just have this focus at, you know, from the smallest scale all the way up on what kinds of impact you want to have. It's just this incredibly perspective, and it takes a lot of the kind of like emotional stakes out of change. If something is changing that you don't like, you can, you know, reframe it in terms of, well, what is the what is the impact that it's having? What is the impact that I wanna have in response to that? So I think that for me is is a really important lesson that I've pulled away from working as a as an engineer is that we don't get, like, super emotionally invested in any particular feature or tool that we've put in. And, you know, we also don't go away and pursue a feature that's gonna take 10 months to complete only to find out at the end that it's the wrong thing. We try to have the most impact we can, and that means even doing things sometimes fast, but imperfectly in order to find out whether or not it's the right thing to be doing. And then if it is, then we can continue to refine and improve it.

C So it's a little harder once, you know, steel has gone into the ground, but I think the the sort of the the corollary to this impact focus is also a willingness to kind of like experiment and fail fast. Try things and really truly evaluate whether they're working and then react to that, make informed decisions on the basis of that rather than sticking to it if it's not working or, you know, whatever whatever else your instincts might be.

B Thank you to Arc IT for their support of this episode. Don't forget to visit get arcit.com/pd to set up your free 15 minute cybersecurity assessment or custom solutions for your design firm.

A Thank you again to our podcast partner, Monograph. Learn how Monograph can help you take control of your firm's financial health. Follow the link in our show notes or visit practice of architecture.com backslash monograph so that Monograph knows that you heard about them from us.

B Hi, disruptors. If you like the content from today's show, you can find all of our past episodes

A Be a part of the conversation by joining us, our speakers, and others in our community at practice of architecture.com/community. Our social media handle is at practice of arch. That's at practice of a r c h. We love to hear from you. Drop us a note to say hello.

B This show is part of Gable Media. You can learn more about other podcasts and video channels in our community by visiting gablmedia.com.

A Thank you for joining us on Practice Disrupted, a podcast by Practice of Architecture. Tune in next week for a new conversation on change in the profession.