Algorithms + Data Structures = Programs - Episode 298: Design of APIs, UIs & Algorithms

Episode Date: August 7, 2026

In this episode, Conor and Ben chat about the design of APIs, UIs & algorithms!Link to Episode 298 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)SocialsADSP: The Podcast: TwitterConor Hoekstra: LinkTree / BioBen Deane: Twitter | BlueSkyShow NotesDate Recorded: 2026-07-22Date Released: 2026-08-07C++Now 2018: Ben Deane “Easy to Use, Hard to Misuse: Declarative Style in C++”NDC Toronto UI talkThe Design of Everyday ThingsAbout Face: The Essentials of Interaction DesignUser Interface Design For ProgrammersJust My TypeThe Elements of Typographic StyleIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

in designing these APIs for the algorithm that work and the algorithms need to fit together, right? And need to fit together well. And you want people who are using your code to, when they try the obvious thing, you want it to work and you want it to work well with good performance, with good composability. And conversely, when they try, you know, you want the easy things to be easy. and the slightly more esoteric things to be possible. But you don't want the dangerous things to be easy.

You don't want them to accident, to do something which looks fine but falls off a performance cliff. Welcome to ADSP, the podcast, episode 298, recorded on July 22, 2006. My name is Connor, and today with my co-host, Ben. We chat about the design of APIs, UIs, algorithms, and more. We should talk in future because you work. on algorithm libraries. Right? You still work on that? Yeah, yeah.

So in some way. I don't know which variant of that you work on right now, but so we should talk about the design of the APIs for those kind of things because most of what I a lot of what I do these days is API design and I

I look at the code my team is writing you know, just to bring this back to what the podcast and theory is about. I look at the code my team is writing and I see where they are having difficulties issues. Sometimes they don't even know they're having them, right? Because because they know how to do C++ plus, they know how this works. They don't see that this can work an easier way or a different way that would make it mesh better with something else. Things like that, particularly in the realm of like, and these are like

sometimes small, small API things. And I'm wondering if, you know, you have the same experience in designing these APIs for the algorithmic work and the algorithms need to fit together, right? And need to fit together well. And you want people who are using your code to, when they try the obvious thing, you want it to work and you want it to work well with good performance, with good composability.

And conversely, when they try, you know, you want the easy things to be easy and the slightly more esoteric things to be possible, but you don't want the dangerous things to be easy. You don't want them to accident, to do something which looks fine but falls off a performance cliff, right? Things like that. So I'm wondering how much of that you do in your day-to-day.

Yeah, we definitely, maybe that's where the next time we record, we should talk about just design in general, because it's interesting. As soon as you started talking about API design, it made me think about your talk title, easy to use, hard to misuse. Right. That's not my title.

That's Scott Myers, but... Well, I mean, you borrowed it. I mean, it's a title for one of my talks. Right, yeah. I didn't originate that term. I have been doing a ton of outside of my day job, like app design and U.S. design. Mm-hmm.

And I've started to realize that, like, and also on top of that, like, I want, there was a talk that probably the most, the best talk that I saw, at NDC Toronto back in a couple months ago was a UX talk. We might have even mentioned it on a past podcast. I'll find it. I'll link it in the show notes.

I can't remember the guy's name. But it was just basically like rattling through different like design principles. Like, you know, if you change the color of a font on a table of words, you know, that pops out more. Things honestly that seem kind of obvious. It's like why are you throwing some guy's name on that principle? Like that's just obvious. But like I guess maybe some things that are obvious to some people are not to others.

And there's a nice philosophical discussion in there of like, especially being in research. You know, it's like, well, something has to be novel. But like everyone's, the novelty of something is informed by one's experience. And like what I think is like, yeah, novelist relative. Yeah, someone else might think something. Oh, that's really novel. And I think, well, that's just obvious. Like, there's nothing novel about it.

It's just like an obvious outcome of like the last two steps that I took. Anyways, and the things that I've noticed is that, like, I have an ex, it. both when it comes to API design, but also just UX design. I am so opinionated, but opinionated because obviously there's a way that this thing should work, the number of buttons that I have to click, you know, the difficulty of navigating to some feature. Some things that, like, this information that I know the app knows, like from the metrics it has, but it's just not showing me. And...

