Help Me Help You - How To Ask For Help

Monday. Monday. Monday.

Open wide dev fans, get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest web development treats coming again hot. Here is Wes, Barracuda, Boss, and Scott el Toroloco.

Welcome to Syntex on this Monday hasty treat. Hey. I'm also having that issue.

Famous things that you shouldn't be doing and how to get your help. How to help me help you in GitHub repos.

If you have a bug in a library and you need help, well, we're going to help you understand the best way To get that help, my name is Scott Polinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's going on, my man? Hey. Yes. It's Really funny that I think people, especially people who are new to coding,

don't necessarily know how to ask for help. And, I see this all the time. I'll get an Instagram, like, single view message. So somebody will take a a photo of their, like, laptop, And it's, like, dirty and it's sideways and it's blurry and there's a foot in the background.

And then they allow me to see that photo once, And then it goes away because on Instagram you have to press like whatever. And it's just like there's so much more you can do to get help because certainly Every people who who put this stuff out love to help people, and are willing to help people. But You got to put in a little bit of effort to make make it so that, it's not extra work on our end or just not it possible on our end, you know. So here's some tips that we can use to to get help. Yeah. Yeah. And and likewise, you know, I I think it's One of the bigger sources of burnout for open source

creators is the constant stream of issues into repos And issues or or or ways that you just straight up can't understand or fix the problem yourself. You're saying, I'm frustrated. I need help blah blah blah. Next thing you know, you're submitting an issue on a GitHub thing and and potentially The owner or the maintainers see that and fix it right away. Other times, they might see it and say, alright. Maybe I'll do this later. Or maybe they say, alright. This guy's being a jerk. I'm just going to ignore this. I mean, there's there's so many different ways that that situation can go. So I think the number 1 and probably most annoying as far as things to do as a part of submitting your issues, we get it. You're already frustrated. There's a bug. But the number one thing you need to do when submitting issues, if possible, provide a reproduction.

Now I can understand the pains of, Hey, I have a very specific context in which this is breaking and my code is not open source.

Therefore, it is very difficult for me to create a reproduction of this issue.

That said, most of the time, When you're actually going into the process of creating a reproduction, it can create some illumination into your mind as to what the problem actually is. And sometimes it even fixes the problem because by taking A lot of times it does, I think.

Yeah. By taking The problem out of the context that it exists in and trying to reproduce it in a clean repo of a similar nature, It's very well possible that you will discover that the bug is entirely user error based.

So having a reproduction, Even though it can be annoying, it is one of those most important things if you want to get help with something. Yeah. Us. And at the very least, if you don't have a reproduction,

because sometimes I'd say most of the time, you need to have a reproduction. But sometimes it's simply just a, Hey. Do you notice anything going that I'm doing wrong here? Yeah.

And a screenshot is Sometimes find even better is the GitHub gist where you're just copy pasting the values in there. Because if I can copy paste it and run it through a linter or just paste it into my editor and, like, click a variable and see all the other instances Of the variable highlight and see how the value is sort of traversing through your function.

Sometimes it's so simple like, oh, you totally forgot to destructure The value, right? And that was the variable that you cannot access.

So posting your code so that we can have it right off the bat is is really great, especially, like we'll talk about I guess we can say the next one here is be responsive, is Have that ready by the time you ask it. Like, people tweet me or, do something and they send me a message in Slack or Send me a DM or whatever. And if it's just like, hey. Can you help me? Then I'm sitting there. It's kinda like the high in Slack. You know? Like, What's up? Like, what can I do for you? Hey. And because now I'm sitting here waiting for you to type out your entire string of whatever.

Whereas if you had that all ready to go by the time I get that notification, I can quickly say, okay.

Because sometimes it's honestly it's just like You could be I do this all the time. I struggle on something for hours,

and then I I ask somebody else and they're like, oh, you're a dummy. Is this a 6 minute effects or 2 minute effects? Yeah. You're you're doing something weird here. I I think in order of importance in terms of, like, things that you could have for a reproduction, CS.

