The ReadME Project // @github

Here’s what’s in store for this episode:

• 00:00 - Meet our newest co-host, and learn about The ReadME Podcast’s new format.  

• 01:40 - First Commit: Neha and Martin explore “Eternal September.” 

• 03:54 - Features Story: RMP Sr. Editor, Klint Finley, joins to discuss his recent story Functional programming is finally going mainstream.

• 18:17 - #AskRMP - Open Source expert and former host of The ReadME Podcast, Brian Douglas, joins to answer this month’s listener submitted question.

• 21:32 - The Interview: Special guest Aaron Francis shares his advice on publishing your work to build your own luck. 

---

Looking for more stories and advice from the open source community? To learn more from the authors and experts featured on this episode, check out:

• Functional programming is finally going mainstream by Klint Finley 

• Publishing your work increases your luck by Aaron Francis

• Bdougie's new project: OpenSauced

• Functional Programming 101 by Cassidy Williams

• The five-minute feedback fix by Hillel Wayne

• ONWARD: A framework for maintaining maintainers by Frances Coronel

Special thanks to Cassidy Williams for lending her perspective on functional programming, @bdougieYO for providing his expertise and answering our #askRMP question this month, and Aaron Francis for sharing his insights on overcoming your fears and publishing your work.

---

Martin: So, Neha, I've got a question for you. 

Neha: Yeah. 

Martin: How do you spot a functional programmer?

Neha:  I don't know, how?

Martin: Don't worry, they'll tell you. I'm Martin Woodard from the GitHub developer relations team.

Neha:  And I'm Neha Batra, I lead GitHub’s community engineering team.

Martin: This is the ReadMe podcast, a show dedicated to the topics, trends, stories and culture in and around the developer community on GitHub.

Neha:  And just like an open source project, we're taking an iterative approach with the series. For those of you who have listened to previous seasons, you know the episode centered on an interview with a notable maintainer or developer, and we're still going to keep those interviews going. But we're also going to bring you the latest stories, expert advice and information you need to know about the culture of software development.

Martin: You might also notice that my voice is a bit different from the one you're used to. I'll be sitting in the chair formerly occupied by my good buddy bdougie. We'll be catching up with Brian later on in this episode to hear about his new adventures and to ask you a question submitted to us through the hashtag askRMP. We'll also talk to The ReadME Project's Senior Editor, Klint Finley, about functional programming and take a look at the value of taking risks and publishing your work with Aaron Francis.

Neha:  Each month will explore a bit of tech history that may surprise you or come in handy during your next trivia night. A segment we're calling First Commit.

 [Jingle] On your mark. Get set. We're riding on the Internet. Cyberspace sets us free. Hello,virtual reality. Interactive appetite, searching for a web site, a window to the world to get online. Take a spin, now you’re in with the techno set. You're going surfing on the Internet.

Neha:  It's already September. I can't begin to process how fast this years flying by.

Martin: Yeah, I know. It's crazy, isn't it? What's going on?

Neha:  If it's any consolation, it's kind of been September for almost 30 years now, depending on how you count.

Martin: 30 years. That's actually that's when I started college or thereabouts. I started college in like ‘94 was when I first started university.

Neha:  Wait, that's so interesting because back before 1994, one of the main ways people access the internet was through colleges and universities.

Martin: Yeah, I remember it well. Yeah, logging on to pine and then you're trying to figure out your way around. And it was just an absolute nightmare trying to understand what was happening.

Neha:  Well, at that time, there were Internet groups that always saw an influx of new users every September because freshman students were getting their first accounts. And that became a really frustrating time for veterans to be online because these new users didn't know the customs or etiquette of the digital world.

Martin: Yeah, that's true, especially on the old NMTP groups and things. And we were always asked the same old, same old questions. I didn't realize I was that annoying freshman at the time, but then again I suppose.

Neha:  Well, do you remember turning into the curmudgeonly person that would say, “read the manual?”

Martin: Well, I didn't say read the manual. I interspersed a couple of extra words in there. But yeah, definitely.

Neha: Read the adjective manual.

Martin: Read the Gopher site is what we used to say. Yeah, exactly. Go go check out this Gopher page. This is pre-world wide web.

