For an individual, lines of code is a bad measure. Some problems are harder than other and some people do more design or leadership work. However, for the collective this all should average out.

No, the problem is that, in general, the more lines of code you have, the worse your program is. Perhaps people working at home feel less pressure to just code, and are thinking more about the problem and writing less code to solve the same problems - a massive win in productivity, which would appear as a loss by your measure.

On the other hand, perhaps people are indeed writing the same old code that they always were, just writing less of it.

So lines of code are not a good metric. Average number of features/user stories/tasks delivered may be a decent metric (at the group level, not for individual developers), as long as it doesn't become a target. Delivery VS estimate could also be OK, in the same way.

The top comment started off with the argument that you can't know the relative importance of the work. 6 lines of code can do a lot. 600 lines of code can do little. To measure productivity you have to measure how difficult the job is compare how valuable the job is. Most of the time both value and difficulty are unknown.

Across JP Morgan as a whole, the "relative importance of the work" isn't going to change significantly over time. It definitely has nothing to do with WFH. It's far more likely that a drop in LOC is caused by an increased difficulty of mentorship, slower time to resolve blockers, etc.