All the activities you mentioned are part of what you're being paid for as a developer, so you should consider yourself to be productive while doing them. If your employer thought that setting up your environment wasn't an essential part of your job, they'd be paying someone else to do it for you. And if they don't want you to write crap code, then finding an efficient way to write a method is also an essential part of your job, and thus productive. And how can you possibly fix a bug without first researching it to figure out the exact conditions that cause it to occur? Even meetings are productive, provided that they allow people to come to an agreement on how to solve a problem (rather just being for status reporting that could be done better with an automated tracking system).

"When I'm completely focused on coding, I'm at my most productive."

What if that code turned out to be the solution to a problem that didn't actually exist? Would you still think you were productive just because you were completely focused on coding at the time?

Now, look at the other side: Let's say that during a meeting, you figured out that some piece of code that your company wanted you to write was completely unnecessary, and it saved them hundreds of hours and thousands of dollars. Wouldn't that be productive?

And if you refactor 1000 lines of code to do everything it did before with just 100 lines of code, is your productivity negative because you threw lines of code away?

As developers, we're paid to solve business problems, not just to generate lines of code.

I'm not suggesting we count lines of code, but I'm only actually producing when the code I write makes it into a final product. If I spend 5 hours writing code, and then throw it all away, I'm not productive. When I re-write a bit of code, was I productive the first time and not the second? Was I productive both times? Does it matter what has changed between the time I wrote them both, or why I'm making the change?

Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business? I may not have, and therefore, that time was unproductive, or I may have added value, and therefore the time was productive.

Interestingly, it seems the definition of productive may be up for debate itself.

Writing throw-away prototype code can be very productive, since it's a way to learn about your domain and the problem you're trying to solve. It can certainly contribute toward making a better final product. If we're trying to solve hard problems, we can't expect to be able to come up with a perfect solution on the first try with no backtracking.

As Thomas Edison said about his numerous unsuccessful attempts to make a light bulb, "I have not failed. I've just found 10,000 ways that won't work." Each unsuccessful attempt got him a bit closer to being able to make a working light bulb.

"Using your example of refactoring 1000 lines of code, if the 1000 lines ends up doing the same as the 100 lines, how have I added value to the business?"

Speaking from first-hand experience, sometimes the code base you inherit is so bad that you can't add anything to it without breaking it. By refactoring, you've made it possible to add the new functionality to the code which your customers desperately need. You've also probably made the code more reliable, since there's less stuff in there to break in the future.

On the other hand, if you had code that worked perfectly and didn't require any new features, and you refactored it merely because it offended your sense of esthetics, then you were probably not being productive.

Wikipedia on the merger between Edison and Swan - "The lamp bulbs manufactured by the company were almost entirely to Swan's design."

It's like throwing away the scaffolding that was supporting a building during construction but is now redundant. It's like removing the stone from the sculpture that isn't part of the figure you're trying to create.

Concise emails really ease the workload by reducing inefficiencies.