Neha:  But now, of course, that period didn't last all that long. Once commercial providers opened up the Internet to anyone with a credit card, the flood of users became an all year round kind of thing. But today, almost 30 years later, the term Eternal September is used to mark the beginnings of the commercial Internet.

Martin: Oh, my goodness. Does that mean, I'm reliving my freshman year forever. I'm not sure if that's, like, awesome or really horrific. 

Martin: I kind of made a joke about it earlier, but there's been a lot of talk in the industry lately about functional programming. It's a style of programming that could be ideal for cloud scale distributed systems and for serverless environments. Klint Finley, Senior Editor for GitHub’s The ReadME Project, has been following this trend and recently wrote the article “Functional programming is finally going mainstream.” He's here to talk to us about why it's having a moment. Hey, Klint.

Klint: Yeah. Thanks so much for having me.

Martin: I've definitely seen more and more people in the industry talking about functional programming. I have to admit I've only used it a little bit and kind of the way I hear explained is that pure functions are the ones whose results are dependent only on the input and the operation has got no side effect. Is that right?

Klint: So I think that the core idea is that you're trying to do programming based around pure functions, which means writing functions in a way that there are no side effects. And you're generally trying to keep your data immutable, meaning that instead of changing data in an array, you are copying that array instead and using the new copy as the primary copy. The analogy I like to use is stomp boxes for guitars. You can kind of think of each effects pedal as a pure function. An input goes into the pedal and an output comes out. If the sound is exactly the same going in the sound is always going to be exactly the same coming out. And the parameters of a stomp box can't alter the parameters of another stomp box. You can wire a whole bunch of them together to make really complex sounds, but each one, if you turn up the gain on one, it's not going to affect the delay on another pedal. So it will affect the other parts down the chain, but they are essentially just little modules that do their own thing. So you can go through and troubleshoot if something's wrong. So it's a pretty big paradigm shift for people in terms of learning to program in this style. It requires thinking in a whole different way, especially when you start thinking about immutable data and not just changing a variable or something like that of like creating a whole new variable, creating a whole new array each time you want to alter something.

Martin: I mean, you know, functional programming has been around for a while. It definitely was around when I was kind of learning to code and stuff, and when I had to make that switch from kind of procedural to object orientated and functional was around and you know, things like Haskell and F# and stuff like that. But it seems that it's really catching on now and like lambda functions and things are around and you know, we've got a bunch of serverless happening and things. So why do you think it's catching on now? What is it?

Klint: Yeah. Well, its like you said, it goes back all the way to the 1950s with the Lisp programming language. The mathematics are even older than that. But to make a long story short object oriented programming came along and kind of displaced functional programming for quite some time because it made some of the reasons that people were interested in functional programming were, you know, the reusable chunks of code, the functions and so forth. But then object oriented programming came along and did some similar things, offered people ways to reuse pieces of code through objects. But over time, a lot of developers became more and more frustrated with the way object oriented programming and imperative programming worked at scale with with really large code bases that companies like Facebook and Twitter were starting to work with that had really large numbers of people working on them, where changing something in one part of the code base might break something for somebody else in another part of the code base. So functional programming never really went away.

People were always interested in it, even if it wasn't super mainstream. So as these problems started to arise, people started to rediscover functional programming or think, you know, maybe this is an answer to help with some of these issues. So where I really started paying attention to it was around 2009, 2010, when a lot of companies like Facebook and Twitter were sending engineers to functional programming conferences to speak about how they were using functional programming to solve problems. For example, Facebook was using Haskell for spam filtering. And so as word kind of got around, I think it gave functional programming some new cachet because these big, kind of thought leader companies were using it, were going to these conferences. And sort of in the meantime, a lot of programming languages started adopting features like monads. They started supporting high order functions where one function takes another function as an input or outputs a function as an output, which is what you really need to be able to do a pure functional programming situation to chain lots of functions together in interesting ways. So the support was getting there.

The React ecosystem I think is really interesting because like I said earlier, the learning of functional programming can be a challenge for people who are really used to other programming paradigms. The React ecosystem, like Redux, which is a state management system that uses reduced functions instead of loops—for loops—for a lot of things is kind of sneaking functional programming ideas in the back door. And so people are sort of learning to do certain elements of functional programming, especially now that React functions, which is a fairly new feature, is available in the mainline react. So most of the people I talked to would not call React a functional programming framework or system, but would call it functional adjacent, in essence. A huge number of frontend developers are using React as a UI library. It's the most popular front end UI library out there. So it's really teaching a whole new generation, a whole big group of people to start thinking about programming in a different way.

