Hey everyone, welcome to today's episode of Developer Tea. I'm very excited for today's episode. We have a wonderful guest for today's show. His name is Anil Dash. We're going to get to that episode in just a moment. But before we do that, I want to take a moment to invite you to do a couple of things. First, as you're listening to this episode, try to look for things that are valuable to you. And, if you find something that's valuable to you, I want you to consider subscribing to this podcast, but also sharing that thing with another person. It's likely that if you found it valuable, then someone else might as well. Secondly, I want to remind you that you can always reach out and talk directly to me. You can email me directly, developerteaatgmail.com, and I'm also on Twitter at ad developertea.com. As I mentioned already, today's guest is Anil Dash. As you'll hear from Anil, this is not his first rodeo he's been doing things on the internet for a long time. Most recently, he is well known for his role as the founder of Glitch and as the host of the podcast function. Let's get straight into the interview with Anil Dash. Anil, welcome to the show. Thanks for having me. It's kind of an honor. I feel like I've seen your work for a long time, and I think the world is a better place because of what you do. But for those who, for whatever reason, they haven't encountered what you do, the things that you are a part of, can you kind of give a basic background to the work that you're doing in tech? Sure. I'm a guy that makes stuff on the web. The first thing I became known for is I started blogging about 20 years ago, writing about tech and software and pop culture and whatever else. In fact, then you didn't have to be. You didn't have to pick a late. You could sort of try stuff. Then along the way, I got to work at a number of startups in the early days of social media and I built a tool called Moveable Type. It was one of the first big blogging tools and people used it to build an open and post and gocker and other things like that. More recently, a lot of my work has been around trying to enable collaboration, creativity, coding together. I'm on the board of Stack Overflow and Stack Overflow actually spun out of a company called Far Creek. Then it also built Trello amongst other products. About three years ago, I took over the company and we launched the latest in that series of products called Glitch. It has become a very substantial, very interesting community of people creating web stuff together and it's both a development platform where you can code right in your browser and instantly ship an app to the entire web. Also a really great creative community where you can sort of see other people's work and remix it and collaborate together. It's been a pretty, not going to work a pretty nice success out of the gates. We've had it just lots and lots of steps come in and feel like, oh, this brings back that creative feeling around coding. We ended up actually reneaming the company to Glitch and focusing all in on it. Since we decided to do that about a year or a year and a half ago, it's really taken off and people have now built millions of apps long-gauge and that's my day to day is running the company and getting to work with the community and the team. Fantastic. I'm going to ask you a intentionally broad and difficult question about Glitch now. Who is Glitch made for and who is it made not for? Who is it not made for? I guess it's a better way to use English properly today. Who is it not made for? That's a great question. The first thing I thought about is every time I'd seen a developer tool in the past, it felt like they had pictured a guy sitting at a desk with a black terminal screen and green text on. That was the ethos and the aesthetic and the mindset of this thing. You were going to prove your command line bonafides and this is how you became a developer. We actually have a great cohort of people that worked that way and they're using those kinds of tools in Glitch. But it wasn't that we put them first. We know how to check that box for those kinds of developers. For people, interestingly, on the opposite ends of the bell care format, that's the middle of the curve of developers. On one end are real experts. People love making stuff on the web. They might create the frameworks we use or create the tools that we use. I think they've lost some of the joy and the fun of just making stuff and sharing it because it's become very complicated. You can't just ship stuff and you're negotiating your deployment environment and all this other stuff that's just in the way. Those very, very experienced coders, I think have lost the fun or the soul of what connected them to creating. At the other end are beginners. This can be a kid who's learning to write their first line of HTML. An experienced developer is trying out an API that they haven't used before over their sort of back to square one. Or somebody that doesn't think of themselves as a coder at all, but maybe they had it formulas and spreadsheet, it workers something like that. But for those people who share in common, they've got some technical skill. But they're a little bit out of their comfort zone, a little bit out of their norm. For them, interestingly, they had the same needs that that expert coder has when they just want to get an idea out of their head, which is, I don't want to worry about the overhead and the complexity. I don't want to be distracted by getting something just the basics running. I wouldn't be able to express this idea. I want to capture this little moment of inspiration that I had before it evaporates because it's so fragile. I see it the same way as I know a lot of friends are musicians and they'll always have their guitar tune and do it ready and sort of sitting next to them so that they got a song stuck in their head, thinking just capture it. I think the same thing applies for making stuff on the web where sometimes you just have this fun idea. You want to get out there and on glitch it's as easy as finding something close to what you do, remix it and change it, tweak it to be exactly what you need from that idea that's in your head. We're making it for everybody that's ever had a moment. I thought, you don't be cool to make. You don't know what the world should see. It's one little idea that I have. Yeah, that's super cool. So there's a lot to be said for lowering the barrier to entry, both for people who are well into the industry and have a job and are doing fine, but also it's perhaps more importantly for people who are not in the industry who want to try something for the first time, but they don't want to learn 16 hours worth of Kubernetes material. That's not what they're looking for. Yeah, and even me, I can provision a server on AWS. I can set up a deploy script, but my gosh, I don't want to. You don't even mean like a bit of work all day. I just want to make something and back in the day, I'm old enough. I used to be able to go on geo cities or live journal or whatever the sites were at the time and just sort of like shove something onto the internet and it would work. And then it got hard. And so it got so difficult that I couldn't just try something, couldn't just experiment. And so having that feel where it's as, like I said, as sort of joyful, it's just like tapping out a song on a piano or something. It's a really, it's a nice feeling. Yeah, I think so what you've said is this really cool idea of a quick idea, get it out on paper. I think a lot of people may have a misconception about glitch based on our conversation so far that it's only made for like these prototyping ideas. But there's actually these like the ability to do a production level thing. Oh yeah, right. Yeah, very much so. I mean, we run glitch.com, glitch itself, on glitch. It's a glitch out. We edit, you know, and that's obviously, you know, it's mission critical for us. It's a very important app. But, you know, there are lots of companies where, you know, you're not going to run your air traffic control system on it. You're not going to run it. That's fine. You're not going to run a stack exchange on it. But short of that, a lot of times people are just like, I want to, you know, we have some, some old proprietary app at our company and we would like to have it, you know, drop something in the Slack so we have a reporting system. And I just want to set it up, but I'm not the one person at the office who has permission to launch a production app and do all that kind of stuff. And I don't want to ask the IT guys to do it for me in the third quarter of next year. And so maybe I can just put something together. And I think that, that, you know, that's the work case. But I think that's true at home or somebody who's like, I just want to, you know, put together a website to organize everybody in a neighborhood that wants to clean up the park, the playground. But I don't want to have to do a Facebook group for it. And so there's a lot of just sort of different ways of capturing that impulse, but they're real apps and they really run and they're full stack and they are, you can use any framework, any toolkit, any API. I do think a lot of times we start with that in the coding world of like, here are the technical bonafides and not so much the creative impulse, which is, that's the thing I care about the most is you will actually figure out any tech you need to or any, you know, you will learn anything you need to learn if there is an idea that just animates you so much that you need to create it in the world. So many of us learn that way to begin with or at least started that way. And we want to just sort of enable that because the expert coders are very well tended to. There are tons of resources, tons of capabilities. But the people who are like, I just need to get this idea out there and then maybe they've got some experience coding or maybe you don't, but we'll handle all that other complexity. No matter how far you want to go, if you want to run a large scale production site like your bar, that's great, that's all in there, but you don't have to think about that when you start. Right. Yeah. I think there's, there's an interesting discussion here that kind of emerges when you start thinking about, you know, that seam between, and back when I was an agency work, especially I saw the seam pronounced even more, but it's between the kind of creative people and the technically adept people, right? Yeah, the designer and developer prototype kind of people where the designer is kind of quarantined to this area where, you know, they might be able to make a motion prototypes. They may even be able to work with HTML and JavaScript. Right. But there's no way that that stuff is going to make it over that seam. It's not going to get into the quote, real app, right? Yeah. And it got harder too because we introduced the frameworks and the toolkits and the build scripts that you couldn't just tweak it yourself. Exactly. You had to have this knowledge. Yeah, we kind of lock people into React now. And if you don't have this big and it creates again, the barrier to entry is like growing, right? And I was that person. You know, I was a friend of Depp for most of my Depp career. And these days, you know, I'm a suit. So I don't get to try to get as much code. But, but the, you know, I did feel that, you know, towards the end of that phase of my career, where I was like, I am, this feels more like engineering, right? And like declarative markup or the expressive parts of the web that was what drew me in the first place. And they don't have to be intentional. It's not necessarily oppositional, but that it's sense that there's something closer to an expressive feel. I think it's just very, very powerful people. And you see it. It's interesting because like, if you talk to writers, even people have right books or screenplays or whatever, you know, they're all used, they use Google Docs sort of the standard. We can go in there and we can get it together at the same time. It's cool. And visual designers have that capability in Figma or envision or whatever, you know, sketch, whatever tools they're using where they're sort of able to draw together, create together, design together, obviously in gaming. And go play single player games. It's all multiplayer collaborative games. And then coding is still this world left to be sort of single player. Even what we call social coding or collaboration is really, let me throw this code over the wall to you and hope you don't slap it back at me with my full request being rejected. And rather, I think about like the ability, I see this on Glitch every day. If you have an editor in the browser, it's got a, you know, it'll lint and catch errors and that kind of stuff. And if you want, there's a little emoji of the person with their hand raised. And you can click that if you get stuck. And the homepage will say, you know, Jonathan wants help, you know, Jennifer, do you want to go in and help him and click on the thing and you're in their coding together in real time together in the code and that's cool. And then if somebody helps you, you say thank you and you click the button or screen fills with hearts. And it's just this like moment. It's like, this is what it should feel like when you make something and that you're surrounded by people who want to help you and collaborate with you and help you create that thing. Yeah, I'm trying to like, in my mind, I'm trying to imagine what is, what is an allegory to this? What is another place in life where we are, where we actually have that kind of collaborative? And I'm thinking like walking around the supermarket and trying to find a particular fruit that is esoteric and I can't find it. And somebody says, can I help you? Yeah. That seems like the closest representation in the physical world. Yeah. Well, there's definitely that sense of we, we in the physical world and community, we help each other all the time. I'm sure you've been in the supermarket and somebody can't reach this hot shelf and you can. Yeah. And they're like, can you get that, can you get that can of beans for me and you'll go out there and get it. And I see this having a kid, an eight year old. And if I'm with the playground, kids will ask each other, will you push me on this wing and will you, you know, open up the gate for me, I can't reach the handle or whatever it is and they do it reflexively. It's innate. It's a thing that people love to do. It's a little bit of help. It's a thing that's easy for me, but maybe hard for you is to give, I can give you the cost me nothing and that reaffirms our humanity to one another and we have provided each other so few spaces to do that in the technical world, even though it is one of our deepest impulses. So this leads to maybe a more kind of a deeper systemic question. Why did we get there? Why did we get to this place where, you know, first of all, asking for help felt like an admission rather than a human moment? And secondly, I guess a more important question is, you know, how did we get to this place where the barrier to entry was so high to begin with, you know, what is that? What do you think the history is behind what causes or cause to that? You know, there are a lot of factors. One of the fundamental things about asking for help, and I talk about this with our product team all the time, is you're putting yourself in a position of vulnerability. And so you have to create an environment where that asking for help is normal and rewarded. And actually we do this thing when you raise your hand, yes, we're helping to glitch that these little kind of bubbles and these very colorful, you know, experience come together. And we're sort of saying this is normal. And by making it a visible thing, it's one of the few things you can do in the editor, like we've limited it very much. It's a normal thing to do. It's as easy and accessible as liking the photo is on Instagram. It's very core. And so we normalized it. But it's about this sort of sense of like this is a place you can be vulnerable. And then even goes down into something like, I mean, the name of it is glitch, right? So obviously the mistakes are okay here. Obviously nothing is supposed to be perfect here. And we try to communicate that through design, we try to communicate that through language. But it's all very much about setting an expectation that there's a place where, you know, perfection is not expected. Humanity is expected. And the imperfections are welcomed. And I think it's one big, important piece. You know, I think it's not important about how did we get to the gatekeeping, you know, where the who has access to information and who is deemed correct and who's allowed to have it, you know, honestly, some of this is economics, right? The information of how to make code, how to make software is information that potentially allows you to become part of the class of workers who are amongst the most well compensated workers in the history of the world. Yeah. Right? That is a, that is a, that is a elite priesthood. And once that started to become true, it is no surprise that some people will try to erect a barrier or some gatekeeping around it. And then obviously all the other, you know, systems of injustice that we have in society replicate themselves in technology, no difference in anywhere else. But I say this word, you know, we share at Glitch co-founders and a lot of sort of historic DNA with Stack Overflow, our civil and government. And there I saw this very positive impulse from day one about not having a proprietary answer or priesthood around the data like we wanted to democratize access to the information of what it takes to be a cutter and a good cutter. And yet, you know, somewhat notoriously, there have been a lot of hostility and a lot of sort of rules, Lord, and about how do you ask the question, who's allowed to ask your question, and how do you phrase it and people felt scolded, they felt unwelcome, you know. And I think it's changing and evolving. I don't, you know, I, well, I don't diminish at all that that's been historically true to I don't, you know, want to dismiss that huge efforts have been made by the community and by leadership to fix them too. So like both those things are true. But all it becomes to get them, you say even with a good intent of democratizing information, there was a reward system set into place that inadvertently I think rewarded a certain type of gatekeeper that wasn't about who could access the information because you don't and me, you could be totally not logged in. We've all been there where you Google an error message and I have a second word flow and you can answer and that's good. Right. Yeah. That to truly participate and to truly feel welcome, you know, barriers were erected. And though I have a high degree of confidence, those things will be fixed, you know, in the fullness of time, what I see is this impulse to replicate, you know, the institutions around this, the social institutions and the cultural barriers and that we still see, you know, so many companies like the one I work at, it used to do whiteboarding interviews until I joined. I was never going to do that again because I wouldn't pass it. Right. And I think I deserve to be here and I think that, you know, our whole team deserves to be. And we started to evolve and we saw that, you know, a lot of things changed. All of a sudden, one, the product that we made became more welcoming to more kinds of coders when we became more welcoming to more styles of coders. And our team got, you know, much more diverse, much more representative. We still have a lot of work to do, but it's, you know, well, the bar is low in tech. So we've already cleared the bar, at least being a little more inclusive than the most other tech companies that we want to keep going. But, you know, without doing that from team, then we certainly couldn't do it for the community. And those things are linked. We're going to take a quick sponsor break and then come back and continue our discussion with A Nail Dash. Today's episode is sponsored by Flatiron. At Flatiron School, you learn how the future is being built. So you can change anything, starting with a new career and user experience in UI design. No matter where you are in your career, it might be time to go back to school. Students at Flatiron School are parents, musicians, travelers, and working professionals from all walks of life. If you're an entrepreneur running your own business, or a marketer that's diving deeper into user behavior, or maybe you're just someone who loves design, it's time to level up your creative chops and you can do exactly that at Flatiron School. In just 24 weeks, at one of the global WeWork campuses or online, you can learn to change not only your career, but the world around you. Flatiron schools committed instructors have both industry and teaching experience and are backed by the master teachers and learning experience designers to ensure that you get the best possible support. While you're in school, you even work on real client projects so you'll graduate with a portfolio of real client work. On top of that, you will have one-on-one support from a dedicated career coach and a money back guarantee. You can learn more at FlatironSchool.com slash terms, that's where the complete details are, and when you're ready to make the decision, head over to FlatironSchool.com slash Developer Tea. That's FlatironSchool.com slash Developer Tea. They begin to Flatiron School for sponsoring today's episode of Developer Tea. Now let's get back into our discussion with A Nail Dash. So I think there's people who are listening to this right now and they got caught on the question about whiteboarding. We haven't really talked about it a lot on the show. I want to know two sides of this question. The first side is, what is wrong with that from the skill evaluation level? If we're evaluating how good of an engineer or what kind of value you're going to bring to the table, what's wrong with it in that frame? But also in the cultural, as you were saying, we're replicating our cultural biases, for example, what kind of sub selections are accidentally being made through that kind of selection process, through whiteboarding interviews, for example? Well, it's interesting. This is a very personal story for me because the company I run, which used to be called Falk Creek and the founder, the co-founders are Michael Pryor and Joel Spolski and Joel used to write a blog called Joel and software. It was very influential in the early 2000s on software development. He really was one of the people that pothed their eyes doing whiteboard interviews. I went back and I read his original blog posts on this thing. He said to us, during the interview process, you should capture how people think about the code they're going to write. How do they structure it? How do they approach the problem? He's like, a whiteboard could be a useful tool for while you're in discussion with the candidate to see how they think and have to be able to map it out and give you something to respond to. That's very reasonable. I think very thoughtful and smart. You don't want somebody stuck in the weeds of like, I can't get the compiler to run. You do whatever it is that's there. So you just want to capture how do they think about the problem. That impulse, I think, is very, very positive. What I think happens a lot in tech is there's sort of a cargo culting of like the ritual that becomes more important than the purpose of it. I think what happened over time and many organizations in some degree our own until relatively recently is it became kind of a hazing ritual. It was show me your knowledge of some arcane data type or data structure or something that you've memorized and recite it to me on this whiteboard in front of me. It became very contrived. It's very obviously nobody's ever written code that runs on a whiteboard. It's definitely not the actual environment you work in. The thing I came back to was I want our interview process and our recruiting process to resemble the work as closely as you can. The way we work is not one person on their own being grilled and examined by somebody else. We work together. We come together in glitch. I mean, it's not the company runs. Our interview process works the same way. Here's some code that's worked through it together. We can talk about how you would solve it, what your approach is. By all means, if you are Googling while writing that code, if you were going to stack overflow and I could create, I don't want to be working for memory about some API that changes every two weeks. I want you to look at the docs. All that put together, I think what happened is this very well intended and actually very thoughtful process of let me see how you think became about the ritual of how that happens rather than the output. That resulted in that it was used as a wedge or a lever to re-arract barriers around who gets included because people wanted it soft-sleeved for who has that degree for the institution that I want or who has that identity or profile of what everybody else in the rest of the team does and you can use it as a gate or a fence around who gets in. That thing is that misuse of it, I think, is really poisonous. To that point, it's worth discarding the entire ritual if it's so often misused. It almost feels like the troll on the bridge that asks you and I don't mean to mischaracterize all these well-meaning people, but for the sake of the cultural discussion. A troll on the bridge that asks you to solve an esoteric riddle that has nothing to do with whatever is beyond that bridge. It's this moment where you have to have a passcode basically to get through. While it evaluates maybe a particular vertical of a skill, it also leaves out a bunch of other things and includes a bunch of irrelevant things. I feel like. I thought very deeply about it and I think it's understandable how we got here because everybody is moving quickly. You got to move quickly, you got to make a decision quickly. What could be, it takes a long time to write good code. What could it do? There would be a shorthand quick signifier of knowledge. Well, don't trivia test, basically. That symbolizes a larger knowledge and maybe it's imperfect, but this will be useful. What is similarly, there's an enormous amount of anxiety around the bad hire. It's really interesting. Yes. Well, if you hire somebody bad, and the truth is that it's like you already have, right? It's more than like three people at your company, there's different levels of skill and how do you define that. But also, you would know, right? That's not so much the issue. It's this plausible deniability of nobody can pass through our screening. We're very, very meticulous. There's an underlining anxiety that nobody wants to be on the hook or to blame for who let that person in here. They didn't have to do this one task. The truth of it is, and this is something that I think we really built as a fundamental principle now, which works, but I think many of the future forward looking coding environments doing this is we're all constantly copying each other's code and looking at each other's documentation and referencing what somebody else's code has on GitHub and doing view source on somebody's webpage. Like there's all these things we're doing that are about learning together, sharing together, and it makes the work better. So anything that doesn't honor that tradition of coders, our coders love to collaborate. Coders are fundamentally generous people who like to share their ideas with the world and others do build up what they made. Anything that betrays that tradition sort of drifts away from the most positive aspects of why we started doing this stuff first place. Yeah. I would say this is kind of fundamental to any cultural revolution. It is the ability to pass on information. That's what differentiates humans, for example, from other primates. It's important that we can pass these things on because that's the only way we can build on top of the knowledge. If we had to do everything from first principles and that's the way we lived, man, we would be, that would be pretty difficult. We would have civilization. And every great cultural artifact, every great expression is a remix. Everything is built on somebody else's work. Everything is a reference to somebody else's work. That song you love, that music shows influence by something else. That film you love, that filmmaker saw other films and shaped what they did. And it doesn't mean they're not innovative. It doesn't mean they're not brilliant. It doesn't mean you weren't moved and touched by what they said. It just means we exist in a context of building on each other's work. And anything, as soon as you look at it through that lens, you see how much of the creation of software and technology is made solitary. We are meant to be alone in the dark on our own, nobody else around us. And our creation of software is meant to happen on its own, in a vacuum without being informed by other disciplines, by being informed by the arts, by being informed by civics, by being informed by sociology and anthropology. And that disconnect at the systemic and structural level is just as poisonous to the software we make as the disconnected personal level is to our psyche in working alone and not having help. Yeah. And I think this is something that is because of the history of software development, kind of where it came from. Perhaps we kind of held on to the limited nature that it started out with. But I believe that some of the original kind of people in this, in the intek, some of the early, whatever you want to call them, forefathers, many of them are still alive because this is so new, but they would absolutely say, no, please pull from the arts, pull from whatever inspiration you can. We just did it that way because we were working basically with metal. Like we were, it was so, well, computer, resources were so scarce. Exactly. And the knowledge was so scarce that they did what they could. But it's funny because people will look at sort of the titans of tech. If you, you'd Steve Jobs, right? And they would copy wearing a black turtleneck. But if you listen to the man and what he talks about and what his public persona was, he spent as much time talking about the Beatles and the music he loved. And their obsessive-ness is the entire company about film and music and these things as anything else. You know, same with I look at Microsoft and always often overshadowed by Bill Gates, you know, Paul Allen, the other co-founder. This is a guy, like the end of Mayning force of his life was his law for Jimmy Hendrix. And his, what he wanted to do to fund the creation of the other, the music experience and the rock-roll museum and all that stuff that he did was like this guy. And he could play too. He could play. He was pretty good to talk to guitarist and can I deeply about that? And so there's this, animating things, even in Gates' case. And he's probably one of the, you know, definitely one of those people feel it's more into that nerds, sort of type, very analytical. But, you know, he was raised in a family of care about philanthropy. His mother was on the board of the United Way with the guy who was in charge of the IBM PC project at IBM. And the reason he got the introduction for them to be able to sell MSDOS to IBM for the IBM PC was a connection through his parents philanthropy. And it was later that his father became the first chair of the Gates Foundation and moved to philanthropy. And like, that is these deep connections to very human things. Right. So, you don't go into philanthropy at a global scale and try to end polio. And you don't build a museum to Jimmy Hendrix, you know, unless you have care about some human passions. Thank you so much for listening to Part One of my discussion with Anil Dash. I hope you will join us for Part Two if you don't want to miss out on that. The easiest way is to subscribe and whatever podcasting app you use, the episode will automatically end up on your device. Thank you so much for listening to today's episode. Thank you again to Flatiron School for sponsoring today's episode. Head over to Flatironschool.com slash Developer Teato get started today. Developer Tea is a part of the SPEC network, head over to SPEC.fm to find all of the episodes of the shows, as well as other shows that are relevant to designers and developers who are looking to level up in their careers. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell. And until next time, enjoy your tea.