Developer Surveys help you figure out how your team is doing, find out pain points developers might not otherwise mention, and get an overall feel of the organization.
Note: Don't send too many a year, or people will get tired of answering surveys. It's best to coordinate internally, if possible, to minimize the number of surveys going out.
Some Questions you may want to consider:
Ideally every question should have a hypothesis around what you’re asking and what you expect the responses to be - in other words, something is being validated. This will help ensure you keep value high while avoiding asking too many questions.
We can’t always be ideal, so we need to remember a few things about questions. While “measuring system” questions can be useful in some senses (e.g. on a scale from 1 to 5), you should make sure they aren’t written as to invoke negativity bias (e.g. how often do you experience <negative thing>) as negativity bias makes us remember the bad stuff more often and over report it.
General Example
Example Developer Satisfaction Survey
Wave's Survey
Once the survey is complete, it is important to analyze and publish the results. This shows your users that you're doing something with the time they spent. It's also important to make sure you're creating action items, and following through on them.