Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:16):
I think everybody would agree that as developers we can't know everything, there's always going to be something that we don't know. And it doesn't necessarily even have to be something new to us or anything like that, but there's such a depth of knowledge. We bump into these things where we don't know the answer to a question that we have. It might be productive for us today to discuss how we would approach that. Because we're all in this predicament from time to time and none of us wants to look like we don't know what we're doing, but there's a balance to be had. Aaron, let me throw it to you, what is your thought process about asking somebody for help?

Aaron Saray (00:56):
Well, first of all I disagree with your premise, sir. That some of us don't know everything.

Joel Clermont (01:00):
Okay, sure.

Aaron Saray (01:03):
Oh, wow. And immediately everyone hates me, all right. I guess it's a mix of trying to move a project forward but also being humble and also trying to understand productivity, also understanding how you learn things. So there's a really complex balance I think that we tend to solve pretty well subconsciously but just like with everything else, if we spend a little bit more time thinking it through it can be even more efficient. I think a lot of times we figure out, like, "Who should I ask this question to?" or, "When should I ask," or whatever, but almost by accident and I think that it's probably worthwhile thinking that through a little bit. So I'll give you an example. If you are newer to a team and you're seeing something weird in the code base, do you ask a question or do you try to google it?
Well, I think the better question to ask yourself is, "Does this seem like it's a language construct or a programming pattern that I don't understand? Or is it a domain level or something in the business that I don't understand?" I've seen a lot of Stack Overflow questions and things like that where people post questions about programming, and it's like, "What are you talking about? All of the answers are in this code that you posted." Really it's some other context that they haven't shared with us that, "Oh, well we have this decision, or this, or whatever." I think that's the first thing I do, is I try to determine if I have a question, is it something that is in the track of you just know more technical knowledge or you know more about your business?

Joel Clermont (02:49):
Yeah, I think that's a good distinction. When I was posing the question about questions, I was actually thinking more just like a pure knowledge question. Like, "How do I do this thing," or, "Why isn't this working?" But really, we run into the other one, the thing you mentioned, just as much if not more. Which is like, "Well, why is it done this way in the code?" Like you mentioned especially when you're newer to a team. I don't think you're going to find an answer to that on Google, right?

Aaron Saray (03:16):
I think when you say, "How do I do this thing?" It still leans a lot towards what I'm talking about. Which is, there might be a way to do this thing but there might be a way to do this thing in this project for certain reasons.

Joel Clermont (03:28):
Yeah. I would like to propose, let's maybe just focus on the purely technical thing. So not necessarily knowledge private to a team where you'd have to get that information. But more like, "Hey, I normally do PHP and I'm doing some JavaScript today. How do I do this thing in JavaScript that I know how to do in PHP?" Something along those lines. Like, something you could find an answer to maybe in Stack Overflow. I've found some benefit, even though it's a little frustrating, in putting in work to try to figure it out on my own to a certain degree before I ask for help. Because if I just ask for help and I get the answer, I find that I don't learn quite as much as if I do my own research or maybe even try a couple things, hit a few dead ends and then ask for help. What is your take on that?

Aaron Saray (04:22):
Well, how do you know then that you're not spending too much time? That you're not just spending up on something for eight hours of researching when you would've asked, "Hey, Joel, how do you copy an object into JavaScript?" And you'd be like, "Oh, it�s simple. Just do this with three dots."

Joel Clermont (04:38):
Right. Generally stuff that's that simple to answer is also pretty simple to google. But maybe the things that are a level one or two up from there, I certainly would not spend eight hours flailing about before I ask for help. But I think for sure, 15 minutes. What I like to do when I ask the question is even to say, "Hey, here are some things I tried. None of this is working, what do you suggest?" That way I kind of show the person I'm asking for help, I tried a little bit and I'm not just leaning on them unnecessarily but I did do a little bit of research on my own too. Without taking the whole day doing that.

