Subscribe
Share
Share
Embed
In our latest podcast episode, we spoke with Erika Heidi, who recently started at SourceGraph as a Developer Advocate. Erika, an open-source guru, and technical writer turned developer relations expert, made a great guest for our Open-Source October celebration. We dived into all things open-source, including how to get started if you're a new developer, the benefits of contributing, and how to navigate tricky situations.
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
If the camera wasn't so far away, I turn and show you, but there's a wall of 3D printers next to me.
Oh, nice.
So very cool.
That's very cool.
Alright.
See if my creaky chair will settle down.
Sorry I changed chairs.
It's horrible.
Just double checking my microphone actually works now.
Alright.
Yeah.
Cool.
Sounds good.
I think it stopped for a minute, so I'm back.
Yeah.
Hello.
Alright, cool.
All right.
Welcome back to API Intersection Podcast.
We are here today with Erica Heidi, freshly starting at Source Graph but has more history tour.
My co host again is Phil from a stop light who handles a lot of our Dev Rel stuff.
I'm Jason CTO at Stoplight and your only persistent host, Heidi.
I guess I probably did a bad job introducing you there, but tell us a little bit more about yourself.
Hi, everyone.
Erica, Heidi, and I'm studying a new job as developer advocate, source graph.
But previously I worked as a technical writer at Digital Ocean.
So maybe you read one of my tutorials there.
And yes, I have content spread all over the internet because I really like to write and create stuff.
Content and cold.
Got it.
We haven't chatted that long before and so now I have to ask because I'm like the total geek about picking apart people's like accents and stuff.
I am Brazilian.
So your Portuguese.
Okay.
Yes.
That's what I thought.
That was my first guess.
Alright, cool.
I used to do Jesse for a long time and tried to learn Portuguese for a while, but I don't know.
already.
So off I got so confused with Spanish.
It's too similar, you know.
Yes.
They're very similar.
Some things are very similar.
Yep.
I know.
Alright.
So Erica, I think one of the more interesting bits of kind of your profile and background.
I think there's two components.
Yeah.
One is you're pretty active in the open source world and two is you're kind of coming into this Devora thing from the tech writing side of things.
Well, open source for me, it started as kind of dream, like with Linux and stuff, and that never seemed that it would become so big.
Like it is today when I started using open source.
Then after I moved to the Netherlands from Brazil and had more contact with the community that opened many doors for me.
And I started getting more involved and contributing.
And so I have special place in my heart for offices always because it gave me more confidence.
It helped me anyway.
So I really enjoy that about tech writing.
Should I continue? You didn't add that yet, actually.
Sure.
Yeah.
Yeah.
I laid a fork in the road there.
I probably should have picked one.
So sorry.
Yeah.
It's because it ends up being quite connected.
When you write code, then you have to explain how to use your code and such not just plain documentation, but also tutorials.
And that one thing leads to the other and also developer relations also comes in the mix with the contact you have with the community and how all the contributing and conferences and it's all connected.
I think somehow.
yeah.
I mean, you start kind of releasing code and send in pull requests and interact with other people on those pull requests and issues and stuff, and you just get chatting to people a whole bunch, and then you get randomly invited to conferences where you meet more people and end up interacting with them.
It's just kind of a whole community thing just in a few different forums.
Yes.
Yes, definitely.
Yeah.
I think that for me has definitely been one of the magical things about kind of the explosion open source over the last ten years or so.
The first decade of my career was all like Microsoft related stuff first and kind of network administration and even desktop support, kind of stuff with a lot of Windows and all that.
And then it's like got into dot net thing actually before dot net, it was just PB script, but did all that like dot net stuff for years and it was like you just felt kind of like not connected to anyone.
It was like you just did what Microsoft told you was good, right? Or ignore it sometimes because you knew it wasn't good.
But I feel like when kind of Microsoft opened up to open source is great, but I already kind of jumped over to Java and some other things, but I think that's really the part that a lot of people don't grasp is you're plugging into a community of people driven by passion.
I'm having issue the audio.
I can't hear you.
Okay, you can't hear me.
I can a Jason.
Okay.
Okay.
I can hear you.
Eric, you need to check your stuff there.
Okay.
It's probably my phone.
Okay.
sorry.
I don't know what happened.
Oh, yeah.
I've had trouble with Bluetooth jumping between phone and computer.
When I'm doing this sort of stuff, just turn Bluetooth off on your phone to stop at hijacking.
Yeah.
This is not working.
Let's see.
Here.
Testing.
Okay.
Testing.
I'm gonna have to switch.
Got a backup.
Yeah.
Can't go wrong with hardware.
Okay.
Okay.
Hello.
I can hear you again.
Yes.
Hello.
Can you hear? Okay.
Very.
Awesome.
Alright, great.
Alright.
I'll just start over on that bit and shorten it up.
Anyways, I was Rampling.
Okay.
He was saying some terrible things about you while you were going as well.
Yeah.
Totally.
Yeah.
I think for me coming out of the Microsoft world where for years, things were very closed off.
And I certainly kind of switched over into PHP and Java and some things.
But you realize that one of the big, powerful things about open source is lots of just passionate people doing something they think is cool, right? As opposed to, like, it's a job task per se.
Yeah.
And I get from you that like, this kind of making connections, building your network.
That's been a significant portion beyond just kind of the what is it that you're building, right.
Yes.
I'm sorry.
The phone just.
Yes.
Okay.
Yeah.
It switches again.
So the audio is coming out of the phone.
That's okay.
Don't worry about it.
And stress.
I turned off now get technologies.
That's why we have Editors.
They can just fix it in post.
Okay.
No worries.
Yeah.
I was just saying that the open source stuff is kind of giving us all a better connection to community.
yes, definitely.
And I also think that it's a good place for fun projects, just sharing.
I think most of my projects are very experimental and I don't intend them to be kind of famous or become used by millions of people.
That's not my intention.
I really want to share a bit of fun things and things that you could do, little tricks and things that I found out along the way.
And then I like to share that and give a chance to people to also experiment with something different, because we already have a lot of serious projects and big frameworks and things like that.
And there is also a space for some fun.
And let's say I like to say indie projects and things like that more not so mainstream.
Yeah.
Yeah.
I mean, looking through your Twitter or through your GitHub kind of seems like top project is this Dina cover thing, which looks like a lot of fun.
Yeah.
I was looking at the repos and I saw the Daisy thing first, and I was like, oh, no.
What all four obscure stuff have you been forced to do at work that led you to write a GD image wrapper in PHP? And then I know it was kind of a dependency of the diner cover things.
Okay.
Yes.
Is that how it started? You like, working on this fun thing and you're like, this is kind of hard to do, and then you end up just spitting that off.
Yes.
Exactly.
There's a lot of my projects that stuff like that.
And then I realized that it's being kind of a pain in the ass to keep all everything come together.
So I kind of break them down so it's just easier to reuse.
Usually it's because I made something and it's really cool part of it I could use in another project, and I see how I could use this.
Definitely.
And then I have to break it down.
Otherwise going to be really difficult.
So yeah, I moved to Gas so I can create some templates.
Dream idea was to have a JSON file and say, I want to build this kind of generator cover image for my post, for instance, in my blog.
we can.
And then I just generate PNG based on the title and something else.
So that was the main, the initial idea.
And then with the Twitter thing, I saw someone that did a version of it and in another language, and I was like, oh, my gosh, I have to do this in PHP.
It's like, just perfect.
And I do all sorts of crazy things.
Phv.
Sorry, but one that I really like is called Mini leaf.
Okay.
It connects to the Nano lips panels that I have.
And I do this with PHP, and because it's often an API, so it has an open API running, so I can just some requests and control my lights via PHP code.
nice.
Luckily, my camera frame is relatively tight and you can't see that there's, like cables and Arduinos and Raspberry piling all over the table over there.
that's cool.
I empathize with your weakness on hardware IoT stuff.
Yes.
That's a lot of fun.
So looking through this is kind of first stop it open source October, right.
This is part of the reason we want to dig into this and think about it.
And I guess I'm curious in contributing to open source stuff.
Obviously, some of your projects you've had contributors, you've probably contributed to things that aren't your repos.
You know, how all that works for you.
Yeah.
And kind of what have you learned in that process of how to get stuff accepted? Things like that.
So my first request was actually kind of unexpectedly to framework, and I didn't want to start as big, but I just found this little issue with Ever message that was not clear enough.
I think my memory doesn't fail me.
It was in a file upload component on Symphony, and actually, I was using Silex.
It's a smaller subset micro framework based on those components.
But the the problem was in a component in the Symphony repository.
So I had to make up a request for that.
And it was terrified.
Really.
I knew how to push code to GitHub at that point, but I never have done a pull request before and going throughout the process.
I really know how to rebate or like which branches should target.
So I was very confused.
And I actually I created, like, three or four per request different because I opened the first.
And then there was this huge thing of, like, thousands of files.
And that was what I mean.
I just changed it on file, but I think, of course, I did it for the OneBridge.
So it was awful.
And then I closed that one and I opened another one.
So it was a mess.
But then finally I got it.
And then I got a response from Fabian Potential, and he gave me a suggestion.
And then I learned a lot from that because I also didn't a way to do that.
It was to change something for a static variable.
And then I change that.
And then he approved it.
And I was like, a shell like, oh, my gosh.
I got an approval, and I was like, very excited.
So it wasn't really I forgot that excitement.
And wow.
But then he said, you have to rebate on Master or something on another branch.
And I was like, oh, my God, no.
Yes.
Everything is good, but you have to rebate.
So yeah, it was probably my first, my first rebates ever.
No.
It was messy, but I could make it work.
So I made it work and then it was merged and my name was in the contributors.
So it was really nice.
So after that, after that, I wasn't so scared anymore because I thought, well, if I went through that, then I can definitely contribute more.
That's awesome.
And also, I don't need to be that scary because now you got a free code review from some really cool people, really awesome developers.
And it's a really good opportunity.
Right.
So yes, it's very nice.
Yup.
Yes.
That's great.
It's good that Fabian was giving you the right words so that you could at least Google stuff.
I think that's kind of an important step because quite often people they're kind of snotty developer that's just do this and they'll say things like, can you tidy up that history? I don't know what that means.
Yes.
And you like, Google it now you're like, that's something.
But if you are kind of very specific about it.
Hey, would you mind doing a get rebase if you're not sure how that works here's a tutorial or that extra little bit of effort dealing with contributor means that you don't make them feel like rubbish, and they might come back and do more pull requests, which ultimately is less work that you need to do.
Yes.
Theoretically.
But either way, you get to make someone like, grow as a person instead of making them feel terrible.
So I'm wondering if you bumped into many of those people that kind of a bit snotty or rude in doing open source.
Well, my personal experience was good.
I didn't have any really bad experience in open source, but I saw orders.
I saw some bad maintainers and giving bad replies to other people that can also scare you a little bit.
Like what I have.
What if it happens with me? Right.
But I was lucky.
And there is I think one time that a few times, not just one time that I got rejected for some reason.
Of course, that happens.
But nothing really bad happened.
I had more like bad experiences in comments, just blog posts and tutorials and things where people can leave comments.
And that is that is for sure.
And also on talk feedback that can be given anonymously.
Yeah.
Turn those off.
Also, these kinds of things.
I got my share of feedback, but actually on Office source.
I had a good run so far.
I am I feel a bit scared of, like when a project gets bigger.
The tendency is that you attract some bad actors.
Please.
But I hope if that happens in the future, that I know how to deal with it because I've seen others.
And then I know that's just a very small portion of people.
And then I have friends that can have my back because also in this comment, sometimes I share something, a comment, a bad comment on read, and then all my friends go there and just have my back.
That happened on YouTube already on.
I think with some people talking about my accent complaining about my accent or something.
And then so my friends come in, you know, so it's good.
Yes.
Well, I for one, love the sound of Brazilian Portuguese and the related accent.
Thank you.
So you have a fan here.
I'm curious.
Coming from kind of tech writing background.
Well, I I did mostly tutorials, like not not documentation.
Most of my experience is in writing tutorials, but I did some contribution to Love Dogs.
It was small, but it was something that also I appreciated how open they were to some changes.
I hope I had more time previously to contribute more.
But yes, that one was about language.
They have really good dogs, but sometimes out of trying to sympathize with the reader.
If we end up kind of creating a barrier because we say that something is easy, for instance, or this is a really easy thing to do.
And maybe that's not the experience.
That's a judgment.
And that was what I suggested to change, and they accepted the change.
I don't remember which page if it was, I think it was something in Eloquence.
So yeah, one day I want to have the time to go and help more of these projects that I love, and I would like to help more.
Well, I've talked to some people who seem like a little intimidated brother process of contributing and feeling like, well, maybe I'll waste my time and I always tell people in stuff that you use.
There's always something wrong.
You got to use some library or some command line thing and something doesn't work out of the box.
Like, contribute documentation.
Those things get accepted, like of the time.
As long as you're actually accurate and you're pointing out a problem, it's like that's probably like I've got repos for all over the place in my GitHub, and probably half of it is just little Doc tweaks where I'm like, that didn't work.
That was broken.
yes.
And I see issues and threads on stack overflow.
And it's like, just go make the little tweak and help everybody out.
And to your point, it gets you into that rhythm of what do I need to do as a contributor.
So.
That was definitely a thing I used to worry about in PHP and open source land was that there were so many kind of clones of other projects, like, clearly someone looked at a package and then just went like, oh, I don't like this.
Okay.
I'm going to make my own, which is basically the same thing, but I'm going to change this one more thing.
Yeah.
And now everyone has to maintain more of those packages, and none of them really leveled up to the point where they could have reached.
We had, like, 200 routing libraries.
Like, how many different ways can you possibly handle routing to a controller? There's really not that much.
She.
And the thing I love the most about open source, I think, is where people kind of come together and all spend a little bit of time making something excellent instead of everyone wasting loads of time making lots of things aren't very good.
Yeah.
Well, okay.
Yeah.
I didn't have a question at the end of that.
That was just a statement.
I get that point.
But also at the same time, I also really like the freedom that exists in open source that you can go and create your version or it's something if you are not satisfied with what exists.
And yeah, there are two sides of it.
There is also this problem of having a really a lot of libraries and you don't know which one to choose when you are using.
Yeah.
You just want to.
But I also worry about the overly dependency, depending on too many too much becoming kind of a nod thing that's like I recently just installed one little package.
I just went in one thing that was a requirement.
I think it was when I was getting tailing ready.
I don't know, remember a plug in or something.
Bye.
But then suddenly a thousand packages were installed through NPM.
So I was like, oh my gosh.
Now all of a sudden I depend on 1000 packages.
Is that right? So modern development is getting to your appointment.
It's a bit complicated, right? You are always depending on more and more and more packages.
So if anything goes wrong in any of those, then you don't know what happens to your project or application.
It's complicated.
It can be overwhelming, too.
Sometimes I just like to go back to basics, and that's why I like to do a lot of things on the common line because it's more like less stuff to worry about and like no front end.
Okay.
So it's kind of so refreshing to just run a command and just have things Don yes, easily.
that's great.
Well, I'm not big on GitHub actions yet, but I want to learn more about them.
I got a book from Michael Hip.
It's a really interesting book about GitHub actions and totally recommend.
Yeah, but I have only basic stuff because I don't have that volume of contributions yet.
At least my process are very small.
I usually just have the basic, like a random PHP.
74 PHP maybe and run the test and just basics.
another significant aspect of kind of maintaining open source stuff, like beyond technical contribution.
I kind of got used to working in cycles, so I will be kind of away for a few months sometimes and then I go back.
I know it's not the best maybe for most projects and most people, but that's how I found it.
It works for me because it keeps me interested.
I usually go through a kind of spring, so I have an idea for the project and then we release a new version.
Then I go and I work weeks and after hours and I do all these things and I do the release and then I kind of slow down and just take some time off of that project and then at some point then I have another idea or I need for something else.
I need a new feature and then I will go back to it.
So that's how usually I work, because my process are really side projects that are supposed to be fun and hobby things.
So that's how I deal with them.
I can totally see that for some people.
If you have a serious project, you should probably be more frequent.
A frequency is important if you have a project that is used by many people and many people depend on it, and it's a big responsibility as well.
So yeah, don't do as I do.
But yeah, I mean to keep it fresh and fun, you know.
Yeah.
I think some of that's perfectly normal, right? Especially.
Yeah.
Yeah.
I mean, especially for open source stuff that it's not part of your day job, right? This is stuff that you're working on out of your own interest and passion.
yes.
Because it's never going to end.
You know, there's always new things that I kind of felt really in the past I felt really more kind of an anxiety around finishing features all the time and getting this new thing out.
meeting.
Or I have a new idea and I have to implement it now and I have to improve it, make it perfect.
And I moved away from these thoughts.
Let's see, since a few years ago, I think after my daughter was born and I took things more, I had a different perspective on things maybe.
So I really take my time and I do what I can because these are not my day job.
These projects are not, but on my job.
So I just take them as a hobby and really way too channel some creativity in some creative energy on them and also learn new things experiments.
So yes, I am taking them very like that literally.
And also I like to use these projects as a way to write, like a tutorial on how to do that.
Yeah.
I usually tie them with a tutorial that I published on to, for instance.
And there is also a challenge on making something that is usable and also making something that is kind of simple enough.
There's a small scope enough that you can write a tutorial about it and that people can actually build their own version of it.
That's what I usually like this option that people can also build one the same.
There is some day in a conference that I have imagined this idea.
It would be fun, you know, how when you're kidding, there's this magazines that you like do your own DIY stuff and has some things and you assemble.
So you buy kids or something.
So I wouldn't that for doctor somehow, and I didn't.
I didn't have any breakthrough ideas on how to do that in no way.
That is attractive.
But I like to think that when I'm creating a project for it and write a tutorial about it, then I think about it like it's like a DIY, and people are going to follow these, and I have to give them all their needs first, and then they can follow and they have the same result at the end.
So that's my dream go and I write things.
Well, what I love out of that is that this kind of clearly you have some maker culture in you.
It kind of sounds like IoT.
And notice in your profile we had some mentions of 3D printing and stuff like that.
so.
And I'm very much the same way.
I feel like I learn a lot about what makes making something exciting from working with physical things.
When you come back to software, they're portable lessons.
Like even you said earlier, your heads down, you're getting this feature out.
And with maybe an IoT project that's like getting this next thing working for me.
I'm trying to get my home assistant server to connect to a smart switch that I set up to turn on my pool pump.
I don't need to do that.
It would be fine if it didn't connect.
I should probably stop.
But it's fun.
And I want to know whether or not it's on, even though it's on a timer and whatever.
It's just satisfying.
But when I'm done with that, I probably won't look at any of that stuff again for a couple of months because I'll be a little sick of it by ten.
And I feel like we talk about this like a stop light with work all the time.
It's like you've been on this big push to push out some big, cool new thing.
yes.
And like, you kind of need time to just tidy up the shop a little bit.
Perfect.
Sometimes it's just, you know, touch up some bugs and address them tech.
That stuff just I call it like the ginger to the sushi moment, right? You just had a great buffet, like how to cleanse the palette.
Relax for a minute.
So I love those kinds of making things.
There are portable lessons that work across tech software and even just good old physical stuff, too.
So I love that.
All right.
So, Erica, I think we've covered the game up pretty good here on Open Source, and even to some extent, I think you did a great job at touching on where this kind of tech writing background feeds into it and how you think about it.
I guess when you're for listeners who maybe haven't done as much in the open source world, maybe they've been in a big company where it's just not a thing they're not hearing about it.
Or maybe folks coming right out of school or something who were just not sure how to get started.
Like, you know, any kind of roll up advice here that you would give to folks on how to get more engaged in the open source world.
yes.
So I'd say it's nice to find a project that you use or that you like probably in a language that I feel comfortable because then you feel more confident about that.
It can be documentation.
It can be something that you use.
And then you contribute a portion of the documentation on details, how to use a specific feature that it's really hard for Montanus to document everything.
Sometimes it's just like a new you add a new option, just a little on the code.
It's easy to implement.
But when you're going to write about it and you have other considerations, then you have to change the structure of the documentation.
And then there's a lot of stuff.
So you can really help with documentation of something that you've been using and you know how to use can explain that.
Also, don't be afraid.
And I would say check the project for the issues and other pull requests that were made before to see if the people the maintainers are friendly, because of course, you don't want to go in any project that you're going to have a bad experience, right? You're going to have to choose wisely, I think.
And now with hectograph at this period of the year, it's really good because there's a lot of repositories with tagging issues with good first issues.
So you can look for that tag on GitHub and then you find some is is there are more beginner friendly.
Also check for like contributing do.
If the repository has a contributing MD, that usually means at least they put together some document with some instructions and guidelines on how to contribute.
That's important, because maybe like you have to create a pull request to a certain branch, then you have to see which branch you should work with and the standards they use.
So that's important also to check, but ultimately just find something that you have fun doing that would make things easier.
And also you may try to reach out to the to the people, to the maintainers beforehand before you start writing the code.
Even you know, it's good to have some contact and ask more clarity or more details.
Or if you have an idea, then as if this is what they are thinking, you know, you don't want to do work, then submit a pull request and then it be rejected that nobody wants to do that.
And maintainer is also don't want you to lose your time.
So it's good that you have this communication going to make sure you are on the same path of the maintainers.
So I think that's pretty much all.
I know it's great advice.
I tell people all the time.
Yeah.
Like for me, open source projects are just like another product to be managed in a way and maintainers.
I think there's this notion that like open source projects are built by this big anonymous army of contributors.
Yeah.
And that's just not how it works in real life.
Thank you.
There's usually a more core group that's interested in a topic and those maintainers once you're a maintainer, you realize you have to make choices.
Yeah.
You have to have a vision for the thing that you're doing.
And sometimes contributions just don't fit.
Right.
And I love your advice to start that conversation early.
Just like if you're at work and writing code, you wouldn't just go write something because it's seems cool.
You have a discussion to make sure it's really solving a problem.
Right.
So I think that's fantastic advice.
I just want to reinforce the idea of doing open source for your.
Alright, well, any other words of wisdom for us, it feels like a pretty good point to wrap up here.
Some people think that doing open source is kind of like donating something, but that's not really.
It is a two way street.
You are learning a lot and you have the opportunity to navigate a code that maybe you wouldn't have the opportunity if you were just doing.
We all have worked in companies that had a legacy code, and you were excited about a new technology, but you couldn't use that at work, right.
So with open source, you have the chance to work with technology that you may not have the opportunity to work at your job or at home in your site project.
So it gives you a chance to try experiment new things.
Also, learn you can learn a lot by just going through each file and navigating the code and finding out which class relates to, which you know all that stuff.
So it really gives you a really better understanding of how things connect together, because usually some projects have so many different components and are more distributed, so you can see how things connect to each other.
I learned a lot of things by reading the code from Frameworks and like understanding how containers like not documents, but like configuration containers, these kind of patterns that are common controllers and how they do things, how they find things and how each thing communicates with other data is best across components.
So you can learn so much from exploring these projects that are more a bit bigger maybe than you are used to.
So it's a great opportunity, I think.
Yeah.
I love it.
Culture of learning is essential in kind of engineering discipline.
Right.
And for those of you that want to learn more about API stuff, a little plug for stop lights.
Open Source as this month is our October Fest celebration.
Definitely looking for contributions on spectral Prism and Elements are three pillars of open source under stop light.
I don't usually plug stop light stuff, but hey, open source is fair game, right? So don't be scared folks get involved.
Come learn something about how it all works and help us out.
Alright, well with that.
Thanks so much, Erica, for joining.
I think this has been a great kind of fresh.
thanks for having me.
Look at something a little bit different.
And thanks for joining again, Phil.
Bye.
Cheers.
Alright, so that'll be our rep point.
You wake over there, Bailey.
Indeed.