Neha: You already talked about how you're seeing companies start to adopt that. You're able to observe that in conferences, right. For a company that hasn't previously adopted functional programming, what do you think, as we've learned about other companies joining, what do you think is the value add?

Klint: I think the big thing that people talk about is essentially fewer bugs in their code. So it means doing a little bit more work up front to write the code in a proper way. But then it means less debugging later so people can spend more time working on the parts of the code that they really want to be working on and not writing it really quickly, then going back and having to do a lot of bug fixes. For companies, it means essentially fewer bugs, which means better software, happier customers, less downtime, less risk.

Martin: There are people who are avid fans of functional programming and they're, you know, they'll go out and they'll sort of sing it from the rooftops. Why do people love this style of programming so much?

Klint: Yeah, yeah. It's sort of like the keto diet where once people start it, then they get really passionate about it. They want to, you know, tell everybody about it, encourage everybody to start doing it. And I think a lot of that passion just stems from it feels really liberating to not have to worry about side effects, to have fewer bugs in your code so that you can work on what you want to be working on. So you can be thinking more about the code and spend less time just trying to fix things later on. I spoke to Cassidy Williams, head of developer Experience and Education at Remote, and she had this to say.

Cassidy: First I was just like, This is weird. How is..how is anything possible with this? You need objects. But then as I started getting more comfortable with it, it got to the point where I was just like, I don't know if I can ever go back. And I did eventually go back, but I loved the concept of just everything being a function and everything being able to be broken down into small pieces and then adding onto each other like LEGO blocks. When I first started the functional programming stuff, I thought it was just a very academic way of building languages. But as I kind of moved on in my career, I took different workshops and taught different workshops on how you could incorporate aspects of functional programming in a very practical way in languages that aren't necessarily functional, like JavaScript. And that was really exciting to me because I thought of it as a very cool way of being able to have some of the benefits and guarantees of functional programming but in languages that aren't necessarily functional.

Neha:  And I think we should be fair. We should also probably talk about the other side, right? So in addition to some of the benefits, what do you think are some of the challenges that come with adopting more functional programming?

Klint: Yes. There's a really good conversation about this article on Hacker News. And one of the big questions that came up was about performance. So essentially the worry was that by doing immutable data, you have all these copies of datasets floating around in your code. Does that bog things down? Does that create performance bottlenecks? And it seems like the consensus is essentially, no, that's not really a concern, because once the code, the functional code is compiled down to Assembly or bytecode or C or some other language, it becomes a lot more efficient. It maybe is mutating data at that point, but it's sort of outside the realm of where human error usually occurs. So there's less concern about the mutability when at that level post compiling. There can be performance problems though when people try to learn a new approach and not necessarily know the best practices, not necessarily know the most efficient ways to do things? And so that learning curve is really, I think, a big challenge for functional programming. And again, Cassidy pointed out some of these challenges that come from functional programming.

Cassidy: Because functional programming does have these guarantees. That means that not too many things can affect it. It has to be very pure, like it's often called pure programming for a reason. And so when you have a much larger system that relies on side effects, that relies on user inputs, that relies on changes in a broader system and parallel programming and stuff, you can do stuff with functional programming, but the usefulness plateaus a little bit.

Neha:  Do you have any advice for developers who want to work in a more functional way and want to convince their coworkers or introduce new ways of working within the code base?

Klint: Yeah. I think from talking to people just in general, it's always best to start with something small. So if you can find a good use case for functional programming, where I think a lot of the best uses are really computationally complex problems, where a single bug could could throw off a big set of problems. So if you have something like that that can be relatively isolated from from everything else that you're doing, you can try it out and then, you know, have some evidence to bring to management that maybe it might be worth moving forward, doing more functional programming for kind of greenfield development, for new features and that sort of thing in the future.

