Ep. #4, Affordances for Developers

Dustin Larimer: We have a larger shared competency around these things, so we don't need to make things that painfully obvious and rooted in the analog world anymore.

David Dollar: We want to make sure that everything that we create react as they would expect in the context of the knowledge that they already have. Even if a hamburger menu is terrible, now that I've encountered my 550th one, I kind of know what's expected of me here.

Dustin: Taking decisions away that don't really deserve the cognitive footprint that they impose. You're just one more vendor in their stack to integrate so they can get on to doing what they really care about. If there is an instruction manual, it's probably been poorly designed.

Steve Boak: Your product is code, but your users are humans.

Dustin: Your understanding of the people using it has to be razor sharp. And on the machine side, you have to know your craft.

Steve: Hi, I'm Steve.

David: And I'm David, and you're listening to Don't Make Me Code, the bi-weekly series where we discuss developer experience and some of the unique challenges we face building developer-facing products.

Steve: Don't Make Me Code is brought to you by Heavybit, a nine-month program for developer-facing startups. For more information, visit heavybit.com.

David: If you're interested in being a guest on the show or if you have a specific topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

What Affordances Are

Steve: Welcome to Don't Make Me Code, episode four. We're calling this episode Affordances for Developers. And with us today is Dustin Larimer of Keen IO.

Dustin: Hello.

Steve: And he wrote a really excellent blog post about how they refactored their code based on some documentation. And we're gonna get to that in a second. I think first, though, since we're talking about affordances for developers, we need to start with what are affordances, since not everyone may know or realize what they are. And so I don't know if you want to kick that off, Dustin.

Dustin: Yeah, sure. It's a really cool concept. It comes more from product design and industrial design. We're talking about the visual cues or properties or attributes of something that tell you how it works.

A really great example, we've got buttons and knobs and dials and levers all around us in our environments. And when we glance at it, you can kind of tell, like, this flips up and down. Or I push this in, I push it out. And so with physical products, it's possible to embed a lot of knowledge about how something works simply in how it looks.

And that's the idea of affordance, is that the thing kind of teaches itself to you. You don't have instruction manuals for coffee pots unless it's some kind of crazy newfangled coffee pot, or tea kettles or things like that. If there is an instruction manual, it's probably been poorly designed, because it's considered successful when you can just kind of figure it out. There's not a huge learning curve to make it work.

And this gets really interesting with software because we're moving from design of physical things to the design of pretty much invisible things.

Steve: Yeah, and in the digital space, we have things that we call affordances, things that look like buttons or look like links, and we've moved from these skeuomorphic designs to flat designs, and a lot of that stuff, I would argue, is getting harder. We have to rely on patterns that we know and trust. And I honestly can't tell sometimes if that's getting easier or harder as we get better at this.

Dustin: Yeah, totally. Early on, things like tabs were kind of based on the little tab of a filing cabinet, like filing sheets, because people were familiar with those in the analog world, and so it kind of transferred nicely into the screen world. Things like drag and drop were brand new back when operating systems became consumer friendly, so how do you teach people about drag and drop? So the little mouse cursor was a hand that literally grabbed and let go of things.

So it's kind of a transition, and this skeuomorphic era was largely to introduce mainstream public to how these interfaces work, because they were familiar with how they, they've seen them before. So if something looked like a big ugly dial on the screen, you knew it could turn.

But then I guess Apple is a good lead for that, moving away from that with their big redesign a few years ago, where they justified it by saying we've kind of moved into a time where enough people have learned about interfaces and screens that we have a larger shared competency around these things, so we don't really need to make things that painfully obvious and rooted in the analog world anymore. People have a little more capacity for figuring this stuff out.

And so they could move into a new world where there's not really a lot of basis for how these things work. They just invent new patterns and it succeeds or it fails. So hamburger menu was one of those. Everybody agreed it worked and now they're everywhere, to a detriment, I think.

But things like that. So these new languages, new vocabulary kind of goes mainstream, new words become very popular or fall out of favor.

Steve: Yeah, and they come and go kind of like fashion. I mean, the hamburger menu again being a good example, that I feel like there's been a lot of backlash against that because of the cost of using it that we only realized after playing with the implementation of it for a while.

Dustin: Yeah, it kind of also became kind of a crutch. People didn't have to think so much about their information architecture because they could just hide it all behind a hamburger menu. And that was a mobile invention that made it into desktop and larger screens, and a lot of the usability testing around that and sort of analytics around things like that find that it's not a great idea.

It's not a very effective design feature to just paste in arbitrarily anywhere. You kinda have to keep thinking about things.