Aaron Saray (05:12):
Yeah, I agree. I think that's a good thing to maybe timebox those things in and see if I get stuck on something. Having worked in other teams for quite some time in my career, there's kind of an unknown sort of relationship that develops with people who ask too many questions. Which is like, "Why does this person not just learn what they're doing? Why do they always ask questions? Why do we have to hold their hand? Or whatever. There's this balance that we have between asking too many questions. Versus, where are they? What are they doing? Why do they spend four hours researching eight different things when they could have just asked us in Slack or something?

Joel Clermont (05:53):
Right, yeah. Well, and you kind of get at another thing that might hold somebody back from asking, which is ego, right?

Aaron Saray (06:01):
Mm-hmm (affirmative).

Joel Clermont (06:01):
Or, not wanting to appear incompetent in the job they're hired to do. But personally, I have those inclinations at times but everybody has to ask for help now and then. So as long as you're asking for help and you've done a little bit of work, or if this isn't something you've asked five times before, that might make me question your competence a little bit. But if this is just something new and you're like, "Hey, I tried this, I'm stuck. Can you just point me in the right direction?" Maybe you're not even asking for the answer, but just some input too, I think there's value to that. We talked a little bit what it's like to think about asking a question, let's maybe flip it a little bit now.
Let's put ourselves in the shoes of the person being asked the question. Because I think there's some knowledge we could share here on how to be a good team member when somebody comes to you for help. First of all, a topic I know is near and dear to Aaron's heart is that of empathy. When somebody asks you a question, try not to be annoyed or puzzled like, "Why don't you know that?" There's things we can do even without really intending to put somebody down that can come across that way. I've experienced that and I've been guilty of doing that unintentionally. But I think that's probably a first thing to have in mind when somebody asks you for help. Just realize like, "Hey, it took a little bit of humility for them to ask for help, so don't like stomp on that." Maybe just be empathetic and do your best help.

Aaron Saray (07:34):
I think some of that comes again, with... you talked about ego. It reminds me of a tiny little aside I want to share.

Joel Clermont (07:43):
Okay.

Aaron Saray (07:43):
The year is 2007 and I've been programming PHP for six years and... Yeah, that's a long time ago. I went to ZendCon, which was a big conference that we run by Zend, the PHP company. I thought I knew everything and I was a little let down that they didn't pick me as a speaker. But I was real tough and thought I'm the best programmer ever. I mean, after five or six years you surely can't learn anything new, right? I was in the back sitting by some of the speakers and I looked over and they were having a conversation about programming in C on one of the pickle extensions.
Then I realized I have no idea what they're talking about and suddenly I am not as great as a programmer as I thought I was. And that was a really really important memory that stays in my head, it was really humbling. It's the sort of thing now I like to remember when people ask me questions too. When I'm answering them is, first of all, as much as you know there's always someone who knows more.

Joel Clermont (08:48):
Yeah, absolutely.

Aaron Saray (08:49):
Then also, we all have these little silos or areas that life has led us through that we learned something. There are people that maybe one of their first contracts was mobile apps and they ended up becoming just really specialized in developing mobile apps. Doesn't mean that I know more than them because I know more about Laravel. Just means that we took different paths and we learned different things. So keeping that in mind when you answer those questions, I think, is super important.

Joel Clermont (09:20):
Yeah, I think that's a good attitude to try to maintain. Another thing I think about at the moment you're being asked a question is how to respond. It's going to depend a little bit on the nature of the question but there's basically two ways of responding. One is giving them the answer and a second way is maybe asking, "Hey, have you tried this? Have you thought of that? Have you looked at this?" Where you're not necessarily giving them the direct answer but sort of leading them to the answer. I know we've talked about it in other discussions on this podcast but that's something to think about too and there's a skill to kind of knowing when to just hand the answer versus leading them to it. The other thing too is kind of back to your previous point about having different paths and knowing different things.
Sometimes knowing the answer to a technical question really has to do with knowing some other area. Like, for example if somebody's AJAX request is failing and you understand the intricacies of DNS and caching and some of network level things, it might be obvious to you why that thing is failing. It has nothing to do with the code, it's like a whole separate thing. But maybe the person is more development focused, they didn't have a side job doing networking or something in the past. Or, they haven't dug deeper into the plumbing of the internet, and so they don't know some of those things. So that really, I think, can be an opportunity to teach. Not just say, "Oh, here's the answer." But point, like take a step back. "Here's the actual root cause of what you're running into," and expose them to this other sphere of information that will be useful to them in the future and other things as well.

