Once in a while, I toss my resume out there on Dice to see what the market's like and what opportunities are out there; you never know, right?

It always amazes me how terrible the process is and how it's so hard to find a job that's just right. Among the top of my lists for pet peeves -- in so far as head hunters are concerned -- are:

• A total lack of reading skills. I put the resume and profile together to help save time not just for me, but also for the head hunters. No need to send me a requirement for a position in California, you know, espeically when I've listed NYC and Princeton as my preferred locations.
• A total lack of courtesy. While my profile asks nicely to use email as the preferred contact method, that doesn't stop head hunters from calling. More annoying is that some just keep on talking, and talking, and talking...for me, it's a waste of time to listen to them read requiremets to me; I can read just fine, thank you. 
• Asking invasive questions. I always get the "So how much are you making now?" question and I hate it. None of your damn business buddy! Your client can either meet the salary requirements or not...why in the world should I tell some total stranger how much I make? The bottom line is that whatever my current salary is has no bearing in the conversation. If a client can't meet my salary requiremets and the job just isn't that interesting, I'm not interested.  Not only that, it's not like whatever number I give can be verified easily; asking this question is pointless because you'll get a batch of people who'll just make up numbers anyways.  What if I said I made a million dollars last year?  Would anyone believe me?  What if I said I made $500,000 last year, would anyone believe me?  What if I said I made $250,000 last year, would anyone believe me?  Then why should anyone believe any unverified income number over the phone (isn't this how we got into this sub-prime mess)?

Well, anyways, once you make it past that morass, then you have to deal with the actual companies and phone interviews. This is where the fun begins (no, really)! I, for one, love being teched out. There is nothing more enjoyable than a match of wits to see if the person on the other end of the line can actually out tech me (and believe me, it would make me incredibly happy and excited if that were the case).

My new favorite part of the process is when the interviewer gets to the "So, do you have any questions for me?" part. Instead of asking boring, standard fare type questions, I've decided that this is my opening to gauge the technical skill of the developers in the organization.  There is positively nothing more satisfying than doing some in depth tech grilling to kind of figure out whether an environment is right for you. I've kind of come to the conclusion that I can really only be happy where I can be out-teched; you know, an environment where I can learn from those around me and drive me to continue to dive into the technologies.  It's a way to make sure that you're going to end up in a position where you'll feel challenged and look forward to learning and solving new problems.

In any case, here are some grilling points which I've come up with:

What's your approach to designing data access?

I like this question because it tells me a lot about the interviewer. In my opinion, data access is essentially the core of any application; it must be simple in design and easy to extend. It must be easy to understand and easy to use by the application layers above. Yet it must not be so basic that it's raw and verbose.

The worst possible answer is a response with any mentioning of datasets (even worse - and an absolute deal breaker - if that's not prefixed with "strongly typed").

Ideally, I'd like to hear something like:

• "We usually build a domain model built on top of Microsoft Enterprise Library." Most companies don't have the liberty of working with open source libraries. Enterprise Library is at least a baseline. The great thing about it is that it's very well documented and a well understood quantity.  Pluse, having EL as a base encourages or enables at least a baseline level of uniformity in the code.
• "We use NHibernate (or substitute another ORM/persistence library)." I realize that not all companies and all projects have the freedom to use open source 3rd party libraries, but it's nice to see if they do or have used them in the past.
• "We're using LINQ." If you get a response like this, you know you're dealing with a group on the cutting edge of technologies and you're dealing with a group that doesn't mind the challenge of designing around new technologies; the developers probably read up on this stuff and work on it in their spare time. This is a group that you want to work with.

The answers to this question offer a rich view into the development resources that a company has and whether they have a strong indication of the Not Invented Here syndrome.

I tend to think that it takes a more advanced developer and development team to understand the landscape of libraries out there and how to utilize them since learning a new library is usually far more challenging, not to mention productive, than hacking together an inferior custom solution. As such, I also like to ask the following:

What's your approach to runtime logging?

It's a shock to me that many consultants I've worked with in the past either:

• Incorporate no runtime logging or tracing capabilities into their code or...
• Roll their own logging library.

If you've been writing applications without logging, then you haven't written any applications of any worth. If you're rolling your own, it means you're not interested in delivering value to your clients by wasting their time and money or, even worse, you don't know any better; you've never spent the time to look into the various off the shelf logging options. log4net would be a great answer, but Microsoft Enterprise Library Logging Application Block would be awesome as well.

I've never gotten to a point yet where I've been able to pop this next question, but I think that nothing would be a better indication of "this is a place where I want to work and these are people that I want to work with" than if I got a satisfying answer to this:

Are you familiar with Inversion of Control/Dependency Injection? Do you use any libraries to implement it?

This is a great quesiton because there are some design challenges in software, particularly around extensibility and orthogonality, that can really only be cleanly addressed by using the Inversion of Control (IoC) pattern. It enables the creation of far more extensible frameworks, libraries, and applications.

Low level developers on simple projects have no need for IoC or they end up writing a lot of code that's not extensible or modular. The more complex the application and the greater the need for extensibility, the more important IoC becomes as part of the glue that makes it all work together without a huge mess of dependencies.

If you get a response of "We use Spring.NET/Castle Project/Unity/CAB", then you know you're not dealing with some junior programmers. (CAB isn't really an IoC/DI container, but it utilizes some of the concepts of IoC).

Speaking of late binding, I'm also thinking this would be a good question as well:

Are you familiar with the Fusion Log and why you would need to use it?

Only developers who've worked extensively with late binding would ever have a need to enable this and you can tell the experience level of a developer if he/she can even give you a straight answer on what late binding is.

If I could make it past that point, I'd pretty much surely ask:

What's the difference between an interface and an abstract class? Which do you prefer when you design a framework or application? Why would you choose an interface over an abstract class? Why would you choose an abstract class over an interface?

In general, I don't like being asked or asking low level nitty-gritty questions like "Can you explain how CLR garbage collection works?" or "How many generations does the CLR GC have?" or questions like "Explain the ASP.NET page lifecycle?"; these questions aren't useful in the big picture and most of it can be looked up.  These are just mere facts, the knowledge of which, doesn't indicate much.

On the otherhand, knowing the similarities and differences in iterfaces and abstract classes and how to use them properly gives insight into a developers approach to object oriented programming.  It's a great question and a tough one as well. Nothing would be more awesome than a reply of "Well, according to Cwalina and Abrams in 'Framework Design Guidelines'...".  Knowledge of interfaces and abstract classes is foundational to an understanding of good object oriented design and programming. You cannot write a well designed object oriented system without the judicious use of abstractions.

Another great question along these lines is:

Do you or does your team use any code generation tool?

I think that in general, it takes a great deal of thought to utilize code generation.  It means that the developer or team in question understands the value proposition that it brings to development.  Of note:

• It leads to more consistent code which means that in the long run, it's more maintainable and easier to document; it leads to repeatable and predictable results from every developer on the team, regardless of whether they've been writing code professionally for 10 years or 10 months.
• It leads to less error prone code since it's easy to fix small errors across the board by fixing the templates or the driver.  For example, writing data contracts by hand is extremely error prone since it's easy to forget to put a [DataMember] attribute on property which needs to be serialized.  Generating it from a template mitigates these types of simple mistakes.
• It increases productivity by allowing developers to get away from writing the plumbing and focusing on the business logic and UI, places where the ROI on code generation is lower.

It indicates to me that the developer or team is able to bring abstractions to the next level; not only are they abstracting in their object models, they are also abstracting the very act of coding.  To successfully utilize code generation means that the developer or team is able to see the big picture and not just a class here and a class there.  The develper or team has analyzed the code, identified the patterns, and encapsulated those patterns into templates and drivers.  You know you're dealing with a high level team if they properly utilize code generation tools to reduce the amount of time spent doing grunt work.

Well, I'm sure I'll think of more if I can ever get past these questions. But overall, this outing has been disappointing.  In general, I don't think interviewers take well to a technical grilling; whether they are unprepared to answer these types of questions or they simply don't know the answers, it hasn't been too promising.  For me, it's important in gauging the technical competance of my potential colleagues and the type of technical training/staff development that the company provides and/or encourages.  It's one way to avoid ending up in a company staffed by 5:01 developers.

I still haven't figured out how to respond to the "So what year did you graduate" question, as it's clearly a form of age discrimination but I'm not sure how to call someone out on that yet.  More importantly, it implies that the groups and personnel are not necessarily organized by merit, but by seniority or, even worse, cronyism.  I think next time, I'll just be blunt about it and ask if the interviewer realizes that it can be construed as age discrimination.

I caught this phrase scrawled on Woody Paige's blackboard last night on Around the Horn (one of the few television shows I watch somewhat regularly).

I love it.

Glenn Campbell on "stupidity":

During our childhood, we are given a certain amount of protection from reality. Our parents dole out rewards and punishments that are often detached from the conditions we must eventually face. Some parents, for example, may reward their children no matter what they do. This sets the stage for stupidity in adulthood, as the subject expects the outside world to hand him the same unconditional reward.

The habits of stupidity can be terribly difficult to change, especially in others. This is why we label some people "stupid" as an overall systemic condition. They are never going to "get it" because they have made a fundamental philosophical decision not to. Their emotional needs are so great and cause them so much internal panic, that they can never accept reality the way it is.

The worst thing you can do for a stupid person is protect them from their mistakes. Maybe stupid should hurt. If it doesn't, then they're going to get even more stupid, and they will be totally unable to deal with life when the protection finally collapses.

When you have a boss, client, parent, spouse or adolescent child like this, that's when you find out what a tragic and terrible disease stupidity is. You clean up one stupid mess, but then there's another and another. There's never going to be an end to it until the stupid person touches reality himself is able to directly experience the results of his actions as they occur.

Smart people, by definition, learn quickly from their mistakes, but stupid people don't. They may have to hit their head against a wall many times before they realize, "Hey, this isn't a good idea." Even then, it's only that particular wall they've learned about. If you put up another wall, they'll insist that it shouldn't be there and repeat their mistakes all over again.

This last paragraph is particularly relevant in software development.  I wouldn't call anyone stupid (you have to have above average intelligence to make it anywhere in software development; more like misguided or unmotivated), but many times, people just don't learn from pain and mistakes.  They settle into a methodology or a style and build up mental inertia.  No matter how many times you try to tell them that there is a better way, a more efficient way, a better tool, they refuse to adapt and expand their boundaries.

It's not that "smart developers" are infallible -- everyone makes goofy design decisions from time to time (especially when "The Big Picture" is not a known quantity), but that they can adapt quickly and learn from their mistakes.  They look for ways to ease the pains of the development process.  They are curious about how to make processes more efficient and less error prone.

Just a random Thursday lunchtime rant

Fred Brooks' The Mythical Man Month is one of my favorite software engineering books.  I first read it in my senior software engineering class at Rutgers.  From time to time in my daily routine of software implementaion, I flash back to bits and pieces from the book and from the class.

One of the most relevant issues that Brooks' touches upon is the issue of communication and how it impacts productivity.  Of this, Brooks writes:

The added burden of communication is made up of two parts, training and intercommunication.  Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work.  This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.

Intercommunicaion is worse.  If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2.  Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.  If, moreoever, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet.  The added effort of communicating may fully counteract the division of the original task...

This issue seems particularly relevant today as teams are more geographically dispersed than ever (whether due to working with offshore teams or with developers working across the country). As you increase the number of developers working on dependent and communicating components, you dramatically increase the development time.

One of the most common approaches to working around this is to partition the work such that each developer is responsible for minimal cross component communications (each developer implements a full stack). 

The approach works because there is less turnaround and less miscommunication between developers.  It reduces dependencies between one component and another, allowing a develper to progress as fast as she can implement the requisite bits.  Need to store an additional field?  No problem.  Add a column, add it to your data model, and then render it in the UI.  No need to ping someone else or write a change request; just make it happen.

The downfall of this approach is that it leads to a lot of duplicate code for common logic; it tends to work well for a very small team with geographic proximity, but breaks down very quickly as the number of developers or geographic proximity increases.  A developer writing data access for one component may have her own practices while another will abide by a completely different set of practices.  In the long run, this leads to code that's hard to maintain as well as adding much more complexity to the product itself. 

Not only that, any given developer may not be suited for developing a given part of an application stack.  A UI developer will be much more proficient at and capable of designing an attractive, easy to use UI than a backend service developer.  An application developer may be capable of writing a much more cohesive domain layer and business layer than a database developer.

Service contracts are an oft touted solution.  The promise is that by agreeing on a service contract, each side can develop independently of a concrete implementation of the other, so long as the contract is followed to a T.  However, at least in my experience, this is usually far from the truth, especially if you work in a team where the contract itself is rarely stable for more than a day or two.  UI tweaks or new features can cause dramatic changes in the service (for example, requiring more data or a change to the model) which comes at a cost of time spent on change requests and communicating those changes to the other side.

For the time being, I've come to conclude that full stack development (hmm...maybe with the exception of the UI layer) is the best approach, so long as it's supported by the necessary tools, templates, and frameworks; it's all about making it easy to make the guts work (and to do so in a consistent manner) so that the implementation differences where it matters is minimized (for example, data access). Enter code generation,  automation, and application frameworks to the rescue.  Tools like MyGeneration, Spring, Smart Client Software Factory, and Enterprise Library are really the answer but I've found it quite difficult to get team members to buy into embracing these tools (it's one thing to use a framework; it's another, entirely, to embrace a framework or tool).  When properly wielded with a cohesive software architecture, you can get the best of both worlds: a coherent codebase with common patterns across component stacks while allowing developers to work with less dependencies.

What do you think?  How do your teams handle working on multiple dependent components?

WCF DataContracts include an ExtensionData property which is a bit troublesome if you are trying to send a modified object back up to the service if it has no properties in Javascript.

So I wrote a little piece of Javascript to clean it up:

function DeleteExtensionData(obj) {
	var keys = Object.keys(obj);

	keys.each(function(key) {
		if(!Object.isFunction(obj[key])) {
			if(obj[key] instanceof Object) {
				DeleteExtensionData(obj[key]);
			}

			if(key == "ExtensionData") {
				delete obj[key];
			}
		}
	});
}

It will recusively delete all ExtensionData properties from the object.  You can call as soon as you get the result from a completed AJAX request or you can call before sending an object parameter to a service.

Note that it uses constructs from prototype.

If you want to get fancy, you can also write a custom serializer.

While reading his article from the NY Times on The 11 Best Foods You Aren't Eating, my curiosity regarding sardines was piqued.  Like most people (I'm just guessing here), sardines aren't on my shopping list...ever.  So I had to google and figure out how these things are supposed to be eaten and what not.

