Design Engineering with Maggie Appleton

The Pragmatic Engineer

In this episode, Maggie Appleton discusses her unique career trajectory from cultural anthropology to design engineering at GitHub Next. She

Key takeaways

• Maggie Appleton applies anthropological 'participant observation' to understand user cultural contexts and unspoken software rules.
• Design engineering is defined by a deep engagement with technical backend, data flow, and product architecture rather than just micro-interactions.

Main topics

• Design Engineering
• AI Agents in Prototyping

Notable quotes

Design engineering... is someone who's like deeply into the engineering side of the design.

Conclusion

The episode offers a profound look at how engineers can expand their i

Transcript preview

Speaker 2 (0:00) What makes for a great designer or a great design engineer and what can us software engineers learn from them? Maggie Appleton is one of the most thoughtful design engineers I know. She's worked as an illustrator, as a designer at an AI startup, and is currently prototyping at GitHub Next. Today we talk about what is a design engineer and why there's often a tension between engineering and design, the tools she's used before and now, and why pen and pencil is not going away even with agents. Do you still need a designer when AI can generate 20 high fidelity prototypes? And is AI design obvious to spot? And many more. If you're an engineer and wanting to know where design is important and how to get better at design yourself, this episode is for you. This episode is presented by TurboBuffer, Vector and Fulltext Search built on object storage. It's fast, cheap and extremely scalable. Today's episode will be about design and design engineering. And so I wanted to share something visually interesting about our season sponsor, Antisysis. We already know that Antisysis verifies your system correctness by running your whole system in hostile simulation and finding bugs. Here's a UI for casualty analysis. You can open a report for a bug and see the probability of a bug occurring throughout the timeline of the simulation. In this case, we can see that at virtual time 25 something happened that makes this bug close to 100 % to occur. So we can jump to this point in virtual time simulation to read the logs. This kind of bug probability visualization is one that I've never seen before. There's also this neat log explorer. You can filter on error messages and then visualize how common or uncommon the error is over time. For example, here's looking for failing linearization failures, the purple line. And you can understand how rare or common a specific failure was. Again, I've yet to see this kind of error visualization and I really like the innovation on the UI side. And finally, the simplified multiverse debugger. You can go back in time and replay a debug timeline. And you can inject bash commands at any time without affecting the playback of the bug. How cool is that? For example, we're listing files in the current directory, but as you can imagine, you can go debug the whole environment so much easier. I love how the team at Antisys are pushing what's possible with both debugging and verifying software. Head to antisys.com slash pragmatic to learn more. Maggie, welcome to the podcast. Speaker 1 (2:17) Thanks, I'm thrilled to be here. Speaker 2 (2:18) I've had... So many guests on the podcast. No one had quite the introductory story into tech like you. How did you get into tech? And you came from a very different background, right? Yeah. Speaker 1 (2:30) I mean, I came in because it was where the money was, I guess. I mean, not really. But in the sense that like I, in university, I studied cultural anthropology, which is like. My one true love, like I adore cultural anthropology. I totally fell in love with it in university. Speaker 2 (2:43) What is anthropology? Speaker 1 (2:45) It's, okay, it's the study of human beings, which sounds impossibly broad and like, how could that be a discipline? But it does it in a particular way where you go and you live with people intensely in this thing called participant observation. Usually it was done kind of when the field was born of different cultures, of course. It was like anthropologists from the West, primarily going to places like Papua New Guinea or Australia and living among kind of traditional peoples and then realizing how different. their cultures were not just like, oh, they eat different food, you know, they have different houses, but they have completely different understandings of like what color is. They don't, they have completely different understandings of time. It was, it was kind of alongside the birth of psychology, like understanding how flexible is the human mind about constructing understandings of the world. And anthropology is really one of these eye-opening subjects when you get into it, because you can kind of get into like medical anthropology or the anthropology of sex and gender. And you just find out how extremely adaptable and fluid human beings are. And I loved it because I grew up as an expat kid overseas. So I think I was exposed early to lots of different cultures. And so it felt very natural to me to realize like, oh, the way things, you know, people do things at home, you know, quote unquote home would be London for me, but I left at age six, is completely different to the way they do it elsewhere. And there's no fixed way for humans to kind of construct a society or live life. And the bounds of what we think is possible is much wider than we originally assume, which is what I loved about it. So I studied it. But of course, come senior year. kind of go, right, what jobs are there available in cultural anthropology? Speaker 2 (4:08) I guess living with natives isn't all that many. It's not very Speaker 1 (4:12) lucrative. So the options were like, go get a PhD and become a professor. Well, the military hires lots of anthropologists to come up with torture techniques for people in different countries. So Speaker 2 (4:23) when Speaker 1 (4:24) presented with these options by our professors, we were like, oh, OK, OK, we'll go think about that. And I had always loved design growing up. So I had been doing... Like, you know, I was a kid of the 90s. I grew up on Neopets with HTML and CSS and MySpace. And I learned HTML and CSS probably around 12 or 13 and knew how to do it. But in the way where like there wasn't that much complexity to it in whatever this was, 1999. Speaker 2 (4:46) Did you have a MySpace? I Speaker 1 (4:47) did. Oh, oh, yeah. Speaker 2 (4:48) And you customize it with all the crazy Speaker 1 (4:50) animations and like the little sparkle trail at the end of your cursor. And like, I think mine was quite goth at the time. Like, but I learned a lot. But of course, at the time, the web was so new. It wasn't like people thought this was a career or you. Didn't really think of it that way. But I came out of university with this degree that wasn't necessarily employable. And I just started doing freelance web design work because that was how I knew how to make money. Like throughout school, I was doing IT tech work for the university and just naturally went into this because it was like, well, I need to pay rent somehow. And I gravitated towards illustration originally because I love drawing. So I was originally an illustrator for the first couple of years. And the way that I went more into the tech side, because you can kind of be an illustrator that's like, you know, editorial or you could go into branding or like all kinds of types. But I started working for a startup. I guess I wouldn't call it a startup. It was more like a design dev shop in Prague that was making UI UX apps for like SF startups at the time. They were doing work for like Tinder and Uber, like in the early days, like in their beginnings. So it was there I got exposed to UI UX design. And I was making the illustrations for these apps and doing logos and branding. But I like that was my first exposure to like, oh, there are people who design buttons and sidebars. And that's kind of interesting. I didn't end up going into that for a while, but that was my first introduction to like what is product design in tech as a field. And eventually I joined this company called Egghead, which does developer education. So they taught JavaScript. Sure, you've seen them around. And I was their illustrator for four years. And then I became an art director and like. art directed other people's illustrations for them. And that was really where I learned JavaScript React. Like that was, I think my real front end engineering education was like doing illustrations for them. But in doing the illustrations, I had to understand the material I was illustrating, which turned out to be like React components and use effect and like JavaScript functions. And in a weird way, I just ended up. moving more into front-end engineering and visual design because it just felt like a natural move. Speaker 2 (6:43) You worked at Illicit as well, right? Yeah. Was that before Eckhead? Speaker 1 (6:47) After. That Speaker 2 (6:48) was after. Yeah. So you were at Eckhead as their learned design there. And then Illicit was an AI startup, right? Speaker 1 (6:57) Yeah, early, pretty early. Well, okay. Speaker 2 (6:59) Pretty early, yeah. Speaker 1 (7:00) I mean, it was like the founders there were really kind of incredible people and that one of them had been... studying language models for 10 years. He had like seen the writing on the wall way before anyone else, but like kind of out of MIT, like PhD kind of like, you know, machine learning stuff and kind of had this realization of like language models are going to revolutionize science. He was really big on like, how could this speed up the scientific process? So illicit originally was, and it still is actually, I mean, they've expanded, but at its core, it is using language models to speed up the scientific literature review process. It's usually this very manual, slow thing of all these academics reading thousands of papers and extracting data about them into spreadsheets. Perfect for models, like a perfect use case. So I joined them, I think it was late 2021, early 2022. Speaker 2 (7:43) And you were the only designer, there was no product manager, you were the founding designer. Yeah, Speaker 1 (7:47) yeah. And there were six of us in the beginning. When I joined, maybe seven, I might have been the seventh, I forget. A very small team. And it stayed small most of the time I was there. And yeah, I was the only designer the whole time. And then we had a PM at some point who left and then we didn't get another one. So there's no PM for quite a while. And it was a really wonderful experience because it was a classic early startup. But like, it was like we were family. We would like stay together for weeks at a time during retreats. Like the founders had really strong conviction and they're really smart people. And I trusted them so much. So it was sort of like get on board with the vision kind of deal. And it was there I really learned product design end to end, I'd say, in the terms of we had lots of users because we had a free prototype that was like very, very popular. So you had all this data you could collect about what people were searching for and clicking on and what worked and what didn't and A-B tests. And we just went really fast. Like we shipped a feature every week for a year. So it was like design, build, like ship it, measure, design, build, ship it, measure on repeat over and over for like the solid. I think I was there a little over two years and I had learned a ton in that time just about the core mechanics of product design in the sense of like really going from what are the user needs, what's their domain. through to doing all the front-end engineering and like tying it all together. So it was a really wonderful experience. I learned a lot. It was intense. By the end of it, I was like, step back from startups for a minute. Speaker 2 (9:02) So you got into design, I guess, kind of more like self-taught, like figuring out there's a need for this. You worked at Egghead where you learned to design or explain developer concept, educational concept for developers. You worked at an AI startup as a designer. What does a designer do? Speaker 1 (9:19) It's kind of a simple answer. Now that Speaker 2 (9:21) you've actually done several roles, and I get a sense that, of course, there's going to be, it depends. But at startups that you've worked with, that you know, how would you describe? And of course, many of us developers have worked with designers. Some have not at all. Speaker 1 (9:39) I mean, I kind of describe it. It's not that different to engineering. It's problem solving. But the materials are different is the way I would describe it. It's like you go through the same process of like you have defining what your problem is. Like, are you sure this is the correct problem? Have you defined it well and scoped it well? You know, researching possible solutions, doing wide exploration, what are all the ways we could solve this? What are the trade-offs of them? You know, prototyping solutions, validating those are the right solutions. Do they work for users? Do they make sense? I don't think it's that different to engineering in the sense that I do some of both in my job, but it's just the material is different. Instead of working with... code, although nowadays with developers, you're working in higher level kind of architecture data flow. You're not necessarily writing the syntax, but at the time, what syntax are you going to use to write this problem? And with design, the materials are like space, size, weight, color, you know, things you'd see in an interface in terms of the visuals, motion, you know, prominence. Is this big enough? Are these the right words for the user to understand what this button's going to do? Like everything from copywriting to visual graphic design. But with product design, you're also dealing with what we would call nouns and verbs of a product. So it's easy when your product is like a sneaker store. It's like the nouns are like sneaker, cart, money. If you're designing AWS, the nouns get extremely difficult. And I've primarily worked in what I'd call like power user tools, like scientists, developers. Where the nouns are extremely hard because they get very abstract. It's sort of like, what's the right container for a set of data? What's the right container or noun to point you to like, oh, this is your whatever set of data or like this set of data connects to that set of data. Or like here's a function that transforms data into another set. You need a noun and verbs to give to users so they can understand how to manipulate whatever you're trying to get them to do. It's really difficult in DevTools sometimes because there's so much malleability in a way there isn't with stuff. Speaker 2 (11:28) What is malleability? Speaker 1 (11:30) Like ability, like it could take many different forms and shapes versus if you're designing things for the real world. Like I have friends who work for like government design. There's restrictions there where it's like you're trying to get someone to fill out a form. It can be a hard design challenge, but it's not complex in the same way. Versus like at the moment, right? I'm, of course, trying to design like agentic tools. And it's like, what are the nouns of agents? Like, we don't know. There's like chat sessions. We have these things called plans. There's something called an MCP. There's skills like. Could we make new primitives that like connect a bunch of sessions all the way to a PR that becomes a new noun that contains it? Like there's all kinds of boundaries you could draw that would make the user think about your experience differently. And then you have to define what verbs can they take on which nouns, right? Can you short edit, rename, delete? This is like classic crud stuff you have to figure out. But I don't know. Can you like fork an agent session? What are the implications of that? I think the hard bit of product design is designing a coherent system that takes all this complexity that could exist, especially in something like DevTools, and reducing it to the simplest possible form you can, which is a very easy to say, extremely hard to do every time, to like a really canonical set of nouns that the user can go, okay, I can point at that. I understand what that's going to do. I can, when I click a button, I don't get surprised at the outcome. This takes time to do this kind of like hard, reduce it to its best. best, most elegant form. This Speaker 2 (12:50) is so interesting because what you've described of like, you know, we have a new product that has not existed before, like a dev tool in a digital space, which lives in our head or inside of a computer with things that we just invented, may that be an MCP or an agentic skill. And then thinking of how we find the right words so people can use it and it makes sense. And you're kind of, I just see that you're kind of drawing up a map in your... your head, which is not all that different to when you're building a new system as a software engineer. And I remember talking with Ken Beck, who talked about how with Ward Cunningham, they came up with some of the basics of that might have been domain-driven design, or it might have been some related concepts, but they had a thesaurus in front of them trying to, they searched for the right words on how to, oh, it was the design patterns. Design patterns later came out of it, but they were trying to put a name on these constructs and these things and how, which feels like a very similar thing to what you're describing. Yeah, Speaker 1 (13:54) yeah, yeah. That's design. This is where I kind of get into, sure, there's types of design. Like you could be like, there's interior design, there's brand design, there's product design. But product design, when we talk about it in tech, is actually software design. And software design is engineering. It's actually the same skill. Like you might be working with slightly different materials in the sense of one of you cares more about the colors and the size and the shadows and like the shape of things and the motion design. But that person also has to understand like what's the shape of the database? Like what are these APIs? Like what is the data in the right place? Are we passing data through this component in the right way? Like they have to also understand. Speaker 2 (14:28) This is interesting because the designers I worked with years back at places like Uber and at Skype, they had their design tools, which. It was Sketch, later Figma. They typically work with the product folks. They did explorations or UX prototypes. They often sat into user testing. But in the end, they had a design. They had visuals. They had animations. That was their thing. And they handed this over to us engineers together with the PRD. Here's the product. Here's how it's going to look. And then we built it. And we would build the UI, let's say, on mobile. And we would then go maybe sit with them or show them and they would say, oh, this motion doesn't feel good. But my view of the designer is like, well, it was very visual. And for example, those designers, maybe they didn't need to, but they didn't need to get involved in like how they basically were. So on how the flows, they were very much aware of the flows of the user journey. Speaker 1 (15:20) Yeah. Speaker 2 (15:20) So like, is that type of... Design, how would you characterize as being different? Or is it just that their domain is a little bit different? It's more of the business level, the more kind of mobile. These were like mobile and web and some of those. Speaker 1 (15:35) Yeah, I think it gets into kind of like how we label different parts of design. Like the kind of design I'm talking about is obviously biased by my experience, which is much more design engineering stuff, because it is like when I hear design engineer, that's kind of a catchphrase now. And what does that mean? But I think of it as a designer who really engages in the engineering and understands how the product works. And it's required. It's not required in all domains. Again, if you're doing government forms, I don't think you need to understand the database. But if you're designing for developers or you're designing in a brand new field like AI, where so much of how the product works is determined by what is possible on the back end and the shape of the data, then you do need to engage with it a lot. But if you're working on an app where actually... A designer is probably better served by advocating for the user. I think that's a kind of more traditional philosophy of product design is that you represent the user and you represent trying to get the best experience possible for the user. And that means user interviews, caring about flows, like does this button feel big enough? Does it have the right words? And then they can spend much more energy there if they don't have to care about the technical backend. Like maybe it's actually irrelevant when really what you need to care about is like, does this flow make sense to people? So that's... Not necessarily a different kind of designer, but if you kind of think of the whole stack, right, but expand it all the way out, not just back end and front end, but the interface and users and then the product in the context of a business and like a product in the context of an economy, like there are people who lean way more on this side. And I'm a bit more of the straddling of the product design and the engineering, but you can have valid designers all along this. And some people, again, you know, just visuals or just animation, like there's lots of niches. I just like a bit more of the... the half engineering, half design, like slice of it. Speaker 2 (17:13) To help understand a bit more of what you do, can you talk about the tools that you use? Like, you know, as engineers, we're kind of used to our tools used to be the ID and the code editor and, you know, some of the hardcore people like Vim and some of those things. And these days, of course, it's changing a bit more. But, you know, those are the tools that we use. What are your tools? It Speaker 1 (17:30) changes all the time. I mean, to some degree, like some things stay constant, like you're and you're doing similar. But of course, at the moment, I'm trying to try everything because part of my job is like trying to figure out what GitHub should do next. That's what our team does. That's Speaker 2 (17:44) actually the name, right? GitHub Next. GitHub Next, Speaker 1 (17:45) hey? It's like, it was well named. So a lot of the time, like we are just, you know, of course, I'm trying out Codex and Claude and like dogfooding stuff internally at GitHub. I've tried Conductor. I mean, name any agentic harness, like OpenCode, Pi. I try them all. I do love Codex at the moment. Like I do think... open AI is onto some really good stuff, at least in there. Their design of their desktop app is beautiful. They've really thought it through. So I think they're doing some really good stuff. I still use paper and pen for initial brainstorming. Speaker 2 (18:15) You have your notebooks here. Speaker 1 (18:17) Yeah, I brought some along because notebooks aren't dead. I don't think they're going to be dead forever. And I still use Figma because I know how to use it and I can do some brainstorming in it before I pass it off to an agent. But to be honest, there's a point where once you figured out what you need to build, which is actually all the work. Once you hand it off to an agent, it's not that implementation is solved, but we've reached a point where implementation is like good enough that if I spec it out really well and I list out how the agent should verify for me that it actually did the work, I can hand it to an agent and just like be like, right, let me know when you've got a PR up. You know, I don't really look at code that much anymore. I do look at PR code when I'm reviewing it, but skim, skim, skim, you know, okay, that looks sensible. Speaker 1 (19:02) merge. So most of the work I find is everything leading up to telling the agent to implement something. And then the PR review is kind of a separate piece of work. But like the bulk of my tools deal in this first section now versus we used to have the IDE, you know, once it was like, okay, you've decided this is the right thing to design. Now you actually start the work of like implementing it. It's kind of beautiful that that's no longer part of it as much. Open VS Code sometimes, but not really. Speaker 2 (19:25) Yeah, but beforehand you would prototype, right? Like you build prototypes. Speaker 1 (19:29) Yeah, yeah, yeah. As part of the like, what should we build? I include in this lots of prototyping. And I kind of have the privilege of being on a team where we don't have to build like production quality software. We are mostly trying to prototype and validate ideas. So we have a lower quality bar than someone shipping to proper github.com. That's a very high quality bar. Speaker 2 (19:47) Yeah, which makes sense. Speaker 1 (19:48) I Speaker 2 (19:48) mean, that's kind of, you get the kind of, you get the directional things right. And then once it's great, you might build it or you might decide to build it. Speaker 1 (19:55) Yeah, yeah. But I definitely, I mean, we can hopefully show these later. I do a lot of stuff sketching. I mean, even just interface design, a lot of what you're doing is just drawing boxes and then being like, does this slide over from the front, from the bottom? Like if I click this button. Speaker 2 (20:08) So this is like you kind of drawing up a... Speaker 1 (20:10) how an Speaker 2 (20:11) interface you think could look like. So I see a mix of UIs, and we'll put these onto the screen, but UIs, description of what they do. Can you just talk to one of these, or one that's interesting or memorable? Speaker 1 (20:29) Yeah, so this is a new, I should explain the context. I'm prototyping at the moment something where my theory is like, one of the bottlenecks with agents is planning, is... really bad experience at the moment. Like at the moment you have a long chat with an agent, sometimes even in a CLI, which is a pretty primitive interface. And then the agent... grills you by asking you a set of like choice A, B or C questions. And it does this like a hundred times over if you're using Matt Pecock's grill me skill or whatever you like. Speaker 2 (20:55) He was just on a podcast. Yeah. Speaker 1 (20:58) And by question 20, you're like quite tired and your brain starts shutting down. Speaker 2 (21:03) That was my experience. I went through and I got 36 questions and I was kind of, they were good, but I was starting to get annoyed around like, yeah, like 20 or 25. I'm like, and Speaker 1 (21:12) I had Speaker 2 (21:12) no idea when it would stop. Speaker 1 (21:13) Right. It's endless. And like the human brain, you get tired. You can't make the same decisions in this shorter time. And also you don't have enough information about most of those decisions because it's given you a question and three options and it's told you number A is recommended. Then you just start being like, yep, A, A, enter, A, I agree with you. So this is not an ideal experience. This gets into like agents love to output reams and reams of text. And that's an ideal output for agents, but it is not an ideal input for humans. So we have a mismatch with like, what do humans need to be able to digest large amounts of information and truly understand it and be able to make informed decisions? That is not the interface for this. So I'm trying to explore how would we make an