No bug in Windows (XP and 2003) has annoyed me more than the one I just learned how to get rid of.

For no discernible reason, while using the Windows Explorer the treeview on the left would just go bananas and display multiple Desktop icons. As seen in the following image. The additional Desktop icons sometimes had other Desktop as children. A recursive bug, nice.

I had been experiencing this bug for many years in both XP and 2003. The most frustrating part of it was that anyone seemed to have seen similar bug on their boxes. I had that problem in every single XP or 2003 boxes I had ever had. Including virtual machines. That led me to believe it must have been caused by some software that I use on all boxes. Nope. Keep reading.

After years of internet searching for people with similar problem, posting to message boards, and almost scheduling an appointment with a shrink, today I found this thread with other poor souls suffering of the same pain.

Without further ado, I present you the culprit.

Yes, my friends. The seemingly innocuous and handy Desktop taskbar toolbar has been that thorn, that little and continuous disturbance that contributed to loss of precious hours of my working and leisure time (when computing all the times it happened in the last 6+ years I've been on Windows XP). Removing that toolbar from my taskbar made the problem go away. I have the same toolbar on my Vista and 2008 taskbars and have yet to see that problem there.

Apparently an abysmal fraction of Windows users care for that toolbar so nobody cared to report the bug. That or everybody else was aware of that bug and skipped the toolbar altogether. In either case, poor me :)

Today I'm glad to cross out that problem from my infinite list of things to figure out some day. I can still get a working Desktop toolbar by adding a new toolbar that points to the Desktop directory in my user profile directory. It does not combine with All users but it's good enough for how I use it.

A friend of mine was telling me about a bug he found in one of his applications caused by a simple lack of escaping quotes when producing CSV files. It immediately reminded me of an old trick in .NET.

If you really want, you can create CSV files using ADO.NET and OLE-DB (or ODBC.) I wouldn't necessarily recommend this approach but it is definitely one of those things that when you see for the first time you go "I never thought this could be done this way."

The idea is simple — open an OLE-DB connection using the Jet OLE-DB provider, create a table (which is really just a file) and insert rows in that table (or lines in that file.)

//create a temp directory for the CSV output
string tempFile = Path.GetTempFileName();
File.Delete(tempFile);
tempFile = Path.GetFileNameWithoutExtension(tempFile);
string dir = Path.Combine(Path.GetTempPath(),  tempFile );
Directory.CreateDirectory(dir);
string csvFile =  Path.Combine(dir, "data.csv");

string cnStr = 
    "Provider=Microsoft.Jet.OLEDB.4.0;" + 
    "Extended Properties='text;HDR=Yes;FMT=Delimited';" + 
    "Data Source=" + dir + ";";

using (var cn = new OleDbConnection(cnStr))
{
    cn.Open();

    //define the file layout (a.k.a. the table)
    var cmd = new OleDbCommand(
        "CREATE TABLE data.csv (CharColumn VARCHAR(30), IntColumn INT)", cn);
    cmd.ExecuteNonQuery();

    //start pumping data
    cmd = new OleDbCommand(
        "INSERT INTO data.csv (CharColumn, IntColumn) VALUES (?, ?)", cn);

    //in a more realistic example this part
    // would be inside some type of loop

    //1st record
    cmd.Parameters.AddWithValue("?", "11111111");
    cmd.Parameters.AddWithValue("?", 1234);
    cmd.ExecuteNonQuery();

    //2nd record
    cmd.Parameters.Clear();
    cmd.Parameters.AddWithValue("?", "22222\"22222");
    cmd.Parameters.AddWithValue("?", 6789);
    cmd.ExecuteNonQuery();

    //etc...
}

//read the csv formatted data
string csv = File.ReadAllText(csvFile);

//cleanup
Directory.Delete(dir, true);

Console.WriteLine("Result:");
Console.WriteLine("--------------------");
Console.WriteLine(csv);
Console.ReadLine();

The output of this will be as follows. Note the escaped double quote in the last line.

"CharColumn","IntColumn"
"11111111",1234
"22222""22222",6789

Of course, you can also read from a CSV file with simple SELECT statements against the file. You can let ADO.NET take care of all your typical CSV tasks.

Fabrice Marguerie wrote about this same topic a long time ago (check the comments and links too).

You may also want to check a more structured approach to the Export to CSV problem by way of the FileHelpers Library.

Turning the table

So here I am, the guy often in charge of assisting new developers get up to speed with my designs and code, facing the diametrically opposite situation.

Like many other developers, I have changed jobs more times than I'd like to. I love the chance to learn from a new industry or platform, I just wish the transition wasn't as traumatic as it frequently is.

