But that is hard!

I've experienced management that could only evaluate your productivity based on hours in the office. Now, I generally did pretty well at that one, because I was doing a lot of hours, but if I had to come in late because my apartment flooded he was all grumpy, because the one tool in his toolbelt wasn't working.

"But that is hard!"

Who said that being a good manager was easy? Managers also need to work hard to deserve their high salaries. Lazy managers who can't be bothered to do their jobs properly should be fired.

How can you tell if he's an excellent manager who knows not to bother engineers, or just lazy? ;-)

Probably by talking to him. It's not hard to tell if a manager has no clue about what you do.

If he doesn't, then he's probably using some silly and lazy metric like "hours in the office" or "lines of code written per day". If he does, he probably took the time to learn about your job and make a more accurate assesment of your work.

Really, as a programmer you are supposed to know lots of things, learn some more and work hard; but the guy above you cannot be bothered to learn some useful skills in order to asses your work? What kind of logic is that?

A good manager still knows what their employees are working on - not necessarily in detail but they should be able to describe the user side of the project comfortably and have some idea about which parts are the most challenging.

That's the Zen of good tech management!

How would you suggest that they measure how hard I've been thinking? Or whether the direction of my thinking will pan out?

They shouldn't measure either of those things: they should find a valid proxy for those things, such as the output you produce. Frankly, if they're measuring the process instead of the output, then they're likely to just ultimately be micro-managing.

A decent manager should make themselves available to the team, but not interfere with the team unless something's going wrong, or appears to be going down the path of 'going wrong'. They should measure the team by their output, and use that to determine whether things are going wrong, or are about to go wrong.

Attempting to measure a team by their process makes the assumption that the manager is capable of understanding both the current process, and the maximally optimal process against which to compare the current process. It's far safer for both the manager and the team for the manager to avoid such endeavours, and instead measure the output itself against the optimal version of the output, because the output should meet business/product goals against which it can be assessed.

Agile PM would actually put process first and simply measure output because poor processes impact everything else and give you no chance of sustained success. You should be trying to optimise the conditions for optimal outcomes via facilitation. That's the reason you measure, to understand and improve your success as a facilitator for the whole team, not to track individual productivity. You shouldn't reward or penalise anybody on outcomes themselves but on ability and diligence (which should be blindingly obvious to a technical manager given any degree of engagement with the development process).