David: It is interesting, though, to think about, because even if you do end up with a bad design, if everybody comes on the same design, there is some sort of value to that, right? Even if a hamburger menu is terrible, now that I've encountered my 550th one, I kinda know what's expected of me here.

Dustin: Yeah, you figured that one out. Yeah, totally. That kinda becomes part of our shared vocabulary around these interfaces.

Steve: And in the digital world it's kind of one abstraction away from the physical world, but then dev tools feel like a whole other level beyond that, because now there isn't even a clicky UI necessarily. There's nothing to latch on to visually.

Designing an SDK From Its Docs

And that's part of what made your story so interesting. And maybe we could start talking about that now. What was the problem you were trying to solve, and how you tackled it.

Dustin: Sure. At Keen, I'm on the experience team. I'm a product designer. I've been doing engineering also for a long time, kind of both interchangeably. And when I came to Keen, I took over all of our JavaScript tooling, data visualization, dashboards, and all that stuff.

And so that was the first time I was ever really faced with having to kind of shepherd along a product that's made of code and designed for people. There are a lot of interesting moving pieces to that. But the idea was that we could keep adding new features and tacking new things on and just calling it whatever we wanted to, and sort of letting feature bloat run away and do that, or we could sort of try to consolidate and shrink the footprint so that, I mean, a big challenge is that when you're designing a product, you like to believe that it's this really important crazy thing that people are gonna spend a lot of time on and love.

But then you have to recognize that you're just one more vendor in their stack. You're just one more thing to integrate so they can get on to doing what they really care about.

And you can't afford to require people to learn about you. And I think that's gonna become very competitive of developer-facing companies, is that time to value. How long does it take for me to figure out what the hell you've created and how to use it and how to plug it in.

And so looking at that, we started designing with that in mind first. How quickly can somebody find the code, install it, wire it up with minimal impact, minimal footprint, and start getting immediate feedback that it's working. And so we can't just keep tacking features on and expanding the docs forever. We have to start shrinking at some point.

So with the JavaScript SDK, where I've put all my time, that's a huge factor. It's our most popular SDK. Most of the data that goes in and out of Keen goes through that. Most of it's coming from browser traffic and that sort of thing. So it's gotta be super effective at people being able to learn it, install it, use it.

And a big part of that is having confidence to know that the thing you're using or the way you're using it is the right way. That's another big one where a lot of things fall down, where you've set it up and you're running it, but you're not totally sure if you did it right. The names of methods and the way that things are called, and it's sort of ambiguous, and it leaves you wondering if you're gonna get surprised one of these days, like, you just did it wrong.

Steve: And we've talked before on the show, too, about the importance of boilerplate code and CLIs and examples, all the things that you rely on.

Dustin: Yeah.

Steve: And so for your JavaScript API, this was just all in one place. It was one giant document.

Dustin: Yeah, it was one monolithic library, one big document. It did tracking, recording events, querying, running analyses, and then visualizing it all in one monolithic pile.

And we started breaking those out into their own standalone libraries, and we wanted each one of those to be very purposeful and effective and super easy to glance over and get it. So another thing we've run into with SDKs is the method name to log an event or to save an event into Keen is called a lot of different things across different SDKs. It's add event or record event or push event or whatever. The common thread being events. We talk about events, which is another point of confusion sometimes.

And so we thought, well, let's just shore that up. Let's only say record events, and let's say it everywhere. And that way when you see something that says record events, you know with absolutely no hesitancy whatsoever that this is the thing you're looking for. You found the right method, this is the way to do it. It works in a predictable way.

So it's really consolidating our vocabulary and shrinking the footprint, so that it makes our messaging more effective, because it works across all these different languages, and it helps us focus the message and give people confidence that they've found what they're looking for. So they don't have to spend hours hunting through docs and looking for examples and asking questions on Stack Overflow to get that assurance that, yes, you've done it right.

A Team of Generalists

Steve: I thought one of the interesting things about your approach, too, is the team that you put together. It sounded like there are developers, designers, product managers, people from all disciplines in the company that got together to work on the problem. Can you talk more about how you approached it?

Dustin: Totally. Yeah, so part of that is to do with Keen itself. So we've always been hedged on generalists, mission-driven generalists specifically, where we like to have people come in who in most cases do have some really great specialty and competency in one important area, but have a lot of sort of lateral interests across other areas and have spent time doing marketing or content strategy or design in addition to engineering. We find people who are doing one thing in life and then became platform engineers. And so they bring a lot of really amazing breadth to the perspective when we solve these types of problems.

