

        <cite>Ben</cite>
      <time>0:00</time>
      <p>
          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 who&#39;s you want people 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 you want the easy things to be easy and the the slightly more esoteric things to be possible, but you don&#39;t want the dangerous things to be easy.
      </p>

        <cite>Conor</cite>
      <time>0:36</time>
      <p>
          You don&#39;t want them to accident to do something which looks fine but falls off of off a performance cliff Welcome to ADSP the podcast episode 298 recorded on July 22nd 2026. 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?
      </p>

        <cite>Ben</cite>
      <time>1:18</time>
      <p>
          You still work on that? Yeah yeah in some way I don&#39;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 just to bring this back to what the podcasting theory is about I I look at the code my team is writing and I see where they are having difficulties issues. Sometimes they don&#39;t even know they&#39;re having them right because because they know how to do C they know how this works they don&#39;t see that this can work a an easier way or a different way that would make it mesh better with something else. Things like that in the particularly in the realm of like and these are like sometimes small small API things. And I&#39;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 who you want people 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 you want the easy things to be easy and the the slightly more esoteric things to be possible but you don&#39;t want the dangerous things to be easy. You don&#39;t want them to accident to do something which looks fine but falls off of off a performance cliff right things like that. So I&#39;m wondering how much of that you do in your day to day.
      </p>

        <cite>Conor</cite>
      <time>2:59</time>
      <p>
          Yeah we definitely maybe that&#39;s where the next time we record we should talk about just design in general because it&#39;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 and right that&#39;s not my title that&#39;s Scott Myers but well I mean you borrowed it and I mean there&#39;s a title for one of my talks but I I didn&#39;t originate that term. I have been doing a ton of outside of uh my day job like app design and UX design and I&#39;ve started I&#39;ve started to realize that like and I and also on top of that like I what 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&#39;ll find it I&#39;ll link it in the show notes. I can&#39;t remember the guy&#39;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&#39;s like why are you throwing some guy&#39;s name on that principle? Like that&#39;s just obvious. But like I guess maybe some things that are obvious to some people are are not to others and if there&#39;s a nice inch philosophical discussion in there of like especially being in research you know it&#39;s like uh well something has to be novel but like everyone&#39;s the novelty of something is informed by one&#39;s experience and like what I think is like yeah novelist relative someone else might think something oh that&#39;s really novel. And I think well that&#39;s just obvious like there&#39;s nothing novel about it&#39;s just like an obvious outcome of like the last two steps that I took. Anyways and and the things that I&#39;ve I&#39;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 like opinionated because obviously there&#39;s a a way that this thing should work the number of buttons that I have to click you know the the difficulty of navigating to some feature some things that like information that I know the app knows like from the metrics it has but it&#39;s just not showing me.
      </p>

        <cite>Ben</cite>
      <time>5:00</time>
      <p>
          And uh and so you&#39;ve been doing you might you described it as UX design? Yeah does that include UI design? Well so I guess UI UX have you been doing that as well?
      </p>

        <cite>Conor</cite>
      <time>5:11</time>
      <p>
          I mean so UX is user experience UI is user interface you know uh those to me seem like like I&#39;m I&#39;m making a Venn 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&#39;ll be banging on your door. Well maybe we should get some of them and put bring them on the podcast because like I was making a uh the a MasterCard symbol with my two hands to represent a Venn diagram that uh an extremely overlapping Venn diagram was what Connor just said that&#39;s the thing is like a user interface in my opinion and obviously I&#39;m not a designer although I will say in today&#39;s age I feel like more and more of what I do on a daily basis is design. Like whether it&#39;s designing an API or whether it&#39;s designing the user interface of an app that I&#39;m working on or whether I&#39;m designing like that because that&#39;s the thing is a user interface sh I th I think I mean I could be wrong we gotta bring the experts on but like is massively informed by the the user experience that I want.
      </p>

        <cite>Ben</cite>
      <time>6:11</time>
      <p>
          Like I think a very broad way to describe the difference might be just to say that and I could be wrong in this but 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 it&#39;s kind of a 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 to be very very basic about it you know that which come into UI design and not so much into UX design maybe. That&#39;s the way I think about it I could be wrong you know I need I should talk to my friends who know these things.
      </p>

        <cite>Conor</cite>
      <time>7:03</time>
      <p>
          We should yeah we should put a we should put a pin in this and uh and definitely talk about this because yeah I I honestly like in inside my I had you know with the inner monologue that is never ends with myself like I I have all these like names for what like what I what do I do you know on paper I&#39;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&#39;ve got this podcast I&#39;ve got a YouTube channel. And anyways internally I&#39;ve started referring to myself as a dashboard designer like it&#39;s so easy to throw up these dashboards now that and and anyways I&#39;ve been thinking a ton about design and that like there is something to be said certain people I think naturally developed 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.
      </p>

        <cite>Ben</cite>
      <time>7:57</time>
      <p>
          I still have not read the design of everyday things is that uh one of them yeah yeah and you should also read the design of is it the design of there&#39;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&#39;s that&#39;s Don Norman you know that&#39;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&#39;t know just some things on my bookshelf uh about face you know there&#39;s I forget the name of the book UI design for programmers I think back in the day there&#39;s things like don&#39;t make me think I don&#39;t know and I don&#39;t know the current state of the the UX slash UI design literature don&#39;t make me think so I should so I should stop talking about a font type book Ben&#39;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&#39;s called Just My Type that&#39;s kind of a that&#39;s kind of a uh 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 has 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 it up really quick. The elements of typographic that&#39;s the one the elements of typographic style that is a that is a must read if you&#39;re interested in in typefaces.
      </p>

        <cite>Conor</cite>
      <time>9:54</time>
      <p>
          Yeah we could probably talk for uh I mean like I said we will resume this conversation about not just not just API design but just I I feel like yeah like these like what you said like easy to use hard to misuse but also too there&#39;s this kind of like I said it&#39;s it&#39;s one of these things it&#39;s like it&#39;s percolating or cultivating in my brain and it&#39;s not fully formed but this like now that I&#39;m in the control of designing a bunch of stuff it&#39;s like I I have expected behaviors of the way things work. Right. And so often now like you don&#39;t realize it when or I mean you do realize it but you&#39;ve just trained your brain to silence the voice of like like so you know one of the apps is a podcast player. I&#39;ve used a bunch and like I didn&#39;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 they&#39;re what you know now. They weren&#39;t what you expect exactly to start with and 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&#39;s a voice in my head saying like well how come it how come it did that how come it&#39;s not showing me this how come I have to hit three buttons to get to this how come I&#39;m not just doing it this way actually like sure it&#39;s never been done before but like the world&#39;s your oyster you can do anything you want if you&#39;re designing it yourself you realize that actually that voice that voice is constantly saying things throughout the day whether it&#39;s when you&#39;re programming whether it&#39;s when you&#39;re opening the handle to some door and you realize that oh it does like I that&#39;s the one that I always remember from you from watching one of your talks I think you mentioned that the Well that&#39;s yeah that&#39;s from Don Norman yeah.
      </p>

        <cite>Ben</cite>
      <time>11:36</time>
      <p>
          Oh yeah that&#39;s right yes the the design of fire doors I think is what you&#39;re expecting. Where it&#39;s the you should never have a handle if you need to push it should just be a flat panel. Right and that&#39;s that&#39;s uh that&#39;s the law in many countries for fire doors specifically fire doors have to open outwards you know they have to they have to basically open in response to a crush of people against them. Yeah.
      </p>

        <cite>Conor</cite>
      <time>12:00</time>
      <p>
          And anyway so it&#39;s it&#39;s small things like that where like you know I I heard that from you or in one of your talks at one point and now any time 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&#39;s a handle there so the handle makes you that&#39;s a pulling mode you don&#39;t grab a handle to push it you uh you grab a handle to to pull it right and uh it affords pulling yeah it&#39;ll yeah it&#39;ll like yeah the affordances of things anyways and it&#39;s like there&#39;s this voice that you have in the affordances in code also is a thing. Absolutely absolutely and like you know you you you can 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 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&#39;t bundle a a binary operation with a generic algorithm because you know it it op because it colors the idea of what the algorithm is limited to.
      </p>

        <cite>Ben</cite>
      <time>13:08</time>
      <p>
          Adjacent difference is the poster child thing.
      </p>

        <cite>Conor</cite>
      <time>13:10</time>
      <p>
          Then on top of that like I I basically added a a a caveat to that in that you should in your library also provide specializations. So like if you could have written accumulate without specifying std colon colon plus plus or std colon colon plus you should you shouldn&#39;t allow the don&#39;t encode the binary operation but also provide an algorithm called sum. Because the fact that I have to go std colon colon accumulate per n std 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 uh and and you know it it is with a a zero integer type and I don&#39;t need to affect the the type of whatever. Anyway so it&#39;s you know these things it&#39;s like you know you you develop stronger and stronger opinions of like okay you know don&#39;t encode it but also add these extra things and uh it it&#39;s in all facets of life. It&#39;s with doors that you&#39;re entering it&#39;s with APIs you&#39;re writing APIs you&#39;re using.
      </p>

        <cite>Ben</cite>
      <time>14:08</time>
      <p>
          Yeah. Yeah. And with engineering with with software engineering with API design there&#39;s a definite discipline to it and it&#39;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 they&#39;re trying to sort their data or or you know get the top ten or whatever it might be. They&#39;re trying to do something. They&#39;ve got a problem they&#39;re trying to solve then they&#39;re gonna use my API to do it. How are they gonna do that? Is it going to be obvious which things to use is it going to be easy is it gonna you know 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 the kind of when you put on a designer hat all the sort of minor irritations that you notice in these apps that that maybe you&#39;ve been using for a few years and when you use them in a day-to-day mode you&#39;ve just gotten used to it you don&#39;t notice that it&#39;s making you do an extra click here an extra press there or whatever but also you know that 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 yes 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 the really good systems and products in the world often are not designed for beginners right they might they might not be designed for beginners. They might now it&#39;s helpful if they&#39;re easy for beginners to get started but and again to look back to games I saw this sometimes in games like you know designing for beginners because 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&#39;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 uh products that I use kind of have that flavor you know you&#39;re not a beginner after you&#39;ve used it for a week or two weeks you know you the beginner phase is very very small but the 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 sub 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.
      </p>

        <cite>Conor</cite>
      <time>17:15</time>
      <p>
          Yeah that&#39;s a very very interesting uh thought provocative like yeah I&#39;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&#39;ve spliced tracks and you want to rejoin them so that you don&#39;t always have to move control J. You know like and that&#39;s the that&#39;s the other thing is it has shortcuts half the time that I don&#39;t know. But I&#39;m sure that you know Yeah.
      </p>

        <cite>Ben</cite>
      <time>17:44</time>
      <p>
          But every so often you learn a new thing you and you know after after a week of being a beginner with that new thing you&#39;ve integrated it into your workflow.
      </p>

        <cite>Conor</cite>
      <time>17:52</time>
      <p>
          Yeah.
      </p>

        <cite>Ben</cite>
      <time>17:53</time>
      <p>
          A very interesting conversation topic that we will next time dive deeper into I mean I I feel like we should stop pretending because we&#39;ve been spending the last 25 minutes talking over this now probably is an episode.
      </p>

        <cite>Conor</cite>
      <time>18:07</time>
      <p>
          I was I was thinking like you know 15 minutes ago I was like we&#39;ll put a pin in this conversation and then 15 minutes later like we have ourselves the actually the first episode of this uh multi-episode uh DPI design there&#39;s a lot more to talk about yeah yeah yeah and honestly I&#39;ve become like that&#39;s the thing is because I I call like in my head I&#39;m calling myself this like quote quote unquote designer I&#39;ve started to care like this voice that I&#39;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&#39;s not important to whine about some app on your phone because like you you can&#39;t affect change it&#39;s just the app you know what are you gonna write the 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 cue like non-existent slash so terrible you&#39;re like the number one podcast player in the world like do you have no one here that thinks deeply about this stuff? Right.
      </p>

        <cite>Ben</cite>
      <time>19:03</time>
      <p>
          Well the other 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&#39;s a sort of thing like you know it&#39;s kind of related is like if you wanted to go into the cola making business you wouldn&#39;t try and make coke you wouldn&#39;t try and copy coke you try and differentiate yourself. Right. There&#39;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 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&#39;t you can&#39;t use it on this platform or you can&#39;t use it in a corporate environment or whatever the the 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&#39;t do this as well as this other thing and I don&#39;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&#39;s maybe the difference.
      </p>

        <cite>Conor</cite>
      <time>20:40</time>
      <p>
          Sometimes the difference is well it was made by people who don&#39;t know their field well enough to know that this is a solved problem yeah that that that&#39;s a whole other conversation like aspect of this conversation is like there&#39;s designing something for yourself and then there&#39;s designing something for population. Yeah.
      </p>

        <cite>Ben</cite>
      <time>20:58</time>
      <p>
          And but that is the most annoying thing as a user when you when you when you come up against a product and it and it&#39;s okay but it&#39;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 smoother ways to do this. You know it&#39;s almost like five minutes thought will tell you how to do this much more smoothly but no you persist in shipping this thing.
      </p>

        <cite>Conor</cite>
      <time>21:22</time>
      <p>
          Yeah all right well now I&#39;m very I&#39;m very excited uh for our our new series called I don&#39;t know design 101 or I don&#39;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 now stands for algorithm design superpowers there you go there we go we&#39;ve got we&#39;ve always backronyming uh different things all right we&#39;ll end this this is probably part three of three parts it was going to be two parts but then as you mentioned we just kept on talking about the design thing and uh and actually maybe the algorithmic design of of software products. Oh there you go there you go that&#39;s ADSP. Be sure to check these show notes either in your podcast app or at adspthepodcast dot com for links to anything we mentioned in today&#39;s episode as well as a link to a GitHub 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 Bryce
      </p>