Building Software That People Love

Building great software always involves technical problem solving, but the best software goes beyond function. It feels fluid, coherent, and genuinely fun to use. This quality lives at the intersection of engineering and design, and very few teams know how to reliably produce it. Metalab https://www.metalab.com/ is an engineering and design studio that has worked with some of the most successful companies in tech, including Apple, Slack, Uber, and Instacart. The studio is known for bringing together software engineering and design craft in a way that few studios can match. Wesley Yu https://x.com/wesleycyu is the VP of Engineering at Metalab, where he leads the teams that design and build digital products for early-stage companies. In this episode, Wesley joins Josh Goldberg to discuss how Metalab approaches tech stack selection for client projects, why agency work demands a bias toward boring and stable technology, how iterative development and deliberately ugly apps lead to better final products, and how AI tools are changing the boundary between design and engineering. Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Building Software That People Love https://softwareengineeringdaily.com/podcasts/building-software-that-that-people-love/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Building great software always involves technical problem solving, but the best software goes beyond function. It feels fluid, coherent, and genuinely fun to use. This quality lives at the intersection of engineering and design, and very few teams know how to reliably produce it. MetaLab is an engineering and design studio that has worked with some of the most successful companies in tech, including Apple, Slack, Uber, and Instacart. This studio is known for bringing together software engineering and design craft in a way that few studios can match. Wesley Yu is the VP of Engineering at MetaLab, where he leads the teams that design and build digital products for early-stage companies.

• 0:43Speaker 00

  In this episode, Wesley joins Josh Goldberg to discuss how MetaLab approaches tech stack selection for client projects, why agency work demands bias towards boring and stable technology, how iterative development and deliberately ugly apps lead to better final products, and how AI tools are changing the boundary between design and engineering. This episode is hosted by Josh Goldberg, an independent, full-time, open-source developer. Josh works on projects in the TypeScript ecosystem, most notably TypeScript ES Lint, a powerful static analysis tool set for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript book, a Microsoft

• 1:27Speaker 00

  MVP for Developer Technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on Blue Sky, Fostadon, and dot com as Joshua K. Goldberg.

• 1:52Speaker 01

  With me today is Wesley Yu, VP of Engineering at MetaLab. Wesley, welcome to Software Engineering Daily.

• 1:57Speaker 02

  Thanks, Josh. Really happy to be here.

• 1:59Speaker 01

  Well, we're happy to have you. Just to start us off, how did you get into coding?

• 2:02Speaker 02

  How did I get into coding? This is...I have very humble beginnings in coding. You know, in nineteen ninety-nine or early two thousands or something like that, there was this browser game called Neopets. I don't know if you remember Neopets, but essentially you care for these like virtual pets called Neopets, and you have this virtual currency called Neopoints. And you could create storefronts and sell items and stuff like this to earn this currency. And they allowed you to edit HTML and CSS. And so as a kid, I just kind of copy and paste stuff, change the text around to create a little custom store for my Neopets. So that's how I got started, very trial and error. I'm just a kid at this point, of course, so I'm not reading like W3C documentation or specification or anything like that, but that's how I got started.

• 2:45Speaker 01

  That's lovely. We have a lot of guests who played Neopets and went there. Do you remember how your store looked? Was it good?

• 2:51Speaker 02

  Yeah, I mean, it looked very kind of early two thousands CSS styling, a lot of sparkles, a lot of banners and things like this, text moving around. Yeah, it was a good time.

• 3:01Speaker 01

  Good time. Let's move forward a little bit. So you know how to code, shout out Neopets. What comes next? How did you get into professional software development?

• 3:09Speaker 02

  Yeah, I think in high school, I created some static websites for me and my friends, and we built little sites for things that we were interested in. We built like a little fandom page for Neon Genesis Evangelion, which is a very formative anime for me. But it wasn't really till college that I started putting some of these skills to work to pay my way through schooling. Like many people that came from non-traditional past into software engineering, I built WordPress sites for small businesses essentially. And for whatever reason, like I didn't really make the connection between coding, websites and my path in college and university. So I didn't actually study software engineering. I studied business and media studies in university.

• 3:43Speaker 01

  You've done quite a few things. You were a talk show producer. Did that involve any sort of tech and what was that?

• 3:49Speaker 02

  Yeah, yeah, that was my first job out of university was a like a radio news producer. So essentially that's finding interesting stories and guests for AM news talk shows for people's morning commutes. And around this time, I think it's kind of around twenty teens or something like this, lots of startups in tech were hiring people from media and journalism to become content marketers. So that's what I did. I got out of radio and then I landed this job as a content marketer for a tech startup. And that's kind of how I got my start in tech. I was immediately thrust into Y Combinator with this startup. And this was around twenty thirteen. And so we went down to Sunnyvale, California, and I was just surrounded by this ambition and energy of tech in Silicon Valley at the time.

• 4:30Speaker 01

  Do you feel fond memories about the way things were back in the day 10 plus years ago?

• 4:36Speaker 02

  Oh yeah, of course. I mean, I don't think I'd be able to do it today, but we all shared a house down in Sunnyvale. I slept on the floor, like in the hallway somewhere. We had our living room, which is just set up with a bunch of computers. So people were building things and I was writing like a big blog post at the time and things like this. So very fun time, like lots of ambition, lots of excitement. We really felt like we were building this tech utopia for the future.

• 4:59Speaker 01

  That's lovely. That really is idyllic. It sounds nice.

• 5:02Speaker 02

  Yeah.