And so on my team, experience team, we are part of engineering, but we're the part that makes the API fit for human consumption. So we build apps and interfaces and tools, developer tools, point-and-click user tools, all the parts of the website that people interact with when they log in. So we own the developer experience and the just general point-and-click user experience. We want people to find what they're looking for and get value fast.

And so to do that, we have some amazing engineers on the team, some really brilliant engineers. A lot of our stuff specializes in JavaScript, because it's just the environment that we spend most of our time in and build stuff in, but people who have also done product management and design and content strategy and things like that in the past. So we're a very small team with a lot of very broad experience. And I think that's important to sort of keep breaking yourself out of the bubble where you might only see things inside of one paradigm, and I think that's where we get caught.

Steve: Yeah, and you were talking about the need for consistency both in the lexicon and in the function of the tools. And so it sounds like you ended up figuring out a logic to break what was one big monolith into pieces. And there was some pretty good logic, it sounded like, that came out of that. And so can you talk about the results?

Dustin: So the way we went about it first is we used that idea of breaking it out and having standalone SDKs for these three functions, for tracking or querying and visualization. We looked at it as a chance to kind of break away from some of the patterns of earlier stuff and try to build the ideal, and then try to work our way back and make it somewhat backward compatible. But we took the chance to really get our thinking clear first, and to do that,

that's where the thesis in that blog post came from, is that if we were building physical products, we wouldn't start building a tea kettle by bending aluminum and hammering something out in the shop. We would probably just get a big piece of paper and start sketching and start thinking through all the different what-ifs and maybes, and to really kind of push the form of that until we could remove all the things that weren't necessary, and we could focus on what mattered, and we could get our thinking really, really clear.

And so we did that with these SDKs also, where we realized that software is more or less invisible in that sense, but its form is its documentation.

So we started out just sketching docs, just doing install guides, writing pseudocode for how to install and run this thing, looking at all of the different method names and functionalities people wanted, and making sure it was consistent.

You don't want the situation where if you use this method, it gives you a callback with these arguments, and if you use another one, it gives you a callback with different arguments, or maybe no callback, with no explanation whatsoever. So we want that consistency to become part of the sort of vocabulary for how the thing functions.

And by doing that, we came to a very, very clear spec of not only how the thing works, but how I use it, how I install it and run it, and under what examples and situations. So we wrote a lot of example code, and all this was before we wrote a single line of code. The beauty in that is once you have that perfect clear picture of what you're building, with good rationale for why it needs to exist, putting the code together actually took no time at all.

Steve: Yeah, and it sounds like a lot of the code, it's already there. You figured out a really nice way to sensibly reorganize the documents, and then you reorganize the code to fit that.

Dustin: Yep. So we started by designing our thinking and designing the conceptual form of it, and then filled in the rest. And really wrote a lot of tests before we even wrote the code itself. So that really changed the way that I've thought about making software.

Where now, if I ever catch myself getting stuck on something new, I realize it's because I'm looking at a very granular level and kind of painting myself into a corner, so I'll stop, drop it, back up, and start writing out pseudocode and docs for it, and then it makes sense. So yeah, that's become our process now. At least on my team. I couldn't speak to other engineering teams and what they do, because they're kind of running their own experiments and learning from their own journey. But it's working for us.

Sketching in Docs and Getting Feedback

David: So I'm kind of curious, as you start designing from documentation rather than, yeah, kinda top down, from the experience. At what point do you actually start sharing some of that documentation with customers, users? Do you even do that before you write code at all? Can you iterate entirely at that point?

Dustin: Oh yeah. Yeah, totally. So the new tracking SDK that we wrote in JavaScript, that was just one gigantic markdown file. That eventually became the README, which is a one-page doc for the README that covers everything.

And I just started sending that around to people who are engineers who do a lot of support, people who have worked with customers hands-on. Some of our bigger customers have people that actually just help them with their integrations and stuff.

So I started bouncing this off of my teammates, people that support and use our SDKs, and some customers too. I've got a short list of customers who have been super active contributors on projects in the past, who are really open to seeing new things and give a lot of great feedback.

So I would just shoot it at them and say, I want to make this thing, this is kind of a new idea. It brings in some new stuff, cuts some old stuff, what do you think? And I'd get questions back like, well, I get it, but how do I install it, or what is this? Like, oh, okay, that's not clear.

So that feedback, questions that you get in return and sort of first impressions, are priceless. That's where you get, did this idea land? Did they glance over this page and get it? Or did they have to come back and dig into it? That kind of becomes the success criteria for the sketch.