So you've been doing... You described it as UX design? Yeah. Does that include U.I design? Well, so I guess U. UX? Have you been doing that as well? I mean, so UX is user experience,

UI is user interface. You know, those to me seem like I'm making a Vend diagram. Be careful what you say now because I have friends who are UX designers and they would, if you say UI and UX are the same thing, they'll be

banging on your door. Well, maybe we should get some of them and bring them on the podcast because like I was making a master card symbol with my two hands to represent a Venn diagram that's an extremely overlapping Venn diagram was what kind of just mind. Because that's the thing is like a user interface in my opinion, and obviously I'm not a designer, although I will say in today's age, I feel like more and more of what I do on a daily basis is design. Like whether it's designing an API or whether it's designing

the user interface of an app that I'm working on or whether I'm designing like that, because that's the thing is a user interface. I think, I mean, I could be wrong. We got to bring the experts on, but is massively informed by the user experience that I want. I think a very broad way to describe the difference might be just to say that, and I could be wrong in this, but it seems like one way to describe the difference might be to say that user experience is a higher level concern, right? User experience is about the flows of what happens in an application when the user has a task in mind, for example.

high-level thing. I want to do this. How does the application enable that guide me through it? UI, it seems to me, might take into account many more low-level kind of design things like, things like Fitzlaw, you know, to be very, very basic about it, you know, which come into UI design and not so much into UX design, maybe. That's the way I think about it. I could be wrong, you know, I need to talk to my friends who know these things. we should yeah we should put a we should put a pin in this and uh and definitely talk about this because yeah honestly like inside my i had you know with the inner monologue that is never ends with myself like i have all these like names for what like what i what do i do you know on paper i'm a research

scientist at work but then like outside of work i do a ton of like development and you know hobby projects and i've got this podcast i've got a youtube channel and anyways internally i've started referring to myself as a dashboard designer. Like, it's so easy to throw up these dashboards now that, and anyways, I've been thinking a ton about design and that, like, there is something to be said, certain people, I think, naturally develop a better design sense. And I think... Have you been reading any of the, quote, design literature?

No. I have a long list of books, which include books from you. I still have not read the design of everyday design. things. Is that one of them? Yeah. Yeah. And you should also read the designer. Is it the design of... There's a sort of follow-up which sort of argues the other side.

The design of not beautiful things, but emotional things. Something like that. But that's Don Norman. You know, that's only one aspect and a fairly small one these days of that is considered good design. There are loads of other things. You know, you should read Christopher Alexander, you should read probably things like, I don't know, just some things on my bookshelf. About Face. You know, there's, I forget the name of the book, UI Design for Programmers, I think, back in the day.

There's things like, don't make me think. I don't know. And I don't know the current state of the U.X. slash UI design literature. Don't make me think. So I should stop talking. About Face. Is that a font type book?

Ben's looking back at his bookshelf of. Actually, no. The Essentials of Interaction Design, Alan Cooper. Essentials of Interactive. But if you want a book about fonts, two books I can recommend. One's called Just My Type. That's kind of a popular science style book about fonts. But the other one, if you really want to know about fonts,

and probably the most beautiful book, one of the most beautiful books in the past century that's ever been published. Bringhurst is the author. Robert Bringhurst, I think, and I forget the name of the book, but it is absolutely, you can probably bring that really quick.

The elements of typographic style? That's the one. The elements of typographic style. That is a must read if you're interested in typefaces. Yeah, we could probably talk for, I mean, like I said, we will resume this conversation.

about not just API design, but just, I feel like, yeah, like these, like what you said, like easy to use, hard to misuse. But also, too, there's this kind of like, like I said, it's one of these things. It's like it's percolating or cultivating in my brain and it's not fully formed. But it's like now that I'm in the control of designing a bunch of stuff, it's like I have expected behaviors of the way things work. Right. And so often now, like, you don't realize it when, or I mean, you do realize it, but you've just trained your brain to silence the voice of like, like, so, you know, one of the apps is a podcast player. I've used a bunch. And like, I didn't realize, but many times in using the app on a daily basis for hours at a time, like, so many things are not what I expect.

But you just, you learn how to navigate to the places. Right. what you know now. They weren't what you expected to start with. But then as soon as you put yourself in a designer like role, you now realize that wait a second, every single time my, there's a voice in my head saying like, well, how come it, how come it did that? How come it's not showing me this? How come I have to hit three buttons to get to this? How come I'm not just doing it this way, actually? Like, sure, it's never been done before, but like the world's your oyster. You can do anything you want. If you're designing it yourself, you realize that actually that voice, that voice is constantly