• 5:03Speaker 01

  But moving forward, you are now a VP of Engineering. So somehow you switched from content marketing to engineering and leading engineers. How did that happen?

• 5:11Speaker 02

  Yeah, yeah. So working for this company, a little later, I think I decided, man, these programmers in tech, they seem to be having a really good time building stuff. And so maybe I want to do that, too. Maybe I can try to put some of this HTML and CSS knowledge to work. And so I enrolled in a coding bootcamp and I learned Ruby on Rails and then immediately got my start at MetaLab as an intern. And MetaLab being the company that it is, I think if you spend long enough there, you get a pretty good education from some of what I think are some of the most influential companies in tech, like the Slacks and Coinbase's and Instacarts and Ubers of the world was kind of how I learned my ropes in the industry.

• 5:47Speaker 01

  Do you remember it being particularly difficult or easy to switch over that kind of mental model? Instead of communicating through words, you're communicating through code?

• 5:55Speaker 02

  Yeah, I took to coding pretty easily. I think my brain just works that way. But I think I specifically found some more success in agency and specifically in MetaLab, just because of the background that I have in communication, breaking down these complex topics and processes and trying to communicate them to a lay audience is a very valuable skill. I think just in general for software engineering, but especially in agency, when you may be working with people that are not so focused on the tech, but more focused on the business of the product that you're building.

• 6:23Speaker 01

  That's really interesting. We should focus a little bit on MetaLab and agency work. What is MetaLab and what is the difference between agency work and let's say a startup or a traditional established company?

• 6:32Speaker 02

  What is MetaLab? Well, MetaLab, I think the way that I put it is we design and build digital products for very ambitious companies. I think we come in to help really early-stage teams to find their product DNA. And many, they later become household names, or we hope that they do. But our strength is very small, cross-functional teams in design and product and engineering, solving kind of problems for a small business. I think I've worked in-house as well, and I think the difference there is that you're less defining the business and trying to find a market in some sense, but you're trying to optimize some part of it. We've already gained traction in this business, and now we're breaking it down into its component parts and then making the whole workflow more fluid, more scalable.

• 7:14Speaker 01

  Let's take an example. You've already have had quite a few notable names like Slack, Uber, and so on. Let's take Slack, because I quite like Slack. What would you do for a company like Slack? Why would they come to you? And what is the kind of service that you would provide for them?

• 7:26Speaker 02

  Yeah, I mean, for Slack specifically, they had already built this communication system. I think everybody kind of in the industry at the time was using a tool called HipChat. When I was at this startup where I did content marketing, that's what we used for internal communication, HipChat. And when Slack came to us, it was positioning and branding to differentiate themselves in the market from these stock standard chat applications and to kind of revitalize this tool with some joy. And so it was less engineering. When we were working on Slack, it was more, okay, well, what does it look like? What does it feel like in terms of UI and UX? Because the functionality of Slack was already baked in there.

• 8:02Speaker 01

  You're talking about things that not a lot of engineers instinctively go to, like look and feel. What do you mean by feel? How does someone approach that for a product?

• 8:11Speaker 02

  What do I mean by feel? From an engineering perspective, like feel is how responsive does the application feel? How much intention can you draw from the user interactions, how they're moving the mouse to the screen? I think a specific example of that is like, if you're hovering over a channel, we may send an event to the backend to say, okay, let's preload that channel so that when you move over to that channel, all the content is already there. It's lightning fast. That's what we think about feel when we're talking about the engineering side of it. But when we're talking about the design, the experience side, it is Slack still has this, but we kind of had the ideation for this in the early days. Is this idea of the Slack bot where you're loading a screen? Slack will have some sort of funny message that it says and you can customize those messages.

• 8:53Speaker 02

  That very little business value to that type of feature, but it brings you a lot of joy when you're using a tool like that. Another example is like if you type something into Slack, Slack will do some sort of red jacks and then it will automatically post a message. So like, we might say, nothing to see here. And then Slack bot will respond with that gif of Abe Simpson, Homer Simpson's dad, kind of like walking in and out of Mo's bar. Like these types of fun things, we just didn't see in other applications back then. And now they're not stock standard, but they're a lot more common.

• 9:22Speaker 01

  Why are they common? How are companies justifying spending the time to make these lovely little things?

• 9:27Speaker 02

  Yeah, I think we have this benefit of people coming to Metal Lab that really care about the design and experience of the thing. They care about the joy of using the tool and not so much just the function of the tool. And so we self-select into these companies, into these people that care about these little experiences, these little surprises and touches to the product that are not just functional aspects of it, but aesthetic aspects.

• 9:49Speaker 01

  Let's say that I'm a company, I have a product and I don't have a lot of delight or joy in the product. Let's say you really wanted to work with me. How would you try to convince me that it is worth it for my business, for my users, for my bottom line to employ Metal Lab to add more Simpsons gifs and such into my product?

• 10:04Speaker 02

  How do we convince you to add delight into your project? You know what? I think that when people come to us just because of our reputation, they don't really take a bunch of convincing. In fact, we need to convince them out of some of these moments of delight in order to get the core functionality in place. It's like, okay, the trade off of adding this delightful feature is the omission of some functional feature. And so we sometimes have to argue for the functional thing over the delightful thing. But yeah, we're in this great position where people come to us and by default, they want this type of experience for their applications.

• 10:36Speaker 01

  Must be nice having people come to you because they want and enjoy what you're able to provide and advocate for.

• 10:41Speaker 02

  Yeah, yeah.

