A few year back, an intern on my team was tasked with updating all the instances where we used a certain type of builder function with a replacement that we had written and wanted to encourage our users to use by example. My boss highly encouraged him to write a script to do that task rather than doing it manually, with the argument that even if wasn't any faster overall, it would make the task much less boring that it otherwise would be. That moment stuck with me a lot; a lot of times, we're highly encouraged to be as efficient as possible rather than doing things a way that might be a bit faster but is much more frustrating or boring, and yet we also have a systemic problem of burnout in our industry. Personally, as long as the end result will be the same, I find doing things in a way that will keep me engaged and energetic increases my productivity in the long run, as making the mundane tasks a bit more fun even at the cost of making them take a bit longer will end up making me much more ready to deal with the harder tasks with a mindset that will end up winning back the time lost and then some. (Note that I'm _not_ necessarily talking about something like using a library or framework that could bloat or slow down the final product, since the "end result" is not the same in that case, in which case the difference in the end result needs to be weighed against the potential benefits)

The other reason for automating a repetitive task is to reduce errors. When you do the same think 100 times you're bound to miss an instance, or paste the text in in the wrong place, or whatnot.

But rewriting code isn't always a repetitive task. If you're trying it with anything other than a full parser and refactoring toolkit, you risk breaking the code in ways that you don't realize because you're not actually looking.

If you really have written the same code many times, you might be able to get away with a search-and-replace approach, and with a little luck everything you break will get caught by a compiler. But the more different ways you wrote it, the more likely you are to make things worse.

Learning a refactoring toolkit might be a fun project, but it may well take more than just a few hours. Code-that-writes-code is pretty tricky.

As you say, the alternative is also risky. So getting it right may be worth the effort. But in a lot of cases, it will be quite a bit of effort.

It need not be code; it could be deleting the phone numbers from a plaintext database. Or any number of manual one-time tasks on data.

Yeah, I think you're right, keeping people motivated vs maximising productivity is key to get right.

There's also the angle of keeping your eye in with other languages, e.g learning or keeping your python skills up to date if you need to do a quick bit of scripting to automate a task (and you don't usually use python).

Now come clean and tell us how far down the path of becoming a beach comber you've considered

I live in the mountains and watch sailing videos every day.

Huh. So do I. Now I'm doing something about it. Heading down to Guaymas to take two ASA courses next week.

I posit there is a hackerish view of sailing, especially bigger boats. Complex systems with a lot of dependencies, and eg the weather gods to contend with.

Sailing looks posh from a distance, but it's a HARD problem, and if you don't succeed you could die. There are physical and mental struggles, endurance, knowledge, judgement. But the challenges are discrete, and all contained within a smallish box. And you can upgrade your box like an arcade racer. There's jargon! So much jargon! And there are sunsets and beaches in the bikini latitudes. And there's travel to new places, new foods and new people to meet. It looks like an amazing balance of challenge-and-reward, if you can afford it.

Enjoy your courses. I'm envious.

Beach combing is a career? Hmmm, very tempting.