saying things throughout the day, whether it's when you're programming, whether it's when you're opening the handle to some door and you realize that, oh, that's like, that's the one that I always remember from you, from watching one of your talks. I think you mentioned that the, well, that's, yeah, that's from Don Norman, yeah. Oh, yeah, that's right. Yes, the design of fire doors, I think, is what you're very much. Where it's, you should never have a handle if you need to push. It should just be a flat panel. Right. And that's, that's, uh, that's the law in many countries for fire doors specifically. Fire doors have to open outwards, you know, they have to basically open in response to a

crush of people against them. Right. Yeah. And anyway, so it's small things like that where like, you know, I heard that from you or in one of your talks at one point. And now anytime I, because you have that experience, if not on a daily basis, on a weekly basis, like you go to open a door and then you go to pull it and then you have to, you have to push.

But there's a handle there. So the handle makes you, it's a pulling mode. You don't grab a handle. to push it, you grab a handle to pull it. Right. And it affords pulling. Yeah. Yeah.

Like, yeah, the affordances of things. Anyways, and it's like there's this voice that you have. And the affordances in code also is a thing. Absolutely. Absolutely. And like, you know, you take it into, yeah, into the array language space as well, which is like I have this whole other thing of like the primitives, which is, you know, the primitives in an array language are the same thing as the vocabulary in an algorithm library, right?

The things that you provide people with affect, you know, how they will build their solutions. And even as far as like, you know, for a while I used to say that, you know, you shouldn't bundle a binary operation with a generic algorithm because, you know, it. Because it colors the idea of what that algorithm is limited to. Adjacent difference is the poster child. But then on top of that, like I basically added a caveat to that in that you should in your library also. provide specializations. So like if you could have written accumulate without specifying stood colon colon plus plus or stook colon colon plus, you should you shouldn't allow, they don't encode the binary operation, but also provide an algorithm called sum. Yes. Because the fact that I have to go stood

colon colon colon accumulate per end stood colon colon plus with zero for the initial value, it now like changes the cost of using that and it irritates me every time. And most of the time, I just want to add up my list of numbers. And, and, and, you know, it is with a zero integer type and I don't need to affect the type of whatever. Anyway, so it's, you know, these things, it's like, you know, you develop stronger and stronger opinions of like, okay, you know, don't encode it, but also add these extra things. And it's in all facets of life. It's with doors that you're entering. It's with APIs you're using. Yeah. Yeah. And with engineering, with, with software engineering,

with API design, there's a definite discipline to it. And it's the same, you know, it takes a lot of, it takes a lot of things from sort of physical,

real world to design design because you have to do the same sorts of things. You have to think about, well, a user is coming to use my API. They have in mind something they want to do.

Right. Right. They're trying to sort their data or, you know, get the top 10 or whatever it might be. They're trying to do something. They've got a problem they're trying to solve. They're going to use my API to do it.

How are they going to do that? Is it going to be obvious which things to use? Is it going to be easy? Is it going to have all the right outcomes for them? And how long is it going to take them to figure that out? And, you know, that you were saying earlier, like the kind of, when you put on a designer hat, all the sort of minor irritations that you notice in these apps that maybe you've been using for a few years and when you use them in a day-to-day mode, you've just gotten used to it.

You don't notice that it's making you do an extra click here, an extra press there or whatever. But also, you know, so the difference between a sort of product that is merely adequate, reasonable, ticks all the boxes that you want to do, gets the job done, and a product that is absolutely top of the line, fun to use even, you know, is those tiny things. a lot of the time, right? You know, and so related to this is a thought I often have, which is that, you know, the really good systems and products in the world often are not designed for beginners, right?

They might not be designed for beginners. Now, it's helpful if they're easy for beginners to get started. But, and again, to loop back to games, I saw. there sometimes in games like, you know, designing for beginners because you want people to, want it to be easy to play your game or use your system or use your API. You design it for the beginner. I think that's the wrong outlook. I think the best, the best systems out there in the world are designed for the perpetual intermediate. The idea of the perpetual intermediate is one that I think about a lot in terms of design,