• 10:42Speaker 01

  All right, so we've talked about the high level what is. I want to dive a little bit more into the tech stack side of things. You're an agency, which means you might not be controlling your project for a full decade the way the client company might be. So how do you make decisions around engineering, knowing that you are more of a short-term player in a long-term kind of game or product?

• 11:00Speaker 02

  Yeah, I think the longer that you work in agency, the faster you settle into choosing the most boring, stable technologies for your clients. When we were a much smaller, a much younger shop, many of our clients were people that had a business idea, but they didn't necessarily have strong opinions about technology. So a lot of the technology choices back then were driven by what we wanted to learn, what we wanted to try in production. So in like 2010, Middle Lab was still largely a rail shop, and we were using the hottest JS frameworks to ship more and more client-side code. So I think we tried everything under the sun back then. I think we were very hipster in using CoffeeScript, and we were trying to knock out JS and Ember and Backbone and things like this, and very early adopters of React and GraphQL using Facebook's Relay project.

• 11:46Speaker 02

  Anyway, it was this type of experimentation that I think actually landed some of our biggest clients. So we worked with Walmart for 10 years, doing design development across their whole digital footprint. And that contract actually started because someone at Walmart was using Backbone, and our CTO at the time, Jason Webster, was an active contributor to the project. And so they were like, hey, you know, we're using this technology, you're clearly contributing to this project, can you help consult for us? And that became a 10-year-long relationship. And people say open source isn't really paid, but in our case, this partnership gave us some pretty reliable revenue to take risks on smaller projects and startups in the early days, and some of those clients became runaway successes.

• 12:23Speaker 01

  Do you have a favorite, fun, hipster JavaScript thing that isn't around anymore that you wish were kind of more prevalent?

• 12:31Speaker 02

  That's a good question. I was a big fan of Meteor back in the day. Like, I was just, I thought it was like the JavaScript version of Rails is how we would put it. Like, you could just build something super fast. That's not around anymore, but I wish that something like that was.

• 12:45Speaker 01

  Let's say that I'm a client and I have a business idea and not much. What would be the framework for decision making around tech stack that you would give to me? Or how would you help me find the right tech stack for my project?

• 12:55Speaker 02

  Right. Yeah, we have it down to a pretty straightforward decision tree, I would say. One of our team members actually just turned this into a CLI tool that you have a little conversation with. Like, you answer a bunch of questions and then it spits you out a tech stack and it does a bunch of boilerplate stuff for you. But we typically select tech stacks based on the needs and capabilities of the client and the product. And really in that order, it's like, what is the client capable of maintaining and then what does the product actually need? So for the client, we ask the question of what technology does their team already have skills in? And then what technology can they reasonably hire for in their geography? And I think this geography piece is kind of important. This is more anecdotal, but when we've worked with companies that are European based,

• 13:38Speaker 02

  they typically want backends that are written in Java-based frameworks. So like Spring and more commonly Spring Boot, just because that's what their universities produce. And so this is kind of part of our decision making as well. And we care a lot about what technologies actually energize the technical leads of our client team when we're choosing these things. Because I think a stack decision is not just a technical exercise. It's also a hiring plan and an onboarding plan. And what does it mean to support this thing at 2:00 AM in the morning? That all goes into selecting the technology that we want to use. And then when we're evaluating on the product lens, we think about speed to market. If we're building iOS and Android applications, we look at cross-platform tools. If speed to market is a big concern and understanding kind of what the performance requirements of the application are.

• 14:24Speaker 02

  Using cross-platform buys you a bunch of calendar time, but I think that native still wins when the product's performance is still core to the product.

• 14:32Speaker 01

  Does this mean that you hate Expo or hate NextJS or any of these other tool chains?

• 14:37Speaker 02

  No, I actually love them and they're like a core part of our technology stack. I think Expo has come a really, really long way in its time. And yeah, it's made things far easier to develop in React Native.

• 14:47Speaker 01

  Hopefully that will have been the closest to a gotcha question you get during this interview.

• 14:52Speaker 01

  I really like how you're phrasing not just the technical values of different areas or tech stacks, but the longevity of them and the way that they interact with the people and the organization around them. Like, the 2 AM trade-off is different than the in-your-garage-at-4pm. Do you have sort of a decision tree, subtree for when you might prefer something new and shiny and maybe better suited to a problem, rather than the tried-and-true and more well-known approach?

• 15:18Speaker 02

  Yeah, it is, I think, more rare that we would choose something that is unproven, unless the client is really advocating for something like that. I think we build a lot of MVPs at Benelove, and so our preference for building these kind of first versions of products is a modular monolith. And I think when we're trying something new, specifically on the backend, we like to build little sidecars, and we may use new technologies for those sidecars. So if we need really fast, real-time WebSocket behavior, we might use something like Elixir or Phoenix in this sidecar. And it's more isolated, it's something that you can change around, and it's not so integrated into the entire stack that it would be challenging to replace. And so we like to limit risk, consolidate risk into these little isolated areas.

• 16:02Speaker 01

  Let's move up in scope a little bit. You were previously a ground-level engineer, now you're VP of Engineering. What does that mean at an agency or doing design agency work when you are leading engineers? How do you lead a group of people who are pulled between such different projects?