The the worst thing you could possibly have would be a screenshot of your code. The next worst would be, I I guess the gist. And then the next best would be an actual repository that you can clone and Try. And then the best, the very best would be something like an online, like a Stackblitz or something where you have your entire application running in a browser window. The code's all there and the error is visible to the library author. You could just click that link.

You can see the error happening in action, and that makes it so much easier to experience the the error. Because Oftentimes, that's like one of the things that in solving bugs in general is just getting somebody else to experience The problem you're having is the biggest barrier for them to understand what the problem is. It used to be

You make a whole GitHub repo with a reproduction and you say, alright. Clone it. NPM install. Blah blah blah blah. But now, honestly, it's amazing. You can give somebody an a entire environment front end and back end. They don't have to set up any weird servers or anything like that, and they can just click the code sandbox, Stackblitz, whatever, And you're up and running. So that's those sort of environments have been a major benefit to, reproducing bugs and getting stuff fixed quicker.

Yeah. That's the ideal. Alright. Another thing you can do here, is like you mentioned it to be responsive, Especially in a chat scenario. If you're in a chat scenario, like you you said, you you post the high and then you wait and all that stuff. Like, that doesn't work.

If you want help and you want help now and you're in a chatroom scenario, make sure that when somebody responds to you asking for clarification or questions, You are there and available to respond because oftentimes, you know, people responding us quickly to a chat or anything like that are just there at the exact right time to see it.

And people are busy. There it's not a help desk. They're not sitting around and waiting for you. Whatever. So if you happen to get somebody's attention, respect their time and respect their attention And be responsive as possible to them or else, you know, if I'm that person trying to help, I'm I'm gonna be bouncing along. I have I have a question for you. Like, let's Say you have an issue

with a library.

I'm thinking about like Cloudflare Worker. I had an issue the other day that I was Working through, and I needed somebody to sort of bounce some ideas and help me with it. Do you what do you where do you go first? Do you try it. Jump in the Discord. Do you try go on Twitter? Do you try go in the GitHub

issues discussions? What's your initial reaction there? Always GitHub issues is for me. I'll go to GitHub issues and start searching. I'm gonna search for I'm I'm not gonna search for things necessarily in my stack trace, but maybe, like, Search for the method that I'm using that's breaking. I'm gonna search for, the maybe, like, if if it's a context thing, like, I'm gonna search for Svelte Or whatever the context is in which I'm using this thing to see if other people are having it. I also was having an issue with a, it's like a webcam library for Rust.

And it turns out it's like an actual bug in the library, but somebody was having the same problem on Linux.

So I was able to go into the issues. I found that Problem even though I'm not on Linux.

And one of the things I have in our list of little helpful to do's here Is to don't do a plus 1. Oh, me too. I'm also having this comment. Yeah. Maintainers hate that. Either leave an emoji or add some context.

So the context I added to that GitHub issue was I'm also seeing this issue only on Mac OS, and then my version number and then posted my stack trace as well. Just so it's not like I'm I'm I'm saying that this is no longer just a Linux issue. This is an issue also on Mac OS as well, adding some context.

I I think you had a really good point there is that you're searching For your issue first, I don't even think we hit that is Mhmm. Sometimes it's a very common thing, and it pops up over and over and over again. And Quite honestly, the AI, like chatbots and everything are making this thing much easier because you might a search for a specific issue and it doesn't a 100% hit the, like, text search overlap, But the AI searches will make that a lot better because it will show similarity of the issue you're having. You don't have to like That's always a frustrating thing is that when you paste this, like, an error in and if the error has specifics about your code, you have to, like, oh, let me genericize this.

