Is the old way of doing things the right way? In their talk at DevXcon 2017, Anil Dash and Jenn Schiffer of Fog Creek proposed collaborative teaching of API and developer-targeted products.
Anil: Thank you. It’s great to be here. I don’t get to San Fransisco as often as I used to, so, appreciate the chance. We are excited to be here at DevXCon and we’ve both come out of New York for this. I’m, Anil Dash, as mentioned.
Jenn: I’m Jenn Schiffer.
Anil: I need to skip through a lot of these real quickly because I…I hope a lot of…has anybody ever heard of Fog Creek here?
Audience member: Yes.
Anil: Some hands? Good. Yeah. Because I feel like, you know, a kid in a candy store getting to join the company. We both, in the last six months, got to join at Fog Creek, and…
Jenn: And now we’re up here.
Anil: And now we’re up here.
Jenn: They let us on stage.
Anil: That’s how the company worked. You just come in and they throw you out into the wild. Our co-founder, Joel Spolsky, I think he was supposed to be here today. I think he got held up. Oh, there he is.
Jenn: Hi, Joel.
Anil: Let’s give Joel a round of applause, too. Who doesn’t love that guy. Great. It’s good to see you. And so, now I’m gonna put all the great things Joel and his team did before either of us joined, so you know about what Fog Creek does. Like over the years, Joel did Joel on Software, which I think a lot of us read is as a really seminal way of understanding what making software could be about. Building Fog Bugs was one of the first bug tracking tools, co-creating Stack Overflow, which is indispensable for all of us in doing our jobs. Trello, now part of Atlassian, as a great way to manage projects.
And then into this sort of legacy we launched Glitch. Now we’ve got a bunch of new stuff to show you today which we haven’t shown anybody ever. We sort of scrambled to get this in front of all of you, and Jenn’s going to talk a little bit more about that.
Anil: Exclusive. It’s like our mixtape that we’re dropping for you. And before that though, I want to talk a little bit about software, because, for me, joining Fog Creek and being a fan for all these years has been about a company that really takes making software seriously. And I think usually in a talk there’s a point where somebody talks about it’s eating the world. I’m not gonna do the eating the world thing. Instead, I will actually just tell you software matters. And this sounds obvious but I think a lot of us that maybe grew up coding, or that have created apps and shipped apps, we take for granted we have the ability to create things that people will use.
But over the time that a lot of us were learning these skills, what software is in the world, what apps are in the world, has become far more important. And I think about this in terms of bugs. When I was learning a code, bugs were data corruption, bad memory management, those types of things. And now I think about what I read in the news and bugs are things like software that’s used for sentencing in the judicial system, it’s perpetuating racial biases that we see in society. And I think that is not a category of bug that I was taught about when I was learning the code.
And worse, we see things even a little more less serious but things like privacy bugs around photo sharing, and we’ve seen like three generations from Flickr to Instagram to Snapchat, where we keep seeing people share their photos and say, “Oh, I didn’t know that was gonna be public. I didn’t know this was gonna share my location when I shared that photo.” And we repeat these bugs, these really big social bugs, over and over and over.
And start to think about why do we keep seeing the same bugs in design, and these fundamental issues around software that are causing these huge social tensions. And what we realized is linked to a couple different related issues. The first is what all of us the conversation I think many of us have been having for years around diversity and inclusion. Who’s on the team? Who gets to learn? Who gets to participate in making software? That’s a really big part of this. But then there’s a more fundamental thing which is simply, how do we collaborate? How do we learn from each other about how to not keep making the same mistakes over and over?
Sometimes we have that institutional knowledge within our companies, we learn from the people that came before us and they say, “Well, you shouldn’t do this because when we did that we made all our users angry. Don’t do that anymore.” And that’s good, you hope to have that. But a lot of the responsibility for how we’re gonna stop repeating the worst bugs and software, comes down to the people in this room. Right, because the unique superpower that all of you have is the ability to talk to the developers. Right? That’s really, really powerful if we’re saying, you know, whatever, “Software is eating the world, and software is more important than ever.” Then the people who influence the creators of software have enormous amount of power.
It’s a really disproportionate responsibility. And that should be exciting, right. That should be something that we can be inspired by and motivated by. Especially if, as I think we all agree, software does matter a lot more than it used to. So with that in mind, we started thinking at a really fundamental level about what would it look like if we put that into practice, and started thinking about what it looks like when we learn from each other. Because the big takeaway we have is we’re not learning enough lessons, not just at the technical level.
Certainly, we need to learn how to use new APIs, learn how to use new frameworks, new libraries. But also learn how to not to repeat the worst patterns in software we’re making. And the conclusion we sort of came to that informs us is we don’t learn alone. We need to learn from each other. A lot of us…I know I used to describe myself as self-taught. There’s only whether you’re learning from other people synchronously or asynchronously, right?
You know all of us that have ever Googled something and ended up on Stack Overflow you know you’re learning from somebody else. It’s just the question whether they’re sitting there with you or not. And thinking about this, I love the story that Jenn had told me about a friendship that she had just made recently.
Jenn: Thank you. I just wanna first say that I’ve never written a bug, okay? Let’s make it out there. Just kidding. Yeah. So, Anil’s right. We don’t learn alone. I think there are two barriers to being an engineer and that’s like, ne, how am I gonna learn? And then what tools am I gonna use? And that’s something that on the Glitch team we’ve been working on, and that’s Fog Creek has been working on for years. And I, myself, as an engineer, know that things like saying that I’m self-taught is like a fake idea. You might be self-guided, but you’re using materials from other engineers and other people in order to learn how to program. And so I wanna tell a story about friendship. Who here loves friendship? You all love friendship, yeah.
So this is a story about a new friend of mine, her name is Madeline. This is a true story, too, and her new friend Jennifer. That’s me, I’m Jennifer. And if you only have five syllables to say, Madelinnifer you can use. #Madelinnifer. You like hashtags, right?
Anil: You can tweet if you want. That’s fine.
Jenn: So, Madeline and I met in early January in the most 2017 of ways. I took her mayorship of a local cocktail place on Swarm and she called me out for it. And it turns out we’re both engineers, living in the New York area. So of course we didn’t meet until three months later, because we’re very busy. And we got drinks and we were talking about the work that we’re doing, she’s starting a new start-up on her own for the first time. I had just joined Fog Creek, and was working on Glitch.
And we were coming up with ideas for things for me to talk about when I came out to San Fransisco to speak at various events. And it turned into like two or three hours and a lot of very expensive small plates, to come out with different ideas of things for me to build. And it was a really, really awesome conversation, which is why it went on for so long. And then it led on later the next day into our Instagram DMs with just different ideas of things for me to build. And it was really cool. It went on for a really long time, there’s all sorts of great ideas. We’re focusing on the Twilio API.
And I’m the kind of engineer that I like to fancy myself an ethical troll. So I like to mix silly things that you think you don’t need, but in my weird perception of how the world works, you do need it, and you will love it. So really anything goes with these ideas. I never really say, “No, that would be too hard.” The brainstorming process early on when working on a product is what is really exciting to me. And then there’s all different ideas that can come through that expand onto different APIs and different hardware that’s available. No matter how ridiculous, it’s always like a really fun time having these organic conversations.
Of course not all the ideas are great. You don’t have to build everything somebody wants you to. But it just keeps going on and on and on, and it’s what’s super exciting for me. This one is a really cool idea that I like. Are there any Twilio Dev Evangelists in here? No? Okay.
Anil: Really? There’s no Twilio Dev Evangelist? Don’t they lurk amongst us?
Jenn: No Twilio? They’re watching the watch bus. They’re very busy.
Anil: I guess they’re always…I feel like they’re always around.
Jenn: And then like, you know, when you’re having these conversations, the idea that you have any…like at this point I haven’t started building anything yet. Right now it’s just a conversation about what I can build and come with the ideas. And you know these things, just to be frank with you, like I haven’t built any of them. But they sparked ideas of other things that I did build with all these sort of technologies. But as the conversation’s going, I’m just getting super amped I have all these ideas of what I’m gonna do.
And this is that sort of like a-ha moment that really is the reason why I’m an engineer today, and why I go through all of the bullshit that one would go through in the community and various communities in order to do this job. I really like the idea of having all these ideas and feeling empowered that I can use code to create them, and then show them off to my new friend and experiences verging in friendship that is really exciting to me. But the thing is that the a-ha moment is super femoral and it fades really easily.
Sometimes it happens when I go to open up a text editor, and there’s a blank page, and I think, “Okay, this was a good idea until I actually had to start doing work.” Or like, “Oh, I could build this, but then I have to deploy it.” And maybe I don’t wanna spend hours writing ansible scripts, terror form planning, taking down the entire infrastructure by mistake.
And then also, you know, I might get stuck and I wonder like will I be able to ask for help anywhere, or will someone have the answer online already. And if I ask for help I’m sort of making myself vulnerable to critique upon whether I’m a real developer or something like that. And that’s something that even today, years after I started learning programming feel. And it’s really interesting how the feelings I have about asking for help parallel how I felt about asking for help when I was first learning computer science in college.
And so we’ve been wondering, and I think a lot of you have been wondering like how do we keep that really awesome aha moment, that femoral moment going? And I think that we sort of come up with a way that’ll help solve that problem. And it’s called, “Help,” on Glitch. So, imagine you’re in our Glitch editor, and you’re working on this project. You could open up a new page and see it going on. And you’ve remixed this from somebody, and you’re fairly new to coding. And you’ve like this list, but you’re thinking, “You know what? I don’t want those bullets there. I kind of want numbers. But I don’t really know HTML that well. So like, well, how about if I’m able to ask somebody in the community for help in real time?”
It’s more like you’re not…they’re not just holding their hand as you’re going along, it’s kind of like pairing. And that all different beginner levels and enemy levels this is kind of useful as opposed to just telling them to move away from the computer and doing it for them. Nobody learns in that sort of way. And people are all smiling.
Anil: And we really like that idea of comments as almost conversational annotation in what you’re doing, and thinking of that as a way for people to connect with one another, just as much as they do through all the other creative ways that they pair up.
Jenn: Yeah. So I see that my app, you know, the person helped me, and instead of having bullets in my list I have numbers. And that’s exciting. And I see in the comments what they had left. And now I know that OL is a type of order list as opposed to UL. I stop asking, because I’m done. And I can thank the user for helping, because I think that was nice that they helped me out. And they get little hearts on their icon. They see that you thanked them. I think one thing that we take for granted is that little celebrations are super powerful. It reminds us that when we do like a really good thing, whether we’re compensating in any sort of way or not, but also like just these little celebrations are just something really fun and makes you feel good.
It reminds you that there’s a lot of altruism that could have really pushed forward the community in a positive way, especially when people are asking for help. And we just really like celebrating and dreams and all that sort of fun stuff.
Anil: Yeah, so one of the things that I wanted to point out, we’re revealing these features about being able to collaborate, about being able to help each other. We’ve also been thinking about, you know, DevRel at a really fundamental level. We think about this idea of connecting to each other, and how it applies to every single API, every single SDK, every single platform that people use. You know, what I found, I started doing DevRel almost 15 years ago. And at first it was very exciting, right. You get to fly around, you get to give people free t-shirts, like that stuff is very satisfying and you get to make lots of relationships with people.
And then after a while I found, well, one, that was a grind, right, that’s hard work, that’s hard work to do to sustain for a long time. And the second part was I wasn’t sure what I was doing was as meaningful because I couldn’t point at, “Well, this many people tried it, and this many people succeeded.” And that was, you know, the time that comes to the earlier conversations about budgeting, right? How do you justify all these plane flights and you getting gold status on two different airlines and whatever?
But then there was also the part of, “Well, this is only meaningful to me if I know that the person I helped was able to succeed in creating the thing they wanted to make.” And that’s a lot of what underpins us. And we think about going forward for us, we wanna give everybody who does DevRel the tools to be able to see, “This is who needs help. This is who got help. This is where they got stuck. This is what they are able to create.” And to think about it, almost with the same rigor as, you know, what we see from folks in marketing or from e-commerce. Right. If you make shopping carts you know exactly how many people abandon the cart and where they got stuck. And I think, well, the developer flow needs to have that same level of detail.
That same level of thought put into it. So we know every single step of the way. Where we’re losing people, or where keeping them in, and also whether we’re doing the jobs we hoped to be doing of helping people create the things that they can imagine. and most importantly we think this is one of those critical steps towards stop repeating this thing big bugs that we keep having. We keep seeing these anti patterns, these bad patterns or behavior happen in our apps. And it’s not usually because people are bad, right. Like people are like, “I’ve set out to create an evil app.”
It’s because we’re busy. We’ve got a lot going on, and we may not have learned all the lessons from each other that we could have, and so the more we can do and develop the tools and the communities that connect us to each other, the more we can remember the fact that we don’t learn alone. So, thank you all for taking the time. We’re really glad to be here.
The distinction between external and internal developers is largely artificial, at least when it comes to how you build APIs, according to Adobe’s Matt Asay.
Creating a developer outreach strategy means having a thorough understanding of where you want to be and where you’re starting out from.