• 16:17Speaker 02

  Yeah, it is, at the level that I am right now, especially for an agency, we look a lot at the pipeline of clients that are coming in, and we try to find efficiency in the pipeline, trying to match the skillsets and capabilities that we have available, the expertise and industries that we have available with the clients that are coming in. And so we may be doing a lot in dating or in healthcare. It's like, okay, well, we want to leverage that experience that we have on current projects into future projects. So it is that coordination sometimes. So we may think about industry in that way. We also think about tech stacks. So our team works across lots of different tech stacks. You may be working in React Native, or you may be working in Swift or React. We kind of like to chain projects so that you've built a ton of expertise in React Native,

• 17:00Speaker 02

  you've built all these efficiencies, we're going to try to put you on a React Native project as your next project, maybe in the same industry as well. And so we gain lots of efficiencies that way. So this type of organizational efficiency is a lot of my concern.

• 17:12Speaker 01

  See, that's interesting. I would have expected the, if you've done React, continue to do React. But within the same industry, why is, for example, dating or healthcare as an area of projects nice for people to stay working in? Are these apps not very different?

• 17:28Speaker 02

  It's nice because specifically with healthcare, there are a limited number of EHRs, electronic health record systems, and we have our preferred EHRs that we like to use when we're building healthcare applications and things like this. And the analogy that I like to use when I used to develop a lot is that I would work on like a Ruby on Rails project. Ruby on Rails has all these magic methods and functions and yada, yada. And then you move away and you go like, go to work on a Node project. You come back and you just forget a little bit about all the intricacies of this framework that you're working in. I think it's the same when you're working in different industries as well with platforms that we commonly use to implement things, specifically EHRs, is that you just have a sense of where the edges are and what all the

• 18:09Speaker 02

  different solutions are. And when you come back to this type of industry in a year, you do kind of lose some of that reflex. And so that's why we kind of like to chain these types of projects together.

• 18:18Speaker 01

  That makes sense. I might imagine that some industries have very important, specific gotchas, like healthcare with HIPAA laws and privacy and whatnot, that you really want to make sure you don't forget between projects?

• 18:29Speaker 02

  Totally, totally.

• 18:31Speaker 01

  I want to ask you a two-part question here. There are some skills that tend to be better for certain kinds of work. Like, let's say there are skills that may be better for short-term or external projects versus skills that perhaps are even opposite of those that are better for long-term or internal projects. Do you see anything in particular that someone might want to understand being better for one type of project versus the other for, let's say, a grad-level engineer?

• 18:53Speaker 02

  Yeah, I think on like the individual contributor front, people have different defaults. I think at MetaLab, we work on a lot of initial builds, V1s and MVPs, and that process is a process of iteration. And so I think a really great skill is being okay delivering an ugly app. An ugly app is you build out the full flow from start to end, and the screens that you build in between, sometimes they just render JSON and a button, and you're able to move through. And you iterate. That process you work with design to say, okay, this screen is JSON. What is the best user experience to present this data that we have on this screen? And I think that can be a hard thing to overcome for some developers because they are more focused on perfection. They want to know

• 19:37Speaker 02

  how is it going to feel? They want to present like the best version of themselves in the screens that they build. And I think that's a hump that you have to get over when you're working very iteratively for these startups. And you need to be okay with delivering ugly applications as opposed to something that is more refined.

• 19:52Speaker 01

  How do you know when an ugly app is okay? Are there types of clients that will react negatively, even though it might be the technically right strategy at the moment?

• 20:00Speaker 02

  Yeah, I do think that clients appreciate the ugly app, but you do need to prepare them for it. Like we do a sprint demo and they're like, okay, what is this text on the screen that I'm seeing? That has all of these squiggly brackets and things like this. But what they appreciate is being able to move through the whole experience and then being able to reorder some of those screens. And you do start to see the project come to life. Screens start to be refined. We go from JSON to wireframes to some sort of mid fidelity that doesn't really have brand applied to something that is high fidelity. And I think what is valuable showing that process is they get a sense of the speed and complexity of each of those features. But when you show just the final product, clients, they don't get that education.

• 20:43Speaker 02

  They don't understand all the work that led up to this beautiful thing that you're seeing at the end. But we like to open up the curtain when we're working with the people that we work with to show them the process because it is also part of the value of working with MetaLab. We want to help build the DNA of this process that we have of building applications.

• 21:01Speaker 01

  And it must be nice to be able to see the iterations and make adjustments to the DNA in progress, right? You're not just giving them one final thing and calling it a day.

• 21:09Speaker 02

  Yeah, exactly. And I think you get to see the gaps or the shortcomings of the initial idea or approach. When you're able to see something end to end, right at the very start, you start to think, okay, well, what if we change this? I feel like maybe that would feel better because it's easier to see the next step ahead of you once you've done the first step. But when you're trying to get to the end and you haven't accomplished any of the steps, building one chunk in a perfect way, one after the other, gives you less room at the end to make adjustments. And so that's why I like to build these ugly apps.

• 21:40Speaker 01

  More ugly apps. This kind of matches a large trend over the last decade or two in industry, though, right? That we aren't doing waterfall style development. We're doing agile or some sort of iterative strategy to allow ourselves to see these gaps and learn as things are coming along.

• 21:54Speaker 02

  Yeah, that's right. And I'm a big fashion and textile nerd. I think like the analogy that I like to use is it's like drape tailoring. Like you hang a piece of fabric over a body and you start to tailor based on how the fabric hangs. And that is like a far less repeatable process than creating a pattern and then cutting that out and then putting out a body. You really are push and pull things as you're building it out to kind of perfectly tailor it to the solution to the body that you're working on. And I would describe that as the iterative approach, whereas when you are cutting out a pattern, that is very much the waterfall approach.