I've seen developers hit the ground running, but I've also seen other developer struggle and run in circles not knowing how to proceed when faced with the new environment.

I believe each place has its own challenges but it's still possible to follow some guidelines (or more like heuristics) to optimize the whole ordeal.

Humility - leave that big ego at home

This may be sad news to you, but it's probable that you'll be facing several brick walls. That has nothing to do with your skills or how great a problem solver you are. It doesn't matter. The environment is new to you, possibly the business itself is completely foreign too.

So ask! You will not be perceived as incapable just because you ask too much. Yes, at least try to solve the problem, but don't go thrashing for hours and hours. You have too much too learn and not a lot of time.

Identify the key players

Maybe you will be introduced to the team in you first day and tons of job titles will be thrown at you. Don't spend too much energy trying to remember who has what position in the org chart.

More often than not, these titles have very little to do with the actual role each individual plays in the team or project. Just because someone is labelled senior developer it doesn't mean that that person's contribution will be more effective or regarded than that lowly intern that is on a Summer job or even somebody not directly in the team, like a business user.

Knowing who really has the information you need should always be one of the priorities in your first week at the job.

Identify the real mentors

You know how that is, someone gets the task of being the assigned target for your questions or for pairing with you for a tour of the system. What may not be obvious is that your assigned mentor may have been appointed and not volunteered for that task.

It's possible that there are other members in the team with more inclination for mentoring or that is better at explaining things. So why was not that person chosen to be you mentor? Who knows... Too busy? He/she was on vacation when you started? Bad management? It's uninportant. It happens. It sucks.

Bottom line, disregard the assignments and go for the gold. Once you discover the mentors in your new team. Jump at them. The real mentors will be happy to make themselves available to assist you.

Pick your battles - everybody has defects

The temptation to point out problems is ginormous when you start. It's understandable. You want to show something you know, to contribute, to become valuable, etc.

The unnecessary risk in that is putting yourself in an antagonistic role. It's hard enough being the new guy. Being the guy that came to make us look bad is definitely undesirable. The system had those problems before you got there, chances are nothing serious will happen if you wait a little longer to understand the ground you're stepping on.

Unless you were brought in specifically to review or address a particular problem, exercise your best judgment and don't stick your finger at every little flaw. Everybody has shameful code in their source control log.

Learn the business, talk the talk

New job invariably brings a different way to do business, maybe a new industry altogether. We will do a huge favor to ourselves if we make an effort to learn this new business. Learn the jargon, learn the business model, learn why your end users are using the software, learn about the competition... Learn.

In any semi-serious shop, just knowing the business lingo should give you a head start in understanding even classes and table names in the system. Not to mention you will be able to sustain a decent conversation with the business stakeholders more quickly.

Jump at the opportunity

To top it off. I've seen these countless times, and it still saddens me. Everywhere you go, every team, every project, there's tons of stuff that could be better if someone dedicated some time to it. Unfortunately the lack of initiative is a plague that affects not only software development but pretty much every field. It probably had more to do with sociocultural roots than being a bad professionals.

How many times you've heard complains or suggestions flying by in team gatherings along the lines of: "Have you guys ever used a wiki? It would be cool if we had one", "Our [ bug tracking | source control | logging component | 3rd party controls library | insert pet peeve here ] sucks, I wonder if there's anything better out there", "We seriously need to take the time to document this API", "I hate doing this every time. This should be automated". Let's try not to look at these statements as merely problems or chores that represent the status quo and be prepared to deal with them. In reality these are examples of opportunity. Things that nobody in the team likes or knows how to do. More importantly, many of these can have a direct impact on how well things work, more than it may be apparent. Oh, that's right, they can be fun too.

Right after I mildly complained about the lack of thoughtful orientation on a new job, I was pleasantly surpirsed with this lovely schedule for my first week at the new place.

Just wanted to share that with you. There's hope for our world.

Next Wednesday, September 10^th, is the next meeting of the Chicago ALT.NET user group. This time IoC containers will be the topic du jour.

Expect to see an introduction to this technology and learn why IoC isn't just overhead. Don't expect to leave with just another introduction to some technique that you'll never want to use.

Inversion of Control for the masses

6:00 pm
Pizza and networking time

6:30 pm
John Nuechterlein (a.k.a. jdn) puts Inversion of Control (IoC) containers under the spotlight. If you have been noticing the increasing buzz around this technology but never had a chance to see what it is and how it can be used, this is your chance to see:

• An overview of what IoC is, using StructureMap as the example
• Why one might want to use IoC
• How one can implement IoC
• When one might not use IoC

7:45 pm
You may want to stick around after the presentation portion of the meeting and take part in our monthly open discussion. The topic is never arranged in advance but it's common that it reflects the content of the presentation.