Good point raised. Just to expand a bit, manual vs automated for some people may mean dull vs fun. So doing some manual work (even if it’s somewhat faster) may actually spoil the day for some in a similar way as redundant meetings. Automating routine can also be a way to hone one’s skills.

On the other hand, the code itself contains shades of automation: Should I just hardcode 2+2 here? Or write x+y and use it? Or write a meta-routine, which will automatically produce a routine x+y to calculate 2+2? Etc.

Cases differ. Number of “meta” depends on the understanding of the problem domain and how often routine happens. If your boss wants some numbers today, one can be sure the same is very likely to happen next month, so it’s probably wise to at least save SQL query somewhere. There of course can be truly unique tasks, which will unlikely to repeat.

On the other hand, generalizing something can require the same amount of efforts as a partial case solution or maybe even the time required will be less. In my opinion, one’s biases towards “generalizing” make one more efficient with more generic solutions. And for others generalizing may require extra efforts (provided problem domain knowledge is the same).

Code is not always the best answer, but I’d argued “no code — code” decision repeats on many levels as “code — metacode”, which programmers are supposed to deal with well. It’s always case by case.