Martin: And I think that's key, isn't it? You know, it's not saying everybody needs to go do functional programming now. This is the only way you should program. But I think by just like when we were doing procedural programming and moved towards more object oriented programming by rewiring our brains that way allowed us to switch it allowed us to use the right tool for the job by going out there and using functional programming techniques. We expand the tools we have. And so then if we find a scenario that's particularly well-suited for functional programming and is going to, you know, introduce less bugs or give you massive scale, especially when you're trying to do, you know, these big distributed systems, then you know how to do that. You recognize that as a scenario where this functional style is going to benefit you, and then you can just, you know, jump in and go do that. So yeah, I think it's a great article and and great to raise awareness around these functional concepts. So thank you.

Klint: Thanks for having me.

Martin: Klint Finley, Senior Editor of The ReadME Project. Thanks for chatting. And before you go, do you want to give us a preview of some of the latest stuff the team's working on?

Klint: Sure. So we have a bunch of interesting stuff coming up. First is a piece on the command line, which I also got to write. Now, the command line for some people is an invitation to adventure and mystery. But for others, that blinking cursor is a source of major frustration. So this piece digs into how the command line is evolving and what that means both for new developers and old pros. It's gotten some great feedback so far, and I'm looking forward to talking with you about it in a future episode. You should also check out our latest guides, our series from guest contributors from around the world of open source. The latest is about the fact that fast feedback is great when you can get it. Contributor Hillel Wayne noticed that there are two parts of the application development lifecycle where it's hard to get timely feedback: requirements and design. With this guide, you can learn how to use formal specification and decision tables to quickly test both so you can validate designs and make adjustments before committing to a lengthy design process. And for anyone maintaining or contributing to open source, there's also a guide by Frances Coronel that provides an actionable framework she calls ONWARD. It provides guidance to maintainers on growing community and fostering future maintainers. You can check out all of these articles and more on functional programming as well on the ReadME project at GitHub.com/ReadME.

Neha:  As part of the community building process, we want to make sure we're answering specific questions that you bring to us.

[Jingle] “I have a question.”

Neha:  This month, Sarah from Vancouver, Canada, asks: “I'm thinking about open sourcing my first project. Are there any pitfalls I should watch out for?” And to answer this question, we're excited to bring in former host of the podcast. Drum roll, please… Mr. Brian Douglas. We know him as bdougie. Here's his advice on pitfalls to look out for when you venture into the open source world.

Brian: My recommendation is having enough information in the readme. That's going to be the central location for everyone to sort of like land on your project. And a lot of times folks just forget to mention what the project actually is. So mentioning what the project does, how it got started maybe, and like a Getting Started guide. A lot of folks add information on how to get started using the project, but if someone wants to contribute, Getting Started guide on how to contribute is also a must have for sure. And it's also really important to think about attracting community to your project from the very beginning. And I think that really just starts with where to have communication. So if you want to have synchronous communication or async communication, make that very clear in your project. So if you're using GitHub Discussions, add a welcome discussion and more than just the intro welcome to discussion when you open up discussions in your project, but like sort of a breadcrumbs like “these are the types of discussions we're working to have here.” And if you have synchronous communication, so if that happens in a chat like Discord or Slack, provide a link on getting there. A lot of people have these Discord servers, but forget the link that somewhere publicly. So be clear on where communication happens and how to find it. In addition to communication, documentation is also a great async communication. So having links clearly where docs live, sometimes they live inside the project, sometimes they live in an entirely different repo. So take the time to create those breadcrumbs and how people can find documentation on getting started or answering quick questions. 

Martin: His colleagues were sad to see Brian leave, but he’s staying close to the community with his new venture. 

Brian: It's been such a joy hanging out with you on the podcast and I'm sad to say that I'm actually going to be leaving as host. I'm going to be taking some time to work on my side project that I've been working on for the longest time called OpenSauced, which is a pathway to your next open source contribution. And I'm just super passionate about not only hearing the stories and sharing the stories, but also finding new stories. And that's what OpenSauced is going to be doing, is finding new contributors to join open source and projects across all of GitHub. And be sure to check me out, all things bdougie on the internet as well as opensauce.pizza. Looking forward to sharing more of what's in store.

Neha:  Do you have a burning question about open source, software development, or GitHub? Share it on social using the hashtag askRMP. That's Ask R-M-P. We might be able to answer it in the next episode. 

