Building Software That People Love

22:49You're not just giving them one final thing and calling it a day. 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.

23:20And so that's why I like to build these ugly apps. 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. 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.

23:59You 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. That's a beautiful analogy. Every body is different. Every person's preferences and experiences and even year to year, their needs are different. It's kind of a beautiful way to think about software. Yeah. Speaking of beauty, I've heard other people describe projects that they take from inception to completion as their babies.

24:30You 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? No, we definitely develop this parental instinct. You know, at Metalab, 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.

25:04Because of the iteration that we're doing, because we're defining a business for a client, It's hard to split your time across lots of different things between lots of different contexts. So you do very quickly become very attached to the thing that you build. And when it comes time to hand that project off, you know, slowly back to the client's team, or maybe we help them hire a team to maintain this application or build a V2 or build a V3, that can be quite hard. You know, you're interviewing this person and you just want to make sure you're finding the best foster parent for this thing that you built.

25:37You want to make sure that your values are aligned. And then sometimes they're not, and they'll look at the application and say, you know, I'm going to change this, that, and the other. And it's a little heartbreaking sometimes, because it's not always easy to convey, you know, all the steps of the process that got us to where we are today, to this person that is going to take it over in the future, because, you know, everyone has their biases, everyone has the ergonomics in which they like to work in the code. And so we very much become these parents for these children that we build. This might be relevant for many different areas of engineering.

26:07Do you have tips for handoffs to make sure people understand why things were made the way they were? 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 read me's and lots of little directories and stuff like that. That's like the worst case scenario. I think, you know, you can only convey so much through documentation.

26:41What 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 with it. 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 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:16That'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 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. 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.

27:55And so that's why we like to involve the person that is maintaining this thing. We want to include their biases in this process, because, you know, we know, we're not the ones that are going to maintain this long term, we want to set this up in a way that fits well with them. This is kind of part of draping a cloth over a body, that body is not just the business or the product, but also the people that are going to be working on this in the future. 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 y 'all work together.

28:27I 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? 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.

29:15And that's the thing that we align on first. Okay, you know, what are the core experience? What are the big beats of this application? And how are they supported by 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.

29:49Once 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 of television. And so when you're producing a season of television, and 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. This event is going to happen.

30:18We're going to tie that through the story. And then you start to write the episodes. You go, okay, now we're going to do episode one, cold open, act one, go. And the design teams, they know where they're going. And the engineering teams, they know where they're going because this structure has been put in place. And so that's, we follow a very similar structure when we're building applications at Mental Lab. 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? I think it's like an instinct or reflex from, you know, 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're already internalized.

31:00And 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. 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? Yeah, our teams that start projects, you know, we do, you know, a phase of discovery, understanding the industry.

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

32:04Just on a personal level, do you prefer at either side of that hill or particular areas of boulder pushing? 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.

32:37And 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, you know, 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. Yeah, you got momentum behind it. Exactly, yeah. Not to say that rolling boulder down a hill is a straight path either.

33:07I think like sometimes you get little bumps and sometimes you have to roll a boulder up a hill to get down to the other side and things like this too. To quote Polinsky, every comparison limps. Yeah. Yeah. All right. Sometimes in product development, there is a beautiful design that has incredible value. It's just really a lovely thing for the client or user. And then the cost of it is obscene. Do you have particular strategies for dealing with incredibly beautiful design that would take three years to implement? Absolutely. We see this all the time. I think one example of this behavior is that we're building an application for collectibles.

33:45and 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's poking through the application, this prototype, and he's like, okay, well, you know, I like this, but could we do it like this?

34:20And then it's thinking about really pushing the bounds of creativity on the engineering side. And it's through this process of iteration that we land on something that is in between this crazy binder experience that the designer has in their mind. And then, you know, what is easy or what is kind of the default for, you know, a React Native developer to implement. And you find somewhere in the middle. And they really challenge each other in their respective disciplines. Trading card games like Magic are so interesting from a product and design standpoint, right? Because they're a thing that inherently is tactile that you, as the player, derive a lot of joy from, you know, the flipping, the shuffling of decks, the, you know, saving draw at the end of a long match.

34:57But 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 the electronic form? 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.

35:27And 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 like opening a pack and your phone vibrates and things like this, or the lights go off and they feel a little bit out of place. They feel like, you know, my phone is vibrating. Oh my God, what is going on? Can't have anything to do with this application. But that's why we kind of rely more on visual aspects of things. There was a lovely period of time with apps when people discovered the haptics and then every app interaction was vibrating, you know?

36:02I'm just shaking. 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? I like it. I think the canvas of Vigma 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.

36:38And 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, 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 Cloud 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?

37:13Such the designer can get to a point where they are also prompting Cloud Code to create PRs. And some of that is understanding what primitives exist in the application. What does the database look like? What functionality do we need to build in that a designer might not be able to prompt into existence? so that the application still functions end to end and they're able to add their touches to it on the UI UX level. 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? I think that the important thing is, you know, not just prompting things in existence and getting things into production, but when there is an issue with something or when you need to make a small change to things, you still need to have a code base that is scrutable, that is inspectable, that you can go in and actually make changes to.

38:03And 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. It's more in code. And I like that a lot.

38:34Suppose 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? Yeah. We have recently been using Cloud Design and these design tools and Figma MCP to get things from Figma into code. You know, I think when you start to use these tools, you start to see the sameness that these tools produce. And very quickly, you're able to spot, you know, as a human, and we're pattern recognition machines, what was generated by AI.

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

40:21And 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. 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 is a little bit split. I think part of it is understanding what trends we should pursue, what we should build expertise in.

40:57And 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. 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.

41:33and we create 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, like 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.

42:08So, 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. Like 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 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.

42:48and 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 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.

43:26That'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. 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? Yeah, yeah, exactly. You know, there's a lot of busy work that you need to do to run a business and we want to do away with that.

43:59We can surface the things that are really fun. The really fun things for us is working with other people. 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? 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.

44:26I 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. 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. Exactly. Exactly. 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 palette cleansers, explicitly non-technical. I actually have two for you. First, and please explain this for people who don't know anything about Magic the Gathering.

44:59If you were a commander and you had to choose a set of colors, why are you these particular colors and what would they be? okay i am just all blue i like to play magic but i like to be the only one that has fun so blue is this color that's each player in magic gathering performs actions and you know try to whittle away someone's life blue's color you know is all about preventing people from doing things and so you prevent people from doing things enough that you eke out a little bit of an advantage and you win the game in that way and i kind of like that why are you like this that's the worst option The worst answer to that question.

45:36I know, I know. I'm sorry. I don't know why I'm like this. It just gives me joy. 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? Yeah, sure. Like one of my actual first jobs was my friend and I started a business performing magic at children's birthday parties. and this was right around the Harry Potter boom. And so we really rode that way. People were really interested in magic back then. And so, yeah, we were really interested in buying tricks and we would perform magic at birthday parties and then we would use that money immediately to buy tricks.

46:16And 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 or producing your own book that only has certain words like no one would ever think that you would put so much so much effort into creating this gimmick, that's the magic to me.

46:59The 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. 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:34I 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 creeping and scrolling, doom scrolling on Twitter at WesleyCYU. Well, excellent. Wesley, thank you again for hopping on Software Engineering Daily. This has been an absolute blast. Cheers. Thanks, Josh. Thank you.