Ep. #100, Non-code Contributions with Ramón Huidobro of Suborbital

Brian Douglas: Welcome to another installment of JAMStack Radio. On the line we've got Ramon Huidobro. Welcome, Ramon.

Ramon Huidobro: Thank you very much, Brian. I'm so excited to be here. Did I see correctly in the show notes, this is episode 100?

Brian: This is actually episode 100, yeah.

Ramon: Wow.

Brian: So congratulations, you have made it.

Ramon: What an honor.

Brian: We have arrived.

Ramon: How exciting.

Brian: I invited you on because I actually heard you on another podcast and I was like, "Ah."

I heard about that thing you were talking about, you were talking about open source, so I wanted to have you come on and talk about non code contributions in open source. But first, could you introduce yourself, tell us who Ramon is and how you got here?

Ramon: Yeah, sure. My name is Ramon. I am a Developer Relations Engineer at Suborbital, it's my third week there. I'm doing lots of WebAssembly stuff and my aim is to advocate for WebAssembly.

I got started as a software engineering freelancer, I'm based in Vienna in Austria, originally from Chile. Very, very quickly into my career I started discovering meetups and that sort of thing. Mind you, this was, I wouldn't say I'm old, but I'm not young anymore.

So this is back in like 2014 that I started discovering meetups and I fell in love with how passionate and caring communities, tech communities are, how empowering it is to have folks get together and help each other learn, help each other grow as engineers, as people as well.

I just instantly wanted to get into that so I started helping organize, give talks at the meetups, then I started going to conferences, then I started speaking at conferences and it kind of snowballed from there into me starting out as a Developer Advocate last year at CodeSee.

Brian: I'm a big fan of meetups as well, as we were before officially starting the podcast, we both spent time in Tampa. My first introduction was actually at the Tampa Ruby Brigade actually.

Ramon: No way. Funny you should mention that, because my first meetup was the Vienna.RB meetup, Vienna Ruby and I'm still organizing that to this day.

Brian: Oh wow. That's awesome. I love folks who take the initiative and lead community as well, because sometimes the hardest part is having to be the person to actually get stuff started, and folks who can actually... Because maybe the hardest thing when I was running meetups was finding speakers.

I could speak every week, but I always want to make space for other folks. It's part of the reason why I do Devrail myself, because by my statement that I always make is, "If you want to be a good advocate you've got to make other advocates."

So basically find other folks who would love to do that thing or, as you mentioned also, I can't remember if it was before we hit record or not, but you also help teach people how to do public speaking as well.

So I don't do it officially, but I'm always mentoring folks and trying to get people to come up and take advantage of the opportunity because there's tons of people who just haven't made the leap or the jump into what we do for our day jobs.

Ramon: Absolutely, because you see that spark, you see that interest and you want to impart the joy of it.

I love that you used that word because mentorship is such a big part of helping folks grow in their careers and become... The same way that ones self, they fell in love with that community, with community in general, it's the same thing.

You want to do your part to help folks thrive and stick around, just like those communities helped introduce you, by turn, introduce others. It's very joyous.

Brian: Yeah, yeah. For sure. Then what brings me to the part of the conversation I wanted to swing into is open source, what's your background in open source and what got you interested?

Ramon: Yeah. That's what the topic that we've got today is about, because my background in open source was through non code contributions so that would be, as the term would say, contributions that don't involve writing code.

What that involves I can get into a little bit with my story and so what happened was, when I was going to these meetups, this was at a time that initiatives like Rails Girls were at their highest, which are workshops to help get women and other underrepresented folks get into coding.

Through doing those workshops and mentoring at them and having a great time, I found an organization called Rails Girls Summer of Code which is kind of like the Google Summer of Code if you're familiar with it.

The Rails Girls Summer of Code itself was a crowdfunded organization that helped under represented folks get into code so we would do a bunch of crowd funding and get folks to apply to do open source for a summer. It was life changing for me, to be able to not only help make that happen, but also talk to these people and see them. I did this for so long that those folks are still around in tech today and they're thriving and it's tremendously empowering.

