In a job interview I was asked to pull a list of records from a database and save them to XML. The data was hierarchical in nature, of course. The code I produce looked a bit like this:

Dictionary<int, XmlNode> connections = new Dictionary<int, XmlNode>();

XmlDocument xdoc = new XmlDocument();

XmlNode root = xdoc.CreateRootNode("Names");   

using(IDbConnection con = GetConnection())

{

      using(IDbCommand command = con.CreateCommand())

      {

            command.CommandText = "select id, parent id, name from Foo order by parent id;"

            IDataReader reader = command.ExecuteReader();

            while(reader.Read())

            {

                  int id = reader.GetInt(0);

            int parent = reader.GetInt(1);

            string name = reader.GetString(2);          

            XmlNode node;

            if(parent == 0)

                node = root.CreateChild("Name");

            else

                node = connections[parent].CreateChild("Name");

                  node.Text = name;

            node.Attributes.Add("id", id.ToString());

            connections.Add(id, node);

            }

      }

}

xdoc.Save("results.xml");

I believe that the purpose was to check if I know how to use recursion, but it never occurred to me to use it in a case like this. The code above uses a single database query and a single pass on the dictionary. It is, I believe, as efficient as you can get without really trying. The funny thing was that the interviewers tried to get me to use recursion (without saying it), but I literally couldn't understand what they meant until they said it.

After reading Joel, and writing my response to that, I started to think about all the things that a typical developer should know in order to produce a working application. The list isn't in any particular order, and I'm focusing it the business / application developer:

• Data Structures

• Complexity

• Cost of operations (local vs. remote)

• Designing usable classes*

• SQL

• XML

• ACID

• Basic Design Patterns:

• Strategy

• Decorator

• Regular Expressions

• Data Modeling

• KISS

• TDD

• Building DAL

• Change Management (SCCS)

Anything to add that you think is essential?                    

* Reusable classes are another matter all together

I like delegates, maybe to the point where I use them too much. I talked about my Repository and that is allowed me to access various sources without caring what the object is, or what is being done with it. Here is a possible implementation of a Finder, which is a read only repository. This code also shows a new pattern that I began to use lately, which is to put delegates in dictionaries, and then invoke them, I find that this is a very powerful way to specialize handling of functionality without much effort.

public class Finder
{
    static IDictionary<Type, Func<object, Type, int>> finders;

    static Finder()
    {
        finders = new Dictionary<Type, Func<object, int>>(new IsInstanceOfEqualizer());
        finders.Add(typeof(ActiveRecordBase), delegate(Type type, int id)
        {
            //Get item from the database
            return ActiveRecordBase.FindByPrimaryKey(type, id);
        });

        finders.Add(typeof(Employee), delegate(Type type, int id)
        {
            //Get the user from Active Directory and wrap it in an employee instance
            return new Employee(ActiveDirectoryWrapper.GetUserWithId(id));
        });

        finders.Add(typeof(Enum), delegate(Type type, int id)
        {
            //would be converted to the enum value by Find
            return id;
        });
    }

    public T Find(int id)
    {
        return (T)finders[typeof(T)](typeof(T), id);
    }
}

In the case, either the object knows how to save itself (Active Record), or it doesn't need to be saved, so I didn't need to implement a full blown repository (in which case I would've written an interface an each of those would be a class implementing the interface). In my real project, I ended up with the repository-as-a-generic-interface approach, but the one above is a very real possibility for all those that use a real Active Record model (I needed more, so I modified it quite a bit).

Why is this good for? Well, consider other generic code, which can use this Finder object without needing to know what it does (think about security, logging, simple UI, etC).

It seems that Joel's article about Java in the Universities has made quite a bit of noise. I think that I will add my two cents to the mix.

Two things pissed me about the article. The first was the claim that CS should weed the bad from the good, and the second was his treatment for OOP (agonizing over has-a & is-a is so not OO).

I completely disagree with the claim that CS* classes should function as discriminators between good and mediocre programmers. That is his problem, as a potential employer, to weed out the great from the mediocre. And if he can't do that in about a week, regardless of technology or project that they use, then the fault is with him, not with the graduate. Being proud because you were up until 4:00 AM chasing a null pointer dereference and broken stack is not the sign of a productive developer. I wrote all the linked lists and hash tables that I ever intend to write. Hell, I even spent some time writing a sparse matrix in C++ that was multi dimensional and efficient. I see zero need in them outside of the class room.

I will walk out of a job interview where the test is being able to write a linked list in C or C++. I have done so before where the questions where at about this level. You want me to deal with pointers, give me a job that requires that I will deal with them. That has better not be a bug tracking software in ASP 3.0 (what Joel sells).

The second part, about OO design being "spending countless hours rewriting your code to rejiggle your object hierarchy, or you fret about faux 'problems' like has-a vs. is-a" is just bull. I'm programming since I was ~14 years old or so (if you don't count making a turtle dance in Logo), I started in Pascal & VB 3.0, I later moved to C & C++, and then to C#. The last time I thought about has-a vs. is-a was when I was learning C++ and was very new to OO. Since then, I didn't touch this stuff, and I produce good OO code. Most of it is online, and you can check it out.

Then there is the whole premise of the article, which seems to be that you need to find a Segmentation fault [sic] and fix it in order to be Real Programmer. Been there, done that, boring. I consider good design much better than knowing how to handle naked pointers. You know what, show me a good C++ coder that still go on to do that, when all the best practices for C++ are full of RAII and safe pointer wrappers.

Now, that said, he does have some points that I agree with. Recursion is a good, clean, way to solve a certain set of problems, and understanding pointers is very helpful in understanding how computers think. And understanding functional programming is very good for being able to write clean code later on.

* I'm currently studying for a CS degree (just started), but I know about 85% of what the degree will teach me because I wanted to learn and a university wasn't a possibility at the time. I've a job, which I like, and I got it because I like what I'm doing, not because I had a degree or a certification.

While I need to read some ugly code, I think that I'm learning SQL in leaps and bounds. Right now I gave a shot to the OUTPUT clause in 2005, and it is just great.

Just listen to this song, it may be not the greatest musical in the history of mankind, but it is very funny nonetheless.

Brad Abrams talks about a new method in the CLR [ ReadAllLines()  ], and the comments list several useful stuff and some wishes.

My wish for the new year is to be able to declaratively set a dictionary. What do I mean by that?

int[] values = { 1, 2, 3, 4, 5, 6 };

But just try to do that for dictionaries:

Dictionary<string, int> values = CreateDictionary();

private static Dictionary<string, int> CreateDictionary()

{

    Dictionary<string, int> values = new Dictionary<string, int>();

    values.Add("one", 1);

    values.Add("two", 2);

    return values;

}

And this is the best thing that I could come up with! Other languages has initializers for dictionaries. This is something that I use constantly (very easy to setup a relationship between behaviors, for instance), and it's annoying me every time.

I just saw this, and I nearly ruined a perfectly good keyboard. Those answers are so… stupid. But I fully believe that actual people answered them in response to actual questions in interviews. I distinctly remember walking out of an interview knowing that I'm not willing to work for those guys, based on the questions that they asked me. (My philosophy is that I want the interview to be hard, I want to make sure that I work with people who know more than I do, and I want to be sure that I'll need effort to keep up with them.)

In the spirit of Groucho Marx: "I wouldn't want to belong to any club that would accept me as a member.", I wouldn't want to work in a place where the work is too easy or the standards are too lax. What is the point, then?