Neha: One thing we want to make sure we do on this show is to look deeper at specific steps that you can take or skills that you can build to boost your career, improve your work, or maybe even make your life better. As part of that, we talk to developers about something they did and something that you can do, too. So today we're joined by Aaron Francis, marketing engineer at Tuple.

Aaron: I was sitting on the back porch right outside of my office here, and I was talking with a friend and we were just talking about the stuff that takes off on Twitter. And I made the observation that the thing that takes off the most is never the thing that's most complicated. It's never the most impressive, shiniest engineering feat. It's just in our little world, it's just people sharing cool stuff that they're doing. I spoke that realization out loud and I told my friend, I'm over it. I'm just going to start sharing so much on Twitter, which is primarily where I share.

Martin: Not long ago in his career, Aaron felt a bit stuck. He wasn't taking a lot of risks in his day to day work, and he didn't understand why he was feeling frustrated and envious of the success he was seeing of his achieve. He had a fear of rejection about putting himself and his work out there for others to see. In the last year and a half, he's turned the attitude around and is feeling luckier than it has in a while, in part because of a few intentional steps he took to increase what he calls his “luck surface area,” a concept I really loved. One big piece of advice he has: Don't be afraid to publish.

Neha:  I'm so excited to have you here today. Your article is fascinating and it, like, sparked so many neurons in my brain and I'm really bubbling about this. I've been wondering, like, why are the experiences in your career, right? Especially with respect to putting yourself out there that have shaped where you are today.

Aaron: If you're in the community and watching other people do stuff and thinking “I could do that or I've done that,” you have two options. And one is to get bitter, and the other is to realize “Oh, people like this kind of stuff, I should share more.” And I was super close to becoming bitter because I was watching people in the Laravel community do stuff and I was thinking “That's really cool, but like I could do that or I've done that before. Why does nobody pay attention to me?” And I realized it's because they're sharing and you're not. And I thought, okay, well, I can't decide I'm just going to be the bitter old grumpy programmer. I'm going to start putting myself out there. I'm going to get over this fear of people, you know, nit picking the stuff that I do. And I'm just going to start sharing because I want to be a part of this community. That's kind of what it felt like. I felt like I was on the outskirts of the community and because I wasn't interacting with people, I wasn't sharing, I wasn't writing, I didn't feel like I was really integrated in the community. And that has completely changed and it's been wonderful.

Martin: So, you know, as an engineer, publishing stuff is one of the scariest things ever and it kind of makes you very vulnerable to do that. Every team I’ve worked with, I’ve worked with a bunch of teams who are kind of getting ready to release their code, open source and things like that, or even innersource. And they always want to refactor a bunch of things first before they publish. And there's always like a bunch of, you know, stuff. It’s just this emotional hurdle you've got to get over. So, you know, tell us, why do you advocate for publishing your work as an engineer? You know, why why do that? Because it is making yourself vulnerable.

Aaron: Absolutely. It is a very vulnerable thing to say “I've done this really hard thing that I am proud of.” and to put it out there for people to potentially say “That's not hard and you shouldn't be proud of it.” That can be really devastating and I'm not pretending like it's not devastating. Like I will never say you just need to get over that because it's hard. The reason I advocate for it is I think the upside is potentially unbounded and the downside is bounded. So I think the upside is unknowable. You put something out there and you never know who's going to see it, who's going to use it, who's going to look at that thing and say “We've been having that problem in our company. Why don't you come work here?” I don't know what could happen if you publish something. If you don't publish anything, ever, what could happen is pretty well known. You're not exposing yourself to the luck, right? So you're just building things in private. I will say, if you want to work your 9 to 5 and then log off and go do puzzles or take care of your family or whatever, that's great. You don't have to do this, right? So I think part of the publishing is what do you want to get out of it? If you want to become more of a pillar in a community, if you want to potentially get new opportunities,. publishing is a great way to do it. If you want to work really hard during the day and close your computer at night, great. Do that. So it's not a one size fits all. It's a what are you trying to accomplish? And I think a lot of engineers are trying to move their careers forward. And this is a great way to do that.

Martin: So it's not just publishing stuff out there, but then recognizing and capturing that luck. How do you go about doing that? How do you go about recognizing and capturing when you've got it? When you've been lucky?