The Summer of Code itself was an open source organization so there were apps, there were Rails apps that were open source and I would do some contributions there.

But most of it from my side came from doing things like helping organize things, help run meetings, keep notes for the app itself, do things like issue triage, that is making sure that issues are being handled or following up with folks who have gotten an issue assigned to them but perhaps haven't followed up with a pull request yet.

Stuff like this. Advocacy, I was out there, especially later on with other stuff I worked on.

Another organization that I joined is Distribute Aid which is an organization, I think it's the largest organization for grassroots supply chain for humanitarian aid in the world, operating mainly in the US, Europe and Lebanon.

My job there is to create awareness through developer advocacy for this open source organization which was kind of a revelation, because I started doing this job last year and I never thought that Devrail was something you could do as open source as well.

Brian: Yeah. It's the one thing that I constantly talk to folks about because I spend a lot of time talking to open source maintainers in projects we've all heard of.

There is constant push for folks to get green squares on GitHub and push code, but there's never enough people to do all the other things.

So if it's like triage issues or test and release or write a little bit of documentation that would help onboard new folks.

Whether it's a contributing MD or it's a setup or a script to... Not even a script, just like, "Hey, these are the things you need to know to be successful at this project."

A lot of time that stuff is getting missed because when I work on a new project I know how it all works because I built the thing.

Most times I forget to write things down, until someone comes through and says, "Hey, I tried using this thing and nothing's written down."

Either that person's going to walk away and never use the thing again or they'll help out and write stuff down. I guess my question to you is how do you convince people to do the non code contributions?

Ramon: It's hard, and you nailed it there, Brian. Because there is that push for GitHub squares as you called them, but getting a streak out of that for non code contributions for that is a little trickier.

So I can tell you that what worked for me to get started in that, and that was to help make me feel... Believe it or not I'm a shy person, so one of the reasons I didn't get started with open source coding itself was Imposter Syndrome for sure.

I was like, "What if I make this PR and it's totally rubbish and people tell me I'm horrible and tell me to go away or something?" They never do that, but there's still that fear, you know?

By being able to do something that I know I can do, which is help out, advocate, help write documentation, you were talking about this really well as well, help with the onboarding process.

I had an interesting situation actually this week or last week where somebody came onto an open source project and they said, "NPM, Run, Start doesn't work."

And it was because in the documentation we left out the part where it says, "Do NPM install." Because it's so taken for granted as a step, but for folks who are interested in getting the app up and running and perhaps don't have that... It's not even like a technical problem, I'm talking a background in NPM, in the JavaScript ecosystem.

It's something that you forget and you take for granted, so that perspective is so valuable.

Brian: Yeah, even something as simple as having the $ sign before NPM, that sometimes can be taken for granted because a lot of times people get hung up.

I actually had that in some of my documentation for how to use something, and another more senior engineer than myself just politely raised a question of like, "Sometimes people will copy and paste all that, it's actually better not to have the $ sign, even though the $ sign is pretty common inside of Unix systems." So actually that makes a lot of sense.

I've done that myself where I copy and paste the whole thing and then I put the $ sign and then I'm like, "Oh, it didn't work." And not knowing, reading the message, I spend way more time googling why it didn't work as opposed to look at the error message right in front of me.

But anyway, regardless, it could've been solved without having the $ sign in the documentation.

Ramon: And that's it, it's those things that you get used to them and you just think, "Ah, a $ sign, I'm not going to copy that."

But especially if you've got stuff like those fancy copy buttons that copy the whole thing in markdown, then it sneaks in and it's this sort of thing.

So by doing stuff like noticing these things, helping out with documentation, putting in pull requests, helping to establish procedures can be so important for things like communication, like contribution guidelines.

Brian: Yeah, those are super helpful. It's a given that some projects have them, but not all projects are created equally, literally sometimes it's a side project someone did over the weekend.

