1 00:00:12,681 --> 00:00:20,160 >> Hello, everyone, welcome back. Up next, we  have the wonderful Leigh Brenecki, who attendees   2 00:00:20,160 --> 00:00:29,600 of past PyCons may recognize. Leigh is from  Melbourne and Adelaide. She was the conference   3 00:00:29,600 --> 00:00:42,640 director of PyCon AU. She's passionate about API  design, cycling and snacks. Everyone, we will   4 00:00:42,640 --> 00:00:48,560 be taking questions, if there is time at the end.  So, remember the handy, little questions tab.   5 00:00:49,360 --> 00:00:54,320 And remember that there is a little bit of a delay  from when we're talking to when you hear us so   6 00:00:54,320 --> 00:00:59,920 make sure you get in your questions before  Leigh finishes up the end of her talk.  7 00:01:01,200 --> 00:01:07,120 All right. Take it away, Leigh. LEIGH BRENECKI: Thanks, Betsy. So,   8 00:01:07,120 --> 00:01:14,000 before we begin, I want to acknowledge that I'm  presenting this in the [Indiscernible]. I also   9 00:01:14,000 --> 00:01:17,520 want to highlight there's a lot of information  and a small amount of time, here, between my time   10 00:01:17,520 --> 00:01:25,680 and on screen text. The URL on the screen has  the link. You need the "www" at the beginning.   11 00:01:30,400 --> 00:01:35,040 So, this is a talk about design and often when  we think about design, we think about websites,   12 00:01:35,040 --> 00:01:43,440 arm chairs, calculators and radios. We think of  color and shape and materials and texture. This is   13 00:01:43,440 --> 00:01:51,440 also a talk about APIs, the way that one piece of  software works. As for color and shape and so on,   14 00:01:51,440 --> 00:01:58,240 they don't apply to our API, which are expressed  in plain text. Design doesn't really have much to   15 00:01:58,240 --> 00:02:05,520 offer us. But they're just the tools of design.  Design is about making things for people to use.  16 00:02:05,520 --> 00:02:12,800 I said that APIs are for one part of the computer.  APIs are for people to interact with software by   17 00:02:12,800 --> 00:02:20,720 creating more software. Dieter Rams active from  the 60s to 80s, who made far more than razors,   18 00:02:23,600 --> 00:02:29,280 his armchairs and calculators were an  inspiration and it's not hard to come   19 00:02:29,280 --> 00:02:40,320 by an analysis for his 10 principles of design.  They are a set of aphorisms for furniture,   20 00:02:41,600 --> 00:02:46,800 design is more than just furniture and stuff. We're going to explore five different ideas   21 00:02:46,800 --> 00:02:51,280 about API and software design and how they  relate to the ten principles of good design.   22 00:02:54,640 --> 00:02:59,200 Something you can't touch and sit on,  but developers interact with every day.  23 00:03:02,160 --> 00:03:11,200 So, I've got problems. Rams' first  principles is design is iterative. Rust,   24 00:03:13,680 --> 00:03:27,120 Swift is more expressive than Java, which was  popular. New language features like pattern   25 00:03:27,120 --> 00:03:35,280 matching for bug matching. But to an even greater  extent and to give you a level of expressiveness   26 00:03:35,280 --> 00:03:42,560 that can approach languages like Python. What's interesting is they're innovative.   27 00:03:44,000 --> 00:03:52,080 When introduced Rust to the world, the  second sentence was just that, nothing new.   28 00:03:53,040 --> 00:03:59,760 Rust has changed a lot. But what makes Rust  interesting are features not invented from   29 00:04:01,600 --> 00:04:07,920 [Indiscernible]. Many other system languages  are better than newer ones and Rust draws from   30 00:04:07,920 --> 00:04:16,720 languages of the 80s and 90s. Programming  language live in two different worlds and   31 00:04:16,720 --> 00:04:22,160 Rust innovates by bringing it to a  more mainstream industry context.  32 00:04:23,920 --> 00:04:35,360 If you explore with Rust our TypeScript is built,  you'll see the real source of the innovation,   33 00:04:36,960 --> 00:04:42,480 people are figuring out how to make it easy  and understand to use, make it accessible   34 00:04:45,920 --> 00:04:49,440 and to communicate them so they can be  best used and best taken advantage of.  35 00:04:50,800 --> 00:04:58,240 Rams said it developed in tandem with innovative  technology. That's what's happening here. It was   36 00:04:58,240 --> 00:05:03,840 developed in all those research languages  and Rust innovation is largely designed,   37 00:05:03,840 --> 00:05:09,840 language and API design, making innovative  technology useful. Rams' talks about it being   38 00:05:10,960 --> 00:05:18,080 [Indiscernible] it can feel like there's a tension  between that and innovation. He compares against   39 00:05:18,080 --> 00:05:27,840 fashionable design. Of course, the JavaScript  ecosystem seems like everyone's go to cycle.   40 00:05:27,840 --> 00:05:35,760 The tools du jour to get changed. If you step back  and look at the web itself, that's a low lasting   41 00:05:35,760 --> 00:05:42,880 design. Here I am, I have a career building  things for it and I'm here talking about them.  42 00:05:43,760 --> 00:05:50,160 So what is it that makes the web long lasting?  It's not a piece of software. Nobody sets down   43 00:05:51,520 --> 00:06:02,800 and opens up Worldwide Web anymore. HTTP,  XML wouldn't have [Indiscernible] they   44 00:06:05,360 --> 00:06:12,960 need to evolve. The web is lucky on this one.  Some time ago, Internet Explorer 6 had won the war   45 00:06:13,600 --> 00:06:22,560 and Firefox came along. It had tabs. It let  web developers do more by pushing the standards   46 00:06:22,560 --> 00:06:31,280 forward. It had the backing of Google, IE wasn't  [Indiscernible] Google's financial support and ad   47 00:06:31,280 --> 00:06:37,360 space on the most visited page on the entire web. We've lean less lucky with chat. [Indiscernible]   48 00:06:37,360 --> 00:06:49,970 has been stagnant for a while. Proprietary have  been adding emoji reactions. If you posted a non   49 00:06:49,970 --> 00:06:54,880 ASCII text, you'd get yelled out because  other people's client didn't support Unicode.   50 00:06:57,840 --> 00:07:04,720 There's talk on the social and political. Free  software is largely dead and [Indiscernible] is   51 00:07:05,760 --> 00:07:13,280 why. It is making deeply disturbing jokes and not  understanding why they're put off by the deeply   52 00:07:13,280 --> 00:07:23,920 disturbing jokes. You can exchange for a shiny  box that the audio and WiFi worked on day one.  53 00:07:25,440 --> 00:07:29,120 On that other side of the fence, we have Slack,  which has been supplanted outside of the business   54 00:07:29,120 --> 00:07:37,360 by Discord. So, we can't talk about software  being long lasting without acknowledging   55 00:07:37,360 --> 00:07:43,040 there's market working against that very thing  and our substantial paychecks come from that.   56 00:07:45,680 --> 00:07:54,960 There is kind of hope, though. My house is  illuminated [Indiscernible] for disposable   57 00:07:54,960 --> 00:08:02,320 hardware that becomes useful when a vendor  releases a new model. I use Lifx because   58 00:08:02,320 --> 00:08:10,640 they can be used by a documented API. And it's  a cottage industry that work with that API.   59 00:08:10,640 --> 00:08:17,680 It's hardly open standards and it's something. So, there's two keys, here, to making long   60 00:08:17,680 --> 00:08:26,320 lasting technology. One is continuing  to evolve and progress and innovate.  61 00:08:26,320 --> 00:08:32,800 Next, I want to talk about learnability, Rams'  words about a good design seem like they were   62 00:08:32,800 --> 00:08:40,240 written with code in mind. Such a common goal,  self documenting coders [Indiscernible] to say   63 00:08:40,240 --> 00:08:45,520 ironically is to tempt fate. Learnability is  a critical part of what makes an API useful.   64 00:08:47,120 --> 00:08:51,120 We know how it works because we're writing it.  We can't [Indiscernible] into our users' heads.   65 00:08:54,720 --> 00:08:59,840 If I'm using a library to use Excel files,  I don't want to deal with the intricacies.  66 00:09:04,320 --> 00:09:08,560 Penetration testing and [Indiscernible]  learnability is one of the key things that makes   67 00:09:08,560 --> 00:09:14,800 a API useful. APIs are hard to navigate, offering  too much or not enough or not being set up in a   68 00:09:14,800 --> 00:09:21,840 way that makes sense. This is in documentation.  What anybody tells you about documentation,   69 00:09:25,920 --> 00:09:33,440 tutorials, how to guides, discussions. The  most important, for your API's [Indiscernible].   70 00:09:34,000 --> 00:09:39,520 The talk is well worth it. The critical parts  are about providing a sense of achievement,   71 00:09:40,560 --> 00:09:43,680 avoiding abstractions and giving  the minimum necessary explanation.  72 00:09:45,040 --> 00:09:54,800 We can give our users less to learn. When I was  doing frontend work, I was doing ES Modules and   73 00:09:54,800 --> 00:10:01,360 doing things using the tools and conventions.  Then I use a Google library. They're in their   74 00:10:01,360 --> 00:10:10,720 own world of tooling. You have to load and give it  a callback and [Indiscernible] API global scope.   75 00:10:11,280 --> 00:10:15,840 I can't use the import key with the Google  APIs, but I can't use my pre existing knowledge.   76 00:10:15,840 --> 00:10:20,640 I have to figure out how to get this weird,  Google tools. Their docs are like that,   77 00:10:20,640 --> 00:10:29,440 too. Details you need to know in order to make the  API, hidden in the foot note. Details you might   78 00:10:29,440 --> 00:10:34,240 just know if you worked at Google, but this is a  public API that's literally made for non Googlers.  79 00:10:36,480 --> 00:10:40,320 When we start talking about things like that, it  often sounds like we're talking about aesthetics.   80 00:10:42,960 --> 00:10:46,720 Code isn't particularly visual, it's just plain  text. There's not a lot of flexibility or control,   81 00:10:48,000 --> 00:10:54,160 but we have a sense of aesthetics. If you  go to the Powerhouse Museum in Sydney,   82 00:10:57,440 --> 00:11:04,160 it has objects designed and you can see the  resemblance, the shared values and priorities.  83 00:11:05,360 --> 00:11:11,760 You can also see a really interesting contrast.  You can see this refined minimalist, everything   84 00:11:11,760 --> 00:11:22,640 is precise, there's whites and grays and silvers.  Very German. Typewriters and calculators. Mostly   85 00:11:22,640 --> 00:11:27,040 designed by [Indiscernible]. I absolutely adored  them. They had lots of curved shapes around edges,   86 00:11:27,840 --> 00:11:38,960 colors and loud and fun and very Italian. The  Germans creating a [Indiscernible] and the user   87 00:11:38,960 --> 00:11:45,520 of a calculator. Across communities, we have  different sets of shared ideas of what good code   88 00:11:45,520 --> 00:11:51,920 looks like. Good design is aesthetic and writing  [Indiscernible] that fit in with the value system.  89 00:11:54,880 --> 00:12:03,040 In Python we talk about this so much, Pythonic,  which includes underscores and goes deeper.  90 00:12:04,160 --> 00:12:08,080 In this talk, fabulous blocks and where to  hide them, Christopher Neugebauer talks about   91 00:12:12,240 --> 00:12:18,240 anonymous code blocks that Ruby has and custom  syntax for particular use cases, like context   92 00:12:18,240 --> 00:12:24,240 managers, async and await. My television is about  to turn itself off so I need to find my television   93 00:12:24,240 --> 00:12:31,440 remote which is a thing I was really hoping  wouldn't happen. But there we go, I fixed it.  94 00:12:31,440 --> 00:12:34,560 [Laughter]. These things are Pythonic,   95 00:12:36,400 --> 00:12:44,000 not like TVs and so is using them. If you have a  resource that opens and closes, make it a context   96 00:12:44,000 --> 00:12:51,600 manager. If you have something that's conceptually  an ordered collection, make it a [Indiscernible]   97 00:12:51,600 --> 00:12:59,600 surroundings with the norms of the ecosystems. If  it can use your API, they don't have to remember   98 00:12:59,600 --> 00:13:07,600 extra details. They might try applying that  and go, sweet, that works. This is hard to do   99 00:13:07,600 --> 00:13:13,600 if you're not immersed in that ecosystem.  It might use expectations in subtle ways,   100 00:13:14,400 --> 00:13:20,720 like a staircase that has fewer stairs than  you're expecting. You need to be a part of it,   101 00:13:20,720 --> 00:13:29,200 interact with it. Every ecosystem, there's  these shared values and norms and understanding   102 00:13:29,200 --> 00:13:34,560 them is key to understanding how the users of  your APIs are going to feel when they use it.  103 00:13:36,160 --> 00:13:40,160 The next thing that I want to talk about is  containing complexity. This is the longest   104 00:13:40,160 --> 00:13:45,840 section of this talk because computers are  incredibly complex. And, at one end, we've   105 00:13:45,840 --> 00:13:54,720 got CPU operations that happen quickly and those  are composed into tasks. The middle is the bulk   106 00:13:54,720 --> 00:14:01,600 of our job as technologists. It can be really hard  to builds something that's unobtrusive and let our   107 00:14:01,600 --> 00:14:06,640 users do whatever they set out to do. I used to do  a lot of work with content management systems and   108 00:14:08,320 --> 00:14:13,200 all those platforms [Indiscernible] some of them  set out to be simple. They followed a process   109 00:14:13,200 --> 00:14:19,840 of building 10% of features that 90% of users  want. They're perfect, so long as you're within   110 00:14:19,840 --> 00:14:23,520 that 90%. If you want to make something  slightly different, you're out of luck.   111 00:14:26,000 --> 00:14:30,720 They've got [Indiscernible] tables and a  checkbox for everything. They feel enterprise y.  112 00:14:34,480 --> 00:14:46,960 There's a Django based CMS called Wagtail. Most  of the other CMSs, they gave you something out   113 00:14:46,960 --> 00:14:54,560 of the box. Wagtail's not like that.  It assumes you know Python and Django   114 00:14:54,560 --> 00:15:02,720 and makes you do coding to set up your page types.  A few different places you can fit things. Or you   115 00:15:02,720 --> 00:15:06,800 can make your own when you needed to. The others  were products with an API. But Wagtail was an API.   116 00:15:11,600 --> 00:15:14,960 You get all the bits you need to assemble  a website with comprehensive instructions.  117 00:15:17,920 --> 00:15:21,680 The other critical thing about Wagtail,  there's a few places you can snap in components   118 00:15:24,560 --> 00:15:28,480 and the interfaces are expected to  provide a minimal and well documents.   119 00:15:34,160 --> 00:15:40,960 So, it is with APIs designed around this.  By using this, also using restraints with   120 00:15:40,960 --> 00:15:44,720 a number of moving parts, you can make an API  to enable your users to build what they want.  121 00:15:47,840 --> 00:15:53,520 This is one approach we can take to contain the  complexity of our systems. One of many ways and   122 00:15:53,520 --> 00:15:58,640 make them fit in your brain. Is it possible to go  too far? I don't have a black and white answers,   123 00:15:58,640 --> 00:16:03,440 but there are definitely abstractions.  Rams talk about trying to manipulate   124 00:16:03,440 --> 00:16:10,587 the users that trick you into accept all or  [Indiscernible] subscription boxes that are pre   125 00:16:10,587 --> 00:16:11,297 ticked. Without that element of intent, but can  lead users down the [Indiscernible] APIs that go   126 00:16:11,297 --> 00:16:27,840 further than simplification. If they try to make  a facade, I'm going to talk about ORMs, Object   127 00:16:27,840 --> 00:16:35,360 Relational Mappers. [Indiscernible] as soon as I  said good design is honest, the first thing that   128 00:16:35,360 --> 00:16:42,880 came to his mind. They are a popular abstraction  layer. He described their role as constructively   129 00:16:42,880 --> 00:16:48,000 lying to you. When you use an ORM, you have your  data accessibility as if it's a graph of objects   130 00:16:49,200 --> 00:16:54,960 and you can jump between objects and walk around  in an ad hoc way. But that's not really the case.   131 00:16:55,760 --> 00:16:59,040 In reality, your data accessibility is sort of  structured like that, as [Indiscernible] within   132 00:16:59,680 --> 00:17:06,160 a relationships with foreign keys linking them. The way you create a relationship database   133 00:17:06,160 --> 00:17:14,560 is wildly different. When you create a  relational database, it has rows and columns   134 00:17:14,560 --> 00:17:23,200 and unless you're using SQLite, you are talking  over the network. ORMs have a lot to do behind had   135 00:17:23,200 --> 00:17:30,480 scenes, they transfer to SQL and get it split  and out and link them together, constructing   136 00:17:30,480 --> 00:17:36,000 this graph they present to you as they go. They're  laying down track ahead of the train, like Gromit,   137 00:17:36,000 --> 00:17:42,000 trying to make it seem like it was there  all along. And they work. Everything's fine.  138 00:17:46,800 --> 00:17:50,720 More complex queries are not harder to write  in ORM than SQL. You have to understand the SQL   139 00:17:50,720 --> 00:18:00,720 you want to generate and what the characteristics  are and the ORM to produce the SQL you want.   140 00:18:00,720 --> 00:18:09,680 The ORM lets you do complex queries. Then, once you sent out your query,   141 00:18:09,680 --> 00:18:11,520 there's the illusion of the data  accessibility being right there.   142 00:18:14,480 --> 00:18:24,960 This is a trap that's so common, so easy to fall  into the, N+1 problem. What you can't see, author   143 00:18:24,960 --> 00:18:29,120 isn't really there yet. When you access  the author, the ORM goes off and finds   144 00:18:29,120 --> 00:18:37,680 an entirely new request, constructs an author  object and pretends it was there all the time.   145 00:18:37,680 --> 00:18:40,160 You're hitting the network every iteration,  that's going to slow things down.  146 00:18:45,760 --> 00:18:51,440 You have this API that's lying to you, to try to  make it simpler. You have to break the illusion.   147 00:18:51,440 --> 00:18:55,840 You have to know about a lie. Know about the  circumstances when it's lying and code around it.   148 00:18:56,720 --> 00:19:04,400 This is one of those headaches for people  building the library. Andrew Godwin has spent   149 00:19:04,400 --> 00:19:15,760 the last few years trying to make Django Async.  This might hit the network at surprising time   150 00:19:15,760 --> 00:19:22,960 through attribute access, doesn't really work  with Async. And this talk, Andrew revealed is   151 00:19:22,960 --> 00:19:31,760 you have to use select related. The N+1 doesn't  work in async mode. We need to have caution.   152 00:19:31,760 --> 00:19:43,440 Are we simplifying or constructing a facade? Django's ORM is very, very good. To implement   153 00:19:43,440 --> 00:19:47,120 things the way that Django has decided to  do requires doing this deal with the devil.   154 00:19:49,360 --> 00:19:56,000 Django is pretty easy to provide custom  sequence. And that's a good lesson to take away,   155 00:19:56,000 --> 00:20:02,080 too. It may be constructing a facade, but at least  it's thorough about it. How's that for a segue?  156 00:20:02,720 --> 00:20:10,160 The most thoroughly designed software is  [Indiscernible] through every path you might   157 00:20:10,160 --> 00:20:17,440 take as a user. [Indiscernible] focus on the  most common use cases or expected outcomes. And   158 00:20:19,600 --> 00:20:25,840 similarly, it's easy to end up designing an  API with a lovely thought through happy path,   159 00:20:25,840 --> 00:20:34,240 but not even think about errors, straight from the  library you're depending on and the library and   160 00:20:34,240 --> 00:20:40,400 framework. The design of the [Indiscernible] is  left the chance and the inner complexity links out   161 00:20:40,400 --> 00:20:47,040 to users. A thorough API will not only handle it  as well, but for each of the errors that happen,   162 00:20:48,160 --> 00:20:55,680 what circumstance it might happen in and how to  handle them. It will have good error messages.   163 00:20:56,240 --> 00:21:01,520 Rust is really good at this. When you get a  compile time error in Rust, there's a lovely,   164 00:21:01,520 --> 00:21:07,840 pretty clear error message. It tells you where it  found the error and it gives you a hint as to what   165 00:21:07,840 --> 00:21:14,400 you might have done wrong. Sometimes there's  enough information to know what you did wrong.  166 00:21:15,760 --> 00:21:23,360 React has an interesting approach, too. When you  use React on your website, every visitor has to   167 00:21:23,360 --> 00:21:28,800 download all of React. So, they don't have big,  long, error messages, they have error codes. This   168 00:21:28,800 --> 00:21:34,160 is one of the cases where it makes sense to use  error codes other than, say, microcontrollers.   169 00:21:35,520 --> 00:21:41,440 In React, it is embedded in the URL and you get  a clickable link and when you visit that link,   170 00:21:41,440 --> 00:21:46,160 that's where you'll get all the detail. You  get a description of what the error means,   171 00:21:46,160 --> 00:21:52,160 some common courses and links to documentation  to learn more and this is really neat approach   172 00:21:52,720 --> 00:22:00,320 that I'd really love to see in both web frontend. Yesterday's education track talked   173 00:22:02,480 --> 00:22:05,520 about Python traces, which touches  on the things I've talked about here.   174 00:22:08,240 --> 00:22:11,120 The other case where it really shows  an API is well thought through, when it   175 00:22:12,000 --> 00:22:17,200 has polished out the caller cases and you can  polish out the corner cases in your own work.   176 00:22:18,160 --> 00:22:23,200 Accessibility features are [Indiscernible]  collectively, a decent amount of us use one   177 00:22:23,200 --> 00:22:30,880 or the other. And more importantly, rarely used  by develops [Indiscernible] and your API can make   178 00:22:30,880 --> 00:22:35,040 it easier for your users to build accessible  software, more of them will actually do that,   179 00:22:35,040 --> 00:22:43,040 which is a win for their users and theirs. Complexity, the best we can do is contain and   180 00:22:43,040 --> 00:22:54,240 decompartmentalize it. And thoroughly designing  our edge cases can contain that and reign it in.  181 00:23:02,000 --> 00:23:05,440 [Away from mic] sip of water. [Laughter].  182 00:23:05,440 --> 00:23:12,560 So, we've talked about three key things,  protocols and protocols and evolution,   183 00:23:12,560 --> 00:23:20,320 learnability, containing complexity and we've  touched on eight of Rams' 10 principles. I want   184 00:23:20,320 --> 00:23:30,000 to talk about the one I left out, good design  is environmentally friendly. It's as important   185 00:23:30,000 --> 00:23:34,800 as ever. But unfortunately, I couldn't find a  way to do it justice so I'm going to recommend   186 00:23:34,800 --> 00:23:41,840 [Indiscernible] from 2019. It's linked in the  resources and a really well put together topic.  187 00:23:49,040 --> 00:23:53,360 I think it's possibly the most important.  Good design is as little design as possible.   188 00:23:53,360 --> 00:23:57,440 Definitely not as little work, but an  end result that's minimal and focused.   189 00:23:58,080 --> 00:24:03,840 It translates really well to API. It  translates to me as really important,   190 00:24:04,560 --> 00:24:13,040 something I think about a lot when I'm designing  APIs. Cognitive overhead. Nothing is infinite.   191 00:24:13,040 --> 00:24:19,840 The machines that run our software have limited  resources. We optimize how much we use. We might   192 00:24:19,840 --> 00:24:28,800 try to write code that runs faster, using less RAM  or uses less battery and we use different tricks.   193 00:24:28,800 --> 00:24:33,120 If we can avoid doing something entirely, we  will. We look for opportunities to use something   194 00:24:33,120 --> 00:24:38,720 for more than one resource. Maybe there's a  component that might not be needed at all, or   195 00:24:38,720 --> 00:24:45,680 maybe there's 20 eventually. We might pre compute  we might know or think we might need later.  196 00:24:48,320 --> 00:24:52,400 Nothing is infinite. And that applies to  developers, too. There's a limited amount   197 00:24:52,400 --> 00:25:00,080 of things we can remember and there's an even more  limited amount of ideas. There's a limited number   198 00:25:00,080 --> 00:25:08,480 of hours in the day and time. It might seem kind  of [Indiscernible] to say the human brain is just   199 00:25:08,480 --> 00:25:15,840 like a computer. When you think about API design,  optimizing your API design is optimizing your code   200 00:25:15,840 --> 00:25:21,440 to run faster. The solutions sound similar in an  abstract sense and you end up using the creative   201 00:25:21,440 --> 00:25:31,360 problem solving. You might try to use similar  concepts. You might design your API to use certain   202 00:25:31,360 --> 00:25:38,080 concepts in certain places and they only have to  certain places. You might use concepts or patents,   203 00:25:40,240 --> 00:25:44,400 like languages and frameworks. I didn't talk about a thing that   204 00:25:44,400 --> 00:25:51,520 I'm saying so we'll skip that. All of the ideas  we've talked about [Indiscernible] protocols,   205 00:25:51,520 --> 00:25:56,560 evolution, long lasting technology create a  shared language, creates that shared aesthetic.   206 00:25:58,320 --> 00:26:05,120 Learnability and understandability go hand  in hand, being unobtrusive and thorough.  207 00:26:10,800 --> 00:26:15,600 How we make our designs as little design as  possible, it feels weird talking about APIs   208 00:26:15,600 --> 00:26:20,640 being for people. We have this divide in how we  think about people. We have users, commoners who   209 00:26:21,200 --> 00:26:28,640 need help and developers, the smarter, superior  class. It feels weird because of contempt culture.   210 00:26:32,480 --> 00:26:36,880 And so we think we don't need design. We think  about the people that use our API and think,   211 00:26:36,880 --> 00:26:40,080 they're developers, they know computers,  they don't need help. They already know this.   212 00:26:40,640 --> 00:26:46,160 Or perhaps we think about code is  something we're building for the computer.   213 00:26:47,280 --> 00:26:51,920 Unless you're fiddling with binaries, there's  layers of abstraction between what you write.   214 00:26:53,840 --> 00:26:59,520 Computers are dumb machines, they don't need  abstractions, the abstractions are for humans.   215 00:26:59,520 --> 00:27:06,080 The code we write is mostly for humans. [Indiscernible] I may be able to take one   216 00:27:06,080 --> 00:27:11,280 or two questions if I step out of my graphic.  I'm not going to take questions even if they are   217 00:27:11,280 --> 00:27:17,440 [Indiscernible] questions. Comments, feedback,  want to say hi, I'll be in Venueless. There's   218 00:27:17,440 --> 00:27:30,240 contact information on the screen, as well. I want  to thank [Indiscernible] and Benno Rice. So, if we   219 00:27:30,240 --> 00:27:39,440 have some questions, I would love to hear them. >> Hi. Okay. So, we have some questions.   220 00:27:41,600 --> 00:27:46,000 Half of them are about your presenting setup.  So, I while they're very good questions,   221 00:27:46,000 --> 00:27:52,160 and I want to know the answers, I'm  going to leave those aside. Everybody is   222 00:27:53,440 --> 00:28:00,240 absorbing all of that and coming up with their  questions and you have a moment to breathe, Leigh.   223 00:28:01,120 --> 00:28:06,480 Sorry. I just want to take a moment for  a round of applause for the stenographer,   224 00:28:07,920 --> 00:28:15,840 well done. Whichever of the stenographers is doing  the live captioning for this. You're a champion.   225 00:28:16,880 --> 00:28:18,880 Great work. [Laughter].  226 00:28:18,880 --> 00:28:23,680 Okay. So, we have some questions  and we have one minute.  227 00:28:23,680 --> 00:28:31,360 LEIGH BRENECKI: Lightning round. >> How do you manage principles and   228 00:28:31,360 --> 00:28:35,280 prioritize something over another? LEIGH BRENECKI:   229 00:28:35,280 --> 00:28:42,960 It depends. It's one of those things where  you sort of got to think about I guess   230 00:28:43,520 --> 00:28:47,280 it depends on the specifics of what trade offs  you're making, who your audience is and stuff   231 00:28:47,280 --> 00:28:52,720 like that. I think it's one of those situations  where the better you have an understanding of   232 00:28:52,720 --> 00:28:57,840 who's going to be user your APIs, you know  the trade offs. I don't think there's a   233 00:28:58,800 --> 00:29:08,640 one size fits all answer to that one. >> All right. And we are at time,   234 00:29:08,640 --> 00:29:13,440 so there is another excellent question there,  that I will copy across to the chat, if that's   235 00:29:13,440 --> 00:29:19,440 all right with you, Leigh. So, we will move this  over to the text chat, the Curlyboi Theatre chat,   236 00:29:19,440 --> 00:29:24,240 in the channels part of the menu, on the left  I have no idea if I'm getting off to the left   237 00:29:24,880 --> 00:29:33,680 of your Venueless. Thank you again, Leigh. And we  now have a little bit of a break. We'll be back   238 00:29:33,680 --> 00:29:39,840 here in 15 minutes, at noon, for our next talk. LEIGH BRENECKI: All right. Thanks, everyone. Bye.