Aaron: Yeah, I think part of the benefit of publishing is you build up this public body of work. So you could go to a meetup or a conference or a podcast and say “I promise, I'm really smart. Let me come on your show” Right? Totally possible, probably works maybe. I don't know. You could go to a meet up a conference or a podcast and say “Look at these blog posts I wrote. Look at this open source library I did. Look at these tweets of these people saying ‘Oh, wow, this was really great, thanks for making this.’” It kind of builds on itself and in a snowbally way. Right. So the way that I started as I wrote this open source library and I was tweeting about it and then a PHP meetup was like “Hey, I saw you tweeting about this. You want to talk?” And I thought this was my big break, I had made it, and I showed up to this online talk and there were like 40 people there and I was freaking out. I prepped so hard for it and it was awesome. And that was like a that was like a stair step up to the next the next spot. And then I took that video that was online and submitted it to a conference and said, I want to speak at this conference. They're like, “Yeah, that sounds good.” And there were 2000 people online for that conference. And so it's kind of just building up this public body of work and using that to leverage into more and more things. And so now I'm at a spot where everybody in our little community, everybody knows that I do these certain things and they reach out to me for these certain opportunities, and they just know me as the guy who does this. Are there other people that do it? Absolutely. I'm just really out in public. And so everybody thinks, oh, he must know what he's talking about, which, you know, to some extent I do, but I'm just also the most vocal about it.

Neha:  I had a similar journey, actually. So, you know, I am a self-taught programmer and I'm going to put myself out there. But like I heard that you could go and travel to conferences and speak and they'll like pay for you to fly over and, like, pay for your hotel. This is when I was on a much more meager salary and I was like “This is amazing, I want to get out there.” But the first few places that I was applying to, no one really knew who I was. And so and they didn't know how to decipher my application from anyone else's. And so I had to also write a blog post back then that like, you have to put yourself out there. And so I started to put my opinions out there and I started to put some blog posts out there. It was on a simpler, simple Tumblr, like it wasn't even out in the open or on Twitter. I was too scared at that time to go on Twitter, but I put it out there and so I was able to link to that post when I applied to those conferences and say like, “Hey, this is like, these are my full thoughts on this, and I've already written a blog post on it.” And it gives you that credibility. First of all, I got a confidence boost out of doing it, but also it gave you that credibility to decipher your application from the other ones out there.

Aaron: You kind of have to think about it from the point of view of the organizer, right? The organizers is wading through all of these probably well thought out CFPs. But you are hedging the organizers’ risk if you can show them that you've already done something. Because every time the organizer chooses a person, they're kind of putting their stamp of approval on it and taking a risk to say, “I chose this person to speak at my conference” and they want as much evidence as possible that you're going to do a good job. And so I think putting something out there publicly speaks to your ability.

Neha:  And I think what a lot of people may not know until you go to the other side as a maintainer, as a manager, or as a conference organizer, is that you have a bit of a risk budget where you want to take a chance on two or three people that you've never met before. And I think it's so easy to feel like there's this glass ceiling where you can't ever get to the other side. But there is a risk budget that everyone wants to spend on someone that they feel really excited about. And that's the person that if you want to spend a little bit more time with, they could have that big break. And so putting yourself out there does that. So I wanted to ask you, you said that you had this big turning point in 2021. Did you have luck coming your way?

