Doing something tedious and manual is a good way to let your brain unwind and kind of meditate. After a bit you get all sorts of insights into how to make the process work better. Or if there's nothing at all worthwhile about the process, your subconscious can still be solving other problems in the background.
One of the problems I find with impressing people with your technical abilities is that they start piling projects on you and you stop doing the tedious stuff that teaches you what needs to be done and how.
The greatest frustration in my career has been that everybody wants to do grandiose automation projects without being willing to assign any proportional effort and talent towards understanding the existing processes.
Amen, I've seen so many failed attempt to automate a process that hadn't even been attempted the "slow" "unscalable" way first. Doing a task manually a few (dozen?) times will reveal a disproportionate amount of information about what actually needs to be done.
Agreed, you want to do it the hard way first to get real insight into the problem. By the time you get around to actually automating it you'll be ready to.
Am fortunate in my present position that the projects I get tend to be complex one-off types. I have a lot of leeway on how it gets done as long as the software engineering aspects are sound.
I've had the opposite frustration at times in the past, where people around me were content to do it the tedious manual way forever. As a typical Perl programmer type that was kind of painful :-).
One of the problems I find with impressing people with your technical abilities is that they start piling projects on you and you stop doing the tedious stuff that teaches you what needs to be done and how.
The greatest frustration in my career has been that everybody wants to do grandiose automation projects without being willing to assign any proportional effort and talent towards understanding the existing processes.