D3v3l0p3r PF3s – 0bs3rv1ng Th3m in Th31r Natural Hab1tat
PFE has engineers who specialize in areas which can contain one or more technologies. This species is universally known as D3v PF3 (Developer PFE). Not everyone really knows their habits and role and, as a consequence, sometimes it’s hard for customers to engage them.
Their specialty is problem isolation, application debugging, knowledge transfer, code review, creating tools and troubleshooting. The D3v PF3s are very skilled engineers that don’t have a product specialization.
D3v PF3s tend to work from their habitat and prefer to not go onsite to troubleshoot issues since that usually increase the Time to Resolution (the amount of time it takes to find the root cause of a problem). Debugging is a very time consuming operation so, contrary to what most folks assume, being onsite unnecessarily is not going to help to be more productive and it’s not going to help isolate problems faster.
Observing the behavior of D3v PF3s, you’ll notice another thing about them: they love to create tools. There are many tools and scripts that have been created by PFEs. That’s actually a good way for D3v PF3s to exercise their software development abilities while helping customers because, at the end of the day, these tools are going to benefit our customers.
Sometimes when isolating software problems, D3v PF3s start working on problems in the application and then move to 3rd party component or in our Microsoft products. When a D3v PF3 encounters this, he may need to engage the 3rd party vendor, another PFE who had the product expertise or CSS to have an Escalation Engineer to work with the product group. D3V PF3 is the last resort to provide workaround for a problem.
Here is what they do:
- Debug and troubleshoot applications. By applications I mean C++/C applications and .NET applications. These applications can be services, desktop, web and virtually any type of application or process. They consider Exchange an application ;-)
- Problem isolation. It’s very common that many products are involved (also 3rd party) and if necessary will collaborate with customer’s support vendor to help them to find the root cause
- Debugging trainings where they teach our customers on how to debug Native/.NET applications
- Tech talks where they teach our customers how to use troubleshooting tools to isolate software problems, like the PFE Developer Toolbox Workshop
- Code Reviews, where they analyze the customer’s code against Best Practices
- Sample code, like samples in PowerShell, C# or other Microsoft programming languages
- Labs with customers. Notice that although lab is considered proactive work because Dev PFEs are helping the customer with their application before they deploy it, the nature of the work is reactive: they debug and troubleshoot their application during the lab engagement
Example of situations where you can leverage them:
- SharePoint application consuming high CPU
- Slow ASP.NET application
- C++ application crashing
- Windows Service consuming too much memory
- Performance Labs with customers to troubleshoot/test
their application
- Performance problem where it is not clear
what the layer causing the bottleneck is
- %productname% is having performance
problems, crashing, etc
- “sample code” to automate some operations
To know more about Developer PFEs check the videos below where Brad Linscott, one long timer Senior PFE, explains how to isolate some typical software problems, also explaining about the framework we use to isolate problems.
Here are all Brad Linscott videos about .NET Debugging for the Production Environment!
I personally watched each of these videos and they are superb! Brad did a great work on explaining debugging scenarios we often encounter with our customers.
Soon he’s going to prepare another video about memory issues related to .NET application.
Happy bug hunting! :-)