If you’ve worked on Azure or .NET for awhile—like Azure Functions and Entity Framework—you’re probably familiar with Jeremy Likness, the senior PM for .NET data at Microsoft. He’s spoken at several conferences (remember those?), writes about various topics at his site, is a familiar face on various .NET-related videos, and, as of late, can be seen in the Entity Framework community standups (and more!).

I caught up with Jeremy to talk about his path to software development and all that’s going on with Entity Framework and .NET 5.

Last week, we got to know Jeremy. Now, we’ll get into his work and discuss Entity Framework and .NET 5.

We go through a lot of resources in this post. I’ve included them all in a list at the bottom of this article.

To be honest, when I think of your role as the “Sr. PM of .NET Data,” I mostly think of “Sr. PM of Entity Framework.” Does anything else fall under that umbrella?

Entity Framework is certainly a large part of what I do, but the role is really about all of the ways that .NET developers interact with data. In addition to EF Core, I also deal with big data and manage .NET for Spark. I don’t just limit my scope to products I’m directly responsible for, but also focus on things like OData, gRPC and GraphQL for connecting to data over APIs.

I’m interested in improving the experience for the products we own at Microsoft as well as supporting community projects like Hot Chocolate, GraphQL .NET, and Dapper—just to name a few. I work closely with the team responsible for the SQL client. I work with Azure SQL and Cosmos DB.

I’m focused on an initiative to reorganize our documentation to have a landing page for .NET Data so that developers can find what they need with just a few clicks. It will focus on topics ranging from storage and NoSQL to relational databases, cache, APIs, and more. I encourage anyone reading this to participate and share feedback using the GitHub issue. Our goal is to provide the best possible experience for .NET developers working with data, so you can imagine there is a lot of surface area to consider.

That’s actually something that applies to the EF Core team as well. They are branded based on that product, but are really passionate about all things data-related. The team “owns” System.Data.

#[object object] #[object object]