← Software Engineering Daily
Software Engineering Daily
Building Software That People Love
00:48:09
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,
Loading summary
Transcript108 lines
- [00:01]
Narrator
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 toolset 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, Fostodon and dot com as Joshua Kgoldberg.
- [01:52]
Josh Goldberg
With me today is Wesley Yu, VP of Engineering at Metal Lab. Wesley, welcome to Software Engineering Daily.
- [01:57]
Wesley Yu
Thanks Josh. Really happy to be here.
- [01:59]
Josh Goldberg
Well, we're happy to have you. Just to start us off, how did you get into coding?
- [02:03]
Wesley Yu
How did I get into coding? This is. I have very humble beginnings in coding. You know, 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 like virtual pets called Neopets and they have this virtual currency called NeoPoint 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. 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.
- [02:45]
Josh Goldberg
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?
- [02:52]
Wesley Yu
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.
- [03:02]
Josh Goldberg
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?
- [03:09]
Wesley Yu
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 until 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.
- [03:44]
Josh Goldberg
You've done quite a few things. You were a talk show producer. Did that involve any sort of tech and what was that?
- [03:49]
Wesley Yu
Yeah, yeah, that was my first job at a university was 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 2010s or something like this, lots of startups and 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 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.
- [04:30]
Josh Goldberg
Do you feel fond memories about the way things were back in the day, 10 plus years ago?
- [04:36]
Wesley Yu
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 that people were building things. And I was writing 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.
- [04:59]
Josh Goldberg
That's lovely. That really is idyllic. It sounds nice.
- [05:03]
Wesley Yu
Yeah.
- [05:03]
Josh Goldberg
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?
- [05:11]
Wesley Yu
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 the. 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.
- [05:47]
Josh Goldberg
Do you remember it being particularly difficult or easy to switch over that kind of mental model? Instead of communicating through words, you're not communicating through code.
- [05:55]
Wesley Yu
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.
- [06:23]
Josh Goldberg
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?
- [06:32]
Wesley Yu
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 are less defining the business and trying to find a market in some sense, but you are 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.
- [07:14]
Josh Goldberg
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?
- [07:26]
Wesley Yu
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.
- [08:03]
Josh Goldberg
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?
- [08:11]
Wesley Yu
What do I mean by feel? From the 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 and it's lightning fast. That's 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. When you're loading a screen, Slack will have some sort of funny message that it says, and you can customize those messages that 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 regex and then it will automatically post a message. So like 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. 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.
- [09:22]
Josh Goldberg
Why are they common? How are companies justifying spending the time to make these lovely little things?
- [09:27]
Wesley Yu
Yeah, I think we have this benefit of people coming to Mitolab 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, the that are not just functional aspects of it, but aesthetic aspects.
- [09:49]
Josh Goldberg
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?
- [10:05]
Wesley Yu
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 mom. 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:36]
Josh Goldberg
Must be nice having people come to you because they want and enjoy what you're able to provide and advocate for.
- [10:41]
Wesley Yu
Yeah, yeah.
- [10:42]
Josh Goldberg
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:01]
Wesley Yu
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. 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, Minalab 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. 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, you know, we're using this technology, you're clearly contributing to this project. Can you help consult for us? And that became a ten year long relationship. And people say open source doesn'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.
- [12:23]
Josh Goldberg
Do you have a favorite fun hipster JavaScript thing that isn't around anymore that you wish were kind of more prevalent?
- [12:31]
Wesley Yu
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 I 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:46]
Josh Goldberg
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:56]
Wesley Yu
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. And. 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, 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 2am in the morning? That all goes into selecting technology that we want to use. And then when we're evaluating on the product lens, we think about speed to Market. 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.
- [14:32]
Josh Goldberg
Does this mean that you hate Expo or hate Next JS or any of these other toolchains?
- [14:37]
Wesley Yu
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:47]
Josh Goldberg
Hopefully that will have been the closest to a gotcha question you get during this interview. 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 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?
- [15:19]
Wesley Yu
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 Ventilab 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:03]
Narrator
Agents are getting smarter every day. But even the smartest agents get stuck without the right context and the right tools. That's where Notion comes in. With the recent launch of custom agents, Notion became the collaborative AI workspace where teams and agents work side by side. And now their new developer platform is turning that workspace into infrastructure developers can build on. Most agent platforms are single player, making you stand up your own infrastructure just to start. Notion's developer platform flips both. You get primitives to sync any data source in, give your custom agents tools that plain MCP can't deliver, and orchestrate agents like Claude or Codex alongside your team. The CLI authenticates in one line and workers run on Notion's runtime, so there's nothing to provision because the workspace your team lives in is the same thing you build on. Permissions and governance come standard. Write your code, deploy. Done. Learn more about Notion's developer platform today@notion.com sed that's all lowercase letters. Notion.com sed to try notion's developer platform today and when you use our link, you're supporting our show. Notion.cesed Every AI team eventually hits the same wall. The models are solid, the infra is solid, but the data coming in is hours old because the pipeline is batch when it should be streaming and nobody's had time to fix. That's not a modeling problem, that's a pipeline problem. Estuary gives you CDC batch and streaming in one platform. 200 plus connectors live in hours, not weeks. Your AI is only as good as your pipeline. Estuary.dev let's move up in scope a little bit.
- [17:47]
Josh Goldberg
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?
- [18:00]
Wesley Yu
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 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. So it is that coordination sometimes. So we may think about industry in that way. We also think about tech stack. 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. 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.
- [18:55]
Josh Goldberg
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?
- [19:11]
Wesley Yu
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, EHR is just 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.
- [20:01]
Josh Goldberg
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.
- [20:13]
Wesley Yu
Totally, totally.
- [20:14]
Josh Goldberg
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?
- [20:36]
Wesley Yu
Yeah, I think on like 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 the 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 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.
- [21:35]
Josh Goldberg
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?
- [21:43]
Wesley Yu
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 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 Minalab. We want to help build the DNA of this process that we have of building applications.
- [22:44]
Josh Goldberg
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.
- [22:52]
Wesley Yu
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, more ugly apps.
- [23:25]
Josh Goldberg
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.
- [23:37]
Wesley Yu
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. And 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.
- [24:13]
Josh Goldberg
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. Yeah. 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 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.
- [24:49]
Wesley Yu
No, we definitely develop this parental instinct, you know, at Metalab, you know, 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 the V2 or build the V3, that can be quite hard. You know, 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, 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.
- [26:04]
Josh Goldberg
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?
- [26:13]
Wesley Yu
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 readmes 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. 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. 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 are the default kind of the biases of the person that we're going to be working with in the future.
- [27:16]
Josh Goldberg
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, I think.
- [27:31]
Wesley Yu
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, git. You know, those biases are neither good nor bad. But when you start to ingrain these types of things into a code base 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 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.
- [28:18]
Josh Goldberg
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 clients to everyone, handoffs and the way 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?
- [28:43]
Wesley Yu
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, 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 to 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 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. 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 we follow a very similar structure when we're building applications at MinaLab.
- [30:37]
Josh Goldberg
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?
- [30:45]
Wesley Yu
I think it's 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.
- [31:13]
Josh Goldberg
How do you manage the internal handoff 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?
- [31:29]
Wesley Yu
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 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 are rolling the boulder down the hill when they get a larger team to implement the thing.
- [32:04]
Josh Goldberg
Just on a personal level, do you prefer at either side of that hill or particular areas of Boulder Pershing?
- [32:10]
Wesley Yu
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 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.
- [33:02]
Josh Goldberg
Yeah. You got momentum behind it.
- [33:04]
Wesley Yu
Exactly. Yeah. Not to say that rolling 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 to the other side. And things like this, too.
- [33:14]
Josh Goldberg
To quote Balinsky, every comparison limps.
- [33:17]
Wesley Yu
Yeah.
- [33:18]
Josh Goldberg
All right. Sometimes in product development, There is a beautiful design that has incredible value. This is 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?
- [33:36]
Wesley Yu
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 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, this prototype, and he's like, okay, well, you know, I like this, but could we 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 a React native developer to implement, and you find somewhere in the middle, and they really challenge each other in their respective disciplines.
- [34:44]
Josh Goldberg
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, 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?
- [35:06]
Wesley Yu
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 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, because 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 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 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.
- [35:55]
Josh Goldberg
There was a lovely period of time with apps when people discovered the haptics and then every app interaction was vibrating.
- [36:02]
Wesley Yu
I'm just shaking.
- [36:03]
Josh Goldberg
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?
- [36:27]
Wesley Yu
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, 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 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 might not be able to prompt into existence? So that's. So the application still functions end to end and they're able to add their touches to it on the UI UX level.
- [37:37]
Josh Goldberg
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?
- [37:46]
Wesley Yu
I think that the important thing is not just prompting things in this incident 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 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 in is less in figma, the delivery is less in Figma and it's more in code. And I like that a lot.
- [38:35]
Josh Goldberg
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?
- [38:49]
Wesley Yu
Yeah. We have recently been using cloud design and these design tools and Figma MCP to get things from figment 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, 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. 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. 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.
- [39:47]
Josh Goldberg
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. Words 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?
- [40:11]
Wesley Yu
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.
- [40:30]
Josh Goldberg
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, my role
- [40:49]
Wesley Yu
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 LLMs. We'd probably use something like LangChain or Langfuse. You know, 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 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 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, like 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. So, you know, 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 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 the 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 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.
- [43:39]
Josh Goldberg
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 that you can focus on what's important. Am I interpreting that right?
- [43:53]
Wesley Yu
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. We can surface the things that are really fun. The really fun things for us is working with other people.
- [44:03]
Josh Goldberg
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?
- [44:10]
Wesley Yu
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.
- [44:34]
Josh Goldberg
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.
- [44:44]
Wesley Yu
Exactly. Exactly.
- [44:45]
Josh Goldberg
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 non technical. I actually have two for you first. And please explain this for people who don't know anything about the Gathering. If you are a commander and you had to choose a set of colors, why are you these particular colors and what would they be?
- [45:08]
Wesley Yu
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 each player in Magic Gathering performs actions and, you know, try to whittle away someone's life. Blues 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.
- [45:31]
Josh Goldberg
Why are you like this? That's the worst option, the worst answer to that question.
- [45:36]
Wesley Yu
I know, I know. I'm sorry. I don't know why I'm like this. It just gives me joy. Great.
- [45:42]
Josh Goldberg
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?
- [45:52]
Wesley Yu
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 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.
- [46:16]
Narrator
And.
- [46:16]
Wesley Yu
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, 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.
- [47:18]
Josh Goldberg
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?
- [47:35]
Wesley Yu
I would direct them mostly to metalab.com if you're looking for Metal Lab, you can find me on LinkedIn, you can search my name, Wesley Yu, and you can find me on Twitter. Just creeping and scrolling. Doomscrolling on twitter@wesley cyu well, excellent, Wesley.
- [47:50]
Josh Goldberg
Thank you again for hopping on Software Engineering Daily. This has been an absolute blast. Cheers.
- [47:54]
Wesley Yu
Thanks, Josh. It.