I just built a side project a couple weeks ago and have not shipped any code to it since because I don't have time to go back to it, but it's not really well documented.

I don't talk about it because I know that it's not well documented. It's more of like I wanted to scratch an itch, I shipped it, it lives, and one day I'll go back and write documentation or what's going to happen is someone will knock on my door and be like, "Hey, I found this thing you built. Can I improve it?"

And I'll be like, "Actually, yes. Here are the 10 things I would love to have in this project. Just do one of them and then that will encourage me to do another one."

Ramon: Absolutely. And that creates a bit of a momentum that then turns into... And you can totally upgrade from non code, upgrade if you can call it that.

Go from non code contributions to those contributions. For me it's a nice way to get into a project, maybe you see, for example, that a bunch of issues are open, you could just follow up on some of them, help triage those issues.

We were talking about meetups, you can totally organize meetups around those projects.

Especially the larger ones that need that advocacy. I forgot how they put it, but essentially what you're doing is promoting their project. They're not going to hate that.

Brian: No, and that's the one thing. I always celebrate one of my previous guests, but I consider a friend, Anthony, AJCWebDev on GitHub.

One of his biggest things is he goes through each project, if he hears something on NPM or something's trending on GitHub, he goes and tries it out and then writes a blog post about it.

Ramon: Love that.

Brian: So it's a series that he says, "It's a first look, and then enter the technology." And he's not building anything to become famous or get lots of stars, he's just more donating his time in a blog post to an experience.

That way folks, if you're looking for the first look for needs or the first look for React18, you're going to find one of his blog posts because he just makes it his thing that, "I'm going to test out all the stuff and see if there are any corner cases, edge stings, or just missing documentation, just document that in a blog post."

Then if he has time or someone else has time they can do a follow up on that, but at least he knows he's going to look at every single new open source project and release as they come out.

Ramon: I love what you touched upon there because it goes into lending one's own skills as well, right?

So Anthony, for example, since they enjoy all the writing the blog posts, totally, what works for you can also totally be applied as a non code contribution. For example from me last year, I discovered that I was pretty okay at livestreaming, right?

So what I started doing with Distribute Aid every week, for example, was just getting together on livestream every week and just coding on stuff.

Talking out loud, talking with Tailor, the head there, and just going through issues, creating issues, encouraging folks like, "Hey, we've just made an issue. Totally go ahead and claim it."

So there was some coding but a lot of it is also non coding, it's spreading some awareness. That was all sponsored by CodeSee, which was awesome. Super cool of them to be able to do that.

Brian: Yeah, and you actually spent some time working at CodeSee. We talked about it before I hit record, but I would love for you to share about the jobshare idea that you had because I think that's a pretty clever way to break into Devrail but can you explain your time at CodeSee, what CodeSee is and then how your role worked?

Ramon: Yeah, that was a tremendous kindness done to me by my friend Jessica who is just amazing.

She came up to me one day and just said, "Hey, I've got this idea for doing something." She has loads of experience in Devrail and she approached me one day and said, "Hey, do you want to do this jobshare thing where we would split a full-time employment between the two of us, essentially."

So we both would do part-time and fulfill one role, and the objective there was for her to supervise me as I learned and I grew as a Devrail, and I got to shadow her as she did things like strategizing, creating goals, determining metrics, come up with campaigns and that sort of thing.

I would help out and then I grew into that role where I became Head of Open Source at CodeSee, where my role was to help leverage CodeSee's code understanding tools to help open source projects thrive.

Then through Distribute Aid I then started doing things related to... Because thinking about me and that shyness I mentioned previously, how could I help tear down that barrier of open source? That's my fear as well.

So one thing we did was we had a livestream show where every week we would bring on a new guest, they were maintainers of open source projects and the aim of the show was to just onboard me onto it, live.

Brian: Nice.

Ramon: Zero looking at the code, zero experience necessary in that programming language and just go at it.