This lead me to this article over at Chowhound and this choice quote:

My favorite sardine to date is Angelo Parodi sardines. They are carried at most Italian markets or delis.

I ate them plain, so can't help you there ... only hint ... if you get a can of sardines you don't like ... sriracha sauce will fix it.

For those Anglo readers who stumble upon this article, sriracha sauce is kind of like the Asian version of ketchup; every fridge should have a bottle of that stuff sitting around.  It's the perfect combination of spicy, savory, and tangy and goes with pretty much anything (okay, dessert dishes? not so much).

Seriously: is there any food that a little sriracha sauce can't fix?

A colleague emailed me today regarding some information I had sent him previously.  Apparently, Lotus deleted all of his data which wasn't archived.  Why?  Who knows.

Anyways, I suggested that he simply ignore the company email system and use a GMail account.  To this, he replied:

If I could I would NEVER use Lotus email. WHAT A nightmare!!!

Emphasis his.  So please, if you're an IT administrator or a CTO, don't punish your minions by subjecting them to Lotus Notes (unless, you know, you're into that sort of thing).

Okay, maybe "death" is a bit severe.  But certainly, I think in the next few years (if not months), Office will start to lose marketshare...significantly.

Now don't get me wrong; I love Office (okay, not really, but I work with it on a daily basis and the whole product strategy for my group revolves around the Office client and server suite), but there are some severe usability issues which have, amazingly, to this day, been pretty much unresolved.

The crux of the shortcomings of Office (aside from interoperability pre-12) is really document sharing.

Today, in the Office world, if you want to share documents (either with yourself (i.e. work on a different machine) or others), you really only have a few options:

1. You can access your desktop remotely using a remote desktop client.  This sucks for a variety of reasons including responsiveness and the require setup to enable a remote access scenario.  It may not even be possible due to corporate firewalls.
2. Email the document to yourself and/or collaborators.  This is what most people do today, I would gather.  It's one of the most annoying things that I deal with because I end up with a folder with a bunch of documents title "Spec rev.1", "Spec rev.2" and so on.  Not to mention what the clusterfuck that happens if I modify the document and rename it with "rev.X" and another collaborator does the same.  It sucks...but even I've been known to do this.
3. Copy the document to a physical medium and pass it around.  This includes CDs, USB drives, external drives, etc.  I do this quite often when I travel and I know I will need to prepare a document.  But it sucks.
4. Use a corporate SharePoint site to share your document.  This is a great solution...if your company has a SharePoint site.  What if you're not a full Microsoft shop?  What if you work for a small company?  It also means you'll probably need VPN access, which is generally annoying.  For the record, I've been using Office personally and professionally for more than 10 years now and I've never shared a document using this method.
5. Use Office Live!  This is a relatively new offering from Microsoft who finally realized "Hey, maybe the rest of the non-corporate world would also like to share documents in a non-shitty way!" However, what sucks about this is that you still need to have the Office client...we'll touch on this point in a bit.
6. Use some sort of remote file share (FTP location, network file share, etc.).  This has various perils as well in addition to the inconvenience of having to have a VPN connection.

None of these options are really appealing, but until recently, there really wasn't a choice.  Regardless of what desktop processor you use, you're pretty much constrained to the same set of options (you can replace SharePoint with whatever web platform your client integrates with).

This sucks, for the reasons listed above, but it also sucks because it means that you have to lug around your laptop everywhere you go to work on documents.  It's the reason why you see business people scrunched up in coach, contorting their bodies and praying that the person in front doesn't put their seat back so they can fold out their laptop.  The desktop document processor client makes us all slaves.

But the future is coming.  For personal use, I don't think I'll ever author another Word document in Office ever again.  Both Google Docs and Zoho offer what I need so far as basic document processing goes and I have the added convenience of being able to easily share documents with others.  There's also the absolute coolness of being able to edit the same document in a live session with your collaborators.  This alone is not enough to change how we work with documents.  The iPhone and the impending release of Android (along with the next generatin of smart phones) will leave the Office stack in the dust.

My house backs a small forest.  So from time to time, we get some interesting visitors.

I saved these guys while I was mowing the lawn...I hope I didn't kill any of their siblings

I briefly considered feeding them to my bearded dragon, Quincy, but decided that it was better to just put them back.

This deer came by about two weeks ago:

It was pretty cool because he walked right out into the main yard before he got spooked and ran back into the woods.

We've also had a red fox visit our back yard one time.  There's also this little garden snake living under our front stairs which I keep seeing every few weeks.  I've been trying to catch him, but who knew snakes could crawl backwards?

I spent bout two hours today tring to figure out why I kept getting a weird error while using prototype to call a WCF service.

There are various other resources on the web regarding how WCF has a few quirks with error handling using the default endpoints, however, none of these scenarios were applicable to me since the JavaScript call worked fine in FireFox.  To complicate things even further, it actually all worked fine in IE7 as well with one caveat: it only worked on the first load of the IE7 process.

After that, any refreshing of the page would return 400/"Bad Request" errors, mysteriously.  Just to make sure that it wasn't isolated to prototype, I also tried jQuery as well.  Still nothing.

Well, as it turns out, that setting the AJAX request content type to application/json wasn't enough; I had to set it to application/json; charset=utf-8.

So if you're encountering weird issues with any AJAX library, IE7, and WCF and/or ASP.NET, be sure to check your content type setting.

Update 6/20/2008: bah!  I woke up this morning and it's not working again!  Oddly, it works fine if I have Fiddler running and as soon as I shut off Fiddler, it stops working.  To complicate matters even more, it's only happening on methods where I have post content.

Update 6/22/2008: after further investigation, I'm concluding that it's related to SharePoint.  To isolate the different components, I created a custom WCF service and a simple runtime which models our current custom WCF runtime.  When I used a plain HTML page or even an ASPX page with a script manager on it, prototype AJAX requests worked fine.  Okay, so it wasn't how we were hosting the service and it wasn't an issue with a collision between ASP.NET AJAX and prototype.  I then hooked a SharePoint layout page up to the same service and boom, it all breaks

I've broken it out into the following scenarios:

1. Using FireFox, the requests always work.  No matter how many times I refresh the page, the AJAX request always works fine.
2. Using IE7, it will always work on the first load of the IE process. 
   1. If I hit CTRL+F5, it will continue to work.
   2. If at any point, I hit F5, it will fail and even CTRL+F5 will not fix it.
   3. If I have Fiddler running, it will always work, even if it entered a failure state after hitting F5! (So Fiddler must be doing something to the HTTP message??). As far as I can tell, the only difference between the Fiddler request and the native request, from viewing the WireShark trace, is the "Authorization" header and the fact that the failed request has a "Content-length" header value of 0 (manually setting the header doesn't work either).  I verified that prototype was not somehow mangling the POST body content by writing a trace of the XHR request body right before and right after the request is sent (both came out okay).

One of the really weird things about this error is that it cannot be observed when I have Fiddler running; somehow, Fiddler "fixes" the issue.  I had to hook up WireShark on the server and watch the raw TCP messages to finally see that on the unsuccessful attempts, the POST content to my WCF service was empty.  The method required one parameter, so the WCF serializer threw a formatter excpetion when it received an empty message:

I've tried playing around with various cache avoidance strategies to no avail (setting the "Cache-Control" header, setting the "If-Modified-Since" header, setting the "Pragma" header, addin randomness to the POST URL) so for now, I'm just going to have to give up on this.  I've confirme the error using three different OS environments (XP SP2 (desktop), XP64 SP2 (dev), and 2003 R2 SP2 (VM)), all running IE 7.0.5730.11.

I know there are various articles out there regarding IE issues with XHR and how the ordering of the open(), onreadystatechange, and send() operations must be called; however, I verified in the prototype source (lines 1213-1223) that the correct order of operations are being performed.

Thinking that perhaps some Microsoft mojo was behind all of this, I gave the Sys.Net.WebRequest a shot.  This also did not yield any postive results.  Oddly, ASP.NET AJAX to web service calls all work fine (we had some existing AJAX components which were calling to a web service, but the goal was to transition away from writing these "empty" proxy services and call directly to the WCF service).

If any SharePoint development team members or program managers are reading this, please look into it!  I'm not sure if it affects IIS hosted WCF services at this point, but a sample project can be downloaded from here: WcfAjaxWonkiness.zip.  Create a layout page which calls the service and add it to SharePoint and observe it blowing up.

I've previously posted on how to move compiled binaries into a remote GAC automatically from your development environment to your SharePoint environment using SysInternal's PsExec utility.

But what about moving content files from your SharePoint environment to your development environment?  When I'm developing content for layout pages (ASPX, js, css), for the most part, I don't want to develop in Visual Studio; I will usually use EditPlus (my weapon of choice) and edit the files directly on the remote server.

However, this poses a problem: synchronizing files between the SharePoint environment and the development environment.  It's quite time consuming and painful to do it manually since you may have to dig through various directories and keep tabs on which files you've edited on the server.

Enter 2BrightSparks' SyncBack utility.  Using this, I can create a synchronization automation between my SharePoint environment and my development environment.  And because I've set up my files to have the same structure on both sides, it's easy to set up the synchronization settings.

The image above shows the layout of my project. You can see in the image below at the directory layout mirrors the project layout, making automated synchronization a snap.

Working smarter > working harder.