Aaron Saray (11:03):
It's almost a full circle to the earlier part of the conversation where it's other context. So it's other things that are available or happening that affect this particular question or challenge. Joel?

Joel Clermont (11:18):
Yes.

Aaron Saray (11:18):
What was the point of all this?

Joel Clermont (11:21):
To summarize it, if I had to say there's two takeaways and these would apply not just within a team but just kind of in the internet at large and in the programming community. Is, number one, don't be afraid or ashamed to ask for help. If you've tried your best, you put some effort into figuring it out and you just don't know, it's okay to ask for help. On the flip side, if you're in a position where somebody's asking you for help, don't be a jerk about it. Be empathetic, try to help, try to teach not just give an answer. And I think the internet will be a better place.

Aaron Saray (11:59):
I like to watch how security in the real world kind of plays out. How we make decisions as well about how we keep things organized or protected or secure. One of the things I've noticed is, when you go to the airport there's tons of different levels of security. And all things are getting checked and everything and you go into special room and you might get patted down, I don't know, a lot of things happen, right?

Joel Clermont (12:25):
Okay.

Aaron Saray (12:25):
Then everything's still, everyone is paying attention. You can't be crazy on an airplane, they might turn around and take you off. Then when you land and you get back into the airport, all of that just goes away when you get to baggage claim.

Joel Clermont (12:43):
Okay. That's a free for all?

Aaron Saray (12:45):
Yeah. It's just suddenly just tons of bags are coming out and no one just questions, "I'm just going to go grab this bag." I don't get it, how is there not... Is there a lot of bags stolen? I know people lose them, but it's like, "Oh, better..." I get it, it's because you want to be safe on the airplane because you're confined. But seems like that's just like, all of a sudden at the very end it's just like end then take whatever bag you want.

Joel Clermont (13:12):
Airports are like, "This is not our problem anymore, you guys work this out as a group."

Aaron Saray (13:17):
Yeah. Here is literally a trough of stuff. Take your stuff, you animals.

Joel Clermont (13:23):
We used to take trips to Florida and when we'd fly back you'd see some different things. Especially in the winter flight from a cold area where we live to a warmer area like Florida. Somebody would have a set of golf clubs, something really big and unusual, or like a box of oranges would come rattling off the baggage claim. And I'm just like, "Wow, those are not going to be in good shape." But, yeah, it is very much a free for all environment.

Aaron Saray (13:51):
Yeah, I wonder if there's any other situations like that. I think about that too is, kind of like roundabouts. At a lot of intersections you have stop and go lights or crosswalks and all that kind of stuff. Then at a roundabout, just go. Just don't hit the guy on your left and just go. It's like such a weird juxtaposition to me. Can you think of anything else weird like that in your life?

Joel Clermont (14:19):
Well, I have a comment on the roundabout. When those were becoming fashionable in this area, I made an offhand joke to a friend that I heard legally you have to circle the roundabout once before you can exit it. He believed me and apparently did that. But anyways, don't do that. Or if you joke at least make it obvious it's a joke. But all right, so other real world examples of things going crazy. One that came to mind for me which maybe isn't quite an extreme an example as what you cited but in the same sort of category is at the grocery store. When you checkout, it's very orderly, you have lines.
But there's that one spot in the grocery store that I find personally a little chaotic and that's the deli counter. Because there's no clear line, there's usually multiple people that can help, and at least around here... Like in the olden days, they'd have taken number and they'd call you. They don't have that anymore so you sort of have to muscle your way to the front, you have to make eye contact with the person. And when you have multiple people waiting, it's a little bit chaotic as far as who gets called on first and who gets helped first.
We've compiled 17 handy Laravel tips into a new book called A Little Bit of Laravel. Our goal with this book is for developers to read one short tip each day and then put it into practice making their apps a little bit better. If you'd like a free copy of this book, go to nocompromises.io/tips.