Observations for .NET N00bs: Developer Paralysis,Exceptionless Programmer Syndrome, and Googleless.
Over at one of my favorite hangouts, eggheadcafe.com, we get lots of forum posts from people just starting out, and many of these posts remind me of when I first started with .NET and ASP.NET back in 2000.
There are two major themes that seem to dominate many of these posts. I call them "Developer Paralysis" and "Exceptionless Programmer Syndrome":
This is when a programmer (even sometimes an experienced programmer) is faced with a request or requirement to create something that they have never done before. The programmer becomes consumed with doubts - doubt about whether they can do what is requested, doubts about how to do it, doubts on whether they'll be able to do it in the timeframe requested, and so on. This process of self-doubt becomes so all-consuming that the developer is literally paralyzed to the point where they are virtually unable to even begin a project. Days can go by with nothing happening. If this ever happens to you, there is a very simple solution:
Get To Work and Start Writing Code!
I have always found that the process of starting a new solution, adding a project and starting to write code -- ANY CODE -- has a settling effect and within a short time, you will find you are no longer paralyzed. Your self-doubts will begin to fade as you start implementing a solution to the programmatic problem with lines of code. Sure, the code will change. Miuch of it may be thrown away later. That's unimportant. What's important is that you are being paid to write code and as long as you are writing code, your frame of reference has changed from being a victim of Developer Paralysis into one of being a working coder who solves problems. As you become a better and better coder, you will throw away less and less of the code you write. You'll develop reusable libraries of classes and solutions that you will be able to draw from later. Even if you haven't a clue where to start, just start anyway.
This is just what the title sounds like. I wish I had a dollar for every time I've answered a post where there was a virtually 100% chance the developer could have solved their own problem by simply instrumenting their code with try/ catch/finally blocks.
You can save yourself countless hours of debugging time by surrounding ANY CODE that could possibly throw an exception with a try / catch block, and doing SOMETHING with the caught exception- even if its as simple as just outputting the Message and StackTrace properties to the debug output window.
Wire up your applications with global exception handlers that will log unhandled exceptions so that you can easily find out why your app "blew up". In an ASP.NET application, for example, you can flesh out the Application_Error in Global with code that calls Server.GetLastError().GetBaseException(). You can call Server.ClearError() after that if you like.
But the important thing is to NEVER assume that any code you write will work. ALWAYS assume that something you didn't think of will go wrong, and code defensively with logging code to tell you about it. And I mean wire up EVERYTHING - every method. If you aren't sure where to put your try / catch block, then just start out by wrapping the entire method body in one. But, don't leave anything out.
At eggheadcafe.com, I have several articles on this subject; you can find them by putting the word "Exception" in our search tool.
Now that I think of it, there is actually a third major handicap, and that is the
This is the developer who spends an inordinate amount of time making posts to newsgroups and forums with questions that almost invariably could have been answered very quickly by placing a few keywords into the Google or MSN search engine pages and pressing the SEARCH button. As I've often discovered by taking a few well-chosen keywords from their question and searching on them, often the best answer comes up in the first page of results. So you are going to post and wait around for a couple of hours for answers, when all you had to do is ask the question to Google, and you'd have gotten answers right away, no?
Having said this, knowing about Google does not equal knowing how to use Google -- or any other search engine for that matter -- effectively. Today's search engines are not evolved enough to guess what we mean when we type in a single-word search query while looking for answers to complex questions. Yet research has shown that the majority of users employ such limited strategies when using search engines. The better a Googler you are the more knowledge you can aquire, faster. Here's an article that pulls together most of these google search tips and tricks.
This is a smaller but active category of developers who seem to take delight in finding what they think are "bugs" in either Visual Studio or the .NET Framework by means of finagling non-standard coding snippets and other subterfuge. Rarely, they do find actual bugs, but in the vast majority of cases it is just "mental masturbation". Then they gleefully post their discoveries on the newsgroups for all to see (Instead of using the Product Feedback site, and searching to see if somebody has already posted it). These people will never amount to much since they are so preoccupied with narcissistic attempts at recognition rather than accomplishing anything. In addition, recognition (which is what they are really seeking) never comes.
(In other news, dark matter is real, scientists say, and 9 million sizzling singles await you on True.)
There are two major themes that seem to dominate many of these posts. I call them "Developer Paralysis" and "Exceptionless Programmer Syndrome":
Developer Paralysis
This is when a programmer (even sometimes an experienced programmer) is faced with a request or requirement to create something that they have never done before. The programmer becomes consumed with doubts - doubt about whether they can do what is requested, doubts about how to do it, doubts on whether they'll be able to do it in the timeframe requested, and so on. This process of self-doubt becomes so all-consuming that the developer is literally paralyzed to the point where they are virtually unable to even begin a project. Days can go by with nothing happening. If this ever happens to you, there is a very simple solution:
Get To Work and Start Writing Code!
I have always found that the process of starting a new solution, adding a project and starting to write code -- ANY CODE -- has a settling effect and within a short time, you will find you are no longer paralyzed. Your self-doubts will begin to fade as you start implementing a solution to the programmatic problem with lines of code. Sure, the code will change. Miuch of it may be thrown away later. That's unimportant. What's important is that you are being paid to write code and as long as you are writing code, your frame of reference has changed from being a victim of Developer Paralysis into one of being a working coder who solves problems. As you become a better and better coder, you will throw away less and less of the code you write. You'll develop reusable libraries of classes and solutions that you will be able to draw from later. Even if you haven't a clue where to start, just start anyway.
Exceptionless Programmer Syndrome
This is just what the title sounds like. I wish I had a dollar for every time I've answered a post where there was a virtually 100% chance the developer could have solved their own problem by simply instrumenting their code with try/ catch/finally blocks.
You can save yourself countless hours of debugging time by surrounding ANY CODE that could possibly throw an exception with a try / catch block, and doing SOMETHING with the caught exception- even if its as simple as just outputting the Message and StackTrace properties to the debug output window.
Wire up your applications with global exception handlers that will log unhandled exceptions so that you can easily find out why your app "blew up". In an ASP.NET application, for example, you can flesh out the Application_Error in Global with code that calls Server.GetLastError().GetBaseException(). You can call Server.ClearError() after that if you like.
But the important thing is to NEVER assume that any code you write will work. ALWAYS assume that something you didn't think of will go wrong, and code defensively with logging code to tell you about it. And I mean wire up EVERYTHING - every method. If you aren't sure where to put your try / catch block, then just start out by wrapping the entire method body in one. But, don't leave anything out.
At eggheadcafe.com, I have several articles on this subject; you can find them by putting the word "Exception" in our search tool.
Now that I think of it, there is actually a third major handicap, and that is the
Googleless Affliction
This is the developer who spends an inordinate amount of time making posts to newsgroups and forums with questions that almost invariably could have been answered very quickly by placing a few keywords into the Google or MSN search engine pages and pressing the SEARCH button. As I've often discovered by taking a few well-chosen keywords from their question and searching on them, often the best answer comes up in the first page of results. So you are going to post and wait around for a couple of hours for answers, when all you had to do is ask the question to Google, and you'd have gotten answers right away, no?
Having said this, knowing about Google does not equal knowing how to use Google -- or any other search engine for that matter -- effectively. Today's search engines are not evolved enough to guess what we mean when we type in a single-word search query while looking for answers to complex questions. Yet research has shown that the majority of users employ such limited strategies when using search engines. The better a Googler you are the more knowledge you can aquire, faster. Here's an article that pulls together most of these google search tips and tricks.
Ponce DeLeon Syndrome
This is a smaller but active category of developers who seem to take delight in finding what they think are "bugs" in either Visual Studio or the .NET Framework by means of finagling non-standard coding snippets and other subterfuge. Rarely, they do find actual bugs, but in the vast majority of cases it is just "mental masturbation". Then they gleefully post their discoveries on the newsgroups for all to see (Instead of using the Product Feedback site, and searching to see if somebody has already posted it). These people will never amount to much since they are so preoccupied with narcissistic attempts at recognition rather than accomplishing anything. In addition, recognition (which is what they are really seeking) never comes.
(In other news, dark matter is real, scientists say, and 9 million sizzling singles await you on True.)
Very good advice I wish i read this when i was at school
ReplyDeleteWire up every method with try catch blocks? Sorry but that is just nonsense...think about what exceptions should be handled in that method. Don't just blindly handle them.
ReplyDeleteEvery exception should be handled yes...but not every method should try to handle the exceptions thrown inside it...sometimes you want them to bubble up.
What I do agree with is not doing this:
try
{
... some code ...
}
catch
{
}
that'll kill ya and developers do it all the time
The suggestion is aimed at beginner developers my friend. As they mature they will learn to think about what exceptions should be handled.
ReplyDeleteBut, we have to get them to learn to put exception catching in their apps first, no?