EPISODE 1930

[INTRODUCTION]

[0:00:01] ANNOUNCER: 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. The 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. 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 ESLint, a powerful static analysis tool set for JavaScript and TypeScript. He is also the author of the O'Reilly Learning TypeScript book, a Microsoft MVP for developer technologies, and a co-founder of SquiggleConf, a conference for excellent web developer tooling. Find Josh on Bluesky, Fosstodon, and .com as Joshua K. Goldberg.

[INTERVIEW]

[0:01:52] JG: With me today is Wesley Yu, VP of Engineering at Metalab. Wesley, welcome to Software Engineering Daily. 

[0:01:58] WY: Thanks, Josh. Really happy to be here. 

[0:02:00] JG: Well, we're happy to have you. Just to start us off, how did you get into coding? 

[0:02:03] WY: How did I get into coding? I have very humble beginnings in coding. In 1999 or early 2000s 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 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 pasted stuff, changed text around to create a little custom store for my Neopets. 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. 

[0:02:45] JG: 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? 

[0:02:52] WY: Yeah. I mean, it looked very kind of early 2000s CSS styling. A lot of sparkles, a lot of banners and things like this, text moving around. Yeah, it was a good time. 

[0:03:02] WY: 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? 

[0:03:09] WY: 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 nontraditional past into software engineering, I built WordPress sites for small businesses essentially. And for whatever reason, I didn't really make the connection between coding, websites, and my path in college and university. I didn't actually study software engineering. I studied business and media studies in university. 

[0:03:44] JG: You've done quite a few things. You were a talk show producer. Did that involve any sort of tech? And what was that? 

[0:03:50] WY: Yeah. Yeah, that was my first job out of university was a radio news producer. Essentially, that's finding interesting stories and guests for AM news talk shows for people's morning commute. And around this time, I think it's kind of around 2010s or something like this, lots of startups in tech were hiring people from media and journalism to become content marketers. 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 2013. 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. 

[0:04:30] JG: Do you feel fond memories about the way things were back in the day 10 plus years ago? 

[0:04:37] WY: 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, in the hallway somewhere. We had our living room which was just set up with a bunch of computers that people were building things. And I was writing like a big blog post at the time and things like this. Very fun time. Lots of ambition, lots of excitement. We really felt like we were building this tech utopia for the future. 

[0:04:59] JG: That's lovely. That really is idyllic. It sounds nice. 

[0:05:03] WY: Yeah. 

[0:05:04] JG: But moving forward, you are now a VP of engineering. Somehow you switched from content marketing to engineering and leading engineers. How did that happen? 

[0:05:11] WY: Yeah. Yeah. 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 boot camp 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 Coinbases, and Instacarts, and Ubers of the world was kind of how I learned my ropes in the industry. 

[0:05:47] JG: Do you remember it being particularly difficult or easy to switch over that kind of mental model, instead of communicating through words, communicating through code? 

[0:05:55] WY: 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. 

[0:06:24] JG: 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? 

[0:06:32] WY: 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 define 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. 

[0:07:14] JG: Let's take an example. You royally 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? 

[0:07:26] WY: 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 use 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. 

[0:08:02] JG: 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? 

[0:08:11] WY: What do I mean by feel? From the engineering perspective, feel is how responsive does the application feel? How much intention can you draw from the user interactions, how they're moving their 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 back end to say, "Okay, let's preload that channel. So that when you move over to that channel, all the content is already there, and 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, Slack still has this, but we kind of had the ideation for this in the early days, is this idea of the Slackbot. When you're loading a screen, Slack will have some sort of funny message that it says, and you can customize those messages. 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 if you type something into Slack, Slack will do some sort of regexs, and then it will automatically post a message. We might say, "Nothing to see here," and then Slackbot will respond with that GIF of Abe Simpson, Homer Simpson's dad kind of like walking in and out of Moe's bar. These types of fun things we just didn't see in other applications back then. And now they're not Slack standard but they're a lot more common. 

[0:09:23] JG: Why are they common? How do companies justifying spending the time to make these lovely little things? 

[0:09:28] WY: Yeah, I think we have this benefit of people coming to Metalab 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. 

[0:09:49] JG: 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 Metalab to add more Simpsons GIFs and such into my product?

