By grunt work, I mean "low skill" for a software developer / white collar professional with a similar income. I don't mean like, minimum wage data entry type work.
I understand that. It sounds like you're describing something similar to what the Google sre book calls "Toil", and I would say that the goal should be to eliminate that kind of work.
While that definition focuses tightly on ops, you can extend it to general swe-ing. A manual, mechanical refactor is probably toil. The eng-time it takes scales linearly with code size. It can and should be automated.
To respond to the specific example in your linked post, you automate the f out of the process and then have the same person do it, but now it takes them minutes instead of hours, or hours instead of weeks.
> I understand that. It sounds like you're describing something similar to what the Google SRE book calls "Toil", and I would say that the goal should be to eliminate that kind of work.
Yes, to some degree.
You'll notice almost everything I point out is powerful automation handed to a user that doesn't really understand it is something to be avoided.
And when I say refactor, I don't really mean "code cleanup" so much as "removing technical debt that doesn't change the current buisness logic".
Keep in mind, my original definition of "Top Performer" was someone who resented even 10% Toil and basically would rather automate it shoddily than deal with it.
>And when I say refactor, I don't really mean "code cleanup" so much as "removing technical debt that doesn't change the current buisness logic".
Well yeah, but in a lot of cases, at least when there's a build of up more than a minimal amount of technical debt, the maintenance of working around the debt-y parts can be a significant drag on development, and itself becomes toil-like. Reducing that isn't something I'd consider toil, and when approached correctly, can be an impactful change.
>Keep in mind, my original definition of "Top Performer" was someone who resented even 10% Toil and basically would rather automate it shoddily than deal with it.
Fair, although I would say that many positions and teams even, can be toil free (or nearly so).
> Fair, although I would say that many positions and teams even, can be toil free (or nearly so).
Yes, and top performers try to move into those positions.
To be honest, in an engineering focused organization it may be possible that tackling technical debt might be viewed positively. Most of the managers I've worked for have been non-technical who don't fully grasp why they are losing momentum due to technical debt and assume its because of the developer(s) assigned being less skilled.
To be honest, I mostly use HN as a sounding board for my own experiences and to see how common/uncommon they are as well as whether there is something I'm legitimately missing.