Then they make it generic. Yeah. Yeah. But that's a really good point. One interesting thing that I do now too is I'll often paste my function if it's just a function into chat gpt and say, hey, do you notice anything, like, blatantly wrong about this code? And I'm not looking for, like, library issues. I'm looking for Yeah. Things that I might have goofed up that my linter isn't catching for some reason. Next one we have, I think this might be the last one, is be nice.

When you are 3 hours in to a bug, your Irritation level is at an all time high. I've certainly been there myself, and it's incredibly frustrating.

And People let stuff fly by accident or on purpose or for whatever reason. And I think you have to remember, like, Super cool.

Often I have to remind myself that I'm probably doing something stupid here.

So careful because you're gonna have egg on your face when somebody says, okay. The issue was x, y, and z, And it was because you did you did this. Right? And it it's not an issue with the library. It's not an issue with the package or the implementation. And, that's incredibly frustrating because you think, like, how this stupid thing won't work. You know what? Why am I wasting my whole Saturday on this thing? I've gotten plenty of frustrated emails from people who, didn't take a second to ask in the chat Or to to do any debugging, but they just think like they go to 90 on how angry they are. And then I have to be like, hey. Like, a couple times I've had to be like, you have to remember that there's humans on the other end of this thing. Walk. Yeah. Exactly. And it it needs to cool off. Yeah. You know what? It is one of those interesting things. And here's something that you should remind yourself of as a developer.

If you are not able or prepared to attempt to fix the library itself if there is a problem with the library You are just a borrower of someone else's code. Right? Mhmm. And there's no sense in getting upset at somebody else If you're like, if I'm borrowing a jacket from you, and I'm sorry, your stupid jacket doesn't fit right.

Like, that's rude. That's super rude. So, I mean, if you're not, like, willing to be the person to fix the problem or whatever, There's there's no sense in getting angry at somebody else for an effort that they've put forward.

And and so it is it's always most important to think, yes, There is a person on the other end who's not only working on this code, but ultimately not being paid Most likely to work on that code many times or, you know, they're they're doing it for fun or for help of the community.

And you getting angry at somebody is not helping the community.

It's just making your ego feel a little bit better because You you have a a full diaper.

I asked AJ who does the support in my Slack room. He's amazing. He is so good at Putting himself in the context of somebody else. And I asked him, like, what's your pet peeve of, like, when you have it? And he says, my only Pet peeve is vague questions such as I need help, I am stuck with an issue, and my code doesn't work. That's kinda similar to the hi, you know. Totally. They don't provide any context or information as to what the issue is Or with the code, I usually find that I have to ask multiple basic questions such as what the error is, what the code is causing. It can be very repetitive. It's true. It's like, if I have to, like And I think, like, for beginners, sometimes you don't necessarily know what to tell the person. But if I have to keep asking questions and extract Information from you.

It can be a little bit frustrating. So try to provide as as much information as as you possibly can.

He says, in the rare instances where someone provides not only their error, but also a link to the code as well, I almost fall all out of my chair, Which is true, like, somebody has taken it's not common for people to take the extra steps, to get help. And that's that's what this whole podcast is about is take those extra steps to get help because You're going to get better help, and you're going to move along your way, and you're going to be happy in coding much faster. Yeah. Totally.

And just again, be respectful. Be nice.

And also another quick little thing before we head out here is make sure that the error is coming from the Library itself.

Like, if you have you're you're you're using a library, you're using a package or something Mhmm. But the code you're writing, has an issue where you're trying to access a property on something that doesn't exist, and you post that to a GitHub issue and it says, Oh, my my, property doesn't have a or my object doesn't have a property in it.

And then that's taking time out of somebody else's data. Look through this and be like, well, That's not our code. Like, that's clearly some other thing. So that's a a small little bit is make sure that the problem is actually coming From the code of the issue or the discord room or whatever it is that you're trying to get help from. Awesome.

Alright. I think that's it. Anything else to add? Should we wrap it up? Nope. I think that is it. Be cool. Be cool to one another. Alright. Peace. Peace.

Head on over to syntax s.f m for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.