By every one of them, I'm happy to say we had a pull request. It was just a ton of fun and it really helped eliminate some of that fear for me, and I hope for viewers as well.

I wrote programming languages I've never written in my life like Go and Python and stuff, it was a blast.

Brian: Yeah, I was doing something very similar. Not so much get to a pull request, but I was doing a meeting with open source maintainers. We called it Open Source Friday which was very tongue in cheek because it's an existing term.

But I had the maintainer of NextJS walk me through how testing works and how deploys work whenever they deploy NPM.

It was mainly my goal I was doing for that is I wanted to get the hairiest problem, stuff that the context inside documentation was always lost and this showed me it because if I can have a senior engineer or someone else who knows the code better than me then I'm going to be unstuck quicker.

But the combination of getting to write a pull request, and I'm familiar with CodeSee's products too as well.

It's a really, really good way to, one, advocate for a product. But also, two, to advocate for new developers in open source.

Ramon: Absolutely. Because I think one of the most important things to get right there and to make sure that you've got those contributors coming back is that onboarding process.

It's making sure, especially as projects grow and you're not as available as I would love to say, to be able to do things like one on one onboarding sessions with a new contributor.

If I had a new project now I would be very happy to have folks come on and just be like, "Hey, do you want to just pair on this?" I feel like especially showing that that's something that you can have in your project and then let it spread from there to other maintainers I think is something that's so vital to make sure that an open source project thrives.

That's what I liked about doing the livestreaming because it was regular, but it also fit into that, "Let's just show you how we work."

Something I find that's super important about livestreaming itself, is that it kind of starts going into is this a code or a non code contribution?

I think showcasing the fact that as a senior developer we don't have all the answers right off the top of our heads, so livestreaming is great because it eliminates all possibility of, "Let me just edit this video real quick and Google something."

You've got to be there, you get stuck and you're like, "All right, let me open the web pack configuration and see what's going on here." It's great.

Brian: Yeah, and honestly what I like about it... I also livestream, consistently, just on my own side project which is Open Sauce.

The focus, whenever I get stuck, it's always, "Let me just drop the question in chat and as I'm googling, other people are googling with me."

And then what usually happens, someone is like, "Hey, here's a link. Here's a Stack Overflow question." I'm like, "Ah, cool. Let's open up, let's get her."

Ramon: And that's it, if you think about it, that's kind of an online ensemble programming environment, what you've got there.

If you're not familiar with the term, it's like pair programming where you've got a driver and a navigator, but with an ensemble with you of folks who are, like you said, googling stuff, giving out suggestions.

That's another way, by the way, that you can do a non code contribution, by facilitating events like these.

That's how I got into Distribute Aid, by helping them facilitate this event, and with very little experience in the codebase, I was able to get in and have folks who had never written TypeScript before.

Again, there's something about that collaborative aspect that I find so magical, that folks can... They'll be hesitant at first, it's like, "Oh, I've never done TypeScript."

It's like, "It's fine, we'll do it together. We'll look up stuff together, we'll get stuck together and it's totally fine." It's super fun.

Brian: Are you still doing livestreaming, live coding at the moment?

Ramon: I was. Actually Jessica and I just wrapped up a six week free bootcamp where we were livestreaming lessons.

Brian: Oh yeah, I heard about this.

Ramon: So we're resting off of that. I think it ended two weeks ago, and so we were doing lots of livestreaming then and I loved it.

Let me tell you, speaking of getting stuck, because when you're helping folks learn to code from very relatively beginner levels, a lot of the things that we take for granted today, it's like, "Oh yeah, getting stuck is fine, it's no problem."

Or not fully understanding JavaScript promises, it's no problem, it's fine.

But when you're starting out and you're getting through lessons and they're like, "Ah, one of the things that you're going to be learning about is JavaScript lessons."

And if you find yourself not rocking that fully, a lot of learners would come to me and be like, "Recursion hasn't clicked yet and I don't feel like I can do this."

