Learning to code: Week 2 - Entity Framework
This week I spent some time learning more about EF (Entity Framework). Entity Framework is an ORM (Object Relational Mapping) framework. Mr. Miyagi has made significant use of this in the project we are working on together (mentioned in my previous posts). Now I understand why better than I did earlier this week. Essentially, Entity Framework removes the need to write lots of potentially tedious SQL statements to get data into and out of a relational database system. EF is essentially a layer between the C# code and the SQL database.
The most helpful resource for learning about Entity Framework that I found this week was a PluralSight video series from Julie Lerman (@julielerman). Julie is clearly an expert when it comes to Entity Framework. Her video series got me to where I really understand how the C# code in the project with Mr. Miyagi is getting data into and out of our database. That was a big help. As an infrastructure guy, I like to understand exactly how something is working. Julie’s videos really helped with that quite a bit. I was able to see how C# using EF was turning requests in code into SQL queries. So, overall it was a good week learning.
I’ve come to realize a few things this week.
#1 – Currently, the more I learn – the more I realize I need to learn about more things. For example Entity Framework makes use of Linq Methods and Linq Query Syntax. While I now have a good basic understanding of how Entity Framework works, I now also realize that in order for that to matter much, I need to become reasonably proficient at Linq as well. I’m hopeful that soon this will settle down a bit and I can quit learning entirely new things and settle into learning about these things at a deeper level. For now I am very much still in the “drinking from a fire hose mode”.
#2 – The body of knowledge required to be a productive developer is large. Its increasingly clear that learning to code C# / MVC Framework (with all of its related parts / pieces) is going to continue to require some substantial work. This is not something you tinker with for a couple of weeks and suddenly get great at. I’m ok with this. If I’m a reasonably productive developer by the end of 2016 – I’ll still be thrilled.
#3 – My existing background in I.T. infrastructure, while seemingly related has not been much help so far. To an outsider, one might think “Ahh – David is good at infrastructure, I’m sure he will easily be able to pick up this code thing he is working on.” The uninitiated might think the two are more closely related than they are. Frankly, so far the large body of infrastructure knowledge I’ve built up through the years has been of very little help. From what I can see so far, development is mostly a separate body of knowledge.
Previously, in my infrastructure work I’ve easily and quickly picked up what I will call complementary bodies of knowledge (virtualization / security / storage / cloud IaaS / etc). These built on or complemented my existing infrastructure knowledge. So, learning them by comparison was easier. So far learning to write code has been different. There simply is not nearly as much cross over. Infrastructure folks who want to learn to code – you have now been warned.
My hope is that in the future I will be able to leverage my infrastructure knowledge and my ability to write code in a way that takes advantage of both bodies of knowledge.
#4 – Higher developer productivity. Mr. Miyagi said this to me before, but now I am starting to understand it at a different level. The Microsoft .Net / Visual Studio world is designed with developer productivity as a high priority. More and more I can see how that really is true. EF alone removes what would otherwise be an awful lot of repetitive / boring work from the development workload.