Tuesday, January 29, 2013

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.


  1. Good one, no one talks/writes of the fact that is TRUE.

    Thanks for well written article.

  2. This studying procedure though can be frustrating as there is an limitless quantity of information to eat in the area of application technological innovation.

  3. Totally agree. Often I feel like the jack of all trades or as Scott Hanselman puts it a "phoney"


    During my 13 years doing this I have come to the conclusion that its impossible to know everything or even a little of everything but that does not make you a bad software developer.

    The ability to learn new platforms and technologies and to be able to produce good software on that platform do make good software developer.

    Never be afraid to say "I don't know" and always be ready to follow that up with "but I can find out".

  4. @Unknown - :P It's the never ending challenge that exists for us and keeps us going! I suppose that's why some in their career call it quits (as a dev) and move to a role that's a little more static (not necessarily less challenging) to avoid this factor.