And that's tremendously disheartening for them, but also I don't know if distressing is the right word. It hurts, it hurts my heart to see that folks are getting frustrated by things that, again, we take for granted after a few years of experience.

My point of my complete ramble there was that during one of the lessons, like we were doing one of the JavaScript exercises on Free Code Camp together, and one of them was a very complicated, manipulating JavaScript objects exercises and I got so stuck on that.

Each lesson was 60 minutes long and I spent 20 minutes of it on this exercise, and I was crying inside. I was like, "Oh my gosh, I can't do this."

And I'm trying not to look at the chat in case people are going to be like, "Come on, just do this, or just do that." But I did solve it in the end, and we moved on.

But for the next week after that I got so many DMs from people being like, "Ramon, kudos for getting over that exercise. It looked hard. Thank you so much for this, because it showed me that senior developers get stuck too and it showed a real life situation of getting frustrated, of googling stuff."

It felt like one of those moments, those big career moments where you're like, "Wow."

Brian: Yeah. You started off this conversation like, "The Imposter Syndrome, and even shyness."

You obviously can turn it on and turn it off because we're having a conversation, and I feel like the shyness is not really relevant or prevalent or Imposter Syndrome to here.

But in reality it's like someone just needs to know that they can do it, and I think a lot of time with things like Rails Girls, the reason why those organizations exist because you want to see people that look like you, that can help mentor and promote you, show you the path and the way.

And if you don't feel like you belong, you won't belong, you won't join yourself in this group, which is why it's so powerful for things like non code contributions, but also even organizations to make that path. That way people can find their way.

So if your introduction to open source is, "You know what? All I do is just make sure the thing installs. I just install stuff and then I walk away. That's my job."

And sometimes that's a really good way to start, by just seeing if you can clone the repo and get it to run locally on your machine. If your machine melts, apologies if it's one of my repos. But if it does melt or if it doesn't run, then that's a really good problem solve.

Going back into code contributions, when folks are looking for issues, and a lot of the feedback during Hacktober Fest and during Christmas and the Advent of Code, it was like, "Ah, there's no good first issues."

Well, if you want a good first issue, sometimes you've got to open your own issues too. So the step one could just literally be install it locally, see what's broken, if it's broken, open up an issue.

Then what I usually do is I show you exactly what code to write and what to do, because I know what's wrong because I wrote it. But if you would be willing to take this on, you've got a mentor for as long as you want to hangout in this project.

Sometimes that could be an opportunity for folks to continue to level up, which I had mentors, you had mentors, the first step is basically taking the first step.

Which is an ironic way to put it, but that's how I'm going to make that statement.

Ramon: And I think that's extremely correct and powerful. I think by taking that first step, and at the same time for us as maintainers, doing everything we can to make it apparent that we're here for you, where possible, understanding that of course we're human beings and we need to rest, we need to work our day jobs.

But what can we as maintainers do to help facilitate and encourage those contributions? Be it code or non code.

For example, one thing I'm doing at Distribute Aid at the moment is working on our website, which podcast name, is a Gatsby website.

What can we do to encourage and help with those non code contributions?

So we installed a headless CMS as one of our jobs. I find this interesting because I hope that there isn't, but just in case there is, there might be a connotation of the fact that a non code contribution might be, "Easier."

You can't see it in the audio, but I'm using quote marks with my hands. It might be "easier" to do or less work to do non code contributions, but I think it's an absolutely vital part to the livelihood of a project. What we, as tech contributors, can do to help facilitate that...

For example, installing a headless CMS so that changes don't have to made by hopping into an MDX file or something, but instead logging into the CMS and having that do the GitHub stuff for you.

Setting that up is also something incredibly important and empowering for folks to be able to join in, and eventually get curious and be like, "All right, but how do I customize the CMS? Or how do I change the color of the header?"And then use that as an entryway.