Steve: Yeah, the most vocal customers being the best ones is something that David and I were talking about and found really interesting, because we're both also very early stage companies compared to Keen. And so, at least Opsee, we're in a private beta right now, and so we're relying heavily on very vocal people to tell us what they want. And specifically what they don't like, and particularly a major refactor of something that a lot of people are already using. The stakes are high. So that sounds like a really good approach.

Dustin: Yeah, yeah, totally.

Steve: The consistency thing is really interesting. Both, our customers being developers, they rely on that kind of consistency. I thought it was really interesting how you opened by saying your product is code, but your users are humans, and so you have to make the two work. And so using the same commands to perform the same functions and

so our users have that expectation, but then for us as the creators of that API and those tools, what are the tools that help us? And so we were talking about Swagger, and so have you started using stuff like that at Keen?

Dustin: Yeah, we've seen some customers asking for these types of things, like Swagger files and that sort of thing. That's where a lot of new ideas come from, is really just customers exploring and taking advantage of all the new stuff that's out there. I mean, they can individually move a little faster than we can, because we have to sort of control a pace that we can actually deliver stuff, and then we want to go out and play with all the cool new tools all the time, but realistically there's other concerns first.

And so we get to see a lot of that glimmer of what might be coming from customer questions. Like, everybody keen to support in some form or another. We're always getting feedback. We're seeing where our stuff breaks down.

I've seen people trying to load up our JavaScript SDKs in new and crazy environments, like Apple TV supports a form of JavaScript. That was really exciting to see.

The SDK crashed and burned and failed miserably in that environment, so we're gonna do something new there, but we would never know about it unless people were actually active and pushed questions back and hit issues and vocalized them and shared them with us. Customers build all kinds of crazy new stuff on top of us. So we see all sorts of intermediary middleware apps that run jobs on Keen and crunch data in new ways and provide new value for themselves, and then sometimes they share that code with us, and we get a better sense of kind of where they're going, where their imaginations are pointing. And that comes back into how we work and what we build and what we prioritize, absolutely.

But yeah, on the API front, as far as that boundary between humans and machines, I mean, your understanding of the people using it has to be razor sharp. You've gotta be completely and consistently in contact and have real empathy and understanding of how people work and what they're up against and why they're using you. Then on the machine side, you have to know your craft.

You have to write clean code. You have to understand how people write software projects these days, what tools they use, what build steps and test steps they use, what script loaders and environmental factors they're dealing with.

It has to be solid, and to reconcile those two, your thinking has to be crystal clear on both fronts. Yeah. So I think a lot of these API blueprints and things like that are a really good start, because it's another format to kind of see it all in a glance and get it. And it takes a lot of the learning out of that. So yeah, I think there's a lot of really cool stuff on the way.

The Burden of Expectation

Steve: Yeah, and you touched on what I'd call the burden of expectation, and that your Keen users have expectations about what the product will do based on what they know it does now. And then David was talking earlier about the expectation that a user of their product has as someone who's also using AWS. The different levels of expectation that we have to attach to when we're building APIs and tools, and David, maybe you could start there too, the expectations that you built your product on based on AWS.

David: Yeah, I guess, I mean, just one thing that we try and really keep in mind is that most of our users are also AWS users, and they have all of this knowledge and familiarity that they've built up, and we want to make sure that everything that we create for them is going to be familiar to them, is not going to break in unexpected ways, is sort of going to react as they would expect when they interact with it in the context of the knowledge that they already have.

I mean, it's just really important for us for the technology not to be scary, I guess. And as long as it reacts predictably, it tends to make people feel okay. Definitely. But yeah, as soon as you're not sure what's gonna happen when you push this button, now you'll just never push that button.

Dustin: Yeah, predictable's the word. That's the word. People are natural problem solvers and pattern hackers, and if they expect something to happen based on the sort of blueprint you've given them and it works, then you get trust. You can build trust that way.

I saw a really cool little quote earlier, maybe an hour ago, that developer trust is earned in drops and lost in buckets. And that is totally spot on, right?

Engineers hate being surprised, because it's usually in bad ways. So that predictability is huge.

Steve: And they're investing a lot in you, potentially. If they're learning your API, they're learning how to write code on your platform. We have expectations of our users to invest time and energy in us, and if we violate that trust, they're gone.

Dustin: Right. Yeah. And especially in the place now, with all the tools that are out there, a lot of people bump up against the question of, maybe I should build this myself. Maybe I should run this service myself and do that. And that's a real question, that a lot of people decide to go the other way and try to do it themselves.

And they'll find lots of fun pitfalls and surprises of scaling event data warehouse and trying to not let that compete with your core business model.