• 22:30Speaker 01

  That's a beautiful analogy. Every body is different. Every person's preferences and experiences, and even year to year, their needs are different. It's kind of a beautiful way to think about software.

• 22:39Speaker 02

  Yeah.

• 22:40Speaker 01

  Speaking of beauty, I've heard other people describe projects that they take from inception to completion as their babies. You know, that's the common phrase. This this feature is my baby, or this app is my baby. A lot of people feel a sense of sometimes approaching what they think is parental instinct or affiliation or love for their projects. Do you think that in the agency world, you have that? Or is it harder to develop that when you're working on so many different projects?

• 23:06Speaker 02

  No, we definitely develop this parental instinct. You know, at MetaLab, we, you know, and maybe different from other agencies, we made the decision that if you are working as a developer on a project, you are working on one project at a time, so that your full attention is on this thing that you're building. Because of the iteration that we're doing, because we're defining a business for a client, it's hard to split your time across lots of different things, between lots of different contexts. So you do very quickly become very attached to the thing that you build. And when it comes time to hand that project off, you know, slowly back to the client's team, or maybe we help them hire a team to maintain this application, or build a V2, or build a V3. That can be quite hard. You know, you're interviewing this person.

• 23:50Speaker 02

  And you just have to make sure you're finding the best foster parent for this thing that you've built. You want to make sure that your values are aligned and then sometimes they're not and they'll look at the application and say, you know, I'm going to change this, that and the other. And it's a little heartbreaking sometimes because it's not always easy to convey, you know, all the steps of the process that got us to where we are today. To this person that is going to take it over in the future because, you know, everyone has their biases. Everyone has the ergonomics in which they like to work in the code. And so we very much become these parents for these children that we build.

• 24:21Speaker 01

  This might be relevant for many different areas of engineering. Do you have tips for handoffs to make sure people understand why things were made the way they were?

• 24:30Speaker 02

  My biggest tip for handoff is to work with the person that is going to be working on this project as early as possible. And so we don't like a cold handoff. A cold handoff is we have no idea who's going to maintain this thing in the future. And so we leave a lot of comments in the code. We record a lot of video walkthroughs of the code base and leave a lot of documentation and readme's and lots of little directories and stuff like that. That's like the worst case scenario, I think, you know, you can only convey so much through documentation. What we like to do is we like to run, you know, three or four sprints with this person. So that they understand the way they work, where they they're in the PR reviews with us, they're making some technical decisions with us. And then this kind of gradual, what I would call like a hot handoff or a warm handoff to projects.

• 25:14Speaker 02

  So my biggest tip is, yeah, as much as possible, work with the person that is going to be maintaining this thing. That's not always something that we can do, but that is our preference and we always kind of advise our clients to make those hires early. So that's the decisions that we're making are aligned with the decisions that that are the default, kind of the biases of the person that we're going to be working with in the future.

• 25:33Speaker 01

  That's an interesting use of terminology. You just said the word biases, which much like tech debt is often kind of a negative word or a bad thing in industry, but you assigned, it seems, no negativity to it. It's just a fact of life biases in tech?

• 25:47Speaker 02

  I think so, like, you know, everyone has kind of, you know, ergonomics to the way that they like to set up their desk or even their desktop on their computer, what types of terminal commands they like to use, how they like to navigate. You know, those biases are neither good nor bad. But when you start to engrain these types of things into a codebase that you need to see every single day, it can be a little bit grating when you're looking at something that doesn't feel ergonomic to you. And so that's why we like to involve the person that is maintaining this thing. We want to include their biases in this process because, you know, we know we're not the ones that are going to maintain this long term. We want to set this up in a way that fits well with them. This is kind of part of draping a cloth over a body. That body is not just the business or

• 26:31Speaker 02

  the product, but also the people that are going to be working on this in the future.

• 26:35Speaker 01

  That makes a lot of sense. So far, we've talked a lot about the engineering and the tech stack side of things, and then the kind of client to everyone handoffs and the way y'all work together. I want to switch topics a little bit for a little bit to talk about the design side of things. You are particularly integrated between design and engineering. How does that look for you folks? And how do you integrate design so heavily into your process that it comes out really beautiful and delightful?

• 27:00Speaker 02

  It is something that we are figuring out still. I think, you know, we found a way to do it through like very specific artifacts. And I think that the most important artifact for us for collaboration between design and development is, I guess, what we would describe as a service blueprint. So service blueprint is all the different user actions, all the different backend actions, all the kind of back office things that need to happen from the start of the application, when a user first authenticates or creates their account, to the end of the value chain of this thing. And that's the thing that we align on first. Okay, you know, what are the core experience? What are the big beats of this application? And how are they supported by

• 27:41Speaker 02

  technology? And what are the user behaviors, the user intentions that are driving those things? And we come up with that process really, really early in our projects. Sometimes we make an estimation of what that might be when we're estimating or scoping something before a client has even come to the door and signed a contract with us, just that we have a really good sense of how we're going to hang different behavior, how we're going to hang different interactions onto this product. Once we have something that we can collaborate on together in this artifact, it makes collaboration far easier. One of the analogies that I like to use is the analogy of producing a season of television. And so when you're producing a season of television, the writers come together and they think about the big beats of the story that they want to tell over the season.

