[mcv]

I completely agree. Replying with "ask Claude" feels to me like admitting you've lost control over the subject matter and don't know anything about it or at least don't trust your judgement anymore. It feels like saying you're replaceable by AI.

It makes sense to hate and despise that answer.

And yet, I'm not 100% sure I've never used it myself. I will have to watch out for that.

[amelius]

> Replying with "ask Claude" feels to me like admitting you've lost control over the subject matter

Huh, what if I don't want to spend time answering a low-effort question? I will have a look if the default answers/approaches don't work.

[mcv]

What is low effort about "I asked him where he'd look, personally, for the answer to a hard question I was chasing, one without industry consensus. Not what the textbook says. If five studies conflicted, which would he trust? I wanted the thing 30 years had taught him that a search engine couldn't."?

He checked the consensus, the textbook, and 5 studies. He's asking for an answer from experience and he gets "Ask Claude".

But even if you don't know, "I don't know" is a better answer than "Ask Claude", which blindly assumes that the asker hadn't thought of that, which is a weird thing to assume.

[anon7000]

Then don’t answer it? Or just give a seconds worth of context into why you think it’s not important?

[peteforde]

Context switches are not free.

Dozens of "quick questions" over the course of a day will drag down your productivity to about one third or worse.

I know that for me, it takes about 45 minutes of focus to enter a flow state, when I'm at my most productive. If I can never enter the zone, then I'm not really doing the thing that made me such a valuable player in the first place, am I?

[mcv]

He scheduled a call specifically to ask this question. What does context switching have to do with anything? Don't accept the call if you can't afford to switch context.

[peteforde]

I wish I was there with you to witness the look on your face as you slowly begin to realize that something as simple as a call can and often will absolutely pull you out of the flow state.

Someone sneezing nearby can pull you out of the flow state.

The idea that the onus is on the person who you're trying to distract to distract themselves to tell you not to distract them is just so broken if you think about it even just a little bit.

[peteforde]

You're projecting several layers of bias onto this scenario.

The more busy you are, the more valuable your time... the more expensive context switching is. When you are known as the person with the answers, your day is at least partially structured around getting people to leave you tf alone so that you can actually concentrate on getting your own work done.

There's a really toxic expectation that people who are senior should stop what they are doing XX times per day to help other people figure out their issues. Usually there's zero consideration given to how much each one of these interruptions takes away from them. Resentment builds cumulatively.

Before LLMs, this conversation usually went like this:

"What should I do?"

"What do you think you should do?"

"X"

"Do X"

There's only so many times that can play out before you really want everyone to just fro.

Anyhow, you should try hard not to "hate and despise" LLMs. Life is too short to invent paranoid reasons not to use the best tools available. That's another instinct you learn as an experienced dev.

[em-bee]

if this is the experience in a team, then the team already has a problem. i expect these things to be made clear up front.

when someone joins a team they should be assigned a mentor whom they can ask any question, no matter how dumb, and the mentor then guides the new team member in how to approach such a question, which at that point can include asking the LLM. it is the mentors responsibility to point out when it is ok to ask another senior developer. daily standups can also help with this sort of thing.

in a close knit team i would also expect that either everyone can ask anything from everyone else, and that everyone learns when it is ok to ask questions. the situation you describe should simply never arise. if it does, then something is going wrong

[peteforde]

Alternative take: the assumption that senior engineers get pressured into agreeing to mentor without it formally being an acknowledged part of their job - that is, that a significant percentage of their time is supposed to be allocated to making themselves available to juniors - is fundamentally a problem.

There is so much stigma associated with being an senior engineer that simply wants to spend 95% of their day working on the problems that they were hired to solve. The worst part is that the vast majority of people in this situation are not compensated for this time, and they are expected to keep up with their actual assigned responsibilities.

This state of affairs is a relatively new thing. The idea that you would join a company with the expectation that the most important people to the success of a project should drop what they are doing to context shift to someone else's problem several dozen times a day is not something that would have been remotely normal twenty years ago.

I am not saying that mentoring is bad or that asking for help is bad, just that there's been a change and the unspoken vibe is that if you're not happy to work at ~30% capacity because you need to mentor people, you're some kind of antisocial jerk.

If a company wants seniors to mentor, pay them to mentor. It's very simple.

[em-bee]

mentoring juniors should always be part of the job. sharing your experience and knowledge is part of the common job description. the idea that you just write code and never need to share your experience with others is a fundamental misunderstanding of what your work is about. you would have expressly negotiate an exception into your contract if you want that, not the other way around.

what doesn't work is the assumption that mentoring doesn't take any of your time and that you are expected to manage the same workload with and without mentoring. that's not ok. and spending 70% of your time mentoring may also be a bit to much, but if that is what the company needs then it is still your job.

[peteforde]

It seems as though you want things both ways.

The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of. It's just increasingly been pushed on people who haven't pushed back enough to keep a new generation from feeling as though they are entitled to it.

You can sample as large a pool of senior devs as you want; I suspect that if you can find 1-in-10 who have specific wording and structure in their employment contracts about the percentage of their time that they should expect to allocate to mentorship, you'll be beating my own estimations. No, what you're doing is attempting to codify a very polite form of exploitation. Yes, those people are usually among the most well-compensated, but it doesn't change the fact that they have their own job to do and a finite time in which to do it.

Please note that I am not suggesting anyone on a team could somehow work in a vacuum. Also, even the most experienced person frequently needs to ask for help, guidance and clarification. Being experienced is pretty much the opposite of knowing everything and is much closer to a measure of how much you have forgotten.

Nor am I implying that senior people have any business being rude or dismissive towards team members who legitimately have good reasons to interrupt someone's flow state. Timely clarification is important to a project regardless of who is doing what.

What I am saying is that if you run a company you might legitimately be horrified to learn that your most critical team members are spending 70% of their productive time mentoring, especially if that remaining 30% of their time is so fragmented that it never resembles a true flow state. You need those people to Build The Thing.

If you don't get that, then you're not living in the same reality I am.

[em-bee]

The notion that an experienced person should automatically consider mentorship to be part of their job is not backed by any code or contract that I'm aware of.

every job i had, every developer i hired. it is also backed by german law for example, refusing to mentor/train others in the work you do is a fireable offense in germany. in any job. not just software development. i doesn't need to be explicit in the contract. it is a natural and expected part of your job. and in the US with at-will employment, what's in your contract doesn't matter as much either. if it seems like a reasonable request they can just let you go if you refuse. the idea that you should not ever have to pass on your knowledge to others in your company seems very entitled to me.

that's my opinion on the matter. you can find more diverse opinions here:

https://softwareengineering.stackexchange.com/questions/8627...

some even fully agree with you.

i already acknowledged the 70% problem you mention. that should not happen unless it is known and intentional. i'd be horrified too if i were surprised by that.

[mcv]

Why would you accept a scheduled call if you want to be left alone? That makes no sense.

You're the one projecting bias onto this scenario. You assume people only want to talk to you to waste your time. If you work with professionals, you can assume that when they ask you a question, they have a reason to ask you that question. Assuming that they're just being lazy is bad faith.

Accepting a call and then giving someone this kind of non-answer is extremely disrespectful of their time and their professionalism.

> Anyhow, you should try hard not to "hate and despise" LLMs.

That's not what I wrote. You're being needlessly dishonest and disrespectful right here.

[peteforde]

Again: getting a call is enough to knock someone out of deep concentration.

Anyhow, in addition to not hating LLMs, I would add "try not to use dramatic, hyperbolic devices in casual writing, it makes you sound ridiculous" to my advice.