A broken pot tells an archaeologist a story. It illuminates the civilization that once was and now has only its remnants to speak for it.
Interviewing IT candidates serves a similar purpose. In an interview we are looking for artifacts of experience. We ask about one keyword after another. We ask about one Code Pattern and then another. How the candidate responds is important. Zero level experience candidates tend to deflect and divert. They will mention Google. They will talk about how they are a great learner. Their expression of enthusiasm will grow ever higher.
After just a little bit of non response joined with expression of enthusiasm from a candidate it is interesting to see the spilt response from a panel interview. The panel was a mixture of technical and business types. The more business oriented the more positive the response, the more technical the individual, the more negative the evaluation.
Business types value that enthusiasm, and for their problems Google always seems to have the answer.
Technical types know that lacking the basics skills in the language is bad news. Only after one has the basic language skills down, does the formation of Code Patterns or Coding Idioms take shape.
Showing posts with label Code Pattern. Show all posts
Showing posts with label Code Pattern. Show all posts
Monday, June 9, 2008
Wednesday, June 4, 2008
Parse TryParse Code Pattern
In c# the int data type has two functions for parsing strings that represent integers; Parse and TryParse.
Parse can throw an exception to indicate failure and TryParse returns a bool to indicate success or failure.
This represents a useful Code Pattern that frameworks can employ to address the needs of those who use them. On the one hand throwing an exception is the traditional way that frameworks indicate something went wrong. It leaves it up to the calling entity to catch and handle the exceptions. The weakness here is that the catching and handling structure can be overwhelming. Not to mention the overhead involved.
The TryParse on the other hand allows the calling entity to branch on success or failure without exception overhead. It also allows for several quick successive checks of parsing to find the best fit.
Neither is superior, it is simply a case of what is needed. So in creating frameworks it is best to provide both.
Parse can throw an exception to indicate failure and TryParse returns a bool to indicate success or failure.
This represents a useful Code Pattern that frameworks can employ to address the needs of those who use them. On the one hand throwing an exception is the traditional way that frameworks indicate something went wrong. It leaves it up to the calling entity to catch and handle the exceptions. The weakness here is that the catching and handling structure can be overwhelming. Not to mention the overhead involved.
The TryParse on the other hand allows the calling entity to branch on success or failure without exception overhead. It also allows for several quick successive checks of parsing to find the best fit.
Neither is superior, it is simply a case of what is needed. So in creating frameworks it is best to provide both.
Subscribe to:
Posts (Atom)