But yeah, the question up front is, and those are awesome developers, to say, I think I could probably do this myself. That's badass. It's cool that we live in a time where that's possible and feasible. So yeah, building and maintaining and protecting that trust is huge.

Steve: Yeah, I think that's a really funny and unique consideration of DevTools companies too, is that we're competing with our own customers, that we have to convince them that they are gonna want to use our thing instead of building it themselves.

David: It's interesting, we were talking earlier about there being sort of two audiences for these things, humans and machines, and that affects the design of these things in so many different ways. Also, talking about engineer trusts, if you're building a visual interface, there is certainly some advantage to having it remain the same and familiar in a lot of ways, even if you do make incremental improvements and evolve it over time.

But if you're building an API, that thing cannot change.

And if it changes, it has to do so in very predictable, and even the change in versioning mechanism itself needs to be designed, because once this thing changes, it's not that this button moved and now I have to find it. It's that everything built on top of it falls down and breaks.

Dustin: Right.

Versioning an API

Steve: Yeah, there are so many good examples and counterexamples of that. Twitter basically cutting off access or rate limiting users and kind of alienating the dev community. Maybe an example, a company that's done it really well, I think, is Stripe. They have, I think, a really well versioned API. I created my first Stripe integration five years ago, and that specific integration still lives exactly as it was.

Dustin: Yeah. Yeah, they do a great job. I think they version on the user, right? So you have to opt into updates. Ah, right. That's a really great model.

I mean, that makes documentation tricky, 'cause it has to stay versioned with every single version going on. But it's not impossible, and they figured it out. I think they have a really awesome product for it.

Steve: And Keen now is a pretty mature company. Have there been any cases already where you've been kind of bitten in the ass by expectation, and that your API or something is set up a certain way and you're maybe held back a little by that?

Dustin: Yeah, we've hit some issues where there's things we want to change or add and you just can't. You can't change response structures. We can add new features, but we can't really rev on the old.

I mean, we're working on a pretty huge update now that will be an opt-in kind of update, and will be a really much needed improvement on a lot of fronts. We're really understanding the new use cases that are emerging in a very intimate and visceral way, 'cause we've been supporting this thing for all these years now. So we're working on that, but that type of versioning going forward is gonna be tricky, because we want to move faster, we want to build more stuff, and there's just a real question about how you balance that with everything else.

So yeah, I don't know. There's a lot of different techniques for versioning. Some people say you shouldn't at all. And that seems kind of violent. But yeah, it's a real question for us too, how we want to do that going forward so that we can innovate and release stuff faster.

Steve: Yeah, and how companies approach that seems really important too. Maybe this was my own fault, but I had a little Instagram integration on my own website, just a personal project, and it broke a couple times because their API changed. I wasn't aware of it, and I just went and saw that the pictures weren't loading. Maybe I was opting out of some kind of communication that I shouldn't have, but I don't remember being notified. And so clearly you're alienating customers if you don't handle these kinds of decisions well.

Dustin: It's frustrating. People will just start to route around you if they can't rely on you.

Steve: The human versus machine needs thing too is interesting. I mean, we've talked a lot about the human needs for sort of consistency and clear expectation and lexicons being human readable, but there are the machine expectations too.

A lot of what we do at Opsee is health checking of HTTP services. And so there's a clear structure to those responses that we need to adhere to. And that constraint can be good at times, because it means we can make a lot of assumptions and guesses about how things are gonna talk to each other. And so we're kind of trying to build a business on this, actually, the expectation that services are going to talk a certain way, and how we can evaluate them as being healthy based on that.

And that feels like leverage, that if we make the right assumptions as developers of APIs, as consumers of APIs, that can take us to good places.

Dustin: Have you encountered any kind of similar challenges or ideas around this, around versioning, and around, how has that influenced your team?

Steve: We're still a pretty new company, and so we're still working on V1 of our API. But we have moved to GraphQL, because we have about 20 microservices at this point, and they were communicating in a totally bespoke fashion. And so already we're having consistency issues, and so we are looking for a way to solve that. We've been using Swagger, and we've started using GraphQL, and so this is a way for us, as you said before, to kind of see the big picture and to know that what we're doing is gonna work well for all users.

And David, I don't know if you've seen something similar at Convox.

David: Yeah, so we actually have a slightly different problem there. I mean, Convox is installed software, so we basically are heavily versioned by nature. It's not a service to speak.

So we have customers on a hundred different versions of our API right now, and that sort of just works, because they stay with their installed version. And then they just kind of upgrade on their own schedule. So yeah, it's a little bit different than kind of a central service where you're upgrading the central service behind the scenes all the time.

