From my DBA role, I also did ran into problem while finding problem "code" on and off
The tools I use most being from the SQL Server side, so I could find which T-SQL statement being most fruitful for tuning (e.g. use most CPU / use the most IO / run the most often etc), from even just SQL Server DMV of procedure cache ...
However, developer are usually talking on their own "dialect", where T-SQL may not always part of that, so fail to communicate is usually the roadblock on such exercise.
Entity Framework is a case (while the earlier post in this topics already discussed), while another arise from an ERP (we use SAP)
The Problem is : developer may not exactly know which statement / "code" they written actually cause the poor T-SQL where DBA recognized.
In fact, the T-SQL statement is just the "product" of the "data tier middleware" (e.g. EF, etc) developer use, which translate their code into DB engines dialect.
For SAP case, (as I am newbie of SAP, 3 years before), it was not until I understand its tools (called "DBA cockpit", or, I just recognized invoke by so called SAP Transaction "ST04") can I become effective to discuss with Developer what they should be watch out.
I guess as the proliferation of all kind of data tier middleware in developers' world, any such tools vendor must also match it with its own "translation tools", so as to allow the generated T-SQL to be back tracked to original statement. (I see SAP tools' use some sort of machine generated comment, which indicate the module / line of codes from which corr. T-SQL statement being generated)
I would be much appreciated if anyone can teach me on any such method applied on "Entity Framework" or any other such kind of "data tier middleware".
(Our development team comes with all sort of tools, they just need not to tell DBA what are being used, until they really need to seek for help)