[0:10:05] WY: 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. 

[0:10:36] JG: Must be nice having people come to you because they want and enjoy what you're able to provide and advocate for. 

[0:10:42] WY: Yeah. Yeah. 

[0:10:43] JG: All right. So, we've talked about the high level what is. I want to dive in 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. 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? 

[0:11:01] WY: 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, much younger shop, many of our clients were people that had a business idea, but they didn't necessarily have strong opinions about technology. A lot of the technology choices back then were driven by what we wanted to learn, what we wanted to try in production. 

In 2010s, Metalab was still largely a rail shop, and we were using the hottest JS frameworks to ship more and more client side code. I think we tried everything under the sun back then. I think we were very hipster and using CoffeScript, and we were trying Knockout.js, and Ember, and backbone, and things like this. And very early adopters of React and GraphQL using Facebook's Relay project. 

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're like, "Hey, 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. People say open source isn't really pay. 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. 

[0:12:23] JG: Do you have a favorite fun, hipster JavaScript thing that isn't around anymore that you wish were kind of more prevalent? 

[0:12:32] WY: That's a good question. I was a big fan of Meteor back in the day. I thought it was like the JavaScript version of Rails is how I would put it. You could just build something super fast. That's not around anymore, but I wish that something like that was. 

[0:12:45] JG: 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? 

[0:12:56] WY: 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. You answer a bunch of questions, and then it spits you out a text 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. 

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 work with companies that are European-based, they typically want backends that are written in Java-based frameworks, so 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 2am 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, 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. 

[0:14:32] JG: Does this mean that you hate Expo, or hate Next.js, or any of these other tool chains? 

[0:14:37] WY: 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. Yeah, it's made things far easier to develop in React Native. 

[0:14:48] JG: Hopefully that will have been the closest to a gotcha question you get during this interview. I really 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 2am 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? 

[0:15:19] WY: 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 Metalab. 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. 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. 

[0:16:03] JG: Let's move up in scope a little bit. You were previously a ground-level engineer. Now you're a 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? 

[0:16:18] WY: Yeah, it is at the level that I am right now, especially for an agency, we look at a lot at the pipeline of clients that are coming in, and we try to find efficiency of the pipeline trying to match the skill sets 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." It is that coordination sometimes. We may think about industry in that way. 

We also think about tech stack. 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. 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. This type of organizational efficiency is a lot of my concern. 

[0:17:13] JG: See, that's interesting. I would have expected the if you've done React, continue doing 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? 

[0:17:28] WY: 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 yadi-yada. And then you move away, and you 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. And 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 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. 

[0:18:20] JG: That makes sense. I might imagine that some industries have very important specific gotchas, like healthcare with HIPPA laws and privacy and whatnot that you really want to make sure you don't forget between projects. 

[0:18:30] WY: Totally. Totally. 

[0:18:31] JG: I want to ask you a two-part question here. There are some skills that tend to be better for certain kinds of work. 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 ground-level engineer? 

[0:18:53] WY: Yeah, I think on the individual or 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 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. 

[0:19:53] JG: How do you know when an ugly app is okay? Are the types of clients that will react negatively even though it might be the technically right strategy at the moment? 

[0:20:01] WY: Yeah, I do think that clients appreciate the ugly app, but you do need to prepare them for it. We do a sprint demo, and they're like, "Okay, what is this text on the screen that I'm seeing that has a lot 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. 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. 

[0:21:01] JG: 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. 

[0:21:10] WY: 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 how I like to build these ugly apps. 

[0:21:41] JG: 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. 

[0:21:54] WY: Yeah, that's right. And I'm a big fashion and textile nerd. I think 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 and 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. 

[0:22:30] JG: That's a beautiful analogy. Everybody 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. 

[0:22:39] WY: Yeah. 

[0:22:40] JG: Speaking of beauty, I've heard other people describe projects that they take from inception to completion as their babies. That's the common phrase. 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 agency world, you have that? Or is it harder to develop that when you're working on so many different projects? 

[0:23:07] WY: No, we definitely develop this parental instinct. At Metalab, I think 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. You do very quickly become very attached to the thing that you build. 

