There is the notion of breadth developer, which encompasses the attitudes of the practical mindset: How can I do such and such task in a straightforward way? For example, I need to analyze a set of VB6 legacy applications and enlist all stored procedures invoked per subroutine per application, how can I use C#’s iterators to scan a large set of VB6 projects and VB6 source text files to group invoked stored procedures from each subroutine from each VB6 project?
There is the notion of depth developer, which —seems to me— encompasses some attitudes of Elvis and Einstein developer stereotypes: Why such and such works this way? For example, why yield return statements are allowed within C#’s iterator blocks whereas return statements are not?
I like to think about breadth or depth developer, or Mort, Elvis, or Einstein developer stereotypes, as roles we could play accordingly to the task at hand. One difference between these stereotypes is the number of concepts that you need to understand before you can do any production-grade work. Whereas the breadth developer enjoys any amount of syntactic sugar that helps to get the job done with a reduced set of conceptual prerequisites, the depth developer enjoys sugar-free programming in order to fully grasp what is behind the scenes of what was just done while in the breadth developer role; also, to jump from a mere effective to a more efficient solution.
I have done some contemplative explorations on the MSIL code generated by the C# compiler that have been found useful to satisfy my curiosity about iterators, deferred execution, extension methods, eager/lazy evaluation, lambda expressions (anonymous function expressions, anonymous method expressions), anonymous delegates, query expressions, etc.
I will share my findings with those contemplative explorations in future posts.