Brian: Yeah, yeah. Sometimes these good for interactions in issues, they're breadcrumbs left by the maintainers, either intentional or non intentionally to have the on ramp into making the contribution.

At the moment I've made some trivial changes to the project I work on, and then sometimes I'm just like, "You know what? This one, it's not critical path, I could actually let this sit for a bit."

So I may actually write exactly what I would do, open up that issue and just let it sit there until someone discovers it and is like, "Hey, I found an issue that no one's claimed." I'm like, "Yes. Please claim it and then ask questions."

And I've been able to grow my community in a way that... Organically people cycle off as you get new jobs and you have family stuff, totally understandable, but I always have something for someone to come to in the event that I do have a new contributor or potential interest come through.

Which I wanted to ask you, where is a place that folks can find projects to contribute to, that are looking for contribution? Especially even non code contributions?

Ramon: Yeah. Working on that visibility was actually something that I was doing at CodeSee, which was working on a place where maintainers could present the onboarding process of their projects.

We were working on something called OSS Port. It's still being worked on, I think there's a revamp coming which I'm super excited about.

But there's a whole plethora of other places like Open Sauce, for example, right? Where folks can come in and find, and level up their open source contributions.

GitHub as well, GitHub has their Explore tab which has a whole bunch of places where you can look for projects to contribute too.

But a lot of the time, the way I find projects is by, of course this was easier when you could do so in person more readily, was just talking to folks, going out, expanding your network and seeing what's needed.

Jessica introduced us to Distribute Aid, and so I got to know them and by being able to do my part in facilitating humanitarian aid, there's that activism aspect to it that I thought, "Okay, I'll do what I can here."

And a lot of it was learning, a lot of learning before I started humanitarian aid, it was something that I was pretty ignorant about.

So it's taking a bit of a leap of faith as well. When I dived into Rails Girls I was like, "Well, as a white cis man myself, I've got to do what I can to make tech more inclusive and approachable," so I started volunteering there and it's spiraled from there.

So at the risk of sounding cheesy, follow your heart as well, follow what is important to you. If it's work that's meaningful to you, do it and find what you can.

Brian: Yeah, it's quite possible if you're not enjoying it, it's going to be harder to do and harder to wake up to.

Which, at that point, probably find something you do enjoy. So if it's not writing code, non code contributions is a thing.

But if it's going outside and leveraging code on your drone or on your tablet or whatever it is, there also so many different ways to get involved. Ramon, thanks so much for the conversation.

Ramon: Yeah, thank you.

Brian: I did want to transition to picks, but I just want to shout out to folks, we have so many links and stuff like that.

Definitely find the show notes at Heavybit.com, you'll find JAMStack Radio and you can find links there, but also reach out.

I'm super impressed with your background, Ramon. Hopefully folks can find you and have the conversation, even connect to some of the organizations you're a part of.

Ramon: Yeah, totally. In fact, I love meeting folks, it's one of my selfish joys in tech. So please feel free to reach out.

Brian: Cool. Speaking of reaching out we're going to transition to picks, so these are JAM picks, things that we're jamming on.

Could be music, food, technology related, there's no real limit. It's just something that you're interested in that you want to share with the audience.

So you've actually come prepared with picks so do you want to go first?

Ramon: The first is I want to do a cheeky plug for the Distribute Aid organization.

If what I've talked about sounds interesting to you and you'd like to contribute, I've put a link to the Donate page in the show notes, DistributeAid.org/Donate, be it financial or code, you'll find an open collective as well. Absolutely feel free to join in and help out.

My other pick is a little less serious, I wanted to give a quick shoutout to an open source plugin I've found for OBS.

If you're not familiar with OBS, it's Open Broadcasting Software which is used by a lot of livestreamers out there.

One of the things I found pretty interesting early on was a lack of support for automatic live captioning, and inclusivity is probably implied as something pretty important to me, so there's this really easy plug and play captioning plugin that let's you do open and closed captions.