Steve: Are you talking about mostly the open source stuff there? Because you've got the SaaS too, right?

David: Mm-hmm. So our SaaS layer really just forwards everything on to the installed product. It's an authentication gateway and then forwards the traffic, more or less. So all the versioning is handled by which particular version they have installed of the software. So it's more of a classical problem of releasing a physical product once a year, and goes out with its old features, and then I kinda just forget about it, almost.

Dustin: Yeah, you can't ship updates to hardware.

Steve: The two companies I worked at before this one both had agents that you had to install on your systems to use the product. And those agents had lots of issues. The long tail of out-of-date agents, people just didn't update them. They would break, or somebody would stop using the product and their agent was still there.

And so we had dead customers. One of these products in particular, it was making requests once a second, and there were so many zombie agents communicating once a second that it was an actual bandwidth problem. They had to build the service to block these connections from dead users.

So now we have an interesting approach where, well, one, we don't have an agent. We basically spin up a new instance inside somebody's AWS environment, and that does all the work for us. But we also have a containerized layer on top of that, where we can send a message over to this thing, and it will automatically trigger an update and restart. And so it's at least partially mitigating that problem, but we still have to rely on getting into the customer's environment.

Dustin: Yeah, totally. When I was saying you can't ship updates to hardware, I was thinking about toasters.

Steve: Well, it is a major problem, though. Even with intelligent servers and machines, you still have to rely on the customer kind of opting into that stuff for the most part.

Dustin: Yeah, totally.

Documentation as the Product

David: Well, another thing that was interesting, talking a little bit about the human versus machine thing, is you mentioned that with APIs, the documentation is almost the form of the thing itself, rather than the actual thing. It's interesting to think about. Yeah, that it's not really true of a lot of things. If I buy some product, when I pull the manual out, that's not the first thing I go for and the most interesting thing.

And so yeah, it just really makes me think, should this documentation be way more interactive? Should you actually be able to play with the API itself? Yeah, and actually put your hands on the real thing and not just the documentation?

Dustin: Yeah, that's another thing Stripe got right, is being able to embed your actual keys in the examples, so that you could just copy paste right out of the docs and use it and it would work. But yeah, I think that's a really great point about being able to kind of go the next step, not just glance at it and see how it works, but actually start interacting with it, especially around docs. I think not just for people trying to understand how something works, but understand the language itself, to learn more about JavaScript with these types of real-time examples, or learn more about PHP or Python or what have you, with getting real feedback.

Because when you get real feedback, you start to develop these sort of systemic relationships between things. If I change this value, I see the output in real time, and I can start to toggle and tweak things and understand more of the boundaries of this thing, the boundaries of the system, what it's capable of, and you can download a lot of information very quickly with that kind of interaction. So yeah, I would love to see something like that, with more sort of contextual information embedded around the docs.

If I'm looking at an example of how something is working and I hover over a callback function, and it pops up and says, this is a callback function, it takes this and this. And it kind of, in some ways, could teach you a little bit about that language if you're not super sharp on it, but at a very basic level it shows you how the system works. I think a lot of people would benefit from that, especially now that there's so many more developers in the world who are learning and growing into their careers. That could be super valuable.

Steve: I was talking with the founder of a company called APIMatic. His name's Adeel Ali, and he had a really interesting tool in this area, that from a Swagger, you can generate an API, and then his tool will generate SDKs from that, language-specific SDKs.

And so now, not only, we're in a world that basically from documentation you can get an API, you can get SDKs. I think they also have an integration with like Apiary so that you can get documentation built on top of that. So we're kind of inching closer.

It would be really awesome to get boilerplate code and examples out of that, so that you can kind of get closer to this world where you can just copy and paste the bits you need in your language of choice. That just seemed like a really cool step forward.

Dustin: Yeah, that's super cool. I've seen things like this popping up also around SDK generation, and yeah, it seems like a logical step for somebody to build a service that creates a lot of value, and there to be an intermediary. I mean, Segment did that to some extent with sort of consolidating all of the trackers by having a single analytics.js library you install, and then can load up and send data to whoever you want.

So it's been cool to see that sort of thesis play out and be pretty effective too. So yeah, I mean, there's a lot of ways to get data into a system anyway. So it's exciting to see stuff like this.

Steve: Yeah, and especially with more languages, more frameworks, more stuff out there, we need tools like this to make it easier for everyone.

Dustin: And make my job a lot easier.

Steve: Yeah. There is also, I think, an art to aligning all of this stuff with use cases and what your customers are actually using it for. And I remember going all the way back to the early Google Maps API, and just how easy they made it to copy and paste boilerplate code and just drop a pin on a map, or all the stuff you'd really want to use that tool for, and that there's still the magic in it, I think, is really aligning that stuff with what people want to do.

