> "Too often someone with an automation mindset will see an task and decide that it can be automated without actually understanding half of what the task involves."

Depressingly common. And also depressingly futile to argue against sometimes.

Person tries to automate something they don't understand. They come up with simple, elegant "solution" that fails to address half of what the task involves. When presented people are, naturally, "what about X?", where X is important and addressed in the previous solution, and not at all addressed in the simpler, more elegant new solution.

Cue blog post where automator complains about how "management" piled on "edge cases" "at the last minute".

The problem is often that the project is underspecified from the beginning, people are very bad at specifying their requirements. I think this is because the edge cases can seem so obvious for someone experienced in X that they don't see the need to mention them.

I've experienced situations like that on the other foot, where the people above me are saying "We will spend our money on X to solve our problem", when it was obviously not an adequate solution. It really makes you feel like your expertise doesn't matter and that the captains are happy to run the ship into the rocks, so long as they are the ones who get to steer.

> Too often someone with an automation mindset will see an task and decide that it can be automated without actually understanding half of what the task involves.

I know I've been guilty of this. The only solution I've found--be humble and ask as many questions as you can. (I guess working in the job for a few months is another solution, but sometimes that is a luxury you can't afford.)