I learned the difference between those, I don't know if you've heard of this.

Brian: Yeah, I actually went down the rabbit hole on captioning as well in OBS.

Ramon: No way.

Brian: I checked, I actually already started this repo, so I definitely have tried this out.

Ramon: Awesome. Yeah, it's super helpful. If you're doing OBS stuff, absolutely check it out. But I got to have something also, so I'm going to go ahead and pick a board game, if I may?

Brian: Please, yeah. I've been getting into a lot of boardgames the last couple years.

Ramon: Same here, with everything being so remote. A friend of my very kindly started... There's this game on Steam called Tabletop Simulator which has allowed her to introduce me to a bunch of boardgames.

She introduced me to a very chill game called Azul, that's Portuguese/Spanish for blue, A-Z-U-L. That's fun, it reminds me of these Match 3 computer games.

Super chill to play with friends and let's you have a cup of tea and just talk about stuff while you play it. So that's my, I apologize, not very short picks.

Brian: Yeah, yeah. I guess I'll add it as a pick, but I got into Skull, which is a very simple card game.

They call them tokens, but it was like a pirate game hundreds of years ago and it got resurgence 100 years ago.

Yeah, I was playing online with a couple other GitHub employees as an icebreaker, hangout, have a meal together and play a game. I loved it so much I bought the actual in person, IRL version.

But yeah, I've gotten really into online gaming through the pandemic and trying to connect with friends and stuff like that.

So Skull is my first pick. My second pick, actually I just got a new grill, which is the Kamado Joe, and that is...

I actually have not used it, but I feel like I actually have used it because I've watched so many videos on it.

I had the benefit of moving further into the suburbs of Oakland so I have a backyard now, so I am 100% doing Dadlife, American-Style, I'm going to be barbecuing this weekend. Last pick I alluded to, I built the project and I haven't touched it in weeks, but it's SocialCarding.com.

I always try to look at my social cards for all the sites I build and make sure there something, if I put it on Twitter it has a nice image.

I also like to test other people's social cards to see what they have, and just know how to organize mine to make sure it looks proper.

So in order to test that I usually go to like Socialcardpreview.twitter.co or whatever, and I'm like, "It'd be cool if I had my own, where I can put a URL in there and then download the image in case I needed it."

Because a couple of times, you actually need that image, save it for something else.

But Socialcarding.com and all you do, it's just a simple... At this point it's in NextApp but I might rewrite it into something faster and simpler like Eleventy or something.

But you just add a URL, it'll present you your social card if it exists and you have the choice to download it, so pretty simplistic but I'm really, really into simple ideas right now that solve simple problems.

Because I don't want to maintain something longstanding forever, but this thing I could just throw out there for anybody.

So if anybody is really good at design and wants to tell me how to make this look a little nicer, all I have is a form and a title, I could use help on trying to figure out how would you approach to make this a more pleasing and aesthetically pleasing, simple form to look at.

Ramon: This is so helpful. Thanks, Brian. I had no idea I needed this.

Brian: Yeah. We made social cards at GitHub. We, I tested it, the engineer that made it, I was testing it for him. As I was testing it I was like, "It'd be cool if I could not try to figure out what the Twitter URL is to try to figure out how to test these."

My other testing platform would go to Slack and send the message to myself, and see what the preview looks like, just to see if it was working.

Ramon: I've done that.

Brian: So now I have an entire site dedicated to testing social cards, so you gotta scratch your own itches, people.

Ramon: Yeah. We're our own best customers, in a way.

Brian: Yeah, indeed. Yeah. We have a very powerful skill, which is writing code. It's either going to be for sites like this, or it's going to be something else random to figure out if you can buy, what is it?

Turnips on Sundays in Animal Crossing? That was a big deal, early pandemic. Tons of sites like that.

Ramon, thanks so much for coming and chatting about contributing to open source and all the things you're involved in.

Ramon: Thank you.

Brian: And listeners, keep spreading the JAM.