• 28:25Speaker 02

  And there's no dialogue happening right now. There's kind of characters that that are going through different arcs. You just know, okay, this event is going to happen and then this event is going to happen. This event is going to happen. We're going to tie that through the story. And then you start to write the episodes. You go, okay, now we're going to do episode one, cold open, act one, go. And the design teams, they know where they're going. And the engineering teams, they know where they're going because this structure has been put in place. And so that's, we follow a similar structure when we're building applications at Metal Lab.

• 28:54Speaker 01

  The second very good analogy you've given, do you personally find yourself jumping to analogies as a form of explanation? When you have a really good one at the ready?

• 29:02Speaker 02

  I think it's like an instinct or a reflex from, you know, my AM news radio production days. It's like you need to be able to translate complex ideas, complex topics, complex processes into things that people they already understand or they're already internalized. And I think the analogies are good. They're not always one to one. Like sometimes you can just completely butcher an analogy, like if you try to take it too far. But I think they're a really helpful tool for getting people into the space of thinking about things in the right way.

• 29:30Speaker 01

  How do you manage the internal handoff then from the early stage folks to the later stage? Like in your analogy, the folks writing the beats of the story to the folks writing the dialogue, even if they're the same person, there's kind of a different way of thinking about those two areas, right? How do they inform each other?

• 29:46Speaker 02

  Yeah, our teams that start projects, you know, we do, you know, a phase of discovery, understanding the industry. And then we do a phase of what we call product definition, which is creating the beats of the story. That team is usually pretty small, but then we grow that team. And so, you know, we're not changing out those folks. We have a very kind of clear through line from the start of the project to the end of the project in these leaders that conceive of the idea. They're the ones taking the idea through execution as well. So they're rolling the boulder up the hill in these first two phases of discovery and product definition. And then they're rolling the boulder down the hill when they get a larger team to implement the thing.

• 30:21Speaker 01

  Just on a personal level, do you prefer at either side of that hill or particular areas of Boulder person?

• 30:27Speaker 02

  I mean, rolling the boulder up the hill is always the hardest part. And I think it is hard, but it is also the most rewarding in my mind because, you know, you have to be very comfortable with being in, you know, very messy, ambiguous parts of a project of a business, not really understanding your users. You have to try to understand those. You want to understand, you know, what their problems are. You don't really understand the dynamics of the business yet. And so that stuff is all really, really hard. But it's also where you learn the most about an industry, about people. And so it can be hard, but it's very rewarding. The other side is also fun. I, of course, have gotten away from the actual implementation of things for a little while. You know, there's a joy to banging up code and solving very technical problems. And so, you know, my preference, of course, is rolling the boulder up.

• 31:10Speaker 02

  But rolling the boulder down has its own joys. You get into the flow of things a lot more when you're rolling a boulder down the hill, kind of like skiing down a hill or something like this.

• 31:19Speaker 01

  You got momentum behind it.

• 31:21Speaker 02

  Exactly, yeah. Not to say that rolling boulder down a hill is a straight path either. I think like sometimes you get little bumps and sometimes you have to roll a boulder up a hill to get down to the other side and things like this, too.

• 31:31Speaker 01

  To quote Polinsky, every comparison limps.

• 31:34Speaker 02

  Yeah.

• 31:35Speaker 01

  All right. Sometimes in product development, there is a beautiful design that has incredible value. It's just really a lovely thing for the client or user. And then the cost of it is obscene. Do you have particular strategies for dealing with incredibly beautiful design that would take three years to implement?

• 31:53Speaker 02

  Absolutely. We see this all the time. I think one example of this behavior is that we're building an application for collectibles. And one of our designers, who's a big Magic the Gathering collector, as am I, I love Magic the Gathering. He's like, I want to build this experience where it feels like you're flipping through this binder of cards. You know, I want to create that experience within an application. And then we show it to our React Native developer and he's like, I don't know, man. I don't know how the hell we're going to do this. And so the process there is very collaborative. They're sitting right next to each other. And our developer is like, okay, these are the constraints. This is what I think that I can do. And then the designer is poking through the application, this prototype. And he's like, okay, well, you know, I like this, but could we do?

• 32:36Speaker 02

  Do it like this and then it's thinking about really pushing the bounds of creativity on the engineering side. And it's through this process of iteration that we land on something that is in between. This crazy binder experience that the designer has in their mind and then, you know, what is easy? Or what is kind of the default for, you know, a reactive developer to implement? And you find somewhere in the middle and they really challenge each other in their respective disciplines.

• 33:01Speaker 01

  Trading card games like Magic are so interesting from a product and design standpoint, right? Because they're a thing that inherently is tactile that you, as the player derive a lot of joy from, you know, the flipping, the shuffling of decks, the, you know, saving draw at the end of a long match. But then you have to turn it electronic. How do you, just from a designer product standpoint, how do you capture that joy and magic of a tactile thing in electronic form?

• 33:23Speaker 02

  Yeah, yeah. Every interaction needs to have some sort of physical reaction. Tapping on something produces some sparks or something like that, like you kind of have to to build the physicality back into those experiences. I think you provided some examples about when you're playing the game and things like this and shuffling a deck. But I get great joy from opening a booster pack and like revealing the cards and things like this. And so we have to try to make that kind of as pleasurable experience as possible, like a visually stimulating experience. Cause that's kind of what you have to work with. We tried some stuff like with haptics and things like that. But I've always found that when you're like, you're opening a pack and your phone vibrates and things like this, or the lights go off and they feel a little bit out of place. They feel like, you know, my phone is vibrating. Oh my God, what is going on?

