There has been a post going around LinkedIn that goes something like: "Are you really a programmer if you haven't spent 40 hrs automating a 2 min task.” I wanted to add my own spin on it so I added in: Have you really worked in data if you haven't spent 40 hrs automating a 2 min task. On the flip side, many experienced data engineers and analysts will find a task taking 100s if not 1000s of hours a year and spend 10 hours automating it.
Really appreciate you mentioning the point regarding how learning to automate a task also helps build skills and understanding of the underlying process. I think it's a great way for a more Junior DE, such as myself, to be able to make more of an impact on the team, especially if you can identify a pain point and try lean into it. Anecdotally, I have tried to pick up work that reduces the amount of manual support we have to do within our team and I can see that it's definitely having a productivity impact.
“Toil is the kind of work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”
Really appreciate you mentioning the point regarding how learning to automate a task also helps build skills and understanding of the underlying process. I think it's a great way for a more Junior DE, such as myself, to be able to make more of an impact on the team, especially if you can identify a pain point and try lean into it. Anecdotally, I have tried to pick up work that reduces the amount of manual support we have to do within our team and I can see that it's definitely having a productivity impact.
Since you asked for a technical term for annoyance, I would suggest copying SREs and calling it "toil":
https://cloud.google.com/blog/products/management-tools/identifying-and-tracking-toil-using-sre-principles
“Toil is the kind of work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.”