Great Affordances in DevTools

Let's talk about some great examples of affordances in the DevTools world, and tools that make use of great affordances. The first one that comes to mind is Light Table, and the idea that code can be sort of compiled and visualized instantly, and that you can be making changes to variables or properties and see that stuff play out in real time.

The first example of something like that I remember seeing was Bret Victor's presentation about it, and the simulations that he had created where you could modify mechanical properties of materials and just see all that stuff play out as you were tweaking the values. And I thought that was amazing.

Dustin: Yeah. Yeah. He's done some really awesome stuff. Really sort of opens up a lot of wild new ideas for everybody else to go build. He's got that visionary bent and does a lot of amazing research around the stuff.

But yeah, like Light Table, yet another talk, something like New Media for Thinking the Unthinkable. And the idea it starts with is beautiful. Imagine back before the written word, before we could actually put thoughts down on any kind of surface. There were some thoughts that were just too big to think, because you couldn't hold it all in your mind at one time. It was just so great that you couldn't capture it all to feel it and to express it and share it.

Once we could write, you could actually sketch out an idea that's bigger than what you can think about at any one time, and it was revolutionary.

And then sort of how he follows how media has changed over the years and millennia to where we are today, where the things that we're trying to think and share are of very complex systemic nature. They're huge again, they're dealing with systems at a very high scale. And so what would media look like to convey that complexity in a way that's easy to digest and download?

And he had this app. It was sort of like a data visualization app, kind of felt like Illustrator. You could load up a bunch of data and create systemic relationships between the values of the data with different knobs and dials to understand things like radio frequencies or current in a system or back pressure in a server system, things like that.

So that was really interesting, to look at new interfaces for letting people play with systems and understand them at a very intimate kind of level. So it's just a matter of time to see that stuff work its way into programming also, to the point where it's becoming more possible for non-developers to create pretty sophisticated programs or automations or connections between systems with point-and-click interfaces.

David: Yeah, we mentioned Stripe earlier, and I think that they're another, I mean, just great example of this kind of affordances in design. It takes something that could be really scary, like, oh, I need to test whether or not this API that charges a credit card actually works. Do I have to put in a real credit card, or what's going on here? And they make it really easy through good test data and sort of all this supporting tools to really confidently build with the stuff without the fear that kinda comes with, financial things are scary.

Dustin: Totally, yeah. And even to be able to play in a sandbox without getting billed. It's huge. Makes the barrier to entry and exploring and trialing so much easier.

That's huge. They've just done a lot of good stuff. Seems like they figured a lot of things out.

Steve: That is really cool. The use case specific example there, that, yeah, Stripe gave you both the developer sandbox, where anything you did would be offline, and then also, I think, even if you are in production, they had certain credit card numbers that you could enter to test out certain operations, and they went through a lot of thought to make those tools accessible.

And that was really cool because I remember when I was integrating Stripe for the first time, I had to use another payments processor also, because Stripe didn't support a bunch of other countries at that point. And this other payment procedure didn't have any of those tools, and so it was a nightmare. I was testing out with real payments and then refunding myself, because I couldn't do that.

You guys were talking earlier too about Go specific tooling, and how it's a relatively new language, but a lot of cool tooling has popped up around it, and this is not my area of expertise.

David: Yeah, I mean, just one of the great things about the kind of the tooling that's pop-up on that language is that, one of the classic debates with any programming language, people argue tabs versus spaces, formatting, how do we do things. Go basically just got together and decided to solve it. There's one right way to do it. You can run a command on a file and it'll just reformat it the right way.

And so as a result, most of the editors, whether it's Vim or TextMate or whatever, for Go, when you save, it just reformats the file in the right way.

And just having that one little decision taken away from you is a huge time saver.

Dustin: Yeah, totally. Unless you focus on the thing that matters, not having to sort of nitpick and lint and get lost in the minutiae there. But yeah, Go is interesting. I mean, I haven't done much with it at all, but just fascinated by that model of, like you said, taking decisions away that don't really deserve the cognitive footprint that they impose.

Taking a lot of that ambiguity away so that, like you said, there's a right way to do it. It's pretty clear. The language is very explicit. It's painfully explicit and verbose, just kind of, I don't know, de-risks big projects. We have new people jumping on code that somebody else wrote, and you can just get it.