• 34:07Speaker 02

  Can't have anything to do with this application, but that's why we kind of rely more on visual aspects of things.

• 34:12Speaker 01

  There was a lovely period of time with apps when people discovered the haptics and then every app interaction was vibrating, you know?

• 34:19Speaker 02

  I'm just shaking.

• 34:20Speaker 01

  Yeah. You also brought up an interesting point that I think is a very good segue to one of our last areas, which is designers and prototypes. A lot of designers nowadays are slowly starting to, in a sense, code with AI or other tools, you know, low code, no code code generation. Do you see there being a kind of direction that you like or don't like with having designers create their own prototypes?

• 34:44Speaker 02

  I like it. I think the canvas of Figma can only get you so far. It's not until you really start to click or tap on the interface that you understand the economics of the thing that you're building. And so I really like the idea of designers prototyping things in code. I think we're getting to this place where we are trying to create the scaffolding of an application enough so that a designer can commit real code, production code, to an application. And when I say commit to production, you know, there is still the review process of a developer to ensure that it works. There maybe is a complete reimplementation of what the designer has prompted into Claude code to produce a PR. But we're thinking about, you know, what is the scaffolding that we need to build? What is the baseline

• 35:29Speaker 02

  that we need to build in an application such that a designer can get to a point where they are also prompting Claude code to create PRs? And some of that is understanding what primitives exist in the application. What does the database look like? What functionality do we need to build in that a designer might not be able to prompt into existence so that the application still functions end to end and they're able to add their touches to it on the UI UX level?

• 35:54Speaker 01

  Wesley, I'm a front-end developer. Can you please expound on that and help me feel comfortable that my job will exist in two years?

• 36:03Speaker 02

  I think that the important thing is, you know, not just prompting things in existence and getting things into production, but when there is an issue with something or when you need to make a small change to things, you still need to have a codebase that is scrutable, that is inspectable, that you can go in and actually make changes to. And so, setting up that foundation, setting up that directory structure, creating clear boundaries between things, that is still very much relies on years and years of experience from a developer. And so, I personally don't think that there is a risk to losing jobs and things like this. We just kind of, we have a new medium in which we're collaborating in. The canvas of Figma becomes a little bit less important. You maybe are kind of drawing things on paper and figuring things out, but now, the material that you're working

• 36:48Speaker 02

  in is less in Figma, the delivery is less in Figma, it's more in code. And I like that a lot.

• 36:52Speaker 01

  Suppose I'm a client and I'm thinking, well, yeah, everything you said is true, but also I could just use AI to figure out what are the delighters and figure out my new designs. So I guess from another perspective, say I'm a designer, how do you make me feel comfortable that my job will exist in two, five years?

• 37:06Speaker 02

  Yeah, we have recently been using Claude Design and these design tools and Figma MCP to get things from Figma into code. You know, I think when you start to use these tools, you start to see the sameness that these tools produce. And very quickly, you're able to spot, you know, as a human, we're pattern recognition machines, what was generated by AI. I think we're getting less good at determining kind of photography that was generated by AI, like we're fooled quite a bit, but we don't need to see too many examples of AI-generated photography to understand that this was generated by AI. And once you're able to see that as a consumer, the value of that thing decreases a lot.

• 37:48Speaker 02

  And so I think there's still this human touch of this was created by a human and I can tell because like an AI would never do this, or there's this blemish to this thing, or that's new, I've never seen something like this before. That I think is going to be increasingly important.

• 38:04Speaker 01

  What we often see is that when something can be newly produced at scale or in a particular way, a lot of the time, you get this counter or reactionary aesthetic right afterwards, where instead of, let's say, large sheets of glass or sameness in buildings, you have these intentionally different, or almost to use your word, blemished things that bring joy because they are not the same as everything else. Do you see any examples of that in the wild with design or even code that you've come across?

• 38:28Speaker 02

  I don't have any specific examples to point to. It does feel intuitively true that things that take higher effort to produce, things that are not mass-produced, have greater value. And so, you know, the blemishes that I talked about are a bit of a marker that something was done by hand or conceived by hand and not purely conceived by some sort of AI machine.

• 38:47Speaker 01

  Love that very much. So what is your role kind of moving forward, the next five, 10 years, either you or MetaLab in general? How do you see the world of design and product, perhaps even agency versions of that, moving forward now that we're able to kind of shift and make the act of designing or writing code, this sort of new AI-enabled age of it?

• 39:06Speaker 02

  My role is a little bit split. I think part of it is understanding what trends we should pursue, what we should build expertise in. And I think My biggest learning so far in the last year or two is that building on the frontier is really hard and risky. You spend a lot of time building bespoke things that you end up needing to throw away because the industry standardizes around some sort of tooling. So some things that we have sunk a massive amount of time into is eval frameworks for L L Ms. We'd probably use something like Langchain or Langfuse. If we were to do it again, we wouldn't build something bespoke. But when we were starting on this journey, we didn't have those tools or those tools were more nascent. We experimented a ton with MCP for when that specification first dropped.

• 39:50Speaker 02

  And we created lots of custom MCPs like for Notion and Figma and things like this. And then, of course, these companies release their own MCPs later and they're better. And we largely discard our own solutions. But yeah, that's what it's like to build on the frontier. And so part of my job is understanding, what should we invest in? And then what should we just wait for the industry to figure out for us? On the other side of things, on the non-tech side of things, it's figuring out how to optimize our organization around the tools that we have available. And I think the analogy that I like to use is it comes from a Japanese bakery. So you walk into a Japanese bakery, they've got dozens and dozens of different types of pastries and baked goods.

