Data collection and metrics can be involved in multiple areas: services and developer environments. This page focuses on the developer environments part of the problem. For services, there is a brief mention in Service/App Databases.

Developer laptops are a developer's environment. Some people are very against any collection at all, which is fine. We have no need to push the issue as long as the majority of people do not opt out.

As a developer laptop is the company's property (presumably), then we can collect data by default and allow people to opt out.

When collecting data, make the same promises with respect to privacy as you would your organization's customers. Collect only what you need, and try to keep the data anonymized.

Some possible data points to collect are:

• How long does it take to get the system ready, on average, for a project?
• What editors are installed?
• What percentage of the time is this computer connected to the internet?
• How often do setup tasks fail?
• How often do they succeed?
• What tasks fail?
• How long do individual tasks take?
• What commands do people run within your tool?

Common metrics collection tooling include StatsD, Datadog, intercom, and Splunk. However, you can integrate with whatever your organization uses.

You should also collect bug reports. This will help you track down issues on developer laptops in the tools you create. Don't worry about anonymized data here, developers love having you reach out to say "Hey, I noticed you ran into a problem with our tool. Want some help?". It also helps that they can see explicitly what is in the bug report. Speaking of which, don't include the ENV var. Developers like to store tokens and passwords in there. You can pick out specific things though, like PATH.