you know, because the best systems and the best programs and the best products that I use kind of have that flavor, you know, you're not a beginner after you've used it for a week or two weeks, you know, the beginner phase is very, very small, but the intermediate phase can go on a lifetime.

You know, you can be an intermediate user indefinitely. And, you know, the good products are the ones that support what you need in terms of an intermediate, but also allow you to discover these new things, these better ways to do things all the time. Yeah, that's a very, very interesting thought provocative. Like, yeah, I'm definitely an intermediate, perpetual intermediate with a few different, like audacity, for instance. Right.

I am not an audacity expert, but I know how to do what I need to do. And every once in a while, I do learn something, you know, if you need to, after you've spliced tracks and you want to rejoin them so that you don't always. have to move control j you know like and that's the that's the other thing is it has shortcuts half the time that i don't know but i'm sure that you know yeah but every so often you learn a new thing you and you know after after a week of being a beginning with that new thing you've integrated into your workflow yeah a very interesting conversation topic that we will next time dive deeper into i mean i feel like we should stop pretending because we're spending

the last 25 minutes talking over this this now probably is an episode I was thinking like, you know, 15 minutes ago, I was like, we'll put a pin in this conversation and then 15 minutes later, like we have ourselves actually the first episode of this multi-episode NPI design. There's a lot more to talk about. Yeah, yeah, yeah. And honestly, I've become like, that's the thing is because I call, like, in my head, I'm calling myself this like quote unquote designer.

I've started to care, like, this voice that I've silenced my whole life, really, except for when it comes to things like PowerPoint, you know, the voice is allowed to talk very loudly. But for all other aspects of my life, you just kind of, it's not important to whine about some app on your phone. Because like you can't affect change. It's just the app. You know, what are you going to write the team and say, hey, please change this for me? I actually did think about emailing the Spotify team to be like, why is your podcast queue like non-existent slash so terrible? You're like the number one podcast player in the world.

Like, do you have no one here that thinks deeply about this stuff? Right. Well, the other thing that happens, the thing that happens, the thing that. happens at a corporate level, at a capitalist level, is that products often are different and objectively worse in some ways, but they have to be different for the sake of being different. Because, you know, it's a sort of thing like, you know, it's kind of related is like if you wanted to go into the cola making business, you wouldn't try and make Coke. You wouldn't try and copy Coke. You try and differentiate yourself. Right. There's no point competing with Coke at making Coke.

Yeah. And so a lot of times what we see in software is different products, which are, you know, in some ways that we can pick on objectively worse than other products. Like sometimes the problem has been, the problem you want to solve as a user, the way to represent that in the software has been solved very, very well. And this software is great. But, but, you know, because you can't, you can't use it on this platform or you. You can't use it in a corporate environment or whatever. The offering you get elsewhere is not as good. And in some, you know, some of it is subjective, of course.

Some of it is what you used to. But some of it is not. Some of it is actually objective. Some of it is just you can say this, this, this doesn't do this as well as this other thing. And I don't know why, because this was a solved problem 20 years ago. Well, the difference is they had to be different because they just had to be different in the market or something like that, you know. That's maybe the difference.

Sometimes the difference is, well, it was made by people who don't know their field well enough to know that this is a solve problem. Yeah, that's a whole other aspect of this conversation is like, there's designing something for yourself and then there's designing something for population. Yeah. But that is the most annoying thing as a user when you, when you come up against a product and it's okay. but it's just clunky and you just think

why is it so clunky we know how to do this like this has been solved there are much smooth ways to do this you know it's almost like five minutes thought would tell you how to do this much more smoothly but no you persist in shipping this thing

yeah all right well now I'm very I'm very excited for our new series called I don't know design 101 or I don't know well come up with a sexier name for it than design 101 design you got any good names design like an alliteration

ADSP and that stands for algorithm design superpowers there you go there we go we've got we've always back naming different things all right well end this this is probably part three of three parts I was going to be two parts but then as you mentioned we just kept on talking about the design thing and and actually maybe the algorithmic design of software products oh there you go there you go there you go

that's ADSP. Be sure to check these show notes, either in your podcast app or at ADSP the podcast.com for links to anything we mentioned in today's episode, as well as a link to a get-up discussion where you can leave thoughts, comments, and questions.

Thanks for listening. We hope you enjoyed and have a great day. I am the anti-brace.