• 40:31Speaker 02

  And Japanese people don't like cellophane or anything around these baked goods when you're buying things. It's more joyous to walk through this thing and pick off baked goods and put them on a tray. But the problem with that is that you bring it to a register and you have this, what you need is a very skilled person manning the register to understand what all these baked goods look like, to punch them into a cash register for you to check out. And so what this bakery in Japan did was they built a vision model and they said, okay, well, you're going to put a tray in front of a camera and it's going to calculate all the different types of baked goods and give you the cost that you need to pay. And the job of the person at the register is service, human interaction between you and the customer.

• 41:14Speaker 02

  And that's the kind of experience that I want to build at MetaLab over the next few years is, okay, what are the kind of non-human things that we can automate away so that we can provide a service and an experience? Fun that preserves the human aspects of working with other people while we can leave the specification, writing, the documentation, the meeting notes to services that can summarize, that can turn it into material that then turns into things that we want to build. We want to kind of optimize for this conversation, this interaction between humans. That's where my focus is right now is, you know, using tools kind of like granola and turning that into tickets and linear and pushing and pulling things, but having more human interaction is my goal.

• 41:56Speaker 01

  That's so interesting. By rolling out all these LLMs and agents and such tools, you're not increasing the amount of roboticness in our lives. You're actually decreasing it by getting rid of the existing stuff so you can focus on what's important. Am I interpreting that right?

• 42:10Speaker 02

  Yeah, yeah, exactly. You know, there's a lot of busy work that you need to do to run a business and we want to do away with that. We can surface the things that are really fun. The really fun things for us is working with other people.

• 42:21Speaker 01

  You might have already answered this second to last question, but what are you excited about in this new world? Within the fun stuff, what's particularly fun for you?

• 42:28Speaker 02

  I love building things. I love kind of, you know, I have lots of big lists of side projects and things like that that I want to do. And so I think it's been incredibly fun to use these tools to bring some of those ideas to life and also very quickly see where all these great ideas that I have in the list are actually all bad ideas. I think that's kind of fun, too. So I think it's awesome that you can build tools just kind of at 2am on your computer.

• 42:51Speaker 01

  Nothing is quite as joyous as having a side project idea, getting to prototype it, learning why it's bad and realizing you're no longer beholden to that idea. You don't have to spend your time on it.

• 43:01Speaker 02

  Exactly, exactly.

• 43:02Speaker 01

  Lovely. Well, Wesley, we've talked about a lot of really cool stuff. I'd like to end every interview with one or two questions that are kind of palate cleansers, explicitly not technical. I actually have two for you. First, and please explain this for people who don't know anything about Magic the Gathering. If you were a commander and you had to choose a set of colors, why are you these particular colors and what would they be?

• 43:25Speaker 02

  Okay, I am just all blue. I like to play magic, but I like to be the only one that has fun. So, blue is this color that's each player in Magic Gathering performs actions and you know, try to whittle away someone's life. Blue's color, you know, is all about preventing people from doing things. And so you prevent people from doing things enough that you eke out a little bit of an advantage and you win the game in that way. And I kind of like that.

• 43:48Speaker 01

  Why are you like this? That's the worst option, the worst answer to that question.

• 43:53Speaker 02

  I know, I know. I'm sorry. I don't know why I'm like this. It's just, it just gives me joy.

• 43:58Speaker 01

  Great. Let's move on to the actual last question. We talked about this before the interview, and I'd love people to hear about this. What is magic to you? And can you tell us about the art of performing magic for people in front of you?

• 44:09Speaker 02

  Yeah, sure. Like, one of my actual first jobs was my friend and I started a business performing magic at children's birthday parties. And this was right around the Harry Potter boom. And so we really rode that way. People were really interested in magic back then. And so, yeah, we were really interested in buying tricks and we would perform magic at birthday parties and then we would use that money immediately to buy tricks. And what is magic to me? Magic is creating something that is seemingly impossible, but by doing it through means that no one would expect that you would put that much effort into. I think like a really good example is a type of trick called a book test. A book test is that, you know,

• 44:49Speaker 02

  someone chooses a phrase or a passage in a book and you are able to predict kind of what they have in their mind. And, you know, some of the solutions to this trick, you know, involve you marking up every single page of this book so that you're able to look at a corner of a page and predict kind of what word they might choose. Or producing your own book that only has certain words. Like, no one would ever think that you had put so much, so much effort into creating this gimmick. That's the magic to me. The magic to me is all the effort behind this tiny interaction, this tiny moment of delight. And I think that's very much the same as coding, is that you put all this effort into a single moment that delights someone, but you don't see any of that stuff. You don't see the production of this thing. And that's what I love about magic.

• 45:35Speaker 01

  That's a lovely way to end an interview. We've talked about product and engineering and design, how it works, collaborating across those in general and with the agency world of MetaLab. Wesley, if folks were interested in you and wanted to find out more about you and your work and MetaLab, where would you direct them on the internet?

• 45:51Speaker 02

  I would direct them mostly to metalab.com. If you're looking for mittalab, you can find me on LinkedIn. You can search my name, Wesley Yu. And you can find me on Twitter, just creeping and scrolling, doom scrolling on Twitter at Wesley C Y U.

• 46:05Speaker 01

  Well, excellent. Wesley, thank you again for hopping on Software Engineer Daily. This has been an absolute blast. Cheers.

• 46:11Speaker 02

  Thanks, Josh.