In my experience for most developers the behaviors boil down to just a few questions?
1. Are the developers willing to write original code or must they be limited to configurations or tooling?
2. Are the developers willing to accept any API (RTFM) or must the developers be limited to prior known APIs?
3. Are the developers willing to accept failure for missing unspecified, but commonly known, requirements such as accessibility, usability, security, or domain specific knowledge?
4. Are the developers willing to alter their personal routines to accommodate a shift in requirements and delivery dates or do the developers shift requirements to accommodate their routines, such as work-life balance?
5. Will the developers write technical documentation to describe process and approach or will the developers shift requirements in anticipation of forth-coming technical documentation?
6. Will the developers refactor code to achieve simplicity (imperative), descriptive concepts (declarative), code style, or not at all? The motivations generally do not overlap.
7. Will the developers accept code that better achieves business concerns or end-user preferences (object measures) in violation to preferred structures or styles (subjective measures)?
8. Are the developers willing to read the existing code (RTFC) before recommending new tools or solutions?
I really want this kind of research to flourish, but the first click I made on an interesting looking paper led me to: "To measure tool usage, we randomly sampled code changes from four Eclipse and eight Mylyn developers and ascertained, for each refactoring, if it was performed manually or with tool support. We found that refactoring tools are seldom used: 11 percent by Eclipse developers and 9 percent by Mylyn developers."
To be fair, I haven't read the paper and the rest of the abstract looks reasonable: "To understand refactoring practice at large, we drew from a variety of data sets spanning more than 39,000 developers, 240,000 tool-assisted refactorings, 2,500 developer hours, and 12,000 version control commits."
But what the heck is the first bit for? Of 12 people I know, the vast majority don't use refactoring tools. That's not the basis on which to launch a study. I've skimmed the abstracts of the other papers as well and I'm not all that impressed. Everything seems to be doing comparisons against Eclipse. While Eclipse has a variety of different usability features, I'm actually not convinced any of them help at all (which is why I don't use it ;-) ). So at the very least, I'd like to see a baseline against a traditional text editor like Emacs or Vim. The "improvements" in usability that they are measuring may simply be the avoidance of problems in Eclipse. I'm not trying to start an editor war here, I'm just saying you can't assume that any single editor is a good baseline. I'd argue strenuously that feature rich editors like Eclipse, IntelliJ, VS Code, etc, etc are particularly bad candidates because nobody has really measured the effectiveness of their features.
Without being too negative, I hope there are better papers on these kinds of topics because I think it's incredibly important.
1. Are the developers willing to write original code or must they be limited to configurations or tooling?
2. Are the developers willing to accept any API (RTFM) or must the developers be limited to prior known APIs?
3. Are the developers willing to accept failure for missing unspecified, but commonly known, requirements such as accessibility, usability, security, or domain specific knowledge?
4. Are the developers willing to alter their personal routines to accommodate a shift in requirements and delivery dates or do the developers shift requirements to accommodate their routines, such as work-life balance?
5. Will the developers write technical documentation to describe process and approach or will the developers shift requirements in anticipation of forth-coming technical documentation?
6. Will the developers refactor code to achieve simplicity (imperative), descriptive concepts (declarative), code style, or not at all? The motivations generally do not overlap.
7. Will the developers accept code that better achieves business concerns or end-user preferences (object measures) in violation to preferred structures or styles (subjective measures)?
8. Are the developers willing to read the existing code (RTFC) before recommending new tools or solutions?