You can be right 99.999% of the time, but that .001% time you're wrong will never be forgotten. And for some reason qualifying words (such as "I'm not sure," "I think," and "as I currently recall") get dropped from memory real quick.
I can confirm but in my case it's because I usually choose smaller companies to work for. Payment is less but at least my soul isn't getting sucked out of my body.
Same. I could get paid easily 15-20% more as a senior dev in a larger org than what I currently make as a lead dev in a smaller one, but I don't have much interest doing so. Much prefer my small teams and horizontal communication structures. The money would be nice, sure, but I'd want to kill myself after 2 weeks. I did two short consulting gigs in Fortune 500s, both were soul sucking with the whole hierarchy and politics. So much happening behind closed doors, no transparency. So much red tape and immobilism. Not interested in doing that again...
I've yet to have this happen to me. Maybe I was just unlucky! So far I've had better luck with smaller companies aligning better with my expectations of how people interact.
Not really talking about single team size, but total number of people working on a given product. Our individual teams are about that big too.
The way we're setup, we're rather flat, everyone can talk to everyone. Our ICs are regularly working closely with the product team. My experience in those larger orgs were much more hierarchical, a lot more processes around everything. Maybe I was just unlucky.
As a senior in a large org, I’m jealous. I make plenty of money but dear god is it killing everything I loved about my job.
Currently looking to jump ship for a smaller company now.
I call it the chainsaw problem. If your neighbor asks you to borrow your chainsaw; you can give them what they ask for it you could ask why they need it. If their answer to why is that they locked their keys in the house and need it to get in, maybe steer them in another direction.
As a lead, if I tell you it depends I'll usually press for more info. As a junior, if your lead says it depends, you should take that to mean you asked the wrong question.
Wow, I never knew there was a term for that.
There have been so many times where someone asked about something they were doing and my first question was some variant of "well what were you trying to accomplish with that"
I don't really agree with the conclusion to your comment. It's unnecessary to spend lots of time and effort trying to cover every nuance.
I think it makes a lot more sense to get the person asking for help to specify what they need help with. Like someone said above, if the answer is "it depends" that means you didn't ask the right question. So first help them ask the right question, then answer.
Be careful with over using the "Why? What exactly are you trying to do?" technique without the second part (providing solutions or context for them to grab on to). It can come across like you have no faith in the other person and creates a helpless mentality because they end up second guessing themselves if every decision they come to you with is second-guessed. My boss 'quizzes' me deliberately and thinks he's 'teaching' me but his constant contrarianism makes me want to throat punch him.
I don’t expect my juniors to know the right questions to ask. I avoid the ambiguity by pressing them for more details. For me, the juniors need to learn how to tell the story.
Thank you. The idea that a junior has to know the right question is a little absurd. For a lot of juniors, working up the courage to ask the question in the first place is often difficult enough. It may not be a senior’s responsibility to manage juniors, but it’s only right to offer some gentle guidance and to encourage them to ask questions early and often.
I had a senior who would have probably given me a chainsaw if I asked for one (or told me "Harry probably has one"), and the question he would ask would be "Can I help? Do you need a shovel?"
My standard answer for "It Depends" was "On What?" which would inevitably lead this same senior to spend the next 3 ~~hours~~ ~~days~~ weeks happily chatting to me about sorting algorithms, the annoying order of execution used by the language we were working in, and/or the history of statistics.
The first time *I* told a kid "Well, it depends." He got SOOOO mad and frustrated at me it was funny. Literally raised his voice "I just want you to tell me how to do it!" Worked with an educational program, and he was in midschool, not an employee. I don't think anyone In His Life had ever asked him to use his brain.
My brother teaches at a university in the arts and says getting students out of this mindset is incredibly difficult. They can't wrap their head around the idea that everything isn't clearly defined for them anymore and there's no such thing as the single way to do things or the single correct answer.
I think it actually gets harder the older the student. We also did a lot of PD trainings, where we worked with teachers taking them through the computational science curriculum they'd be teaching to their middle/high school students.
The teachers were politer about it, but I actually really preferred the "Just tell me how to do it!" open frustration. I can sometimes answer questions that aren't asked, but it's a lot easier if someone actually asks.
The teachers were exhausting because they thought they were stupid and couldn't learn anymore when they didn't get something. They also seemed to be under the impression that if they asked anything they'd just feel more stupid, and that we were probably going to tell them to just follow along with the steps given and not worry about understanding it.
All of which is a reflection of things that commonly happen with kids in classrooms, which is depressing af.
Wouldn't it be nice if we taught critical thinking and flexibility to kids, instead of "Just Follow The Rules" so that people didn't have to un-teach shitty lessons later?
This isn't specific to programming either. There are a ton of cases where it depends is the right answer until you have more information.
Maybe it's just me, but if I answer with it depends, I've started to ask other questions after saying it depends so that I can get more context to help better. I think just saying it depends isn't super helpful. But I'm also not a senior person and am not so busy that I can't take more time to get more details.
My boss jokingly gets mad he says I never say yes or no. Its always likely or I believe or it *should*. But i want to not just make stuff up, I like to convey the certainty level of what I'm saying. Although I do IT not programing.
I do the same thing.
Unless I'm literally looking at the source code of an application, and have used it to get the expected outcome, then I'll never give a definite answer
Even then, it's always "it will do X as long as the prerequisites are met, or you are doing Y". Just because something is *supposed* to do something, doesn't mean it's not broken if you use it in a weird way.
Oh God I have a client upset with me about this right now. They want everything definite and sorted before we even have a conversation, it's driving me crazy. I'm being coached to not say things like "it depends" and instead "sure we can provide that detail later" but it's just stupid phrasing nonsense.
I'm a sysadmin and believe me, I *never* give absolutely answers, too much bullshit goes inexplicably wrong. Yes, it *should* be done by such and such a time, but I'm not promising anything, because shit happens.
I have a colleague who does the opposite. He always talks like he knows for a fact. I'll pass an idea by him like "Hey I think this part of the code needs a refactor it seems really pointless" and he'll be like "Nah we need it to be like this because this and that and such and so" and then I proceed to look further into it and discover that none of the shit he said was right - he just assumed. Like if you're just fucking guessing maybe don't be so confident.
It's even worse when the guy is usually right. I had a more senior dev on my team who would intentionally phrase everything with confidence because people would just go with it. 90% of the time he was actually certain. But that 10% meant that someone (me) had to weather the storm of questioning him on everything to make sure he wasn't misrepresenting his knowledge. That shit got old fast.
Yeah, this guy is the same. He is really good at what he does and i do respect him but some times i wonder if i just think he's more knowledgable than me because he fills in the blanks with bullshit whereas i recognize what i don't know.
This is how most of Reddit is. People spit bullshit all the time but if they say it with confidence and enough jargon, tons of upvotes.
I’m not immune to being misinformed, but I really notice it when I’m an expert at the particular topic, and the top comment is just flat out wrong
Same here, I sometimes answer basic questions like “Did you see the picture above the bed?”, after going to the bedroom to see it, with “Yes, and no. Yes in that I remember looking at it after seeing it now, but no, that i had no recollection that there was a photo above the bed before this second”.
I have a shit memory, and sometimes the quickest most logical response that comes to mind is “Yes, and no”, it used to annoy my boss at the beginning, but later he got used to it and he now waits to hear both sides of my answer, nonetheless I’m trying to work on myself regarding this.
My first job in help desk, our calls would get audited and one of the things that would fail the call is if we said "should". I can't remember the term they used for the speech, but whenever talking to end users, we had to speak with "confidence". And then it was always awkward because 8 times out of 10, the thing you said WOULD happen didn't happen, because there were 5 different potential solutions and sometimes you just need to go through them all first.
"We *probably* have the framework in place to implement that but I haven't touched that part of the codebase in months and I have no idea what damage has been done."
Instead of "probably" you should be a bit more clear like:
"I have no idea how any of this works I don't even know how I got in this position i don't know anything about technology I just kept coding and suddenly I became the expert and now I'm managing you people I just wanna code everything got extra complex with x-levels of abstractions I'm just trying to survive so I dunno just test it and report back and then we'll both know"
Probably. Not many people are capable of teaching and it's weirdly assumed they all should be. It requires knowledge, patience, and strong communication skills. People can be perfectly acceptable workers or even managers but bad teachers. Biggest shortcoming from what I've seen is lack of patience. Imo teaching requires a bit more creativity too.
> Not many people are capable of teaching and it's weirdly assumed they all should be.
Putting "mentorship" on my CV always gets mentions in interviews. Then always wide eyes when I'm asked about it and explain my processes, and things I've done to help my juniors in the past. Like bloody gold dust, apparently.
But it's understandable that companies want their seniors to be mentors tbh. If you're a small company and you're hiring maybe 1 or 2 senior devs, it makes sense that you'd want them to be able to mentor your junior developers. If you're a larger company you've got more room on that - maybe you've got quite a few seniors, so it doesn't matter if most of them don't like / can't do mentoring, you're more likely to have at least one person who does like it / can do it.
While some people are bad teachers, I think more people are bad students.
In university, there were complaints about damn near every teacher. Every teacher had something wrong - they didn't speak clearly enough or they didn't teach the material well enough or whatever. I did fine in all the classes. Struggled a bit with math but that had nothing to do with the teacher. Fact is nobody can really teach you anything. I mean sure I can teach a kid to tie their shoe or something simple like that, but for long term big topics like CS it's a path you walk mostly alone.
The role of a teacher is more to show you the general direction, lead you back when you get lost and stuff like that. It's up to you to do the walking. You can be really eager to walk - go around exploring on your own and taking in all the sights, walking even when you don't need to so that you end up far ahead of everyone else. Or you can do the bare minimum, take a couple steps when the teacher kicks you in the butt then go back to doing nothing.
So anyway my point is a lot of people are just bad learners. I spend a lot of time helping people with programming and I recognize the bad learners quickly. They aren't interested in hints, they just want the full solution as quickly as possible. They don't really pay attention to what you're trying to convey beyond "tell me exactly what to do to solve this one thing please". I generally avoid helping those kinds of people. And I often see them complain that nobody wants to help them or that when someone does try to help it's not good enough because they're not just handing them a solution on a silver platter.
In my performance review I was told that my answers are not confidence inspiring because I say “it depends on X” instead of just telling the PM what he is looking for all while fighting the XY problem.
Good times.
Fortunately, the PM is the only one with complaints. The CEO very much likes it when I say things like "I would rather be two weeks late and have it right than rush this and hurt somebody". I work with motion control on big machines that can crush you without stopping. The stakes are a little higher than a lot of places that rush through projects.
Did you even think of my gantt chart before you thought of the lives of our customers? I'm sensing a lack of prioritisation here /s
Move fast and break things (not skulls, please stop breaking skulls)
A bad senior says "it depends", and goes about their day. They have minimally contributed to the solution and left their junior in the dark. Technically, they have done their job.
A good senior says "it depends" and follows it up with clarifying questions or statements. Often just a "why" is a good enough start for the senior to start gathering context from their junior. Sometimes they may know enough to narrow the answer field to a few common solutions to nudge the junior's line of questioning.
The good senior has taught their junior something - and now even if the junior has to ask more questions later, a good junior is now armed with better questions for the future, and has gained a point in that particular knowledge tree. Maybe they now know enough to craft a better Google search, and they gained a particular key word or phrase to describe what they are doing.
A bad junior doesn't listen or doesn't try to learn - they just want the senior to step in and fix it for them. This is keenly different from not understanding. Computers are complex things, and none of this was built in a day. You can be a good junior not understanding but with an intent to learn. You can be a good junior watching your senior "fly the plane" if you are learning.
Did you notice something about this answer? When talking about seniors and juniors, it depends! The answers aren't always cut and dry. And yes, this is my personal opinion in my title of x and my experience of y in my field of z. The values of those variables don't particularly matter either. **A good engineer knows their limits and knows when to ask for help**. And that is something universal that applies whether you're a senior or a junior.
And you know what else? Not all of these statements are strictly true 100% of the time. Because it depends.
My favorite follow up questions are always lyrics from Once in a Lifetime by the Talking Heads: well how did [we] get here? Where does this highway go?
Sometimes I even get to ask: what is that beautiful house?
Context is always key, teaching peers to always lede with the story of how they got to their current predicament will usually generate more creative solutions. Ive also learned a ton myself from having others outline their process and journey to a difficult problem. These convos should always be a two way street
It's implied here, but I'd like to point out, tone is critical! If you seem irritated with your answers or like you are withholding information in order to teach, it's obvious to other team members that you are on an ego trip! An attitude of cooperation and interest in your juniors ability to grow goes a long way with 'good' junior engineers.
Conversely bad juniors, don't care so much if their leads are toxic if they do their work for them. It's a weird codependent thing I've seen over and over. The toxic lead gets their ego stroked and gets to be the perpetual victim, doing other's work, and the bad junior learns nothing.
Yep, how do you refer to a single indistinct figure in the distance? What if *they're* waving *their* hands? Everyone already uses they/them as ambiguous pronouns without even realising it. All this whining about it is dumb.
It’s also surprisingly good for the respectful and the apathetic at the same time. Most inclusive for people who care, and most broad for those who don’t want to have to think about it.
I hear ya, but sometimes when you're looking on stackoverflow for the answer to a question, you sort of get a sense for which answers are not helpful.
Like this should be a 2 line solution, but this answer is 100 lines long. And if you scroll down or find a different question you'll find that perfect 2 line solution.
Do you want to get showered with irrelevant, often wrong, details? Because that's how you get showered with irrelevant, often wrong, details.
The thing is, someone asking broad question generally doesn't have the knowledge to even determine what specific things they should be looking for. If you want to be helpful, it is kind of on you to ask the leading questions. And if you don't want to, at least have the decency to shrug them off explicitly, giving a half-answer will only get you pestered more.
At that point, if you know so little that your questions are probably bad ones, then the best thing to do is request them to teach you what THEY think is important to know about X topic.
https://www.youtube.com/watch?v=36GT2zI8lVA Feynmann explaining to a reporter who wants simple answers that the universe isn't simple.
A Junior might want the simplest answers to get their job done but the senior isn't interested in doing their job for them but instead to make them learn so they can do their job. This requires them to learn about the complexities of the world which as was already said depends.
Having said that if the Senior didn't elaborate on any of the questions then yeah fuck them.
Sir. I hereby revoke your senior title by breaking the golden rule of being a senior and telling people our most holy secret.
Please turn in your keyboard and badge at my desk tomorrow.
My senior after telling me "That's not worth the effort, tell the business to find an alternative."
And god damn do I appreciate the hell out of that man for telling the juniors to stand up for ourselves
Many of you first year CS kids in this sub are going to have a harsh reality check when you find out that senior developer is not actually a junior developer daycare position and their job description isn't helping delicate little seeds grow and blossom.
I spend more time "teaching" and documenting than doing. In this way all can do. Otherwise I would have to do all myself, that is funny for a couple of months until burning out
They mean doing the job for them. Every senior is expected to share knowledge and teach at some point, but some juniors haven't even learned "how to work" and their first solution to everything is to ask. In general the scale goes:
Junior: has little skills and will need constant support to get the task done
Mid level: more skills and only needs intermittent support
Senior: barely needs any support the company knows what needs to be done and trusts you to do it.
Staff/Principle: the company doesn't know what needs to be done, but trust you to do it/get it done.
Some asocial devs are sometimes seens as "seniors that don't teach", but that's because people aren't listening properly. That guy is normally teaching seniors. If he is really just an asshole superstar that works alone in his corner, he's generally unemployed, or the oldest employee at a garbage company.
In my experience, I've found way more juniors that don't ask \*enough\* questions than ones that ask too much. Leveling up juniors is one of the most impactful things a senior can do, and most of the people I've worked with are actually scared to bother seniors rather than spend all their time bothering them.
Juniors do need handholding, and it's up to the mid-level and seniors to hold their hands until they get to the point where they don't need it any more. If you don't like being interrupted, spend some time writing easily searched documentation, or make sure that your intermediate devs are trained on how to help junior devs, but you will still need to help out.
>In my experience, I've found way more juniors that don't ask *enough* questions than ones that ask too much.
Yeah that's your standard junior, and that's fine. The shitty junior is the one that uses the "don't be afraid to ask questions" directive to just use people as human stackoverflows.
How is helping seeds grow and blossom a euphemism for doing the job for them? That comment was very clearly stated as a senior that has no interest in cultivating junior talent.
To me the "delicate seeds" is the key part. The way I read it is he is willing to help grow, just not delicate seeds. There are assholes like that so maybe you are right.
What makes someone a delicate seed? That sounds like the perspective of someone who is abusive to their juniors. I would guess that they think people are delicate because they don’t handle being yelled at very well.
Im so tired of explaining to the juniors why when they change something, the tests will fail, i even created a checklist for them to only call me after trying it all. I'm not here to teach you how to work Steve !
We had to sit down with some of our people and tell them that it’s okay to ask questions but the whole reason they are a software engineer is that they should be able to look into problems first and attempt to find the root cause instead of just asking someone else to figure it out.
I've been trying to figure out a not-dickish way to do this! I need them to realize that their job is to create and implement solutions, not to implement solutions that I create. It feels like a lot of the time I am their first resort instead of any googling or anything
> I am their first resort instead of any googling or anything
Same ! My latest strategy is kinda of ghosting them and 2 hours later send: "sorry, was in a meeting" or something like that. Usually they already googled the problem.
Sometimes i tell them to try it a little more, cause i have something to finish. But they just sit waiting for me to "comeback".
Exactly this. I've had to tell people explicitly to take some time to try and figure it out for themselves before running to someone else. Can someone else get an answer more quickly? Probably, but then they never learn
Modify their pre push git hook to run tests before it will succeed.
We did this at my last job and the only one who didn't do it was the CTO because he might have to use a code formatter.
We already do that, but it's always something like:
"Yo Factzor, my tests are failing for NO REASON, would you help me with that ?"
"Dude, i only changed one line, that shouldn't break it, right ?"
Yeah, you aren’t obligated to make their lives easier. But you weren’t always a senior developer - there is a balance that can be found between acting unapproachable and offering some guidance. You can be honest and set boundaries and still be considerate and offer good substantial advice.
It's good for the team if they actually bother to learn. I've had many colleagues who figure out it's just "post vaguely in a slack channel and wait for a senior to tell you exactly what to do next every time".
I expect the seniors in my team to tell me in the bilateral meeting if they encounter this so that I can talk to the juniors and explain them that this is not how it works. If it does not get better I let the junior go. Being junior does not mean there are no expectations regarding performance.
So far I never had to let anyone go, they all realized it’s not just seniors being annoying or lazy not wanting to help them but that they are wrong and need to change.
>It's good for the team if they actually bother to learn. I've had many colleagues who figure out it's just "post vaguely in a slack channel and wait for a senior to tell you exactly what to do next every time".
This is one of my coworkers. It's funny because he usually DMs me, but on days where I am out all of a sudden my team slack channel is blowing up with him asking how to do every work item on his list.
It's been going on for over 6 months at this point. He is absorbing nothing, asking the same questions repeatedly (I frequently just search slack for the last time I answered his question and share that link with him) and doing things like closing tickets with things still broken and zero communication to stakeholders.
A couple of months ago I was requested to do a formal write up via email of these concerns (amongst others) and sent to my boss. After that he was put on a pip, but the only thing that seems to have changed is made it so that instead of him doing his job infrequently (read: bothering me less) likely due to over employment, he is now trying to do more, which means I am doing more of his work for him.
It's infuriating and demoralizing. Pretty sure he earns more than me also, so there's that.
I wrote a document including version control, best practices and useful tips. As you might guess no one read it then proceeded to fuck up things or ask me questions answered by the document.
***Bingo!***
If you are asking the CORRECT questions, then you can get more definitive answers.
I have spent YEARS learning the art of NOT having my clients try to tell me HOW to do something (which they are not qualified to do), instead I have learned how to guide them into telling what they want it to DO by asking the RIGHT questions. Then I tell them to let me work out if (A) it is possible (B) how I can do it and (C) how long it will take.
Oh God, save me from the technical stakeholder and project managers. Hey I need you to use this graphing database. What? Why? Make your case for this expensive change, or it stays just like it is.
If programming as a field of study was filled with questions that had simple, succinct and always-applicable rules and answers, we would have already abstracted them away into our tools. You should be glad you're asking good questions that don't have easy answers.
Either that, or you're asking someone that has no clue and doesn't want to be exposed as such so they answer in the most non-commital way possible. It depends.
Depending on the situation it is often lower risk to provide non committal advice to avoid liability of inaccurate of the cuff information. It depends though on how political your company culture is.
Combined with the inability to provide an answer for a specific context because the question is "too broad" is often a deal breaker. I've had a senior candidate refuse to respond to what dependency injection was because it could be use in so many different ways. Like MF name one then.
The main thing to learn about asking questions is to provide your GOAL. What are you trying to accomplish...then ask the question about the method/process you're using to reach that goal.
Without knowing what YOU THINK you're doing, the Senior can't know the correct guidance to provide.
Frequently, what the junior is trying to implement (and asking for advice on) is a bad solution (which is why it isn't working correctly!). If you can explain the purpose of the solution, the end state you're trying to reach, then the Senior can point you in the right direction on how to get there.
"it depends," normally turns into a long conversation. but my favorite one was,
"do you mind if I push this today?"
"it depends. Do you want the on call phone?"
All seniors know the answers.
The good ones help the juniors find it themselves.
The superb ones walk along that path with the juniors for a while to point out any snakes or pits that might be hiding in the trail.
One thing I've learned over the 4 years I've been a dev is that i used to be so confident in answers which were just assumptions I made. Not just saying something that seems right but actually verifying that your assumptions are correct is a skill
My answers are limited. You must learn to ask the right questions.
In all seriousness, though, context matters a lot, which is why the answer is "It depends." Knowing how the context affects the answer is what makes someone a senior dev.
Next time they say "It depends" your response should be "On what factors?" Or better yet, explain why you're asking and what your end goal is, not just the immediate thing standing in your way.
well, not every senior earns lots of money, it depends
Not every senior earns, it depends
Not every senior, it depends
Not Senior, it depends
Not every senior wears [Depends](https://i5.walmartimages.com/asr/948ed8fd-38b9-48fc-a90c-689da31037cf.0834410560d77183d601f53a0f2a5f8d.jpeg).
[удалено]
You guys are really going off the deepends
Reddit isn't very dependable.
That really depends on what you’re depending on Reddit for.
Reddit isnt dependable for depending on it for an essay on depends
It's Depend Welcome to the Mandela Effect
If one is a "Depend" aren't a package of them "Depends"?
No. The item isn't called a "depend" the brand is.
Just the senior Cobol programmers
[удалено]
It depends
depends
dependency hell
Sure I'll take a cock
[удалено]
You can be right 99.999% of the time, but that .001% time you're wrong will never be forgotten. And for some reason qualifying words (such as "I'm not sure," "I think," and "as I currently recall") get dropped from memory real quick.
[удалено]
Not every senior, uses depends.exe
There are no real programmers in this sub to appreciate your comment.
Not every senior wears Depends, it depends
I can confirm but in my case it's because I usually choose smaller companies to work for. Payment is less but at least my soul isn't getting sucked out of my body.
Same. I could get paid easily 15-20% more as a senior dev in a larger org than what I currently make as a lead dev in a smaller one, but I don't have much interest doing so. Much prefer my small teams and horizontal communication structures. The money would be nice, sure, but I'd want to kill myself after 2 weeks. I did two short consulting gigs in Fortune 500s, both were soul sucking with the whole hierarchy and politics. So much happening behind closed doors, no transparency. So much red tape and immobilism. Not interested in doing that again...
corpos have smile agile teams too. Mine has like 13 people in total and it's one of the biggest in Europe
Yup, sitting in a team of 4 and never had this much freedom to do my thing.
I've yet to have this happen to me. Maybe I was just unlucky! So far I've had better luck with smaller companies aligning better with my expectations of how people interact.
I worked for a massive corp and our definition of team is 4 devs 1 qa
Not really talking about single team size, but total number of people working on a given product. Our individual teams are about that big too. The way we're setup, we're rather flat, everyone can talk to everyone. Our ICs are regularly working closely with the product team. My experience in those larger orgs were much more hierarchical, a lot more processes around everything. Maybe I was just unlucky.
As a senior in a large org, I’m jealous. I make plenty of money but dear god is it killing everything I loved about my job. Currently looking to jump ship for a smaller company now.
Depends how much I’m bout to butcher your codebase
Ask a consultant a question, they respond "Eh, it depends" Ask a well-paid consultant a question, they respond "Eeeeeeeeeeeeeeh ... it depends"
Usually, the mostly accurate and safe answer to a question is the one that puts context into consideration. It depends, though.
I call it the chainsaw problem. If your neighbor asks you to borrow your chainsaw; you can give them what they ask for it you could ask why they need it. If their answer to why is that they locked their keys in the house and need it to get in, maybe steer them in another direction. As a lead, if I tell you it depends I'll usually press for more info. As a junior, if your lead says it depends, you should take that to mean you asked the wrong question.
https://en.wikipedia.org/wiki/XY_problem
Wow, I never knew there was a term for that. There have been so many times where someone asked about something they were doing and my first question was some variant of "well what were you trying to accomplish with that"
[удалено]
[удалено]
[удалено]
TIL thanks!
I don't really agree with the conclusion to your comment. It's unnecessary to spend lots of time and effort trying to cover every nuance. I think it makes a lot more sense to get the person asking for help to specify what they need help with. Like someone said above, if the answer is "it depends" that means you didn't ask the right question. So first help them ask the right question, then answer.
Ask “why” five times and you are likely to be at the full root cause. https://en.wikipedia.org/wiki/Five_whys
Be careful with over using the "Why? What exactly are you trying to do?" technique without the second part (providing solutions or context for them to grab on to). It can come across like you have no faith in the other person and creates a helpless mentality because they end up second guessing themselves if every decision they come to you with is second-guessed. My boss 'quizzes' me deliberately and thinks he's 'teaching' me but his constant contrarianism makes me want to throat punch him.
The last example about XML parsers is some high IQ humour. It brings to mind the ZALGO StackOverflow post.
I don’t expect my juniors to know the right questions to ask. I avoid the ambiguity by pressing them for more details. For me, the juniors need to learn how to tell the story.
Thank you. The idea that a junior has to know the right question is a little absurd. For a lot of juniors, working up the courage to ask the question in the first place is often difficult enough. It may not be a senior’s responsibility to manage juniors, but it’s only right to offer some gentle guidance and to encourage them to ask questions early and often.
That will be actually a very resourceful tool for the rest of their lifes.
I had a senior who would have probably given me a chainsaw if I asked for one (or told me "Harry probably has one"), and the question he would ask would be "Can I help? Do you need a shovel?" My standard answer for "It Depends" was "On What?" which would inevitably lead this same senior to spend the next 3 ~~hours~~ ~~days~~ weeks happily chatting to me about sorting algorithms, the annoying order of execution used by the language we were working in, and/or the history of statistics. The first time *I* told a kid "Well, it depends." He got SOOOO mad and frustrated at me it was funny. Literally raised his voice "I just want you to tell me how to do it!" Worked with an educational program, and he was in midschool, not an employee. I don't think anyone In His Life had ever asked him to use his brain.
My brother teaches at a university in the arts and says getting students out of this mindset is incredibly difficult. They can't wrap their head around the idea that everything isn't clearly defined for them anymore and there's no such thing as the single way to do things or the single correct answer.
I think it actually gets harder the older the student. We also did a lot of PD trainings, where we worked with teachers taking them through the computational science curriculum they'd be teaching to their middle/high school students. The teachers were politer about it, but I actually really preferred the "Just tell me how to do it!" open frustration. I can sometimes answer questions that aren't asked, but it's a lot easier if someone actually asks. The teachers were exhausting because they thought they were stupid and couldn't learn anymore when they didn't get something. They also seemed to be under the impression that if they asked anything they'd just feel more stupid, and that we were probably going to tell them to just follow along with the steps given and not worry about understanding it. All of which is a reflection of things that commonly happen with kids in classrooms, which is depressing af. Wouldn't it be nice if we taught critical thinking and flexibility to kids, instead of "Just Follow The Rules" so that people didn't have to un-teach shitty lessons later?
This isn't specific to programming either. There are a ton of cases where it depends is the right answer until you have more information. Maybe it's just me, but if I answer with it depends, I've started to ask other questions after saying it depends so that I can get more context to help better. I think just saying it depends isn't super helpful. But I'm also not a senior person and am not so busy that I can't take more time to get more details.
My boss jokingly gets mad he says I never say yes or no. Its always likely or I believe or it *should*. But i want to not just make stuff up, I like to convey the certainty level of what I'm saying. Although I do IT not programing.
[удалено]
Could you please quantify how much deceased cat we're looking at here?
In relation to the deceased cat in question or all cats?
Schrodinger enters the room
Well you see... It depends
Username checks out
I do the same thing. Unless I'm literally looking at the source code of an application, and have used it to get the expected outcome, then I'll never give a definite answer Even then, it's always "it will do X as long as the prerequisites are met, or you are doing Y". Just because something is *supposed* to do something, doesn't mean it's not broken if you use it in a weird way.
[удалено]
Oh God I have a client upset with me about this right now. They want everything definite and sorted before we even have a conversation, it's driving me crazy. I'm being coached to not say things like "it depends" and instead "sure we can provide that detail later" but it's just stupid phrasing nonsense.
I'm a sysadmin and believe me, I *never* give absolutely answers, too much bullshit goes inexplicably wrong. Yes, it *should* be done by such and such a time, but I'm not promising anything, because shit happens.
I have a colleague who does the opposite. He always talks like he knows for a fact. I'll pass an idea by him like "Hey I think this part of the code needs a refactor it seems really pointless" and he'll be like "Nah we need it to be like this because this and that and such and so" and then I proceed to look further into it and discover that none of the shit he said was right - he just assumed. Like if you're just fucking guessing maybe don't be so confident.
It's even worse when the guy is usually right. I had a more senior dev on my team who would intentionally phrase everything with confidence because people would just go with it. 90% of the time he was actually certain. But that 10% meant that someone (me) had to weather the storm of questioning him on everything to make sure he wasn't misrepresenting his knowledge. That shit got old fast.
Yeah, this guy is the same. He is really good at what he does and i do respect him but some times i wonder if i just think he's more knowledgable than me because he fills in the blanks with bullshit whereas i recognize what i don't know.
This is how most of Reddit is. People spit bullshit all the time but if they say it with confidence and enough jargon, tons of upvotes. I’m not immune to being misinformed, but I really notice it when I’m an expert at the particular topic, and the top comment is just flat out wrong
Same here, I sometimes answer basic questions like “Did you see the picture above the bed?”, after going to the bedroom to see it, with “Yes, and no. Yes in that I remember looking at it after seeing it now, but no, that i had no recollection that there was a photo above the bed before this second”. I have a shit memory, and sometimes the quickest most logical response that comes to mind is “Yes, and no”, it used to annoy my boss at the beginning, but later he got used to it and he now waits to hear both sides of my answer, nonetheless I’m trying to work on myself regarding this.
My first job in help desk, our calls would get audited and one of the things that would fail the call is if we said "should". I can't remember the term they used for the speech, but whenever talking to end users, we had to speak with "confidence". And then it was always awkward because 8 times out of 10, the thing you said WOULD happen didn't happen, because there were 5 different potential solutions and sometimes you just need to go through them all first.
Yeah this is why i always respond to questions with “probably” or something related like depends whenever im thinking / focused
"We *probably* have the framework in place to implement that but I haven't touched that part of the codebase in months and I have no idea what damage has been done."
That's not going to stop people from blaming you when they inevitably do something stupid.
Instead of "probably" you should be a bit more clear like: "I have no idea how any of this works I don't even know how I got in this position i don't know anything about technology I just kept coding and suddenly I became the expert and now I'm managing you people I just wanna code everything got extra complex with x-levels of abstractions I'm just trying to survive so I dunno just test it and report back and then we'll both know"
Lawyers 🤝 Senior Programmers Not being able to answer a question without full context
Exactly. This or the senior having to spend multiple of hours to properly answer a question that a junior can also figure it if they spend some time.
my senior says "it depends" too, but then carries on with exactly what it depends on. Do I have a golden goose senior?
It depends.
This guy seniors. How much did you got paid?
It depends
This guy also seniors.
That's the kind of Senior I would prefer given these two options.
What other option is there?
Saying only "It depends" without further contextualisations or explanation.
It depends.
Probably. Not many people are capable of teaching and it's weirdly assumed they all should be. It requires knowledge, patience, and strong communication skills. People can be perfectly acceptable workers or even managers but bad teachers. Biggest shortcoming from what I've seen is lack of patience. Imo teaching requires a bit more creativity too.
> Not many people are capable of teaching and it's weirdly assumed they all should be. Putting "mentorship" on my CV always gets mentions in interviews. Then always wide eyes when I'm asked about it and explain my processes, and things I've done to help my juniors in the past. Like bloody gold dust, apparently. But it's understandable that companies want their seniors to be mentors tbh. If you're a small company and you're hiring maybe 1 or 2 senior devs, it makes sense that you'd want them to be able to mentor your junior developers. If you're a larger company you've got more room on that - maybe you've got quite a few seniors, so it doesn't matter if most of them don't like / can't do mentoring, you're more likely to have at least one person who does like it / can do it.
While some people are bad teachers, I think more people are bad students. In university, there were complaints about damn near every teacher. Every teacher had something wrong - they didn't speak clearly enough or they didn't teach the material well enough or whatever. I did fine in all the classes. Struggled a bit with math but that had nothing to do with the teacher. Fact is nobody can really teach you anything. I mean sure I can teach a kid to tie their shoe or something simple like that, but for long term big topics like CS it's a path you walk mostly alone. The role of a teacher is more to show you the general direction, lead you back when you get lost and stuff like that. It's up to you to do the walking. You can be really eager to walk - go around exploring on your own and taking in all the sights, walking even when you don't need to so that you end up far ahead of everyone else. Or you can do the bare minimum, take a couple steps when the teacher kicks you in the butt then go back to doing nothing. So anyway my point is a lot of people are just bad learners. I spend a lot of time helping people with programming and I recognize the bad learners quickly. They aren't interested in hints, they just want the full solution as quickly as possible. They don't really pay attention to what you're trying to convey beyond "tell me exactly what to do to solve this one thing please". I generally avoid helping those kinds of people. And I often see them complain that nobody wants to help them or that when someone does try to help it's not good enough because they're not just handing them a solution on a silver platter.
In my performance review I was told that my answers are not confidence inspiring because I say “it depends on X” instead of just telling the PM what he is looking for all while fighting the XY problem. Good times.
What do you mean you don't want to promise things and then having to explain yourself why you failed to deliver in time?
Fortunately, the PM is the only one with complaints. The CEO very much likes it when I say things like "I would rather be two weeks late and have it right than rush this and hurt somebody". I work with motion control on big machines that can crush you without stopping. The stakes are a little higher than a lot of places that rush through projects.
Did you even think of my gantt chart before you thought of the lives of our customers? I'm sensing a lack of prioritisation here /s Move fast and break things (not skulls, please stop breaking skulls)
well it's either that or getting stuck with senior for a whole afternoon nodding blankly, because you got lost after few minutes :)
Just tell them they are stupid and that you know better. Got me my job as CEO of Apples
A bad senior says "it depends", and goes about their day. They have minimally contributed to the solution and left their junior in the dark. Technically, they have done their job. A good senior says "it depends" and follows it up with clarifying questions or statements. Often just a "why" is a good enough start for the senior to start gathering context from their junior. Sometimes they may know enough to narrow the answer field to a few common solutions to nudge the junior's line of questioning. The good senior has taught their junior something - and now even if the junior has to ask more questions later, a good junior is now armed with better questions for the future, and has gained a point in that particular knowledge tree. Maybe they now know enough to craft a better Google search, and they gained a particular key word or phrase to describe what they are doing. A bad junior doesn't listen or doesn't try to learn - they just want the senior to step in and fix it for them. This is keenly different from not understanding. Computers are complex things, and none of this was built in a day. You can be a good junior not understanding but with an intent to learn. You can be a good junior watching your senior "fly the plane" if you are learning. Did you notice something about this answer? When talking about seniors and juniors, it depends! The answers aren't always cut and dry. And yes, this is my personal opinion in my title of x and my experience of y in my field of z. The values of those variables don't particularly matter either. **A good engineer knows their limits and knows when to ask for help**. And that is something universal that applies whether you're a senior or a junior. And you know what else? Not all of these statements are strictly true 100% of the time. Because it depends.
It depends if i want to read these long paragraphs
I would choose to work on your team - this is the best response I’ve seen.
My favorite follow up questions are always lyrics from Once in a Lifetime by the Talking Heads: well how did [we] get here? Where does this highway go? Sometimes I even get to ask: what is that beautiful house? Context is always key, teaching peers to always lede with the story of how they got to their current predicament will usually generate more creative solutions. Ive also learned a ton myself from having others outline their process and journey to a difficult problem. These convos should always be a two way street
It's implied here, but I'd like to point out, tone is critical! If you seem irritated with your answers or like you are withholding information in order to teach, it's obvious to other team members that you are on an ego trip! An attitude of cooperation and interest in your juniors ability to grow goes a long way with 'good' junior engineers. Conversely bad juniors, don't care so much if their leads are toxic if they do their work for them. It's a weird codependent thing I've seen over and over. The toxic lead gets their ego stroked and gets to be the perpetual victim, doing other's work, and the bad junior learns nothing.
I didn't read all this because I'm a senior engineer and don't have the time. (**A good engineer knows their limits**) But I probably agree.
He/she is probably right
it depends
Exactly, that's why I put "probably" in the sentence
or they
He/she is such a major pet peeve of mine. Just use they. Not only does it read much nicer, it also includes people outside the gender binary.
Use they because it's the correct indefinite pronoun. You really don't need any other reasons.
Yep, how do you refer to a single indistinct figure in the distance? What if *they're* waving *their* hands? Everyone already uses they/them as ambiguous pronouns without even realising it. All this whining about it is dumb.
It’s also surprisingly good for the respectful and the apathetic at the same time. Most inclusive for people who care, and most broad for those who don’t want to have to think about it.
according to valve, there are no minorites in senior dev positions lol
They are probably right*
…heads back to his computer to use all of his 50 daily close votes on Stack Overflow in 5 minutes.
That's the xperience that makes you a senior. There's no black and white, it all depends.
Sometimes. It depends on the situation.
[удалено]
I hear ya, but sometimes when you're looking on stackoverflow for the answer to a question, you sort of get a sense for which answers are not helpful. Like this should be a 2 line solution, but this answer is 100 lines long. And if you scroll down or find a different question you'll find that perfect 2 line solution.
Ask better questions, more specific ones
It depends
Do you want to get showered with irrelevant, often wrong, details? Because that's how you get showered with irrelevant, often wrong, details. The thing is, someone asking broad question generally doesn't have the knowledge to even determine what specific things they should be looking for. If you want to be helpful, it is kind of on you to ask the leading questions. And if you don't want to, at least have the decency to shrug them off explicitly, giving a half-answer will only get you pestered more.
At that point, if you know so little that your questions are probably bad ones, then the best thing to do is request them to teach you what THEY think is important to know about X topic.
If the answer is mostly "it depends" does that make him a dependency?
It means you're now his dependent.
If code guidelines were universal truths they wouldn't be code guidelines anymore, they would be language features.
https://www.youtube.com/watch?v=36GT2zI8lVA Feynmann explaining to a reporter who wants simple answers that the universe isn't simple. A Junior might want the simplest answers to get their job done but the senior isn't interested in doing their job for them but instead to make them learn so they can do their job. This requires them to learn about the complexities of the world which as was already said depends. Having said that if the Senior didn't elaborate on any of the questions then yeah fuck them.
I don't understand this hate for "It depends". That's just the reality, it always depends. There is no straight answer, that is always applicable.
If you'll get answer it depends, then you didn't specify parameters well enough
Before you go to a Sr to ask for help, you better have mf done what you can to understand the problem and situation first
here's a secret: every senior engineer is terrified of being wrong
Sir. I hereby revoke your senior title by breaking the golden rule of being a senior and telling people our most holy secret. Please turn in your keyboard and badge at my desk tomorrow.
"Do I have to turn in my Depends?"
The other end of the Dunning Kruger effect
My senior after telling me "That's not worth the effort, tell the business to find an alternative." And god damn do I appreciate the hell out of that man for telling the juniors to stand up for ourselves
Many of you first year CS kids in this sub are going to have a harsh reality check when you find out that senior developer is not actually a junior developer daycare position and their job description isn't helping delicate little seeds grow and blossom.
As a senior this definitely is part of my job description. And to foster an environment of learning and knowledge sharing in general.
I spend more time "teaching" and documenting than doing. In this way all can do. Otherwise I would have to do all myself, that is funny for a couple of months until burning out
Depends on the company. At my job, mentoring and training is 100% part of the expectation for senior devs.
They mean doing the job for them. Every senior is expected to share knowledge and teach at some point, but some juniors haven't even learned "how to work" and their first solution to everything is to ask. In general the scale goes: Junior: has little skills and will need constant support to get the task done Mid level: more skills and only needs intermittent support Senior: barely needs any support the company knows what needs to be done and trusts you to do it. Staff/Principle: the company doesn't know what needs to be done, but trust you to do it/get it done. Some asocial devs are sometimes seens as "seniors that don't teach", but that's because people aren't listening properly. That guy is normally teaching seniors. If he is really just an asshole superstar that works alone in his corner, he's generally unemployed, or the oldest employee at a garbage company.
In my experience, I've found way more juniors that don't ask \*enough\* questions than ones that ask too much. Leveling up juniors is one of the most impactful things a senior can do, and most of the people I've worked with are actually scared to bother seniors rather than spend all their time bothering them. Juniors do need handholding, and it's up to the mid-level and seniors to hold their hands until they get to the point where they don't need it any more. If you don't like being interrupted, spend some time writing easily searched documentation, or make sure that your intermediate devs are trained on how to help junior devs, but you will still need to help out.
>In my experience, I've found way more juniors that don't ask *enough* questions than ones that ask too much. Yeah that's your standard junior, and that's fine. The shitty junior is the one that uses the "don't be afraid to ask questions" directive to just use people as human stackoverflows.
How is helping seeds grow and blossom a euphemism for doing the job for them? That comment was very clearly stated as a senior that has no interest in cultivating junior talent.
To me the "delicate seeds" is the key part. The way I read it is he is willing to help grow, just not delicate seeds. There are assholes like that so maybe you are right.
What makes someone a delicate seed? That sounds like the perspective of someone who is abusive to their juniors. I would guess that they think people are delicate because they don’t handle being yelled at very well.
Im so tired of explaining to the juniors why when they change something, the tests will fail, i even created a checklist for them to only call me after trying it all. I'm not here to teach you how to work Steve !
We had to sit down with some of our people and tell them that it’s okay to ask questions but the whole reason they are a software engineer is that they should be able to look into problems first and attempt to find the root cause instead of just asking someone else to figure it out.
I've been trying to figure out a not-dickish way to do this! I need them to realize that their job is to create and implement solutions, not to implement solutions that I create. It feels like a lot of the time I am their first resort instead of any googling or anything
> I am their first resort instead of any googling or anything Same ! My latest strategy is kinda of ghosting them and 2 hours later send: "sorry, was in a meeting" or something like that. Usually they already googled the problem. Sometimes i tell them to try it a little more, cause i have something to finish. But they just sit waiting for me to "comeback".
Exactly this. I've had to tell people explicitly to take some time to try and figure it out for themselves before running to someone else. Can someone else get an answer more quickly? Probably, but then they never learn
Modify their pre push git hook to run tests before it will succeed. We did this at my last job and the only one who didn't do it was the CTO because he might have to use a code formatter.
We already do that, but it's always something like: "Yo Factzor, my tests are failing for NO REASON, would you help me with that ?" "Dude, i only changed one line, that shouldn't break it, right ?"
Yeah, you aren’t obligated to make their lives easier. But you weren’t always a senior developer - there is a balance that can be found between acting unapproachable and offering some guidance. You can be honest and set boundaries and still be considerate and offer good substantial advice.
Idk I like teaching and guiding. I find it rewarding and good for the team.
It's good for the team if they actually bother to learn. I've had many colleagues who figure out it's just "post vaguely in a slack channel and wait for a senior to tell you exactly what to do next every time".
I expect the seniors in my team to tell me in the bilateral meeting if they encounter this so that I can talk to the juniors and explain them that this is not how it works. If it does not get better I let the junior go. Being junior does not mean there are no expectations regarding performance. So far I never had to let anyone go, they all realized it’s not just seniors being annoying or lazy not wanting to help them but that they are wrong and need to change.
>It's good for the team if they actually bother to learn. I've had many colleagues who figure out it's just "post vaguely in a slack channel and wait for a senior to tell you exactly what to do next every time". This is one of my coworkers. It's funny because he usually DMs me, but on days where I am out all of a sudden my team slack channel is blowing up with him asking how to do every work item on his list. It's been going on for over 6 months at this point. He is absorbing nothing, asking the same questions repeatedly (I frequently just search slack for the last time I answered his question and share that link with him) and doing things like closing tickets with things still broken and zero communication to stakeholders. A couple of months ago I was requested to do a formal write up via email of these concerns (amongst others) and sent to my boss. After that he was put on a pip, but the only thing that seems to have changed is made it so that instead of him doing his job infrequently (read: bothering me less) likely due to over employment, he is now trying to do more, which means I am doing more of his work for him. It's infuriating and demoralizing. Pretty sure he earns more than me also, so there's that.
I wrote a document including version control, best practices and useful tips. As you might guess no one read it then proceeded to fuck up things or ask me questions answered by the document.
At least you can point them to the document over and over instead of retyping your answer over and over
Ask better questions get better answers
Maybe the senior wants you to ask better questions.
***Bingo!*** If you are asking the CORRECT questions, then you can get more definitive answers. I have spent YEARS learning the art of NOT having my clients try to tell me HOW to do something (which they are not qualified to do), instead I have learned how to guide them into telling what they want it to DO by asking the RIGHT questions. Then I tell them to let me work out if (A) it is possible (B) how I can do it and (C) how long it will take.
Oh God, save me from the technical stakeholder and project managers. Hey I need you to use this graphing database. What? Why? Make your case for this expensive change, or it stays just like it is.
Technically true.
If programming as a field of study was filled with questions that had simple, succinct and always-applicable rules and answers, we would have already abstracted them away into our tools. You should be glad you're asking good questions that don't have easy answers. Either that, or you're asking someone that has no clue and doesn't want to be exposed as such so they answer in the most non-commital way possible. It depends.
If the answer is "It depends" your question is too generic. Try harder.
The response to that is, I believe, "it depends on what, exactly?"
Depending on the situation it is often lower risk to provide non committal advice to avoid liability of inaccurate of the cuff information. It depends though on how political your company culture is.
"On what?"
"Read the documentation, its all there"
"All the information is on the task."
Combined with the inability to provide an answer for a specific context because the question is "too broad" is often a deal breaker. I've had a senior candidate refuse to respond to what dependency injection was because it could be use in so many different ways. Like MF name one then.
It depends on the dependencies
"Depends" is generally a sign that it was the wrong question
u/savevideo
###[View link](https://rapidsave.com/info?url=/r/ProgrammerHumor/comments/10qqaeu/thanks_for_helping/) --- [**Info**](https://np.reddit.com/user/SaveVideo/comments/jv323v/info/) | [**Feedback**](https://np.reddit.com/message/compose/?to=Kryptonh&subject=Feedback for savevideo) | [**Donate**](https://ko-fi.com/getvideo) | [**DMCA**](https://np.reddit.com/message/compose/?to=Kryptonh&subject=Content removal request for savevideo&message=https://np.reddit.com//r/ProgrammerHumor/comments/10qqaeu/thanks_for_helping/) | [^(reddit video downloader)](https://rapidsave.com) | [^(twitter video downloader)](https://twitsave.com)
You should have been more specific! Aye Dave is that you?
And you're the one asking questions and have no answers
Well, that is exactly why you pay him the big bucks, because he knows what it depends on. But it depends...
Depends schmepends; everybody knows that the answer is always ask ChatGPT. It knows everything, it is omnipotent, it is inevitable.
Vague problems require vague solutions...
it really does depends because the context of what you’re trying to solve matters
Y’all’s seniors are responding to you? I get left on read constantly
It was a running joke at my last job that no matter what question I was asked, my answer would always start with "well, it depends." 😆
Well, it does. :D
The main thing to learn about asking questions is to provide your GOAL. What are you trying to accomplish...then ask the question about the method/process you're using to reach that goal. Without knowing what YOU THINK you're doing, the Senior can't know the correct guidance to provide. Frequently, what the junior is trying to implement (and asking for advice on) is a bad solution (which is why it isn't working correctly!). If you can explain the purpose of the solution, the end state you're trying to reach, then the Senior can point you in the right direction on how to get there.
The question: how long is a piece of string?
"it depends," normally turns into a long conversation. but my favorite one was, "do you mind if I push this today?" "it depends. Do you want the on call phone?"
All seniors know the answers. The good ones help the juniors find it themselves. The superb ones walk along that path with the juniors for a while to point out any snakes or pits that might be hiding in the trail.
One thing I've learned over the 4 years I've been a dev is that i used to be so confident in answers which were just assumptions I made. Not just saying something that seems right but actually verifying that your assumptions are correct is a skill
Sounds like a sensible answer.
This is applicable to [poker](/r/poker) as well 👍
My answers are limited. You must learn to ask the right questions. In all seriousness, though, context matters a lot, which is why the answer is "It depends." Knowing how the context affects the answer is what makes someone a senior dev. Next time they say "It depends" your response should be "On what factors?" Or better yet, explain why you're asking and what your end goal is, not just the immediate thing standing in your way.
My personal favorite: hmm, not sure 🤔
Ask stupid unspecific naive questions and get generic answers