I wonder if it's possible to turn things around for some people: Sitting around relaxing, and then doing their work in bursts of cleverness, may be a coping mechanism for someone who has a hard time staying continuously busy all day long. Or maybe there's a sliding scale between those extremes.

I fall somewhere towards the side that you might guess, since I'm defending it here. ;-)

I don't necessarily automate my job, but I depend on things like math and theory, to solve problems that the other engineers tend to solve laboriously through brute force and trial-and-error. I suppose a math equation is a sort of automation. And of course programming is how one does math these days.

Maybe I avoid resentment, because I'm doing work in a way that most people hate even more than doing hard work. It's also hard for them to pin down how much I work because they don't know how to estimate it.

Hypothetically, if someone wanted to debate with me about the value of work, I'd ask them how work is measured: What are the units of measure? Joules? Hours? Indulgences? How about... dollars?

The only time that we don't measure work in dollars is in a social setting, including within the workplace. For instance, we don't give motivational speeches and other kinds of attention such as meetings in proportion to your wages, but tend to treat all workers relatively equally in those things.

While not everyone on HN is a developer, it does tend to skew that way so I don't feel guilty pointing out how frustrating it is to measure the output of a top programmer.

Often, a mature codebase shrinks as code quality improves. This drives the efficiency wonks absolutely bonkers.

>This drives the efficiency wonks absolutely bonkers.

what do you mean by that?

I think they're referring to the problem of measuring programmer output (and thus, measuring programmer efficiency). And how the output of that work (lines of code) can actually be reduced, but still considered productive.

I'm not putting this very well.

In most areas of business, there are important signals which can be observed that are often based on counting values over time. There are people for whom it is their primary job function to identify what should be counted, and how.

When a codebase shrinks AND increases in quality, you've now demonstrated that the most obvious way to quantify the utility of a resource - units of productive output - is not useful. So now people who are used to tallying widgets and graphs that are "good" if they move up and to the right, now have to understand things like refactoring, technical debt and design patterns.

> I don't necessarily automate my job, but I depend on things like math and theory, to solve problems that the other engineers tend to solve laboriously through brute force and trial-and-error.

What sort of work do you do?

> One thing that I find maddening about this topic is the assumption that people who automate their jobs won't take the new time they get back and put it to better use.

I think it's fair to say they will, but will they do so for their company's benefit? Possibly, but why? This is effectively gifted time.