I thought this article was quite interesting: http://blogs.techrepublic.com.com/programming-and-development/?p=673

 

Essentially the article argues you can't be a programming expert any more because of the pace of change of prorgamming languages and the variety of them out there on the internet.  I disagree!

 

I agree the sentiment of the article, but I would differentiate between specific API knowledge and an understanding of how to design and write good software, and of the programming 'memes' over the last 20 years.  I would argue that the real pace of innovation is not that fast, if you have sufficient expertise & experience to distinguish between a new concept, and merely a new implementation of one.  AJAX was around for 5 years before the term became widely used, and is actually a simple use of DHTML, HTTP and XML, though some of the abstraction frameworks around it are great for productivity.  SOA is an attempt to describe ideas 10 years older in a more cohesive, and more standardised way.  An expert programmer sees Ruby and thinks 'cool implementation', not 'OMG I need to go buy a book'.

 

The .NET / J2EE APIs are very different (e.g. swing vs. WinForms) and you certainly can't hold all of their details at the forefront of your mind.  However, the principles of being able to code well in either, and make good decisions about approach and API selection, are almost identical - not surprising because both are OO imperative languages with a JIT compilation, GC'd runtime.  People I know who are expert in one learn the other very, very quickly - and that's down to their programming expertise and experience.

 

I don't think the problem is so new either, I think it's just that the bar has been raised significantly in the last 10 years with more competition to be productive, and hence to use higher level languages with rich, abstracted and large APIs.  You used to be able to get away in the early 90s with writing everything from scratch and still be perceived as competitive - now you can't.

 

An expert programmer nowadays is someone with experience of multiple programming paradigms in a mixture of contexts.  e.g. imperative (C++/C#/Java), functional (ML/Scheme), who has worked at a systems level and business application level.  I know quite a few people like that.  They still pick up APIs and frameworks as the article describes, but they have the knowledge and experience that gives them a deeper understanding of why and how an approach should be taken.  If you're stuck with a complex technical problem, or a load of bugs, then someone like will solve it for quickly regardless of whether they know the API you're using or not.

 

They know the relationship between a semaphore and a mutex, they know that the network is expensive and they should go for coarser grained messaging, they know the pros and cons of ATL vs. MFC, and are comfortable with regular expressions, SQL injection, transaction isolation levels and probably wrote their own equivalents of AJAX back before everyone called it that.  By my definition of expert programmer, there's still just as many as there ever were out there.

Exception handling is an interesting topic... even though the topic has been known about by most OO developers for 10-15+ years, and most MS developers have been using it now in some form for 5 years, I always seem to end up reviewing code with excessive or inappropriate exception handling and that happened to me again recently.

 

Personally I like this article: http://www.codeproject.com/dotnet/exceptionbestpractices.asp which I think is fairly complete and easy to understand.  FxCop also does a reasonable job of picking up some common exception handling misuse (e.g. 'catch (Exception ex) {...}') so keep that turned on to remind you when you are being lazy :).

 

One thing I think people often do badly beyond the core practices mentioned in that article is making decisions on where to put exception handling in scenarios such as reusable class libraries, and/or with respect to the different tiers in an n-tier application.  A common decision that I think is wrong in most cases, and certainly wrong as a principle to apply to all .NET development, is that 'all public methods should have exception handling', the factors driving the decision this week  being that each component should be treated as autonomous and hence considered independently.  Hence for that component, its public interface was the system boundary so if no exception handling happened there, that component 'wasn't doing exception handling' and hence would be a 'bad component'.  I think this is very obviously flawed but I've seen this reasoning before.

 

It boils down to the basic principle of "don't handle exceptions unless you can do something about them to enable the system to behave as expected" - which of course also means that user interfaces should tell the user if they are unable to do as requested, rather than just sit there and pretend nothing has happened (hide the problem) or totally fall over (meaningless error messages and terrified users).  A way I like to think of it is that normally, unless you can recover transparently to the caller (e.g. wait for the database cluster to fail over and then reconnect/re-run the transaction as if nothing has happened), you shouldn't handle exceptions - i.e. only code that understands the overall context of its use, input and output as relevant to the complete solution should handle exceptions and log/report them.  In general it means that class libraries should never implement exception handling and that user interfaces and (typically web) services written with SO in mind should always implement some form of exception handling.  Have I said that wrong?  If so tell me ... but hopefully you can see what I mean.  This is all really a corollary of the principles and recommendations espoused in that article but I think that's useful in helping people better understand how to apply them.

 

When these decisions about where to handle exceptions are made wrongly, then they often go hand in hand with other bad practice, such as not re-throwing exceptions and instead returning empty collections / empty XML etc.  Obviously that would mean that calling code (and therefore end-users of the system) would potentially be unable to distinguish between no data being stored / available and a fundamental system malfunction such as a database being offline.  This kind of thing is however sufficiently covered by the article above, so I'm not going to discuss those in any more depth... READ THAT ARTICLE .