You Can't Know It All (YCKIA), But Keep Pursuing After It Anyway

Here's how I feel:

I'm 10 times better and 100 times worse than the pool of talent in software engineering out there.

Confused? I'm not bad, but I don't feel like I'm elite either.

I wanted to spew some thoughts here for some time around the endless complexity and challenge that exists in our industry which is software development. This post is not some self-pity loathing about the challenges, but rather to present a challenge back and a certain clarity to others that there is always more to know. But don't let your head get too big because (wait for it... my 1st acronym that I made up): You Can't Know It All (YCKIA)

Here we go developers on the Microsoft Stack: C#, VB.NET, WinForms, ASP.NET webforms, ASP.NET MVC, MVC Razor Engine, MVC .aspx engine, JavaScript, AJAX, JSON, XML, WCF, ASP.NET Web API, .asmx, Silverlight, WPF, HTML5, WinRT, Metro I mean Windows Applications, OOP, Architecture, Design Patterns, SQL Server (which version), Entity Framework, TFS, REST, OData, LightSwitch, WebMatrix, IIS, TPL, LINQ, PLINQ, Lambdas, Async, Azure, SPAs, Knockout, Backbone, Mobile, and an endless amount more. There are several listed above that one can make an entire career out of by knowing well (i.e. SQL Server, TFS, ASP.NET, etc.)

How many of those do you know? Let me ask again, how many of those do you know well? Think your great? Humble yourself and do a quick search on any of the topics and I'm sure you could be humbled quickly by technology, practices, implementations, etc. which you do not know or understand... yet.

