Maybe the question of "How do I measure developer productivity?" is to broad to be useful?

Per the article, what managers often actually want to know is "How do I detect when a developer is so unproductive that they should not be retained?".

What are some behaviors that developers have when they've "checked out"? Not showing up to work or logging in is an obvious example. Lines of code might be a poor metric, but maybe the bottom 1% of coders in that metric is a sufficient detection for poor performance?

...at least as a detection mechanism to highlight for further investigation?

The manager rarely needs to detect when the developer is that unproductive - it's glaringly obvious. In practice, even if you as the manager don't notice, the team will tell you that another developer isn't pulling their weight. However, you can't just fire someone in most organizations because their teammates have a gut feeling -- you need to have evidence as you get a case together. Further, some causes of poor performance are temporary; some are an indication of a lack of skill that can be remedied; some are that someone is a good worker in the wrong place in the organization; Sometimes, a developer is just lazy. A good manager will be able to discern this and determine if the solution is to change the environment in a way that brings success to the dev.

But if the case is that the developer needs to be "managed out," you need to build the case as a manager. This is where those metrics help.

Your best programmer will likely remove thousands of lines of code from your application and replace them with just a few lines.

For a manager there is no universal metric other than the hard work of understanding what your employees are actually doing.