 going to start this session with some inspiration from Jim Wyrick. He was a legendary developer. He had tremendous experience before Ruby was even invented, and he brought that to the Ruby community with great joy and wisdom, which he freely shared at every opportunity. He was a thoughtful teacher and an effective communicator. This video clip that I'm about to show you is from Rocky Mountain Ruby five years ago. This is a song that I took an old, old tune and put some new words to it for quite a day last month. Quite a day is a celebration of all the things that quite the lucky certificate was. And I wrote some crazy code that day. At the end of the day, I had an hour or two extra. So I wrote a code about how Rubyists love to take, they love their language, they love writing code, they love to take their programs around and show other people, they go around and say, hey, does anybody see my code? Do you want to see it? So this is, has anybody seen my code? Work is for all. Ruby is for all to know, as any has one, others lack. Has anybody seen my apps for sure? Ruby is my job, but your has anybody seen? It's accompanied by Chad Fowler, who's also in the audience. He was always an inspiration. And this song, for me, really demonstrates what the Ruby community really has in a lovely culture of openness, where people share their work publicly with permissive open source licenses or song or cartoons, which that openness really provides the opportunity for serendipitous collaboration. And I'm going to talk about a lot of different examples of this, but first, some basics. So this is Bundler. We commonly have jams, libraries, applications, even, where we just invite people on the home page. This is how you install it with quick, easy steps. Sinatra is a framework that I love. They put, in case you've forgotten, how to write a HTTP response in Sinatra, they include a little whimsy there. Maybe do inspire people, pique somebody's curiosity, or just share their joy in this creation. As Jim Song suggests, we like to share our code, and we like to read the code that other people write. And just in case you think that this kind of effort of sharing only makes sense when you've got a mature thing that you've been working on for years, I picked a random repo from one of my favorite developers, Sarah May. She wrote this small app in a few days with just 33 commits. In the first day after her 14 commits, she created this readme for in blogging, which just has a quick description, installation, steps, of course, and a wish list of what she has in progress. And that is typical of what people do in the Ruby community. And it's really a best practice for open source. And this can happen like I just prove that this isn't just random and it's not just Sarah May. I looked at Jekyll, which is a popular thing now. It's used to drive GitHub pages. And if you look at it, and you go way back in time as we can with Git, the first day didn't have a readme. But a couple weeks later, the developer put together autoblog, that was the original name of Jekyll. Anybody know that? And this was clearly just for his own blog. And it didn't really explain much. Blog like a developer, like what the heck does that mean? But he put together this readme and it had installation, steps, and a license. And a couple weeks later, he used that framework to put together better readme. Like he's clearly collaborating with other people now. He's got a name, which I'm not sure is better than autoblog, but whatever. But here he actually explains what it is, which is a key part of sharing what you do, explaining what it's supposed to do. And also the fact that at this point, he's sharing the innards a little bit, means that it's sort of sending a signal that this is for other developers. If you wanna get your hands dirty and see how it's made, but it's not yet the polished thing that it would later become. So we normally think of software as being made of code. But really, software is made of people. So it's people who make software. We, before we ever type the code, we are imagining what that software might do. We're typically making that software with a group of people and with our code, we turn our ideas into reality. And so whether you're working on your passion project or something for your job, communication is essential. It can be fun, but it's absolutely serious. It is not some fluffy thing that you can just delegate to another member of your team. This is hard work, but it's important because communication is a part of the technical work. It is not some separate thing. So I'm gonna talk about some examples, some that I participated in, others that I've witnessed. I'll actually show you some code too. But first I'm gonna talk about what I think are the three key attributes of effective communication when it comes particularly to software products. First, I think it's really important to convey your big vision. Sometimes it's kind of scary. You're like, who am I to say I'm gonna do all this? But if you don't tell people where you're going, they can't go along with you. And if you suggest a direction and spell it out, what will the future look like if you're successful, then they can participate and they can help. Then you can't just stop with the big vision because you gotta do something. So you wanna make sure that you have some concrete steps, some key features, some specific things that people can grab on to be like, oh yeah, this is a thing, it works, I get it. And then paint the picture of what is the path from those small tangible things that you have built already and people can use right away to that big vision and how you're going to make the thing. So my first story is actually a story of social change from Bridge Foundry, which is a nonprofit that I lead that has a vision of the future where the makers of technology are reflective of our society, where all people have equal access. And this isn't just about fairness, although that's also a good thing. This is because we have some very real, urgent, tough problems that face our world and our society. If we don't have all of the talent and potential on the planet focused on solving those problems, then they won't get solved. And software is gonna be a big part of solving those problems in our future. So a big thing that we do is these workshops. So who's been to a Rails Bridge workshop? Yeah, a lot of you. Who's been to another kind of Bridge workshop? A few of you, what kind? Closure Bridge? Closure Bridge, yay. So it started with Rails Bridge and now there's Closure Bridge and Go Bridge. It's gonna be an Elixir Bridge and Elm Bridge. It's so exciting, I can't even name all the bridges off the top of my head. But I wanna tell you how this thing works. We have this big vision, right? Transforming society and most people who are talking about this today are like, oh my gosh, we have to boil the ocean, we have to, you know, there's problems in college and before that in high school and before that in middle school. Like, holy cow, we have a certain preschool. Like it is overwhelming, it feels like such a big problem. So we have a deceptively simple workshop and it has some key elements. We seek to have a diverse team teaching. We offer childcare. So moms and dads can show up. We offer food, so you know, you don't have to worry about that. And key thing, we have an install fest. There's usually beer and pizza and stuff. So you can get the hard part out of the way because like, I don't know, maybe some of you like installing software but most people are, it's not their favorite part of the job. And then there's a day of coding. So we create an environment that we seek to create a safe and effective learning environment. We're trying to share this environment that on our best days we have, that if we have a good job we have, that we have snacks at work and we don't have to worry about somebody taking care of our kids and we can just focus on the work that we have the difficult stuff out of the way and we can get in the zone and make the stuff we love. And that's what we share. It seems to be about teaching coding but I actually think it's really about teaching this culture that we love and want to share. And it has been a transformative experience for people. And if at the beginning people are like, yeah, yeah, I don't know if I can change the industry but I can sign up for coming for one day, one night, one day and teach a few people, five people, 20 people to code, like, I can get behind that. And then after the experience, they see that in that short time they've had an effect on a few people's lives and they can feel the ripple effects across the industry. So we actually, in our first six months, we measured what was going on here and we started with 2% women in our local San Francisco Ruby community, Sarah and me. And six months later, that was 18% of measured by people who were coming to the meetups and we found it wasn't just the women that we were teaching in these workshops who were either new programmers or just new to Ruby on Rails, but they were women who had been in the community that had stopped coming to the meetups because they felt alienated due to the homogenous nature of the group. And so by doing those small workshops, doing this deceptively simple solution where you can get behind, you can get your head around doing this for one weekend, but also sketching out the big vision that we're trying to do in society, people get super jazzed about this. And it's grown all over the world beyond anything I could ever imagine. And it's not because of something I did, it's because of something we did. We co-created it because we didn't have all the answers, because we were transparent about what we were doing. People came in and helped us create the right solution for the community. And I think that was a big win in communication and a big win because the Ruby community is awesome, which is where we started. My next story is in business. So I have a new job. I now work on the Firebase team. And I'm preparing for this talk. I was like, well, can I use an example from my new gig here? So one of the reasons I picked this team is because they're really collaborative and good people and I really like the work environment. And I wanted to share this story. This is James Tamplin, who's our Firebase product manager. And he gets up every week. We have these, every other week, actually like product meetings where he shares like stories from customers and like product updates. And he starts every meeting by saying, our mission is to help developers build better apps and grow successful businesses. It's like a mantra. And I think that's cool. Like, you know, it gets all aligned. We're all like focused on what we're trying to do together. And I was like, this is gonna make a great story. But I'm like, this, it makes a better story if we're saying this publicly, right? Firebase used to be like a startup company. They were acquired by Google a couple of years ago. So I'm like, I don't know if their public voice is like quite as loud as it used to be. I'm just a little anxious about that. So I Google like Firebase mission and I find a bunch of stuff from like the era of like when they were acquired. And I'm like, ah, well maybe this isn't such a good story. And then I'm like looking around and on the homepage, it says, app success made simple. The tools and infrastructure you need to build better apps and grow successful businesses. I'm like, well, that's it. Oh my gosh, our mission's like on the homepage, not kind of what I expected from being in the midst of this ginormous company. And if you just read this in isolation, it just looks like marketing fluff, right? But the way that it's folded into the work of our team makes it not that. So a couple of tactics that they do, we do is focus on the first 15 minutes of the developer experience. So this happens over and over again at different interactions. Well, how's this gonna affect the first 15 minutes and how are we gonna describe this so developers are gonna get it right away? I talked to Joey Yang, one of my colleagues who talked about the developer experience. It's so important to this team where the user experience is the sum total of every interaction the user has with the product. So that is not just the documentation and the website and the code that we produce. It's blog posts, not only our blog posts, other people's blog posts. It's our GitHub repo. It's the Stack Overflow questions and answers. It's presence on social media. It's conference talks, meetups, hackathons. These are all experiences of the product. In fact, the first time I met the Firebase team was in May 2012 at Hackathon and me and a few other people were creating this app that was like, you had your mobile phone and you would like, this is the idea, you would like wave it around and then when you like click the button, it would create a 3D shape of your thing, right? You can see it on my laptop and because we were using Firebase, like we hadn't really considered doing it in real time but because we do, with Firebase, as soon as you click the button, zap, it would be like on the screen and they were like coming over and helping us. They ended up giving us a prize for like the best Firebase app at the event and they like invited us back to their office and they made us feel like superstars. Like we were there with like companies that were actually like building businesses and this was like our mobile graffiti app. We think it's cool. It's not yet on the app store. And they made us feel powerful. It was our story. Of course it was their story, right? But we felt like it was our story. And those elements of focusing on the first 15 minutes and really creating these cherished interactions with your customers is what builds to their big vision. And of course they have to make a great product and of course they have to do all the other things but having those concrete steps, let the large team actually work together to build towards something that's gonna be aligned. So my next story is about open source and rack. Who has heard of rack? A lot of you, yay. So some of this might be review but some maybe not everybody knows the history. I kind of knew the history because I started using Rails in 2008 and then it seemed like and Rails adopted rack in 2009 with two, three and it seemed like there was this era where like all of a sudden from my end user sort of developer perspective, like all the frameworks just suddenly started using rack. Like everybody got together and was like, okay, this is what we're gonna do. But I don't think that's actually how it happened. So I looked up the original blog post by Christian Neukirchen about announcing rack. So he made this observation that at the time the web frameworks and the web servers had a lot of repeated code, right? Because each web framework would have kind of custom code to talk to the different web servers and they had to like actually work to support each of the different web servers and at first there weren't that many so it wasn't that big a deal but it kind of got to be a little messy. And so he made this observation that there's actually, you could have a very simple interface of making a call and returning an array with three things and that that could be the new interface for a web server. And he wrote this up in a blog post and made this compelling argument and I'm gonna share with you a little code that is something that I used to teach, back when I used to teach Ruby on rack which is based on a presentation by Dan Webb. So rack is not a web framework. It's not a web server. It's not even a library. It's a convention. If you've got a Ruby object that's got a call method with one argument and a method that returns an array with three elements then you can connect it to any web server that supports rack and you've got yourself a web application, that's it. So I'm gonna go quick because I think I'm running out of time. So this is an example. So proc is a Ruby thing that has, you can knew it with a block and then it has a call method. So it's a really convenient way to create an app that you pass into a web server like thin and there you have, if you run this you will have a web application that serves up hello world. Completely different code. You've got a class hello world that has a constructor that takes a name and then you've got a call method, right? That's explicitly a method here and then it returns this array. And in this case, I've got mongrel, I'm calling hello world.new with Dan and this would serve up hello Dan. So you've got a call method with an environment that's views up all of your HTTP request. Information, the status code, HTTP headers, a response body. The response body can actually be any object that responds to each. So you can do this with a file. So suppose you wanna do a streaming file. You can just write in each method that serves up chunks of your file and then you have this super simple response. This common interface was then gradually adopted just I think, I don't know, I'd love to actually talk to all the people who've adopted this, maybe some people in the audience know the answers. But it was adopted gradually by all of these different web servers and frameworks. And what was great about this concept is that it only took a couple of players to adopt it for it to add a lot of value. And then every new library framework server that adopted it added more value. And that method of letting people take a small action to build towards the big vision without making everybody change everything at once, I think that was brilliant. It was like, right once, serve however you want. And what's great about Rack is it was really just an idea. I mean, sure, he wrote a bunch of libraries that made it easier for people to do. But Rack itself was not the library. He didn't have to make anybody use his code. It was an idea that it was a good idea and he facilitated its adoption along with some other people. So communication is what we do. I find it confusing that anyone could even suggest that communication is somehow like some different skill that programmers don't need. This is what we do. We write our code in programming languages. We define things and then they exist by using this language we make things real. When I was a little girl, I wanted to be a wizard. And I think software development is the closest thing that I could get to this because I say stuff with my code and it makes it real. I can wave my magic wand and an image appears a thousand miles away. And that's a magical thing and that's a power that we all have. And I've been really, I wanted to kind of close this by remarking on sort of my excitement about all the different languages that there seem to be exploding. And I think that it's a benefit of like our faster processors. But I also think we have new problems in the world. They've touched on some of these this morning. We have new problems of how to build these distributed systems that require better handling of concurrency. And new user experience patterns with mobile and all sorts of connected devices. And I've sort of like sort of splayed out. I was trying to understand this. I've probably put things slightly in the wrong corners but I find that like looking at across time and across kind of different programming trends helps me make sense of what all these things are. And I think of it as a bit of a conversation between the past programmers who did all this early foundational work and how we're communicating to the future in these new capabilities that we put in the hands of our colleagues. Software developers exchange ideas through experimentation. So learn a new language. Make a new language. Code is communication. And what will you say? What's the language that you've been learning or experimenting with most recently? That is a good question. I'm not intending to languages. Yeah, well so I've been learning Angular. It's, so it's a thing. I, when I was in early in my, like in, I don't know, at some point, I don't know, 10 years ago, I made an open source JavaScript framework for UI stuff that was called OpenLaslo. And it had a very, it was very similar to Angular and that you sort of can create these tags. So it's been really interesting to see like these patterns play out in new ways. But I've been wanting to learn one of these hot new functional languages for like five years. It was like closure, first it was gonna be closure and I went to a closure bridge in San Francisco but then I didn't persist. And now I'm like super excited about Elm. There's gonna be an Elm bridge in San Francisco in October. I'm very opportunistic with like what languages I learn. I'll go to a hackathon and learn a new thing. But, but I'm pretty excited about this trend in functional languages. I think that it's really a solution whose time has come with a lot of the problems that we have today. Any questions? Oh, way back. Hi, Sarah, thank you for coming. You mentioned some of your work as a White House Innovation Fellow, the Smithsonian at AT&F. I was wondering if you could comment about your experience there and how does communication kind of work differently in government spaces? That is a good question. I need a seat for that question. So I came into government as a Presidential Innovation Fellows. It's very confusing. There are White House Fellows, they're a different thing. We were Presidential Innovation Fellows and we were partnered with people inside government who really understood government. And what I really learned a lot is one is in we use the word politics, I think in really inappropriate ways in the industry that it was eye-opening that politics can be used for good. That I saw secretaries, people from the White House, very senior government officials with a few words change the course of, like you could sort of see like, oh wow, that's actually gonna make economic impact on this industry because people are gonna go forth with this new knowledge and new awareness and do action. That you could with words, with policies, actually change human behavior in really fundamental ways. I came in on the heels of Obama signing the Executive Order for Open Data which made all data produced by federal employees by default open. So before that, anybody would have had to get permission to open a data set which is a big thing in government to get permission to do stuff. And it's not just that people are afraid of getting permission or it's a lot of work, that there's actually like laws, right? Like in government, the reason you have a job is because somebody like wrote a law that you should do the thing, right? So if you don't do the right thing you could actually break the actual law. And that's scary because you're like, I don't wanna like break the law. So there's great power in these like sort of baseline policies that let us, and how we act. And there are all these assumed policies that are a whole other thing. And so I learned a lot about different ways to communicate. And the other big thing I learned is I was for the first time really working deeply with people who had like no technical skills, right? New, like there was like assumptions that I made is just like, of course, open source is good. And they'd be like, why would you, huh? Open data is naturally good, but why would you know, like so many fundamentals I had to explain. And, but I was working with people who were like deeply experienced in other domains. And it caused me to learn how to very quickly assess the skills that somebody else has. And to realize, because the other thing in government is like, especially when you're there for a time, I was there for six months initially, like there's, you can't trade out the players. You can't fire anybody like, you've just got who you've got, right? And I used to get really pissed off when like people were incompetent, like screw that. Like I'm life short, like why don't I work with you Bozo? But then I realized like one, it doesn't serve me to assume that somebody has skills that they don't have, right? There's some reasons they never acquired those skills and they don't have them. And like life short, like I don't need to teach them those skills, I should just work with what I've got. And getting angry about it also, like it doesn't help anybody. And sometimes you just go to show up at the meeting and be like, thanks for coming to the meeting, why don't I just give you an update on our progress? How was your weekend? And like that's all the meeting's gonna have. And you know going into it that this person is not gonna move your anything forward. But you don't have to be obnoxious to them. You could just appreciate and you never know when their good word is gonna be in the air of somebody who you need to make a decision. So I think the biggest thing I learned about communication to answer your question is it's not about me. It's not even about what I want. It's about what is actually going to serve the situation. What is actually going to move this thing forward? So my last anecdote from this segment is, so I went to the Smithsonian, I was a Smithsonian employee reporting to the office of the secretary. For those of you who don't know, secretaries in government, they're like heads of agencies. They're not like somebody's admin. They're important people. But I was a presidential innovation fellow and I was with this cohort who kind of reported to the White House and like the president of the United States of America. But it wasn't like I had one-on-ones with the president, I didn't get direct orders. And it was a little awkward because sometimes like the things that the Smithsonian wanted to do in the short term were different from what the office of science, technology, policy, and the CTO of the United States were telling me were important. And it was a little awkward, right? And there wasn't really, earlier in my career, you'd have different bosses telling you different things. You'd go to their like joint manager, right? But I didn't have access to those people. So I developed a technique which was to say like, okay, I'm a presidential innovation fellow. And just like the president, I work for the United States of America. So when this situation with this problem, what is the best thing for the United States of America? In what way could I justify my salary being a good use of American tax dollars? And when I could bring it to that place, that's incredibly powerful. Because that's what everybody wants there, right? Everybody wants to do the right thing, you know? And then you could get to the heart of like, what's the problem and how to get in between those things and how do you overcome those things? And that philosophy has like helped me in every area of my life to think, okay, well like I'm working with these people for some reason. I'm in a room frustrated, communicating these people for some reason, like what's the thing we're all here for? That's what it's about, right? It's not about you, it's not about them. It's not about whatever horrible thing is in your way. It's about what you're all trying to make happen. And by any means necessary, you get there. Thanks, Sarah. Three, two, one.