I am still early on in what I hope to be a long and storied professional career designing software systems. I'm coming up on three years of working full time, and I'll be the first to admit that I'm still wet behind the ears. There is much I have left to learn about the ins and outs of working with other humans, designing successful systems, and how to navigate the world of non-tech business.

I have noticed something that concerns me, though.

What are you doing?

I've had the misery of opportunity to work on a legacy VB6 project recently. In an effort to gradually move away from VB6, which lost official support more than four years ago, we have been migrating the project to newer technologies; one piece at a time. This has led to a monster that contains VB6, a COM control which contains new forms and user controls written in a combination of VB.NET and C#, and Silverlight 4 rendered in VB6's web control.

I know, it can be as bad as it sounds.

To be fair, the migration has been mostly smooth sailing. I'd say we have a solid majority of the functionality migrated to our target framework, Silverlight 4. Our new code base is stable, consolidated, reusable, the works. The problem is that our old code is, well, not.

Programmer, Plz, Stahp

While I was working on a fix for something unrelated, I found myself in the code for a VB.NET control. This particular screen had some management-only functionality, which required a certain menu item to be visible or not visible based on the permissions of the given user. The VB6 host controlled whether or not the menu item should be shown, the VB.NET code only had to act upon that information.

I should note that the menu item was a named element, lets say mnuSpecialFunction and that the VB6 set a property on the control called SpecialFunctionIsVisible. How did my predecessor (who is no longer with the company, I should add) handle this stunningly obvious task?

I would have gone with something a little like this:

mnuSpecialFunction.Visible = Me.SpecialFunctionIsVisible

But the answer, apparently, was more like this:

Dim _mnuItem As ControlFor Each _mnuItem In MenuStrip.Items    If _mnuItem.Name = "mnuSpecialFunction" Then        _mnuItem.Visible = Me.SpecialFunctionIsVisible    End IfNext _mnuItem

I laughed so I wouldn't cry.

My Point

This brings me to my point. When I was interviewed for my current position, I got all kinds of technical questions. I was asked to write a SQL statement to join two tables together for a result set. I was asked what did inheritance mean in the context of the OOP model. I was asked if I knew what LINQ is and for what it is used.

I was never asked when and why I would use such tools. If someone had asked my predecessor if he knew how to control the visibility of a control on a screen, he could honestly say that yes, he did. If asked if he knew how to iterate over items in a collection, he could have said yes. If he had been asked if he knew when and where it is proper and correct to do these things, I imagine he may have been stumped.

But because he knew the how, he got the job and now I'm rewriting code that shouldn't have to be rewritten.

I think it is time we start focusing on the when, where, and why of coding when interviewing potential programmers. The how changes; will always change. With each new framework, language, or whizbang system, the how of what we do will change and with instantly available resources at our fingertips, I don't think that's a worrisome thing. I'm years away in my career from having the power to interview someone for a position, but the how is not important to me. I don't care if you know how to do X in language Y. You can Google that in a few seconds. I want to know under which conditions might you X? When might Y not be an efficient use of resources?

These are the real problems we face. This is what we need skilled developers to handle. Otherwise you just get poop cobbled together from well intentioned coders trying to shove their square solutions into round problems.