Another point. It's not important or a requirement to know them all either. Being great vertically in a single or few topics is quite powerful so that's not the message either. In fact look at the prestigious Microsoft MVP award. It is awarded to an individual who contributes in an exceptionally or revolutionary way to a single technology or area (i.e. MVP of C#). However examining the inverse of this shows not to be too concentrated or narrowly confined to a finite few technologies or you might find yourself obsolete in a few years. For example being a strictly ActiveX guy from the late 90's, a solo Silverlight gal from the late 00's, or a classic ASP pages thing from the turn of the century are some areas that one should diversify their learning portfolio to continue strong.

I remember thinking early in my career it was so taboo to state that you didn't know something, or at least understand it at a broad level. "What, ha, ha, ha little dufus, you don't know what OO COBOL Web Services Are??? Please turn in your certification to be able to develop applications" (if you thought that OO COBOL Web Services are something to research please don't and hint sarcasm). This is far from the truth. I remember going to some of my 1st big conferences and have industry leaders make statements like "Yeah I really couldn't answer that because I don't do web development " What!?!? Again I say What!?!? You are speaking at a conference and it is presumed you know a little something about .NET and you don't do web development? Yep that's correct, and that's 100% OK.

Let me state again, YCKIA. I wonder how many times I have thought to myself, "wow I feel like the jack of all trades and the master of nothing." Being spread too thin is another challenge to concur.  While it is fun and actually useful to know a lot about everything, it is typically advised (or at least my advice) to narrow in on a few topics to really sharpen your skills against. You will be more marketable regardless of the arena if you are very deep in at least a few key and relevant topics. If you find yourself getting too broad, make an assessment of what is valuable today and going forward. Then begin to lessen the efforts of a few outlier technologies if needed to focus on the more important ones you are interested in using and continuing to learn. If you are a engineer by profession your job may dictate this. If you are a hobbyist  you may be able to stay more broad as you are not relying on your living from doing it routinely.

So how does one become elite in knowledge anyway? Well that's a matter of opinion. And really even the elite in my opinion (i.e. for the .NET world, maybe a C# CLR guy up in Redmond that knows the framework inside and out is someone well along their way) have the YCKIA issue as well. However the measurement of success is not by how we view our self but how the community sees our projection and contribution to 'move the ball forward' in the field of software engineering. For me that's the folks that write books, speak at volunteer based events in their free time, contribute to forums, write blog posts, draw and share on a whiteboard to peers that want to learn and observe, folks contributing to open source projects, and more of the like where the output given unselfishly is equaled or greater than the input absorbed.

Are knowledge and success liner? Not necessarily, so don't use it as a single motive. Ever know or interact with the guy or gal (or thing if you like science fiction, and to encompass all here), with the brain that is a real jack ass? Yeah don't be that person please. These are the folks that might argue against YCKIA, for the fact that IKIA (I Know It All). It's tacky and comes off as arrogance so steer clear of that attitude. Fortunately for these folks there are outlets and dark rooms where they can produce solutions and make a great living regardless of their arrogance and bad attitude. A little humility would do them well, but so long as they don't have to interact with others all that often they stay in the safe comfort zone. These folks don't need as much learning on the stack but rather in the etiquette of manners, cooperation, and team work. There are books, seminars, and others willing to teach so there is more learning even for the naturally gifted.

On the other hand, ever meet or interact with the brain that is the mentor of all mentors? These people are great and rare. Gravitate toward them and you will learn a lot. These folks are the type that have a similar sentiment and are constantly pursuing more knowledge in an effort to better themselves and those around them. They are the gems of our field so be on the lookout. 

Even though knowing it all is an impossibility, especially in the field of software engineering, we should try to pursue it anyway. It will never occur but learning is something that should never cease in your career. I have never been able to settle for "cruise control programming", where one tries to use a model from previous to do things over and over and over the same way each time. If we all did this, we would still be using punch cards or have 5,800 lines of code in frmMain as we did in our 1st major Windows VB6 application (if you still do this, here is an opportunity for you to grow your knowledge further; ask for help if needed). 

Folks like this in our industry do fill a void as there are billions of lines of code in existence that need to be maintained. However the natural progression of a skilled software engineer should be to take care of other people's code for the first 5ish years of our career and then begin seeking out writing our own code. Most people do actually follow this path, but to be successful you will have to push the envelop of learning to be truly successful. Otherwise one would find themselves writing new code in a manner of old as they were reared writing the code they maintained for so many years.

This learning process though can be overwhelming as there is an endless amount of knowledge to consume in the field of software engineering. To add to this challenge, there are very few set guidelines or certainties in our industry so there are always various ways to solve an identical solution (some obviously better than others, but yet multiple ways always exist). This pursuit of adding knowledge though becomes increasingly difficult as we challenge ourselves into solving more complex solutions for larger systems. It also becomes easier as the field is not 'new' anymore as when we started so comprehension tends to happen at a faster rate for familiar topics.

This brings me full circle to my original sentiment about not being able to know it all. I do believe that those with the same sentiment of mine are humbled by those that know more and continue to seek additional knowledge and better ways to solve a problem in the software engineering realm. While it feels like we can't catch a breath to be able to keep up with what's new and valuable for use in our .NET industry, those of us that enjoy and want to better our craft will continue that pursuit of knowledge  Even if YCKIA, your efforts in pursuing the endless amount of knowledge will pay dividends to yourself, the solutions you provide, and the betterment of our industry for the quality code that you laid down that was the byproduct of your efforts. Even if the euphoria of having an elite amount of knowledge is quite rare and in some respects impossible, the process of learning is still enjoyable and that's one of the main reasons I and many of you enjoy software engineering so much.

Separating Entity Framework POCO Classes Generated From T4 Template in VS.NET 2012

The Entity Framework has come a long way and has some really nice features out of the box when using EF5 with VS.NET 2012. Specifically, if you are using a Database First approach, the generated entities from your .edmx are already POCOs. No more are the classes auto generated and inheriting from ObjectContext as in past versions. You could achieve this affect either manually or via POCO generation extensions in VS.NET 2010, but it is done by default now in VS.NET 2012.

So the 1st thing you might want to do is separate the POCOs into their own layer, separate from the .edmx. You would want to do this to keep your entities free from being tightly coupled to it's persistence details. After all there is no reason the POCO classes can't be used independently and outside of EF all together, and is why POCO support was such a big deal back when EF4 arrived.

There are a few things you need to do to separate the POCOs generated under the .tt branch under the .edmx file in VS.NET. As a side note, remember that the .tt file is just to support deign time tooling and is not compiled with the project. You don't need to have any heartburn with having this file reside near the POCO classes as it is not an indication of the classes being only used with EF; it brings along with it no dependencies to EF.

You may have already tried to drag the .tt file and associated POCO classes in Solution Explorer into a different layer and noticed it did not work. There are (2) ways to solve this issue: delete the .tt file and recreate in a new layer using a new 'EF 5.x DbContext Generator' item, or remove the dependency in the project's metadata file and then move it. Both will work, and I'm going to show you how to remove the dependency in the metadata file and then drag the files to the new layer. I don't get nervous modifying the .csproj files and this is a 1 time change. If you are not comfortable, then just add a new 'EF 5.x DbContext Generator' item to the separate layer and then follow the same steps below. I personally want the ability to move items around and want to break this dependency.

First make sure to build the solution to have all the metadata generated in the .csproj file, and then close VS.NET. Navigate to the project containing the .edmx file, and open the .csproj file for the containing project using notepad. We need to remove the XML element that creates a dependency between the .edmx file and the .tt template file. Search for the line below and remove it:

Reopen the solution and we now have the ability to drag the .tt and associated POCO classes into another layer. Remember, the .tt file is a design time tool and adds no dependencies or references to EF, so when we move these POCO classes they really are independent of any persistence details. Go ahead and drag the object in solution explorer as shown below. Once finished, add a reference to the layer that contains the .edmx to the new layer that contains the POCO classes.

There are (3) more steps to complete the move. 1st, we must update the path to the .edmx in the .tt file. Look for the following line near the top of the project and update as shown below:

The next step is to update the namespace for which the .Context.tt file under the .edmx is using. Because we have now moved the POCO classes to another layer, we must provide the namespace of the new location. If you do not do this, your Model.Context.cs file will have errors upon building. You might be tempted to add a 'using' statement to the namespace to fix the issue, but remember that you are dealing with auto-generated code. Every time the model is updated this class will be overwritten, so we don't want to modify it if possible. The proper way is to update the Custom Tool Namespace property on the Context.tt properties within VS.NET as displayed below:

The final step is to delete the original .tt file containing the POCO classes from the layer containing the .edmx as shown below:

The one step we must remember now is to run the Model.tt file manually now when we want our POCO classes to reflect an updated model. This will not happen automatically anymore as we have moved the POCO classes away from the .edmx. However it is as simple as right-clicking on the .tt file where the POCO classes are located and select 'Run Custom Tool' as shown below. Test it out by making a change to the .edmx model (i.e. change a property name), and then running the T4 template to recreate the POCO classes. Inspect the class to make sure the changes were reflected. If they were, then everything has been updated correctly.

Rebuild the solution and run, and everything should work as before. However, we have separated out POCO entities from the layer containing any persistence mechanism which is a good practice and follows the guidelines of SoC along with aligning our application with many of the designs and architectures we are familiar with using.

Route Debugging in ASP.NET MVC

Here are a couple of easy ways to have insight to route debugging your MVC applications. If you begin to build up your route tables with lots of different options, possibly including complex regular expressions, you might get undesired results based on incorrectly intended matching. Remember routing works in a top down matching methodology, so if a URL matches an earlier route then intended the incorrect view might be returned (if anything at all).

The easiest way in my opinion is to use the Route Debugger utility (thanks to Phil Haack) that can be installed from NuGet. This process takes all of 2 minutes, so check it out. Use the following command from the Package Manager Console to install:

The configuration for enabling and disabling is in the web.config <appSettings> section:

<add key="RouteDebugger:Enabled" value="true"></add>

As you can see the output shows the matched route at the bottom of each page:

Another technique for debugging routes not found via the result of a HTTP 404 is to use Fiddler. Open it up, but remember to place a dot '.' after the word 'localhost' if using the local IDE to spin up your web application (I have a post about this here: Using Fiddler With VS.NET And The Local Web Development Environment 'Cassini'). After refreshing the page, click on the the 404 entry in Fiddler, and then press the 'TextView' button on the response. Scroll to the bottom, and take a look; you get a much more meaningful response message to view.

Lastly, Glimpse is another route debugging tool but last I checked they are still working on support to port over the MVC3 version to MVC4. If you are still using MVC3, check out Glimpse on NuGet as well.

No Incoming Audio on Skype for Windows 8

Happy New Year and a quick tidbit on chasing down an audio issue using Skype on Windows 8. Maybe you use Skype for your development team that is disconnected or just for personal use and have run into an issue with the audio, If you find everything to be working except the incoming audio, then it is probably a issue with the default playback device.

Go to Control Panel -> Sound and view the 'Playback' tab. Odds are you have a device such as 'Headphones' that is used as the Default Communications Device for playback of incoming audio such as that used on Skype. Disable the device by right-clicking on it and select 'Disable'. Try making another Skype audio or video call and the problem should be fixed.