# Monday, 13 February 2012

I am currently in the process of getting my Microsoft Certification mainly because I was told I should.  I have started the process 3 times previously in my career but quickly “fell of the wagon” due to priorities I deemed more important such as bringing you this awesome blog content Smile.  I guess I have never really placed a lot of importance in certifications and figured that my past work/reputation are enough.  Anyone can pass a test with enough memorization of content, but not everyone can deliver quality software applications.

My thoughts on certification

  • I have never lost an opportunity as a consultant because I was not certified.
  • Certification is beneficial to new grads/ new entries in the software development work force.
  • Experience and proven track record should far out way a certification.
  • The content, at least in Microsoft exams, does not reflect the world.
  • You should be reimbursed for your time and fees should be covered by your employer and /or a comparable bonus should be awarded.

So, the point of this post, other than to get something out quick so I can get back to studying for said certification exam 1, is to ask a few questions to you my loyal audience.

  1. Are you certified in any technology/methodology/software practice?
  2. If you are certified:
    1. What are you certified in?
    2. Why did you get certified? 
    3. Did the content you study reflect the real world?
    4. Did you ever lose an opportunity prior to certification because you where not certified?
    5. Since becoming certified have you gotten an opportunity because you are certified?
    6. Did your employer provide compensation/bonus for becoming certified?
    7. What have you gained by becoming certified?
    8. Was it worth it?
  3. If you are not certified:
    1. Why aren’t you?

 

I would love to hear what everyone has to say on this.  Thanks for your time.

posted on Monday, 13 February 2012 16:27:00 (Central Standard Time, UTC-06:00)  #    Comments [2]
# Monday, 30 January 2012

The var keyword was introduced with C# 3.0 and the .NET Framework 3.5 to allow the declaration of implicitly typed variables.  The driving force behind the need for implicitly typed variables was the introduction of Anonymous Types

If you are using var outside of truly anonymous types you are doing so out of laziness.  I know this is a bold statement that a lot of developers are going to disagree with, so let me explain.

First off I totally agree that using var can speed up your lines per minute coded and I do use var in this manner.  But, I always replace var with the actual type after the fact.  You can do this with out requiring a large amount of time after the fact using a tool such as ReSharper and setting up you Clean Up Code” functionality to replace all usages of var with the actual type when possible.

Now for my supporting arguments:  *All of which only pertain to using var when the type is not truly anonymous.*

  • C# is not a Dynamic Language!  This may be bad or not ideal but it is fact.  The truth is not everyone is fluent in dynamic languages and they are not expecting to read code coded in a dynamic fashion when dealing with C#.
  • Code written in a dynamic fashion, i.e. implicitly typed , is harder to read, especially when you are not use to reading it.  I know what you are saying how is this hard to read?:
    1. var x = "This is not hard to read and understand what x is!";

    And you are correct, that example is not hard to read and figure what x is.  What about this?
    1. var x = from custs in dataContext.Customers
    2.         join orders in dataContext.Orders
    3.             on custs.CustomerId equals orders.CustomerId
    4.         join lines in dataContext.OrderLines
    5.             on orders.OrderId equals lines.OrderId
    6.         join products in dataContext.Products
    7.             on lines.ProductId equals products.ProductId
    8.             where products.Name.Contains("FooBar")
    9.         where custs.LastName.Contains("Smith")
    10.         select products

    I would much rather see and read;
    1. IQueryable<Product> x = from custs in dataContext.Customers
    2.                         join orders in dataContext.Orders
    3.                             on custs.CustomerId equals orders.CustomerId
    4.                         where custs.LastName.Contains("Foo")
    5.                         join lines in dataContext.OrderLines
    6.                             on orders.OrderId equals lines.OrderId
    7.                         where lines.Quantity > 10
    8.                         join products in dataContext.Products
    9.                             on lines.ProductId equals products.ProductId
    10.                         where products.Name.Equals("FooBar")
    11.                         where custs.LastName.Contains("Smith")
    12.                         select products;

              The truth is you know what your result is, at least you better or you have no business writing the code in the first place, so just declare it as such!

              One more thing,  var has no place in demo code, tutorials, and blog posts. The purpose of demo code, tutorials, and blog posts are to provide education and in doing so the code should be clean and concise and accessible to the masses.

              OK, let me have it.

              posted on Monday, 30 January 2012 10:00:02 (Central Standard Time, UTC-06:00)  #    Comments [12]
              # Friday, 17 September 2010

              Earlier this week I got into a bit of spat with a couple of Tweeps on Twitter.  It started with someone I follow and respect re-tweeting something someone tweeted about him which basically said the tools which he is associated with aid developers in creating bad design.  I responded to this tweet in support of this person whom I respect by saying…

              Tools don’t do bad design.  Bad developers do bad design.

              Immediately after tweeting this I got multiple reply’s stating that just because you do bad design or write bad code you are not necessarily a bad developer. 

              To be blunt…this confused the hell out of me.  If you knowingly create a bad design or write bad code how can you be a good developer?  I guess the key word in that previous statement is *knowingly*.  But if you don’t know what good design/code is in my book you can’t be a good developer.

              Don’t get me wrong.  We have all been in the position when due to forces outside of our control we have been forced to write imperfect code or create a less than perfect design.  To me this is one place where you can quantifiably determine the good developer from the bad developer.  A good developer, when writing imperfect code due to factors outside of there control, will do one or more of the following:

              1. Get upset because they know they are writing less than perfect code/design.
              2. Leave a comment stating why the code/design was done in this factor.
              3. Add a ToDo for refactoring later.
              4. Will do the imperfect code/design in such a way that the refactoring effort will require less effort.

              This argument of writing bad code does not a bad developer make really rattles me.  That is exactly what it does!

              OK…Let me have it!

              posted on Friday, 17 September 2010 08:58:51 (Central Daylight Time, UTC-05:00)  #    Comments [1]