00:00:13.630
I am going to start this session with some inspiration from Jim Wyrick. He was a legendary developer who had tremendous experience before Ruby was even invented. Jim brought that experience 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 am about to show you is from Rocky Mountain Ruby, five years ago.
00:00:54.190
I took it and added some new merch for my day last, but why day is a celebration of all the things that 'the lucky stiff' gave us. I wrote some crazy code that day, and by the end of the day, our team was ecstatic. We were coding about how Rubyists should love to be included and how to get your ideas around to show people you love.
00:01:15.380
This is a celebration of the techniques we use. Has anyone seen my phone or my CD? This is because anyone can connect; anybody can participate and share.
00:01:56.960
In this occasion, I was accompanied by Chad Fowler, who is also in the audience. He has always been an inspiration for me. This song really demonstrates what the Ruby community embodies: a lovely culture of openness where people share their work publicly with permissive open-source licenses, whether it's songs or cartoons. This openness provides the opportunity for serendipitous collaboration.
00:04:05.650
I will discuss a lot of different examples of this culture, but first, let's cover some basics. Bundler is commonly used for managing gems, libraries, and applications. It invites people to contribute on the homepage. Installing Bundler is straightforward and quick. Sinatra is a framework that I love. They even provide whimsical documentation, perhaps to inspire curiosity or simply to share joy in their creation. As Jim's song suggests, we love to share our code and read the code that others have written.
00:05:30.100
Some may think sharing efforts only make sense for mature projects developed over many years. I picked a random repository from one of my favorite developers, Sarah Mae. She wrote this small app in just a few days with only 33 commits. In her initial day, after 14 commits, she created this README with installation steps and a wishlist of what she has in progress. That is typical of what people do in the Ruby community, and it represents a best practice for open-source development.
00:06:27.020
This is not just an isolated act. I looked at Jekyll, which is widely used to drive GitHub pages. If you trace back its history using Git, the first commit didn’t include a README file, but weeks later, the developer created 'autoblog,' Jekyll's original name. Although it was initially for his own blog, he eventually put together a README explaining what it was. This key aspect of sharing is crucial—helping others understand what you're working on and giving them insight into the inner workings signals that it's for other developers.
00:07:52.729
We normally think of software as being made of code, but really, software is made of people. Before we ever type any code, we are imagining what that software might do. Typically, we make that software with a group of people, turning our ideas into reality through our code. So whether you're working on a passion project or something for your job, communication is essential. It can be fun, but it’s absolutely serious and not a fluffy task to delegate to another team member.
00:08:40.399
I am going to talk about examples I have participated in and others I've witnessed. I will share some code, but first, I want to outline what I perceive to be three key attributes of effective communication, especially concerning software products. First, it’s crucial to convey your big vision. Sometimes, it can be daunting—one might think, 'Who am I to say I’m going to do this?' But if you don’t articulate where you're heading, others can't join you. By suggesting a direction and outlining what the future might look like, you invite participation and help.
00:10:03.240
A big initiative we undertake is running workshops. Who here has attended a RailsBridge workshop? Great! What about other types of Bridge workshops? It started with RailsBridge and has since branched out into ClosureBridge, GoBridge, and more. We address the big vision of transforming society. Most discussions today revolve around how overwhelming these problems are, from college education to preschool. It feels like such a massive challenge, but our workshops have deceptively simple elements.
00:10:39.480
Our workshop emphasizes diversity among instructors, provides childcare so parents can attend, and offers meals to ease participants' worries. The key part is our install fest—pizza and refreshments help overcome the hard part of installation, because many find software installation a daunting task. Then comes the day of coding, where we strive to create a safe and effective learning environment. We want to replicate the best days at work where you can just focus on what you love doing.
00:12:30.170
What we actually share isn't just about coding; it’s about sharing a culture that we love. This has been a transformative experience for participants. Initially, people often think they can't change the industry, but they can commit to teaching a few people for just one day and one night. After the experience, they realize they’ve impacted others' lives, and they can feel ripple effects across the industry. We've seen significant changes in our community dynamics after just six months.
00:13:34.140
In our first six months, we started with just 2% women in the local San Francisco Ruby community, which increased to 18% after the workshops. Interestingly, it wasn’t only about teaching new programmers; it also included women who had felt alienated from the community. Through these workshops, a deceptively simple solution allowed us to sketch out a big vision, and people became enthusiastic about it. This initiative has expanded globally, beyond what I could have ever imagined, not because of one person's effort but because we co-created it transparently.
00:14:40.290
My next story is about my new job at Firebase. I picked this team because they have a collaborative work environment. Our product manager, James Tamplin, starts every meeting by reiterating our mission: 'to help developers build better apps and grow successful businesses.' This mantra aligns our focus and serves as an anchor for our efforts. However, I was initially unsure of how 'public' this mission was, especially considering Firebase’s transition from a startup to a part of Google.
00:15:54.630
I found that the company's mission, 'app success made simple,' was prominently displayed on their homepage – a fantastic representation of our mission. When you look at it in isolation, it might seem like marketing jargon, but the way the team embodies this mission makes it much more meaningful. We focus on a positive developer experience, particularly in the first 15 minutes of user interaction. Each interaction matters and encompasses everything from documentation and the website to blog posts and social media presence. All of these factors combine to define the sum total of the user's experience with our product.
00:17:43.500
When I first encountered the Firebase team was in May 2012 at a hackathon where we developed a mobile app, revealing how we could create real-time functionality using Firebase. They provided us with support and ultimately recognized our efforts with a prize for the best Firebase app. The level of encouragement we received made us feel like superstars. This experience was pivotal as it emphasized the importance of focusing on those first interactions with customers.
00:19:10.030
Next, let’s discuss Rack, which many in the community may be familiar with. Rack was integrated into Rails around 2009, which marked a shift in how various web frameworks operated. However, behind that integration, there was a lot of hard work and collaboration. The idea was simple: having a unified interface for web frameworks to communicate with web servers, which saved significant coding effort and reduced redundancy.
00:20:43.120
Rack isn’t a framework, a library, or a server; it's a convention. If you have a Ruby object that responds to specific method calls, you can connect it to any web server that supports Rack to create a web application. This gradual adoption of the Rack concept is noteworthy. It showed how effective communication and collaboration could encourage integration without compelling every player to make immediate, sweeping changes.
00:23:00.000
Communication is integral to our work. It's perplexing to think that anyone might suggest that communication isn't a critical skill for programmers. We write code in specific languages to define and create things in our world. When I was a little girl, I wanted to be a wizard, and software development feels like the closest reality to that dream because with my code, I can manifest things into existence. This ability is magical and empowering for all of us in the tech community.
00:24:16.840
I want to express my excitement about the diverse programming languages emerging today, which I believe is driven by our faster processors and the new challenges we face worldwide. I'm encouraged by the evolution of distributed systems, new user experience demands, and the drive to create functional languages that better address today's problems. I see this as an ongoing conversation between past and present programmers as we create tools for the future.
00:25:32.420
As software developers, we explore ideas together and learn new languages or develop new ones. This act of coding is communication, and I encourage everyone to continue this journey by experimenting with new programming languages.
00:26:46.230
To conclude, I was a White House Presidential Innovation Fellow, where I learned valuable lessons on communication in government spaces. I observed how the term 'politics' is used improperly in the tech industry. In government, politics can actually drive change for good. For example, the executive order for open data made government data accessible by default. However, I also recognized that not everyone I worked with had technical skills, and I needed to adjust my assumptions accordingly.
00:29:26.550
Ultimately, effective communication is more about understanding others and less about personal desires. The most significant learning was about serving the situation at hand; it's paramount to focus on collaborative solutions rather than individual ambitions.
00:30:12.120
I experienced a challenge while working at the Smithsonian, where I reported to the office of high-ranking officials. I had to navigate varying priorities, often without direct communication with the decision-makers. My approach involved reminding myself that, like others, I was working to serve the public good. By centering discussions on what truly benefits our shared goals, I found powerful solutions to challenging problems–reminding myself and my peers of our common purpose.