You can understand it. That makes me wonder too, if the language is that specific and structured, and a lot of the work happening with natural language processing now, I wonder if these ever merge, where you can just talk into a microphone like I am right now and just say, build this thing. Do this, run this method, call this server, take the response, send it here, infer semantic meaning out of that and just go scaffold it out, because there's one way to do that stuff. It could be really interesting to see where that goes.

Maybe voice is the next IDE. That would be wild.

Steve: Yeah, that's so much of what we do.

David: That would be really interesting. It's almost like you have to be able to reason about the entire program and get it right up front, or at least have a lot of the work done for you.

Voice, Chat and Text as Interfaces

Dustin: One of my teammates built a Slack bot that uses NLP, so you can just talk to it in our Slack room and tell it to run queries against Keen, and it'll give you charts back. So it'll run off, figure out what query you're asking for, run the query, spin up a PhantomJS instance, build a chart, take a picture, and push that back in the Slack channel. So you can just, we have a Slackbot data scientist now, where it's like, hey, how many pages do we get in the last twelve hours, divided by or grouped by country?

And that chart comes back, not a table of data or response, but just you get a picture. That's fun. That stuff's really cool to make. We made a robot that uses Keen for you.

So yeah, I'm excited to see what that does, voice and text, for these types of reasoning about these big systems and making them work for you.

Steve: Yeah, it does seem like the chatroom is this sort of intermediary step to get there, that we already live in this world now. We're all communicating in the room, and sounds like you've already built something that'll cater to that. We've been talking about this too, even punting on a mobile app or something so that we can better integrate with chat. And there's obviously a lot of talk now about text being the new UI. And yeah, that's really interesting.

Dustin: Yeah. Text, voice, and email, I think, are always gonna be the main channels for content. So that was a big one too for us, talking about dashboards. We're just working on a big dashboard feature now that's gonna be really awesome, and people have been asking for it for a long time. Being able to build custom dashboards and track things happening in your Keen projects.

But another really useful format for dashboards is to just get them emailed to you. So the 7 a.m. sitting on the toilet waking up use case, your dashboards are there.

You see your engagement from yesterday, all your new signups, all your stuff, revenue. Just sitting there waking up, thumb through your dashboard, close it, archive it, done. You'll get another one tomorrow. That would be fun to build.

And we've seen some people build that for themselves, but that could be a really fun service for anybody to build on top of Keen. I think we would be their first customer. So yeah, it's really cool to see freeform text as a format on both consumption and on input.

Steve: That was an interesting one about the medium of delivery, the dashboard versus the notification, let's call it. I mean, we're that's a big part of what we're dealing with now, is who the user is and the mode of delivery, that for us, it's sort of about infrastructure operations, and for someone whose full-time job it is to make sure that things are working well, they'll happily keep a dashboard up on a big screen somewhere, just because they know what to look for, it's their job.

But a lot of our users, this is not their main job. They want to write code. And so we spent a lot of time trying to make that easier for them by giving them rich notifications with charts, with relevant context, everything that they need to know what they need to know, and then get back to doing what they actually want to be doing.

Yeah. And you kind of said it perfectly at the top of the show, for all of us as makers of DevTools, our users, they use the tool, but that's not their end. They have their own interests, they're doing their thing.

We are merely a means to it, and so we need to get out of the way.

Dustin: Totally. Yeah. You gotta give them power and get out of the way and let them use it.

Wrapping Up

Steve: It's been really fun talking about affordances and how they exist in the world of developer tools, and it's been really fun having you, Dustin, on the show. If anyone wants to reach out to you, they should. So how can they do that?

Dustin: Yeah, awesome. So they can find me on Twitter, just Larimer, my last name, L-A-R-I-M-E-R. It's just at Larimer.

Medium has the same username, and then pretty much anything to do with Keen, you can jump in our Slack, our public Slack room, and come ask questions and see what we're building and hang out with us. Slack, pretty much any day of the week. There's usually a dozen Keen people in there hanging out at any given time.

But yeah, thanks for inviting me to come chat. It's been a lot of fun, and really awesome topic. I'm interested to see where this sort of body of knowledge and conversation goes, because it's becoming more and more essential for companies to think about, and there's people out there putting a lot of awesome work and thought into it.

Steve: Cool. Yeah, it's been great having you. And like you said, this developer experience is now table stakes for building a DevTools company. And so yeah, it's fun to talk about.

Dustin: Yeah, absolutely.

David: Well, yeah. Thanks for joining us.

Steve: That's about all we have time for today. If you're interested in being a guest on the show, or if you have a DX topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

David: To learn more about Heavybit, visit heavybit.com. And while you're there, check out the library. It's packed with amazing talks from founders of developer tools companies and other industry leaders.