And when it comes time to hand that project off, slowly back to the client's team, or maybe we help them hire a team to maintain this application or build the V2 or build the V3, that can be quite hard. You're interviewing this person, and you just want to make sure you're finding the best foster parent for this thing that you 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 what? 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 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 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. 

[0:24:22] JG: 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? 

[0:24:30] WY: 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 in the future. And so we leave a lot of comments on the code. We record a lot of video walkthroughs of the code base and leave a lot of documentation and readmes, and lots of little directories and stuff like that. That's like the worst case scenario, I think. You can only convey so much through documentation. 

What we like to do is we like to run three or four sprints with this person so that they understand the way they work. 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 warm handoff to projects. 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 advice our clients to make those hires early so that the decisions that we're making are aligned with the decisions that are the default, kind of the biases of the person that we're going to be working with in the future. 

[0:25:34] JG: 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, and it seems no negativity to it. It's just a fact of life biases in tech. 

[0:25:48] WY: I think so. Everyone has kind of 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 Git. Those biases are neither good nor bad. But when you start to ingrain these types of things into a codebase that you need to see every single day, it can be a little bit grading 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 we know we're not the ones that are going to be maintaining 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 the product, but also the people that are going to be working on this in the future. 

[0:26:36] JG: 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 you 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? 

[0:27:00] WY: It is something that we are figuring out still. I think we found a way to do it through 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. 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, what are the core experience? What are the big beats of this application? And how are they supported by 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 through the door and signed a contract with us, just so 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 an analogy of producing a season in television. And so when you're producing a season in television, the writers come together and they think about the big beats of the story that they want to tell over the season. And there's no dialogue happening right now. There's kind of characters that are going through different arcs. You just know, "Okay, this event is going to happen, and then this event is going to happen, and this event is going to happen. We're going to tie that through to 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 we follow a very similar structure when we're building applications at Metalab. 

[0:28:55] JG: 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? 

[0:29:03] WY: I think it's like an instinct or a reflex from my AM news radio production days, is like you need to be able to translate complex ideas, complex topics, complex processes into things that people they already understand or they already internalize. And I think the analogies are good. They're not always one-to-one. Sometimes you can just completely butcher an analogy 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. 

[0:29:31] JG: How do you manage the internal hand-off then from the early stage folks to the later stage? 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? 

[0:29:46] WY: Yeah. Our teams that start projects, we do 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 we're not changing out those folks. We have a very kind of clear throughline 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. They're rolling the boulder up the hill in these first two phases of discovery and product definition, and then they are rolling the boulder down the hill when they get a larger team to implement the thing. 

[0:30:21] JG: Just on a personal level, do you prefer at either side of that hill or particular areas of boulder pushing? 

[0:30:27] WY: I mean, rolling the boulder up the hill is always the hardest part. And I think it is hard, but it's also the most rewarding in my mind because you have to be very comfortable with being in 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 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. There's a joy to banging out code and solving very technical problems. And so my preference of course is rolling the boulder up. But rolling the boulder down has its own choice. 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. 

[0:31:19] JG: Yeah. You got momentum behind it. 

[0:31:21] WY: Exactly. Yeah. Not to say that rolling a boulder down a hill is a straight path either. I think sometimes you get little bumps, and sometimes you have to roll a boulder up a hill to get down the other side and things like this, too. 

[0:31:31] JG: To quote Polinsky, "Every comparison limps." 

[0:31:34] WY: Yeah. 

[0:31:35] JG: 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 3 years to implement? 

[0:31:54] WY: 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." I want to print 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 and this prototype, and he's like, "Okay. Well, I like this. But could we do it like this?" And then he's thinking about it 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 what is easy or what is kind of the default for a React Native developer to implement. And you find somewhere in the middle. And they really challenge each other in their respective disciplines. 

[0:33:01] JG: 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, the flipping, the shuffling of decks, the saving draw at the end of a long match. But then you have to turn it electronic. Just from a designer product standpoint, how do you capture that joy and magic of a tactile thing in electronic form? 

[0:33:24] WY: Yeah. Yeah. Every interaction needs to have some sort of physical reaction. Tapping on something produces some sparks or something like that. You kind of have 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 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 because that's kind of what you have to work with. 

