Yours, former excel guy.
In places that people don't realize it's part of their job to learn the tools, it often turns into complaints of "why they designed it that way?" going on and on with dissatisfaction of the system that doesn't read their mind. (And certainly, they will come back with the same question in few days...)
I've been there a decade ago and it was DRAINING that I was just better off not offering the help altogether.
Blame goes both ways. And the original point still stands. It is productive to teach someone to improve their own processes.
You spend time explaining on what is essentially deaf ears, and being on call all the time
They often have often accumulated bad habit, and won't listen to you because "I have been doing this way for years."
Also, it's interesting to observe that many who struggle in Excel (or many of "consumer" applications) actually are struggling in basic computing skills. (e.g. can't tell difference between left and right mouse buttons, don't know how to copy files, etc.) It often result in infuriated people, pointing out that they need to learn basics of the operating system.
It rapidly recedes from the realm of reasonable considerations once we're talking about someone providing informal Excel support to colleagues as an extracurricular activity.
Then you destroy their work area with a hammer when they come back for more help on the same thing. (obviously humor)
It's just like teaching.
Source: I'm the 'excel guy' in my service area. I tell them I'll show you twice and I'll make sure you don't have any questions. Then I'll show you youtube videos. I'm not in the business of 'doing' for anyone.
Being able to share mastery is a key part of being a master at a subject, which is a political and image advantage.
I used my excel ability to learn how to best explain vlookup and got good at it.
I did get taken advantage of early on, but I learnt how to deal with those specific types of users, and not do their work for them.
In contrast to those people, there are others who genuinely respect you for your help, and then use your training to make their life and yours better.
Not to mention, many excel problems are not that hard. If you know what you are doing, it’s an easy win/goodwill for you, and a major problem for someone else solved.
I love talking about git workflow, and am happy to spend a half hour diagramming how your repo relates to origin, what branches mean, how pull requests and merges work, and what rebasing does. For people who don't yet grok git (or maybe just distributed source control?), this has proven to be very helpful.
I typically present this information about 2x a year. However, if I had people ask me for this kind of explanation every week, or multiple times a week, it would have a much larger impact on my productivity.
Excel is also notoriously opaque when it comes to debugging, so there often are not useful questions to ask Google if you don't already know or understand what you are looking for.
Debugging: "excel debug a spreadsheet" - quite a few decent returns on page one and two. Related searches in Google gives some more hints.
I'm willing to bet that I am not alone.
Don't be too hard on Excel - some of today's clueless spreadsheet monkeys will be real bona-fide developers in fifteen years.
I converted planning from Lotus 1-2-3 to MS Excel (for shame) and then with my smart Pentium 60 based machine, developed a nearly complete finite capacity planner for the factory - in Excel. The devil is of course in the detail but my labour plan and forecasts beat the planners most of the time - except at Easter and Christmas.
Today, I'm really not a developer 8) I grew up and became a sysadmin (oh and a managing director - but that's another story)
Warning: This is from memory quite a while ago and it was a very minor part of stuff I did at my job then.