Build your own luck

September 21, 2022

I was a guest on the GitHub ReadME Podcast to talk about how I built my own luck by publishing my work.
Learn more about this show →

Transcript

Martin
00:00:02 – 00:00:07
So, Neha, I've got a question for you. Yeah. How do you spot a functional programmer?
Neha
00:00:08 – 00:00:10
I don't know how.
Martin
00:00:10 – 00:00:19
Don't worry. They'll tell you. I'm Martin Woodard from the GitHub developer relations team.
Neha
00:00:19 – 00:00:23
And I'm Neha Batra. I lead GitHub's community engineering team.
Martin
00:00:26 – 00:00:35
This is the Read Me Podcast, a show dedicated to the topics, trends, stories, and culture in in and around the developer community on GitHub.
Neha
00:00:35 – 00:00:58
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's centered on an interview with a notable maintainer or developer. And we're still gonna keep those interviews going, but we're also gonna bring you the latest stories, expert advice, and information you need to know about the culture of software development.
Martin
00:00:59 – 00:01:27
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 your questions submitted to us through the hashtag ask RMP. We'll also talk to the reebly project senior editor, Clint Findlay, about functional programming and take a look at the value of taking risks and publishing your work with Aaron Francis.
Neha
00:01:29 – 00:01:38
Each month, we'll explore a bit of tech history that may surprise you or come in handy during your next trivia night. A segment we're calling 1st Commit.
Speaker 3
00:01:44 – 00:02:02
On the mark, get set. We're riding on the internet, cyberspace, set free. Hello, virtual reality. Interactive appetite searching for a website, a window to the world got to get online. Take the spin now you're in with the techno set, you're going surfing on the Internet.
Neha
00:02:04 – 00:02:09
It's already September. What? It can't begin to process how fast this year is flying by.
Martin
00:02:09 – 00:02:13
Yeah. I know. It's crazy, isn't it? I'd say, what's going on?
Neha
00:02:13 – 00:02:18
If it's any consolation, it's kind of been September for almost 30 years now, depending on how you count.
Martin
00:02:19 – 00:02:27
30 years. That's actually that's when I started college, thereabouts. I started college in, like, 94 was when I first started university.
Neha
00:02:27 – 00:02:34
Wait. That's so interesting because back before 1990 4, one of the main ways people access the Internet was through colleges and universities.
Martin
00:02:35 – 00:02:44
Yep. I remember it well. Yeah. We now logging on to Pine, then you're trying to figure out your way around, and it was just an absolute nightmare trying to understand what was happening.
Neha
00:02:45 – 00:02:59
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
00:03:00 – 00:03:10
Yeah. That's true. Especially on the older, NNTP groups and things, and they were always asked the same old same old questions. I didn't realize I was that annoying freshman at the time, but there we go, I suppose.
Neha
00:03:10 – 00:03:14
Well, do you remember turning into the curmudgeonly person and that would say, read the manual?
Martin
00:03:15 – 00:03:19
Well, I didn't say read the manual. I thought I interspersed a couple of extra words in there, but, yep, definitely.
Neha
00:03:20 – 00:03:22
Read the adjective manual.
Martin
00:03:22 – 00:03:28
Read the Gopher site is what we used to say. Yeah. Exactly. Go go check out this Gopher page. This is pre worldwide webs.
Neha
00:03:29 – 00:03:45
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
00:03:45 – 00:04:23
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. 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.
Martin
00:04:24 – 00:04:38
Clint Finley, senior editor for GitHub's The Veeami 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, Clint.
Speaker 4
00:04:38 – 00:04:40
Yeah. Thanks so much for having me.
Martin
00:04:40 – 00:04:57
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 it 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?
Speaker 4
00:04:58 – 00:05:40
So I think that, like, 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're 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. Input goes into the pedal and an output comes out. It's always if the sound is exactly the same going in, the sound is always gonna be exactly the same coming out.
Speaker 4
00:05:40 – 00:06:06
And the parameters of a of a stompbox can't alter the parameters of another stompbox. You can wire a whole bunch of them together to make really complex sounds. But each one, if you turn up the gain on 1, it's not gonna 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.
Speaker 4
00:06:06 – 00:06:26
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 you start thinking about immutable data and not just changing a variable or or something like that of, like, creating a whole new variable, creating a whole new array each time you wanna alter something.
Martin
00:06:27 – 00:06:55
I mean, you know, functional programming has been around for a while. It's definitely was around when I was kinda learning to code and stuff. And when I had to make that switch from kind of procedural to object orientated and functionals around and, you know, things like Haskell and f sharp 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?
Martin
00:06:55 – 00:06:57
What is it?
Speaker 4
00:06:57 – 00:07:29
Yeah. So like you said, it it goes back all the way to the 19 fifties 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 for quite some time because it made some of the 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 through objects.
Speaker 4
00:07:29 – 00:08:23
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 has been answered to help with 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.
Speaker 4
00:08:23 – 00:09:07
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 cache because these these big kind of, thought leader companies were 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.
Speaker 4
00:09:08 – 00:10:00
The React ecosystem, I think is, is really interesting because like I said earlier, the the learning 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 backdoor. And so people are sort of learning to do certain elements of of functional programming, especially now that React functions, which is a fairly new feature, is available in the the mainline React. So most of the people I talked to would would not call React a functional programming, framework or system, but we'd call it functional adjacent, in essence. You know, a huge number of, front end developers are using React as a UI library.
Speaker 4
00:10:00 – 00:10:12
It's the most popular front end UI library out there. So it's, kind of teaching a whole new generation, a whole big group of people to to start thinking about programming in a different way.
Neha
00:10:13 – 00:10:30
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?
Speaker 4
00:10:30 – 00:11:02
I think the big thing that people talk about is essentially fewer bugs in their in their code. So it means doing a little bit more work upfront to write the code in in a proper way, but then it means less debugging later. So people can spend more time working on the parts of the, of the code that they really want to be working on and not writing it really quickly, then going back and having do a lot of, bug fixes. For companies, it means essentially fewer bugs, which means better software, happier customers, less downtime, less risk.
Martin
00:11:03 – 00:11:13
There are people who are avid fans of functional programming, and they're, you know, they'll go out, and they'll they'll sort of sing it from the rooftop. So why do people love love this style of programming so much?
Speaker 4
00:11:14 – 00:11:35
Yeah. Yeah. It's it's sort of like the keto diet where once people start it, then they get really passionate about it. They wanna, you know, tell everybody about it, encourage everybody to to start doing it. And I I think that a lot of that passion just stems from it 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 to be working on.
Speaker 4
00:11:35 – 00:11:48
So you can be thinking more about the code and 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.
Speaker 5
00:11:48 – 00:12:12
1st, 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.
Speaker 5
00:12:13 – 00:12:50
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
00:12:55 – 00:13:05
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?
Speaker 4
00:13:06 – 00:13:22
Yeah. So there was a really good conversation about this article on Hacker News. And one of the 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?
Speaker 4
00:13:22 – 00:13:52
Does that create, performance bottlenecks? And it seems like the consensus is essentially no. That's not really a concern because the once the code, the functional code is compiled down to assembly or bytecode or c or or some other language, it it becomes a lot more efficient. It's it's maybe is mutating data at that point, but it's sort of outside the realm of where human error usually occurs. So there there's less concern about the mutability when at that level post compiling.
Speaker 4
00:13:52 – 00:14:12
There's can be performance problems though as 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 is really, I think, a big challenge for functional programming. And again, Cassidy pointed out some of these challenges that come from functional programming.
Speaker 5
00:14:14 – 00:14:47
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 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 you can do stuff with functional programming, but the usefulness plateaus a little bit.
Martin
00:14:50 – 00:14:51
Do you
Neha
00:14:51 – 00:15:02
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?
Speaker 4
00:15:03 – 00:15:43
Yeah. I 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 I think a lot of the the best uses, are really computationally complex problems where, you know, 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 could try it out and then, you know, have some evidence to bring to, to management that maybe it might be worth moving forward, doing more functional programming for, for kind of greenfield development for new features and that sort of thing in the future.
Martin
00:15:44 – 00:16:13
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 and allowed us to use the right tool for the job. By going out there and using functional programming techniques, we expand the the tools we have.
Martin
00:16:13 – 00:16:42
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 gonna benefit you. And then you can just, you know, jump in and and 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, Clint.
Speaker 4
00:16:42 – 00:16:43
Thanks, Thanks again for having me.
Martin
00:16:43 – 00:16:51
Clint Finley, senior editor of the Remi project. Thanks for chatting. And, before you go, do you wanna give us a preview of some of the latest stuff the team's working on?
Speaker 4
00:16:52 – 00:17:16
Sure. So we have a bunch of interesting stuff coming up. 1st 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.
Speaker 4
00:17:16 – 00:17:53
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 2 parts of the application development life cycle 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.
Speaker 4
00:17:54 – 00:18:11
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 readmeproject@github.com/readme.
Neha
00:18:17 – 00:18:23
As part of the community building process, we wanna make sure we're answering specific questions that you bring to us.
Speaker 6
00:18:23 – 00:18:24
I have a question.
Martin
00:18:25 – 00:18:27
Mhmm. Oh, yeah.
Neha
00:18:28 – 00:18:46
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. Mister Brian Douglas.
Neha
00:18:46 – 00:18:52
We know him as B. Dougie. Here's his advice on pitfalls to look out for when you venture into the open source world.
Speaker 7
00:18:53 – 00:19:15
My recommendation is having enough information in the read me. That's gonna 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 it 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 as they're using the project.
Speaker 7
00:19:15 – 00:19:39
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 wanna have synchronous communication or async communication, make that very clear in your project. So if you're using GitHub discussions, add a welcome discussion.
Speaker 7
00:19:39 – 00:20:02
And more than just the intro welcome discussion when you open up discussions in your project, but, like, sort of a breadcrumbs. Like, these are the types of discussions we're looking to have here. And if you have synchronous communication, so if that happens in the chat, like Discord or Slack, provide a link on getting there. A lot of people have these Discord servers, but they forget to link that somewhere publicly. So be clear on where communication happens and how to find it.
Speaker 7
00:20:02 – 00:20:21
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 bread crumbs on how people can find documentation on getting started or answering quick questions.
Martin
00:20:24 – 00:20:30
As colleagues, we're sad to see Brian leave, but he's staying close to the GitHub community with his new venture.
Speaker 7
00:20:31 – 00:21:05
It's been such a joy hanging out with you on the Readme podcast, and I'm sad to say that I'm actually gonna be leaving, as host. I'm gonna be taking some time to work on my side project that I've been working on for the longest time called Open Sauced, which is a pathway to your next open source contribution. And I'm just super passionate about not only hearing the stories and and sharing the stories, but also finding new stories. And that's what Open Sauced is gonna be doing, is finding new contributors to join open sourced and projects across all of GitHub. And be sure to check me out, all things B Ducky on the Internet, as well as opensauce.pizza.
Speaker 7
00:21:06 – 00:21:09
Looking forward to sharing more of what's in store.
Neha
00:21:12 – 00:21:46
Do you have a burning question about open source software development or GitHub? Share it on social using the hashtag askrmp, that's a s k r m p. We might be able to answer it in the next episode. One thing we wanna 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.
Neha
00:21:46 – 00:21:49
So today, we're joined by Aaron Francis, marketing engineer at Tuple.
Aaron
00:21:50 – 00:22:20
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, like, 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 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.
Aaron
00:22:20 – 00:22:25
I'm just gonna start sharing so much on Twitter, which is primarily where I share.
Martin
00:22:27 – 00:22:56
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 others achieve, but 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 that attitude around and is feeling luckier than he 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.
Martin
00:22:56 – 00:23:00
One big piece of advice he has, don't be afraid to publish.
Neha
00:23:02 – 00:23:22
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 am really bubbling about this. I've been wondering, like, what are the experiences in your career, right, especially with respect to putting yourself out there that have shaped where you are today.
Aaron
00:23:22 – 00:23:53
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 2 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 I've, 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.
Aaron
00:23:54 – 00:24:15
And I thought, okay, well, I can't decide I'm just gonna be the bitter old grumpy programmer. I'm gonna start putting myself out there. I'm gonna get over this fear of people, you know, nitpicking the stuff that I do, and I'm just gonna start sharing because I want to be a part of this community. That's kinda what it felt like. I felt like I was on the outskirts of the community.
Aaron
00:24:16 – 00:24:26
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
00:24:27 – 00:24:54
So, you know, as an engineer, publishing stuff is one of the scariest things ever, and it it kinda makes you very vulnerable to do that. Every team I've worked with and I've worked with a bunch of teams who are kind of getting ready to release their code as open source and things like that, or even inner source. And they always wanna refactor a bunch of things first before they publish. And there's always, like, a bunch of, you know, stuff. Isn't this it's just this emotional hurdle you've gotta get over.
Martin
00:24:54 – 00:25:05
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
00:25:05 – 00:25:36
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 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.
Aaron
00:25:36 – 00:25:59
So, I think the upside is unknowable. You put something out there and you never know who's gonna see it, who's gonna use it, who's gonna 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.
Aaron
00:25:59 – 00:26:15
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?
Aaron
00:26:15 – 00:26:36
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 wanna work really hard during the day and close your computer at night, great. Do that. So it's not a one size fits all.
Aaron
00:26:36 – 00:26:45
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
00:26:46 – 00:26:57
So it's not just publishing stuff out there, but then recognizing and capturing that look. So how do you go about doing that? How do you go about, you know, recognizing and capturing when you've got a hit, when you've been lucky?
Aaron
00:26:59 – 00:27:12
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?
Aaron
00:27:12 – 00:27:24
Totally possible. Probably works. Maybe. I don't know. You could go to a meetup, 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.
Aaron
00:27:24 – 00:27:35
This was really great. Thanks for making this. It kinda builds on itself in in a Snowball y way. Right? So the way that I started is I wrote this open source library, and I was tweeting about it.
Aaron
00:27:35 – 00:27:47
And then a PHP meetup was like, hey. I saw you tweeting about this. Do you wanna 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.
Aaron
00:27:47 – 00:28:01
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 wanna speak at this conference. And they're like, yeah. That sounds good.
Aaron
00:28:01 – 00:28:27
And there were 2,000 people online for that conference. And so it's kinda 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.
Aaron
00:28:28 – 00:28:36
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
00:28:37 – 00:28:56
I had a similar journey, actually. So, you know, I, I'm a self taught programmer, and I'm gonna 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 wanna get out there.
Neha
00:28:56 – 00:29:17
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 I had also read 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.
Neha
00:29:17 – 00:29:35
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 like already written a blog post on it. And it gives you that credibility.
Neha
00:29:35 – 00:29:42
First of all, I got a confidence boost set of doing it, but also it gave you that credibility to decipher your application from the other ones out there.
Aaron
00:29:43 – 00:30:13
You kinda have to think about it from the point of view of the organizer. Right? The organizer is is wading through all of these probably well thought out CFPs, but you are hedging the organizer's 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 gonna do a good job. And so I think putting something out there publicly speaks to your ability.
Neha
00:30:14 – 00:30:48
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 wanna take a chance on 2 or 3 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 wanna 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.
Neha
00:30:48 – 00:30:50
Did you have luck coming your way?
Aaron
00:30:51 – 00:31:03
Big time. Absolutely. Yeah. So I started I've you know, like all of us, I'm sure, we we're always tinkering on projects. So it's never been an issue of, do I have anything to say?
Aaron
00:31:03 – 00:31:31
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 was like, hey.
Aaron
00:31:31 – 00:31:58
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.
Aaron
00:31:59 – 00:32:14
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.
Aaron
00:32:14 – 00:32:33
I started working at Twupil because the CEO tweeted and said, are you a developer that makes things that other developers find interesting? And I was like, yeah. I I kinda am. I could do that. And so, you know, I, instead of instead of, like, responding online and saying, yes, I am.
Aaron
00:32:33 – 00:32:52
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 backyard that people on Twitter are loving.
Aaron
00:32:52 – 00:33:12
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 Tupelo 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.
Aaron
00:33:12 – 00:33:19
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
Martin
00:33:20 – 00:33:36
it for us? Yeah. Totally. 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.
Martin
00:33:36 – 00:34:00
So, and it's also amazing as a as a hiring manager of 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, they aim them. It's a no brainer for me because just like Neha was saying, I have a risk budget of people I wanna gamble on. And, if you show me you you are being out there and being proactive, and I'm like, okay. Let's go for it.
Martin
00:34:00 – 00:34:23
Let's let's do it. So seeing where you were in 2021, middle of the pandemic, like, you know, sat at home and, like, kinda didn't have anything else to but to post on Twitter and do open source. What do you what tips do you have now for kinda, you know, how to get started? How to you know, if that because like you say, you can't just say get over it. So what what could they do?
Martin
00:34:23 – 00:34:28
What could they be at their first step to get started in in in creating some look for themselves?
Aaron
00:34:29 – 00:34:42
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.
Aaron
00:34:43 – 00:35:14
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.
Aaron
00:35:14 – 00:35:47
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 gonna start catching on, and you can snowball from there.
Martin
00:35:47 – 00:35:59
Aaron Francis, marketing engineer at Tupelo. Thanks so much for chatting with us here today. You can read more about Aaron's story, his tools for creating more look, and how to reach out to him on github.com/readme. Thank you, Aaron.
Aaron
00:35:59 – 00:36:00
Thank you.
Neha
00:36:07 – 00:36:36
That's it for this episode of the Read Me Podcast. Thanks so much to this month's guests, 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 the readmeproject@github.com. You can also learn more about all that we do at GitHub by heading to github
Speaker 6
00:36:45 – 00:37:08
Github's the Read Me podcast is hosted by Neha Batra and Martin Woodward. Stories for this episode were reported by senior editors Clint Finley and Mike Melanson. Audio production and editing by reasonable volume. Original theme music composed by Xander Singh. Executive producers for the Read Me Project and the Read Me Podcast are Rob Mapp, Melissa Beiser, and Virginia Bryant.
Speaker 6
00:37:08 – 00:37:16
Please visit github.com/readme for more community driven articles and stories. Join us again next month, and let's build from here.
Aaron
00:37:21 – 00:37:22
That was fun.
Me

Thanks for reading! My name is Aaron and I write, make videos, and generally try really hard.

If you ever have any questions or want to chat, I'm always on Twitter.

You can find me on YouTube on my personal channel or the Try Hard Studios channel.

If you love podcasts, I got you covered. You can listen to me on Mostly Technical.