We tried some stuff with haptics and things like that. But I've always found that when you're opening a pack and your phone vibrates and things like this, or the lights go off, they feel a little bit out of place. They feel like, "My phone is vibrating. Oh my god, what is going on? Can't have anything to do with this application." But that's why we kind of rely more on the visual aspects of things. 

[0:34:13] JG: There was a lovely period of time with apps when people discovered the haptics, and then every app interaction was vibrating. 

[0:34:20] WY: I'm just shaking. 

[0:34:20] JG: 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, 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? 

[0:34:45] WY: 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 ergonomics 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, reduction code to an application. And when I say commit to production, there is still the review process of a developer to ensure that it works. There maybe is a complete re-implementation of what the designer has prompted into Claude Code to produce a PR. But we're thinking about what is the scaffolding that we need to build? What is the baseline that we need to build in an application? Such the 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 may not be able to prompt into existence so the application still functions end to end, and they're able to add their touches to it on the UI/UX level? 

[0:35:55] JG: Wesley, I'm a frontend developer. Can you please expound on that and help me feel comfortable that my job will exist in 2 years? 

[0:36:03] WY: I think that the important thing is 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 code base 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 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 in is less in Figma. The delivery is less in Figma, and it's more in code. And I like that a lot. 

[0:36:52] JG: 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." I guess from another perspective, say I'm a designer, how do you make me feel comfortable that my job will exist in 2, 5 years? 

[0:37:07] WY: Yeah, we have recently been using Claude Design and these design tools, and Figma MCP to get things from Figma into code. 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 as a human, and 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. 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. And so I think there's still this human touch of this was created by a human. And I can tell, because an AI would ever 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. 

[0:38:04] JG: 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 afterwards. Where, instead of, let's say, large sheets of glass or sameness in buildings, you have these intentionally different or almost, 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? 

[0:38:29] WY: 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, 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. 

[0:38:47] JG: Love that very much. What is your role kind of moving forward the next 5, 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? 

[0:39:07] WY: 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. 

Some things that we have sunk a massive amount of time into is eval frameworks for LLMs. 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. And we created lots of custom MCPs 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 kind of discard our own solutions. But yeah, that's kind of 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 kind of 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 like a Japanese bakery. You walk into a Japanese bakery, they've got dozens and dozens of different types of pastries and baked goods. And Japanese people don't like cellophane or anything around these baked goods when you're buying things. It's more joyous to kind of like walk through this thing and like pick off baked goods and put them on a tray. 

But the problem with that is that you bring it to a register, and 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, service between human interaction between you and customer. 

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 that is fun, that preserves the human aspect 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 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. 

[0:41:56] JG: 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? 

[0:42:11] WY: Yeah. Yeah. Exactly. There's a lot of busy work that you need to do to run a business, and we want to do away with that so we can surface the things that are really fun. The really fun things for us is working with other people. 

[0:42:21] JG: 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? 

[0:42:29] WY: I love building things. 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. I think it's awesome that you can build tools just kind of at 2am on your computer. 

[0:42:51] JG: 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. 

[0:43:01] WY: Exactly. Exactly. 

[0:43:03] JG: 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 pallet 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? 

[0:43:25] WY: Okay, I am just all blue. I like to play Magic, but I like to be the only one that has fun. Blue is this color that each player in Magic Gathering performs actions and try to whittle away someone's life. Blue's color 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. 

[0:43:49] JG: Why are you like this? That's the worst option, the worst answer to that question. 

[0:43:54] WY: I know. I know. I'm sorry. I don't know why I'm like this. It just gives me joy. 

[0:43:59] JG: 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? 

[0:44:10] WY: Yeah, sure. 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 wave. 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 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 some of the solutions to this trick 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. 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. 

[0:45:35] JG: 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 at Metalab, where would you direct them on the internet? 

[0:45:52] WY: I would direct them mostly to metalab.com. If you're looking for Metalab, you can find me on LinkedIn. You can search my name, Wesley Yu. And you can find me on Twitter. Just creep in and scrolling, doom scrolling on Twitter @wesleycyu. 

[0:46:06] JG: Well, excellent. Wesley, thank you again for hopping on Software Engineering Daily. This has been an absolute blast. 

[0:46:11] WY: Cheers. Thanks, Josh.

[END]