Aaron: Big time. Absolutely. Yeah. So I started, you know, like all of us, I'm sure we were always tinkering on projects. So it's never been an issue of “Do I have anything to say?” It's always been an issue of not saying it, right? So I just took the projects I was already working on and started talking about them a lot, and that is what led to this first open source library that landed me, you know, the conference talk a year later, is I was on Twitter and I saw someone explaining a problem that they were having. And I thought, oh, this library that I haven't written yet, but I think could be cool, this library could solve that problem. And so I tweeted back at him and it was like, “Hey, if you do this and this and this and this, you know, complicated thing with these buzzwords, I think you could solve it.” And he responded and said, “Dude, I have no idea what you just said.” And I was like, “Oh, okay. Like, I'm I'm recognizing now that I am steeped in this very technical solution that everyone else is not thinking about. And so maybe I should write a library that makes it super simple for people to do this.” And that's what I did. And so just by being on Twitter, talking to this guy about how he could potentially solve it and him say, “Bro, I got no idea what you're talking about,” I thought, “Okay, this is an opportunity for me.” And so, like I said, I got the meetup, I got the conference talk, I got a new job. I started working at Tuple because the CEO tweeted and said, “Are you a developer that makes things that other developers find interesting?” And I was like, “Yeah, I kind of am. I could do that.” And so, you know, I instead of instead of like responding online and saying, “Yes, I am, please hire me,” I just made a simple like markdown page and put it on my website and said, “I think I am that person, here are the things I've done.” Again, back to the body of work publicly available. Here are the articles I've written that got to the front page of Hacker News. Here's a random shed that I built in my back yard that people on Twitter are loving. Here's a bunch of robots that I made one time. And I sent it to him and he was like, “Great, this guy can build stuff.” And so I got hired and that's how I got my my job at Tuple was by linking back to this trail of online detritus, all of this stuff that I had done and I derisked myself for the CEO because he looked at it and said, “Yeah, he can do it. He would just have to do it for us” instead of like looking at me and saying, “I wonder if he can do the job.” It was just a mere question of “Can he do it for us?”

Martin: Yeah, it's only I, you know, I've got my job just like both of you, the job I have now is from putting myself out there and publishing things and then reached out to somebody who just happened to have seen the work that I'd done and realized I knew what I was talking about. So it’s also amazing as a as a hiring manager, the types of roles you're doing. Like if somebody comes to me and they show me evidence of them building community, of them going out there creating content, then it's a no brainer for me because just like Neha was saying, I have a risk pool of people I want to gamble on. And if you show me you are being out there and being proactive and I'm like, okay, let's go for it. Let's do it. So seeing where you were in 2020 while in middle of the pandemic, like, you know, sat at home and like kind of didn't have anything else to but to post on Twitter and do open source. What tips do you have now for kind of, you know, how to get started, how to you know it's because like you say, you can't just say “get over it.” So what what could they do? What could they be at that first step to get started in in creating some luck for themselves.

Aaron: Yeah. I would say, again, the first step is decide what you want. So the first step is the hardest step in in all of existence. You gotta decide what you want. And if you don't want to be a person sharing stuff publicly and trying to do conferences, great. Don't do it and don't feel guilty that you're not doing it. That's terrific. If you do decide that this is kind of a path you want to go down, I would say a couple of things. One is you need to realize, probably by being a part of the audience of this podcast, you need to realize that you know a ton of stuff. And I think people get to the point where they forget what it's like to be a beginner or they forget what it's like to be an intermediate. And so now they're a senior and think, “I don't have anything to share” when really there is a whole trail of people behind you just desperate to learn. Then the question is, how do you do it and not be afraid? I would investigate the fear that you may potentially have and see if it's worth hanging on to. And then just real practically solve a problem. Start with a specific pain point that a community is having and solve it better than anyone else could. Put in way too much effort. And then that is going to start catching on and you can snowball from there.

Martin: Aaron Francis, marketing engineer at Tuple, thanks so much for chatting with us here today. You can read more about Aaron's story, his tools for creating more luck and how to reach out to him on github.com/readme. Thank you, Aaron.

Aaron: Thank you. 

Neha:  That's it for this episode of the ReadME podcast. Thanks so much to this month's guests, Aaron Francis, Cassidy Williams,and Brian Douglas, a.k.a. bdougie. And thanks to you for listening. Join us each month for a new episode. And if you're a fan of the show, you can find more episodes wherever you get your podcasts. Make sure to subscribe, rate, and review. Or drop us a note at [email protected]. You can also learn more about all that we do at GitHub by heading to github.com/readme.

[CLOSING CREDITS]

GitHub’s The ReadME podcast is hosted by Neha Batra and Martin Woodward. Stories for this episode were reported by senior editors Klint Finley and Mike Melanson. Audio production and editing by Reasonable Volume. Original theme music composed by Zander Seng. Executive producers for the ReadME Project and The ReadME Podcast are Rob Mapp, Melissa Beiser, and Virginia Bryant. Please visit github.com/readme for more community driven articles and stories. Join us again next month and Let's Build from Here.

 Aaron: Whoo! That's fun.