Browser Toolbars

Recently, Microsoft announced a deal with Dell to distribute the MSN toolbar with new computer purchases. This comes after previous announcements with Sun and Lenovo. While I am excited about the traffic this will bring to Live Search, I have to say that I hate browser toolbars. Seriously, what good are they? Most browsers already have the functinality that the toolbar provides: search box, term highlighting, etc... The MSN Toolbar does provide a few interesting twists like automatically launching Live Messenger, but on the whole, who needs them? They just use up space and memory. My wife's computer has both the Yahoo! toolbar and the Google toolbar on it. I have to go take them both off now...

You know, what I'd really like is a browser that prohibits toolbars, that I could use. And while I'm on that topic, over Christmas I installed extra RAM in my father-in-laws computer because it was going slow (it only had 256 MB of RAM). I also noticed that he hadn't upgraded from IE 6 and had some Yahoo! toolbar that provided virtual tabs of some sort. Why hadn't the browser updated itself to IE7? Seriously, why doesn't our software just fix itself? Why don't my drivers automatically update? ARRRGGG!!!!

Ok, I feel better.

New Layout

As you can tell, I picked a new layout from blogger. Let me know what you think.

Rules for running an IT organization

The last post was how to run a research organization. In this post, I'm going to set my sights even higher and tell how to run an IT organization. These rules have been picked through my studies of various companies.

1. Hire the best people - I've harped on this before. So have others and others and still others. If you don't know by now that there is at least a 10x difference between the top programmers and everyone else then you haven't been paying attention. I can't say much on this topic that hasn't already been written, but I will point out that you need to be proactive about hiring the right people. It's not just the free food. It's about providing employees with incentives to do great work. If you just need a warm body, then provide him with a steady paycheck. But if you work in IT, you don't want warm bodies, they are not in the 10x group. You want the best, so you have to make it worth it. You have to make them feel important and wanted. You have to put effort into finding them at the top colleges, recruting them, and retaining them. If you are a small company, you can provide stock options. A large company? You can provide free food :-) Either way, you have to provide challenging problems, a sense of ownership, and other fantastic people to work with. Remember, if you have ten of the 10x group that is equivalent to one-hundred of everyone else. If you don't think that is true because of parallelism, etc... you are wrong. Parallelism doesn't apply because the communication pathways increase leading to lower overall productivity. Just like you don't get a linear increase with most parallel algorithms, the same applies for programmers. The communication overhead gets in the way. Therefore, with ten 10x programmers you can be more productive than with one-hundred other programmers. And you don't even have to pay them 10x as much, though you will have to pay some extra. With the savings, you can provide more stock options or free food :-)

2. Make the source available to all - Everyone in the company should have access to all the source code. At Google, the designers of the library can easily update it, because they can open everyone else's code up in eclipse, choose refactor, and then save and recommit it. They are not blocked. In addition, an open code base implies group accountability. Too often, programmers get too attached to their work. They don't see the flaws that are inevitable in their programs. An open code base allows everyone to view and comment on everyone else's work. It forces programmers to realize that they are mortal and make mistakes. Eventually, they will come to know that the group is better than the individual and their work improves due to peer review. Forcing an open code base allows this to happen sooner and with more acceptance.

3. Dedication to infrastructure - Who is responsible for the build system? Who writes the core infrastructure components? Who sets up the distributed computing system? Who determines which dependency injection framework should be used? All of these are core infrastructure decisions and they all matter. As we'll see in a future bullet point, standardizing the infrastructure is vital. You want your application programmers to focus on their individual application. If every application programmer has to focus on their infrastructure, then you are losing 3 to 6 months out of every project. If it takes a week to set up an automated build system and a week to attach the test harness and another week to set up the distributed key/value store, then you have lost 3 weeks of your project to things that have to occur for nearly every project! Instead, you want application programmers to think about their application. You want them to worry about delighting their customers. They need an automated build system, but they shouldn't have to think about which one to use, how to set it up, or what happens when it isn't working. That is infrastructure. In the past, there were extra teams responsible for hardware, networking, and OS setup. These were not the responsibility of programmers. Now, we're adding additional layers. The build system, test framework, and distributed computing platform are additional infrastructure components that must be standardized and managed elsewhere. There could be additional infrastructure components for your organization as well. For instance, Google uses dependency injection so often that they wrote their own framework for it. Notice that I didn't say every team wrote their own framework. Instead, one team wrote it and maintains it and everyone else uses it. This consistency and willingness to use other people's work makes for a successful company. As another example, Google has a Java collections library that the company uses. Every team can take advantage of this without having to rewrite it. In other words, the goal of the infrastructure group is to find and eliminate duplication throughout the company. This could be with hardware, applications, or libraries. Regardless, duplication is the enemy of the IT organization and it must be eliminated!

4. Repeatability - Everything that is put into production must be a repeatable process. Not only that, but it must be repeatable by someone else! This means both applications and documentation must be written and available that show how to repeat it. Once again, we're trying to seek out and eliminate duplication. Programmers in the future shouldn't have to reverse engineer or re-create your application. If it is worth putting into production, then it is worth documenting and ensuring repeatability.

5. Enforcing standards - You want programmers to feel empowered, but you also want productivity. You need standards to ensure the latter, but you need only the right standards to ensure the former. Standardizing on one build system (perhaps per language) ensures that everyone can access and build everyone else's code. Standardizing on a common base class ensures pandamonium. You want to standardize tools, not techniques. Not only does this allow programmers to quickly move from one project to the next, but it also provides continual feedback and improvement on your internal tools. When a programmer says, "Tool X doesn't provide capability Y so I'll write my own" you are in for disaster. Now, every project begins with a 3 week tool writing cycle. Instead, if the programmer would just fix Tool X then everyone else can take advantage of capability Y. Libraries work the same way. Pick a dependency injection library and use it across the organization. It doesn't matter if one team happens to like Spring over Guice. They are both open source and you can alter it to suit your needs. Just pick one and be consistent. Get everyone moving in the same direction. That way, when they increase others' velocity they move in that direction even faster.

6. Don't start from scratch - If nothing exists, then you have to start from scratch. However, if you have a working product, then don't start rewriting it from scratch. The only thing you do is create new bugs that you don't know about instead of fixing the old ones you already knew about. Now, that doesn't mean that you shouldn't take a troublesome component and rewrite it. That doesn't even mean that over the course of a year you don't eventually rewrite 90% of the application. It does mean that you work piecemeal, with legacy code. You create tests, if you don't have them. You write documents, if you don't have them. You continually improve the product you have. Then, when you are ready, you begin refactoring. You improve its structure a little bit at a time. Just enough to add your new functionality with new tests. Then a little more and a little more. Eventually, your crufty working system blossoms into a beautiful piece of artwork. Well, you'll think so anyway, but the next developer won't understand why you did X, Y, and Z and he'll want to rewrite it from scratch. That's the problem and the point. When we don't understand how something works, we want to rewrite it so that we do. However, the next maintainner doesn't understand it either, so the rewrite circle continues and is vicious. If something works, use it, clean it, modify it. Don't rewrite it.

7. Be dedicated to testing - The best organizations have dedicated testers. This is not a coincidence. Recognizing quality as a core attribute of a product is vital to having a quality product. Manufacturing companies have known this forever. Why is it that IT shops think they can ignore quality and still have a quality product? Google's Chrome has unit tests for highly ranked web pages, automated UI testing, and random input testing. Not only that, but they also ran other test suites against it. For instance, it passes 99% of webkit's layout tests and passes all but 2 of jQuery's unit tests. Quality is a core attribute. At Microsoft, there is a Software Development in Test job role. Each team is assigned one or more of these resources to ensure they deliver a quality product. These people are top notch programmers that love to break things. They are not random guys off the street. They can code just as well as the SDE's and it is vital that they can do so. Testing today is about coding. It is about double entry bookkeeping. It is about automation and repeatability. People expect thier products to work, out of the box. They expect future releases to be backwards compatible. They expect a quality product. To delivery that, quality must be a feature. The organization must be dedicated to quality - having a special testing division is one way to commit to that level of dedication.

8. Metrics - "In God we trust, all others bring data." Metrics are at the core of process improvement. How can you possibly know if you are improving if you don't measure that improvement? Would you be satisfied with your water treatment plant if it told you the water quality was improving because it looked a bit clearer? No. You'd want to know the Ph levels, the amount of sediment in the water, etc... You expect a quality product to have metrics that back up its quality. If speed is a feature, then you'd expect metrics around how fast the product will go in certain conditions. If accuracy is a feature, then you'd expect benchmarks showing the accuracy against other products or human judges. In all cases, metrics are vital to a product in order to show improvement and achievement of goals. The one caveat is to be sure you are measuring the right thing. It is inevitable that programmers will find a way to improve the metrics. If the metrics are measuring the right thing, then that is great. If the metrics are measuring the wrong thing, say lines of code, then you have a recipe for disaster. Make sure that your metrics are measuring externally visible things, not internal ones. You want improvements to your metrics to affect the customer, not your programmer's salary. Everyone cheats the system, you want those cheats to have a positive impact on your final product.

Well, there you have it. 8 rules for running an IT organization. Hopefully they will make your company the next IT powerhouse!

Applied Research

At one point in my career, I had the experience of being on an applied research team. In fact, I was one of its founding members. At the time, I wasn't sure what applied research was; even now, I can't say for sure I know.

For our team, applied research was new product development. Honestly, I think that had disastrous effects. We were in limbo between delivering a new product and maintaining our "research" mantra. In the end, we wanted product teams to adopt and maintain our product. This, too, led to tension. Product teams want to feel comfortable with what they will eventually own. They want to use and support things they have used and supported in the past. Research products are wild-cards and not to be used unless nothing else like it exists. Even then, most product teams will choose to rewrite it. Take, for instance, Pig. Pig is a dataflow language created by Yahoo! Research to run on Hadoop. It was created to prove a point, but it was also created to be used. However, once it transfered to a product team in Yahoo!, it was scheduled for rewrite. I'm not sure the cause. It could be Not Invented Here syndrome. It could be that research teams are not focused on the long term, so they deliver a short term product. It could be that research teams don't know how to code or that product teams and research teams speak a different language, so they can't see eye to eye. Regardless, having a research team deliver to a product team is doomed to failure, if you count failure as an eventual rewrite of the product or technology.

To help guide my thoughts on this matter, I had the good fortune to speak to Hector Garcia-Molina of Stanford University. If you don't know who this guy is, you are missing out. Stop and go read the wikipedia entry linked to above. He recounted to me his description of what a research organization should do. I'll recount here and embelish a little.

First, a research organization should publish. The benefit of publishing is that it brings notariety/publicity to your organization. The company's sales force can go to battle with slides that reference conference proceedings. Of course, no sales person would read the proceedings, but it does make their presentation look legit. In addition, presenting at conferences allows the researches to make the aquantence of people like Dr. Garcia-Molina and bring new insight and innovations back. Finally, publishing creates an attractive employment environment. New graduates from top schools want to go to a place that has a publishing history so that they can continue their research. To get a graduate of MIT or Stanford, you need a publication record. I'll add one more to his list. I think a research department that publishes shows a commitment to innovation by the company; a commitment that roots itself in the culture and makes the company a hotbed of innovation.

Second, a research organization can be used as a SWAT force. Tackling a hard problem or subset of the problem. I think this can be the area where the most "good" can be done internally. Instead of creating a product, create an extension to an existing product. There are always "next version" features that never get created. These features either provide too little value or are too difficult. It is that latter segment where the research department can really shine. Since they are not constrained by time to market, etc..., the research department can think outside the box and take the time to create an "academic" solution. For example, PageRank was an academic solution to the problem of which web sites were more popular. It is a beautiful recursive algorithm that just happens to produce great results. Is it a perfect algorithm? No, of course not. Was it better than the "engineering" algorithms of the time? You betcha! It was what happened when two academics got together and had the time to think about the problem. They realized the probelm was similar to that of research paper citations, so they devised an algorithm that treated the problem thusly. Had they had to meet an arbitrary deadline so that their employer could make the trade show deadline, they would not have come up with PageRank. That is the benefit of a research team. Not to create some fancy product for the trade show, but to take the existing product the next step. To finish out the "next version" features and do so elegantly.

The final task for a research organization is to benefit the company at large. There are many ways to do this. One is to create best practices and spread them out to the other development teams. Another is to investigate various technologies and report on how they could/should be used throughout the company. An additional way could be to create the infrastructure to ensure developer productivity if no other team is responsible for it. Do developers have access to distributed key/value stores? If not, install MemcacheDB or CouchDB, and help developers to connect to it by creating modules in various languages. Do developers understand and have access to technologies like Hadoop and Pig? If not, create demos and give a roadshow. All of these things lay in the "best practices" umbrella and often organizations don't have the teams in place to create and distribute the "know-how" required to use them.

In all three cases, the applied research team stayed away from the product team's core product. Instead, the research team focuses on small, manageable pieces that fit nicely into the strategy already outlined by the product team. This creates trust and will foster future collaborations between the product and research teams.

Good luck and let me know of your experiences dealing with research teams!

Gay Boyfriend

I'm not sure which one I like the best

dorky fan version
dorky house version

Ouch

I hope not

Facebook lament

I have too many facebook friends. I lament it. I only have about 5 that I actually want to monitor and communicate with; however, when people request friendship I don't want to say 'no, I care nothing for you.' I really want a "preferred facebook" view where I can just track and interact with those I care to. One would think that it is not that big of a deal, but it really is. For instance, I just went to superpoke a friend of mine and it took far too long because I had to find that person in my list of friends (and I don't have *that* many). It actually reduces the amount of time I spend on facebook.

Less is more.

Infinities and Series

Those of you who read this blog (all 1 of you!) know that the number of integers is infinite and the number of irrational numbers is infinite, but the latter infinity is greater than the former infinity. I tend to think of this as mathematical shenanigans. The idea that one infinity is larger than another just doesn't meet the "beauty" test that accompanies mathematics. In the past, I've argued that infinities don't exist, so we can make contradicting remarks about them to our hearts content. It's similar to asking the question "Can God make a rock so big even he can't lift it?" The words make sense and are in the right order, but the semantics of the sentence are off. They produce a barber paradox that belongs to the realm of meaninglessness. They show that Goedel is alive and well and relevant for today's meta-mathematical problems, if only we'd heed his words. Ok, back to infinities.

First, can we create a more intuitive reason for why one infinity might be greater than the other, a reason that doesn't fall back on establishing a one-to-one correspondence with the integers?

First, let's establish that the integers exist in one-dimensional space. In fact, they exist on a number line which is the definition of one-dimensional space :-) But, let's consider a slightly different definition of dimensionality. In this definition, we'll look at the number of infinite dimensions. In the case of integers, the length of the integer is finite. No matter how big the integer becomes, there is always a finite number of digits. Even if the integer explodes to a googolplex digits, there is still a finite number of them. Therefore, the only infinity is in how many integers there are, the size of the actual integer is finite. So, there is only one dimension of infinity.

Let's now look at rational numbers. In the case of rational numbers you might say that there are two dimensions of infinities. The first dimension is the number of rational numbers. There are an infinite number of rational numbers. The second dimension is that some rational numbers have an infinite decimal expansion. For example, 1/3 has an infinite expansion of 0.333333333... Therefore, rational numbers have two dimensions of infinity and should be larger than integral numbers, right? Not so fast. That's just their decimal expansion. If you keep them in their functional form, then we get a different story. All rational numbers can be expressed as the division of two integers. Moreover, we know that both integers have a finite number of digits. Finally, we know that adding two integers with a finite number of digits will produce a third integer with a finite number of digits. Therefore, there is a representation that is finite in length for every rational number. That leads to the logical conclusion that all rational numbers have one dimension of infinity.

Next up, irrational numbers. Irrational numbers extend to positive and negative infinity, giving one dimension of infinity. In addition, they have an infinite expansion in every base, which gives them a second dimension of infinity. So, we can easily see why there are more irrational numbers than rational numbers, because we allow irrational numbers to have an infinite expansion!

So, if we can't represent irrational numbers with a fixed number of rational numbers, what can we represent them with? Why, an infinite number of rational numbers, of course! For example, PI can be represented by the following series (one of many): PI = 4 * (SUM[k=0 to inf] (-1^k)/(2k+1))

So, in essence, we have an infinite set of numbers each composed of an infinite set of numbers. Two dimensions of infinity!

But wait! If we can create a series to represent each irrational number, does that mean that there exists a representation that is not infinite and therefore we can count them, similar to the rational numbers above? No. With rational numbers there was a finite number of integers that created the rational number. With irrational numbers there is an infinite number of rational numbers.

So, it is true that the number of irrational numbers exceeds the number of rational numbers, right? Well, maybe. I think it is fair to say that an infinitely expanded irrational number doesn't exist, so we're back to the land of Goedel. It is worth thinking of an irrational number as a function of an infinite number of rational numbers much the same as a rational number is a function (division) of two integers. Functions are often useful in mathematical manipulations, but that doesn't make them "real". The number 3 is a physical, real number. You can count out 3 things. The number PI is not a physical, real number. We can only approximate it. In fact, complex analysis is based around the number i, which is a function (sqrt) applied to -1. As long as we don't expand the function, we can do mathematics with it, but if we ever need to expand it our equations blow up. The same thing is true with irrational numbers, they are mathematical niceties. Abstractions that we can manipulate as long as we don't look too closely. Similarly, questions about abstractions such as if one abstraction is infinitely larger than another abstraction requires you to look to closely, so you get crazy results, just like if you had really taken the sqrt of -1 or divided by infinity (another function).

So, the next time you see PI, take it for what it is, a function that can be evaluated to the necessary precision. A mathematical abstraction that can be admired from afar. Just don't get too close.

North vs South

I've been in the Pacific Northwest for four months now and I thought I'd share a few of the differences I've noticed.

1. In the South, we have sweet tea. In fact, we have most any fattening item you can imagine: gravy, lard, fatback, etc... In the Northwest, everyone drinks their tea unsweetened and even IHOP lists the number of calories in their food.


2. In the South, you drive everywhere. If you take the bus or walk you are most likely poor and almost always frowned upon. In the Northwest, you are hailed as a hero and considered "green".


3. In the South, PTA was for the crazies who had nothing better to do with their money. In the Northwest, our PTA paticipation is at 100% for the third year straight.


4. In the South, the kids look forward to deer season. In the Northwest, the kids look forward to the new Star Trek movie.


5. In the South, teachers send letters home with the children. In the Northwest, teachers email the parents


6. In the South, we get our coffee from McDonalds. In the Northwest, the city would shut down if Starbucks closed.


7. In the South, the biggest technical gathering is when Ma Potter drops the security on her wireless router. In the Northwest, you are constantly bombarded with invites to technical events.


8. In the South, a top IT graduate comes from Vanderbilt. In the Northwest, a mediocre hire comes from Berkeley.


9. In the South, the churches are dense, huge and filled with Southerners. In the Northwest, the churches are sparse, huge and filled with former Southerners.

I'll pause here and reflect on a few things. First, with regards to schools, it is easy to find a correlation between money spent and quality. The schools in the Northwest are better funded. Heck, my daughter's school here has a buffet! However, those people who feel that spending more on education will fix it have missed the boat. The real issue is parental involvement and peer pressure. In our schools the children challenge each other and the parents are involved. At our PTA social events nearly everyone is there. We, and the children, want each other to succeed. No amount of money will make kids want to have a read-in instead of play outside. No amount of money will make kids come to school dressed as their favorite storybook character instead of their favorite pop-star. No amount of money will make kids succeed. It takes dedicated parents. Moreover, it takes a school full of dedicated parents. Otherwise, you will run into the problems faced by other behavioral economists. The smart kid with dedicated parents will be ostracized. He or she will be considered an outcast. After all, they aren't going to be staying around after graduation, so why invest your friendship in them? You need an entire school full of dedicated children and dedicated parents in order to succeed. Money won't help, changing the culture is required.

Secondly, you can see the failure of the church in the Northwest. The educated, affluent people avoid the church while the Southerners flock to it. I think there are a number of factors at play here. First, the larger churches are getting the publicity and they are taking a stance against education. I have personally been in a church where the pastor said that anyone who believed in the Big Bang is going to hell. I didn't go back to that church. However, if a church accepts everyone and everything then there is no point in going. You can socialize on the net. So, there is no middle ground. The educated people are turned off from the backwards southern denominations and have no reason to attend the more "progressive"/"liberal" variants. If higher education becomes the norm in the South (which is a big question mark), then the church as we know it is doomed. The church must find its way in a new era. It must bridge what we know to be true, scientifically, with what we believe to be true, spiritually. It must exclude certain things as immoral, even though it accepts them civically. For instance, homosexuality is banned in the Bible. However, so is adultery. No churchmember protests the legality of adultery; hell, half of them have committed it themselves. But homosexuality is an abomination! The same goes with other moral sins such as lying and blaspheming. The church needs to realize that it does NOT have a civic duty to outlaw immoral behavior. No one can legislate morality and those that do are seen as haughty and hippocritical. Instead, they should accept that the world's morality and the church's morality are different. Christians are "sanctified". Before Christianity, to sanctify something was simply to set it apart; there was no religious meaning. If the church gets to legislate everything, then there is no more sanctification; we are just like everyone else and that is not our mandate. We are to work in the world and change the people. That can only be done by example. Right now, we're not setting a good example. It won't be long until the church is completely irrelevant outside a few poor areas where their only role is to give the poor hope.

In total, I've really enjoyed living in the North. I have no idea if I'll stay here long term, but it's been a great experience so far and I'm glad I was given the opportunity.

C# Awesomeness

As you can imagine, my current employer gives me a number of opportunities to work in C#. I've really been enjoying myself, but only scratching the surface of what C# was capable of. So, tonight, I tried a few more interesting ideas that use the C# anonymous types and lambda function capabilities.

The first one is a pretty simple copy of ruby's IO.each_line function. My goal is to have the C# function encapsulate the logic of opening and closing the file and me pass in a lambda that does the processing I want (just like Ruby's).

Here's the code

1    public delegate void IOProcessor<T>(T line);
2    public static void ForEachLine(string fileName, IOProcessor<string> processor)
3    {
4        using (StreamReader reader = new StreamReader(fileName, Encoding.UTF8))
5        {
6            while (!reader.EndOfStream)
7            {
8                processor(reader.ReadLine());
9            }
10       }
11   }

First, I declare a delegate. In C or C++, it would be a function pointer. Here, it is more than that because it can be generic, which is utter coolness in a box. We'll see the point of the genericity in a moment.

The next line declares my function which takes the file name and the delegate (we will be giving it a lambda.) Here, we explicitly set the generic parameter to a string because we know that is what we are retrieving from the file.

The using statement opens the file, specifying a UTF-8 encoding. It will also ensure the file is closed whether or not an exception occurs.

Finally, we have a loop that reads each line and passes it to the delegate until we run out of lines. Very simple and straightforward.

If we wanted to use this code to sum up the lines in a file we could write code like the following.

1    int sum = 0;
2    
3    ForEachLine("my_integers.txt", (line) => { sum += int.Parse(line); });

After line 3 finishes, sum contains the sum of each line in the file.
For instance, if the file was
10
20
30
40
Then sum would be 100.

Another thing I do a lot of is handle delimited files. Usually, I'll open one up, perform a line by line manipulation of the file, and close it back. Of course, the obvious string.Split() method comes to mind, but that is somewhat unsatisfactory because you are still dealing with integer offsets into an array. How do I know that offset 3 is the anchor text and offset 7 is the ubercool feature? It would be nice, if I could specify their names in the beginning and then work with objects.

So, to handle that, I created a function that would objectify my delimited files.

Here goes:

1    public static IEnumerable<T> EachDelimitedLine<T>(
2           string fileName, char delimiter, T outputObject)
3    {
4        Type outputType = outputObject.GetType();
5        using (StreamReader reader = new StreamReader(fileName, Encoding.UTF8))
6        {
7            while (!reader.EndOfStream)
8            {
9                string[] fields = reader.ReadLine().Split(delimiter);
10               yield return (T) Activator.CreateInstance(outputType, fields);
11           }
12       }
13   }

I'll break this function down line by line in the next blog. Specifically, it takes in a prototype object called outputObject and creates an object like that from each line of the delimited file, using the strings after splitting to initialize the object. I call this function like

1    foreach(var x in 
2       EachDelimitedLine("delimitedFile.txt", ',', 
3                         new { Title = "", Body = "", Anchor = "" }) 
4    {
5       if (x.Title == "Thoughts of Me")
6       {
7         // do something with my blog...
8       }
9    }

As you can see, I specify a prototype object of an anonymous type and my code uses that prototype to create objects from the delimited file. Of course, in production code you would want checks for too few fields or too many fields so that you don't get the weird error messages you would get from this code by default. However, I think it gives you a flavor of the power of C#.

Now, for the final piece, we combine the ideas of the ForEachLine function and the EachDelimitedLine function to get a ForEachDelimitedLine Function. This also shows you the power of the generic delegate.

1    public static void ForEachDelimitedLine<T>(
2        string fileName, char delimter, T outputObject, IOProcessor processor)
3    {
4        foreach (var x in EachDelimitedLine(fileName, delimter, outputObject))
5        {
6            processor(x);
7        }
8    }

In this case, the IOProcessor now accepts a generic argument T which is the same type as the prototype object I pass in (called outputObject).

Let's look at the above example code redone to use the ForEachDelimitedLine function

1    ForEachDelimitedLine(
2        "delimitedFile.txt", ',', new { Title = "", Body = "", Anchor = "" }, (x) =>
3    {
4      if (x.Title == "Thoughts of Me")
5      {
6        // do something with my blog...
7      }
8    }

There, no more foreach statement. Now, the logic is part of the function itself.

Next, I plan to extend my C# emacs mode to generate a class around my static functions and compile and run for me so I can have a C#-script of sorts. Don't get me wrong, I still love and use perl on a daily basis, but C# is often much faster than perl, surprisingly enough, and seems to be able to handle memory more efficiently as well. However, I do admit that is anecdotal and not based on any tests I have performed. On a more pragmatic side, it is easier to integrate with exsiting C# libraries from C# rather than writing a SWIG interface.

Hope you enjoyed!

disgruntled iPhone user

I'm tired of the Apple iPhone. As long as you don't need to do anything unusual, it is fine, but try to go outside what the folks at Apple have deemed appropriate for you and it blows up. For example, if you want to sync with two computers, you are hosed. If you want to make a different interface (for example, I want playlists to have folders), you are hosed. If you want to do anything custom, you are up a creek - I'm tired of it. When my contract expires, I will be moving to a different phone. No more Apple for me, I want something more open.

Midomi

Just a quick post to give props to the Midomi team. I always enjoyed Shazam, but it only works for commercially recorded songs. Midomi lets you sing and then tries to determine what song you were singing. It is great karaoke fun! My wife and I played a game of Horse with it recently and had a blast.

Great job, guys!

The end of broadcast TV

Seems like broadcast TV should be in its death throws. I give it no more than 7 years. I imagine within 5 everyone else will chime in with its death. I wonder how Dish/Comcast/DirectTV/etc... will fight back. Will they try to lure the RIAA into banning places like hulu.com? Or will they hold out hope that people will want to see their shows as soon as possible instead of waiting for them to come online? At what point do they stop coming out in broadcast form first? Seriously, between netflix, hulu, veoh, and mtv.com I don't really need cable. I have enough entertainment with just those sites. That doesn't even include iTunes and the paid providers. The tail is growing in this area and it will only be a few more years before it becomes mainstream. Not only that, but the monitization ability is already there through commercials, so it is a viable model. I do hope it doesn't get bogged down by commercials though - and I hope the commercials become personalized. Just because I'm watching The Hills doesn't mean I want to see a cosmetics commercial...however, my eyebrows do look a bit...nevermind.

What a great family

I received these pictures from my wife and kids when I arrived in Seattle. They are a great family and I miss them. From left to right is my niece Ashlan, my daughter Brooklyn, and my son Carter. See you soon!

Amazon Interview

I went through my interview with Microsoft in my previous blog entry. In this entry I plan to discuss my Amazon interview. I applied to Amazon after having visited the Silicon Valley area. I knew that I didn't want to work in that area and hoped the Seattle area would be nicer. Amazon gets tons of traffic daily and I'd been very impressed with their S3 and EC2 technologies, which I discuss here. I wanted to work at internet scale and Amazon seemed to be a prosperous and growing company.

I received an email from an Amazon recruiter not too long after submitting my resume. She described the process: two phone screens where I would have to write code over the phone and then they would fly me to Seattle. I had just come off my interviews with Google and Yahoo, so I was excited to have another opportunity ahead of me.

For my first phone screen, I was out of town, so I had to do it in my car. They mentioned I would have to write code and I shouldn't be driving. I had pulled over in a parking lot and was ready with pencil and paper when the call came. I had also turned off my car and it was about 100 degrees F outside; it was definitely uncomfortable. In this first interview, he asked me to write a binary search function for an integer array. Normally I don't describe the questions that are asked; however, in this case I don't think I'm giving away any big secrets.

I wrote a recursive binary search implementation and read it back to him over the phone. It was a bit odd to read code over the phone. I had to read out curly braces, square brackets, the whole works! When I finished reading it he asked me if line X was ok. I told him that I thought it needed a +1 to it. He said ok and then asked me why I chose a recursive implementation. I told him that I thought it would be easier to write. I tend to think recursively. He asked me what the downsides of a recursive implementation are. I told him that it requires time to push on and off the stack. I also mentioned something about stack overflow, but in hindsight that was a bit silly. The greatest stack depth you can ever have for a binary search is 32 (on a 32 bit machine). I also mentioned that a tail call optimizer would eliminate the performance penalty. I'm not sure he understood that, so I didn't pursue it. Besides, I don't know of any C++ compilers that include tail-call optimizations.

We had plenty of time left, so he asked me to rewrite it iteratively. I complied and started writing it. In the middle of writing it, I realized I screwed up the recursive version. I told him about my screw up over the phone and called myself an idiot. We both got a laugh out of that. I finished my iterative implementation, double checked it for accuracy, and read it to him over the phone. He seemed happy with that approach and I mentioned that it was easier to write than the recursive version. However, I imagine that is because I had calmed down some and the recursive version had prepped me. He asked me about some of the test cases I would run on it. I mentioned as many as I could such as element not in the array, element at each end of the array, element in the middle of the array, duplicate elements, etc... He seemed satisfied and began telling me about their team and projects. In the end he asked me if I had any questions. I only had one or two about the team and working conditions. I'm not a huge questioner, I guess.

Honestly, at that point I wasn't sure I'd be getting a call back. I had flubbed the recursive version of a binary sort for goodness sake. I mean, come on, who does that? I should have nailed that one. I was a bit disappointed. (On a side note, there is a really great article on binary search in Beautiful Code. If you don't have that book, you really should.) Since my phone screen was on a Thursday evening I had to wait until the next week to hear my results. The recruiter called and told me that they were interested in talking to me further and they would like to set up another phone screen. I was excited to be moving on to the next round!

The next interviewer also asked me a fairly basic programming question. It is one that I ask a lot in interviews and therefore quickly pounded out the optimal solution. In this case, it seemed to take him a few minutes to verify that it worked. I was a bit surprised - I figured if you asked a question you should know the optimal answer for it. It could be that he was testing me to see if I would rush to change anything, but I was confident in my answer. He seemed pleased and we moved on to talking about other things. After this interview, I was pretty confident that I would be getting to go to Seattle and after a few days, the recruiter called to confirm it.

There were a few negatives about the trip to Seattle with regards to Amazon. First, the put you in a hotel downtown, which means that you are within walking distance to everything. That's not a negative. However, they don't imagine you need a rental car, so they don't provide one. Instead, they reimburse you for taxis. Now, I appreciate being reimbursed, but it is a lot of trouble. I have to find the cash to pay the taxis, get receipts, keep the receipts, turn them in, and wait 6 weeks for the money. Honestly, it's just not worth it. Secondly, the hotel they put me in didn't have free in room internet. I wasn't going to pay $10 a day to get it, either. They did have free internet in the lobby, so I would go down there, download an Ars Digita Video Lecture and go back to the room to watch it. I will say that the staff at the hotel was very courteous and the restaurant was great, but not having in-room internet sucks. Big time.

Amazon flew me in a day before the interview, so the first day I was there I went and walked around the downtown area. I found it vibrant and clean. I went to a suggested restaurant nearby and had some really amazing food. However, it was getting late and I was tired, so I went back to my room to rest up for the next day.

The next day I awoke and took a taxi to the Amazon building. It was on 5th street South. Either that or 4th Street South. I forget. But the reason I bring it up is because the directions explicitly say that South is different from not South :) In other words, they are on different ends of the town. I'm paranoid that my taxi driver won't know that and keep repeating to him, "South, right? I mean it's a different street or something." We get on 4th Street (or 5th Street...who knows...) and it's not South and I'm repeating again "4th Street South!". Finally, he assures me that he knows where he is going and I should just let him take me there. I sit back, say "ok", and enjoy the ride. We drove by the Seattle Public Library and I am amazed by its architecture. It is truly stunning.

Finally, we arrive at our destination. He lets me out and he pulls off after giving me a blank receipt. For that matter, all the taxi drivers have given me blank receipts. Do I fill in the amount and sign them myself? I have no idea. Anyway, I'm looking around and I don't see an Amazon sign anywhere. I'm freaking out thinking "Oh my gosh, he has taken me to the wrong street!" However, I do see a street sign and it has South on it, so I must be in the right place.

Finally, I see an entryway on the side of the building with "Amazon" on it. I go inside and speak to the receptionist. I'm about 30 minutes early, so she asks me to take a seat. Interestingly enough, as I'm sitting there thumbing through magazines, I find an advertisement for my current company, Acxiom. It had to be the worst advertisement I'd seen. It was a city-scape with a lake and the words "We make information intelligent." What does that even mean? How do I know what Acxiom does from that? I sat there for about 10 minutes coming up with better advertising campaigns. It wasn't hard. Having worked at Acxiom, I am Jack's complete lack of surprise.

A little after the appointed time, my first interviewer came and got me. He didn't say much as he walked me to the room where I would spend the rest of the day. In fact, once we were in the room he immediately asked me to code the solution to a problem. There was no introduction, soft-skills questions, or questions to make you comfortable. It was just an immediate call for action. I did well on the first question, though it took the entire time. The next interviewer had to wait outside the door a bit for us to finish up. The only odd thing was that I still have no idea what the first interviewer's name was or on what team he worked.

The second interviewer was a bit better, I think he told me his name :) However, he once again avoided any comfort questions and went straight to the coding ones. He asked a question that I put to my CS 101 students. I told him that it is a programming assignment that I give them and that it is usually a bit long to write out; however, I hoped I could do a better job than they could. Still, the program just takes time to write and it took up an entire whiteboard by the time we were done. He asked quite a few questions about it and I fixed a few bugs reading back through it. He also asked me how I would test it and I went through the various scenarios. One of those scenarios failed with my current implementation, so we fixed that as well. Then, it was time for the next interviewer.

The next interviewer asked a design question. It was a question that I had some familiarity with it as it included aspects of record linkage. In fact, I explained a few things to him from the leading edge of research that he was not familiar with. We got into a little debate about whether user click-streams could be substituted for a heuristic algorithm, but on the whole it was a good interview.

After that, it was the team's boss's turn to take me out to lunch. Amazon doesn't have a cafeteria (at least they didn't take me to it), so we went across the street to a Thai restaurant. Turns out my interviewer liked the same type of food I did and we ended up ordering the exact same thing. We talked about my experience and work history over lunch and he talked about the team. He mentioned a number of times that it was a production team and I would have to carry a pager. He wanted to make sure I was ok with that. I told him that I was and that I had done support in the past and was fine with it.

When we returned to the office, it was his turn to ask questions. His were more logic/match puzzles. At first, he started by saying "You have an array..." and I thought, "Oh boy, here we go again." Pretty much every company asks the same array question. "You are given an array with N integers. Each integer is in the range of [1,N-1]. Furthermore only one integer is repeated. How can you find the repeated integer?" I got this question and variants of it in 3 of the 4 interviews. I was getting ready to answer it again for Amazon when he threw a curve ball and asked a variant of it that I had never heard. This one was more interesting and actually fun. Now, I don't think that this type of question shows anything about the programmer other than whether or not he's heard the question before. It's kind of like the moving Mt. Fuji questions of old. However, I worked through the question, got the "Aha!" moment, and solved it. I tend to like solving those questions. Even though it didn't say anything about me as a programmer, I had fun with it.

The next interviewer was to assess my C++ and OO design skills. He asked me stock C++ questions, which I answered without difficulty. He then posed a coding question that was really more about interface design than actual coding. I had to do things like make sure my constructor was correct and write operator + in terms of operator+=, etc... I wasn't familiar with the domain (and told him so), but in the end I came up with a solution. He told me that it was the same solution he came up with when he first attempted the problem. However, he had to do it in a production setting, not an interview setting. I felt like coming up with the same solution as my interviewer was a good thing, so I was ok with that.

The final technical interview of the day was another design question. It was with this question that I had the most trouble. It was a question that was directly related to how they track and update pricing information. I tried to use a database to help solve the problem. I'm not sure if this was the right approach or not as it really constricted me. In the end, I came up with a pretty pathetic solution to a very complex problem. I don't think either the interviewer or I was happy with it. It was the one interview that I sucked at :)

After that was supposed to be the boss of the second team I interviewed with. However, he was out of town so he sent a sub :) This person described his team and the other team that I was interviewing for. I asked a lot of questions trying to distinguish the teams. I don't know that I ever could distinguish between the two teams, they were so similar. The only difference I could gather is that one was also responsible for a new framework.

After not getting the team structure sorted out, I was on to the final meeting of the day. It was with the human resources person. He and I chatted about a few HR matters and then he showed me to the lobby where they called a taxi for me.

On the whole, my experience with Amazon was just "OK". They were obviously not a "tech" company. Their dress code, lack of free drinks, and general frugality said that they were a retail business. The employees were smart, but seemed a bit like "cowboys". Their plans were overly ambitious and I wondered about their success rate. I'd also read online about how hard they worked and how little they were rewarded for it. Now, I certainly don't believe everything I read online, but it can't help but color your views.

In the end, I thought that Microsoft would be the better choice. I've never worked for a "true" tech company and the search space was very exciting. I really enjoyed visiting Amazon and I'm sure it would be a fantastic company to work for, but in the end the prospect of working for Microsoft was too good to pass up.

Well, I hope you enjoyed this second installment of my interviews and be sure to look for the third (Yahoo!) and fourth (Google) installments.

Microsoft Interview - Live Search

After reading about Ben's interview at Microsoft, I thought I would post my own. Perhaps I'll post my interviews at Google, Yahoo, and Amazon later.

Where to begin? Let me start by saying I'm not a Microsoft fanboy. I don't have anything against them and use Windows on my home desktop and Office at work, but that's about it. I spend most of my time in Cygwin: a linux environment for Windows. In addition, I use Emacs and Eclipse. I have programmed professionally for 8 years, 7 1/2 of those years have been exclusively in a Linux or Unix environment. My primary languages have been C++, Perl and more recently Java. For a while, I ran Ubuntu on my desktop, but the kids and wife didn't like that so much :) Nevertheless, I think you can see that I am by no means a Microsoft fanboy.

I first applied for a position at Microsoft in 2003 in their Visual Studio group. I had recently completed my Ph.D. at Clemson and thought I was God's gift to programmers. I won't go into that interview at this time, since this entry is focusing on my latest interview, but I will say I bombed badly. For one thing, I ate something that disagreed with me and spent more time in the bathroom than in the interviewer's offices. Secondly, I was interviewing for both a PM role and an SDE role and so I kept having to switch modes. Thirdly, I was bull headed and wouldn't listen to any of the interviewers. I just sucked. They said I could apply again in a year, but I didn't. I figured they had a big red X on my submission folder.

Most of my professional career has been spent at Acxiom, a global interactive marketing services firm. Primarily, I study and implement ideas around matching and record linkage. Over the last two years, we've been bringing machine learning and information retrieval research to bear on the record linkage problem and it has been very exciting. I wanted to spend more time working on those large scale problems. Therefore, I submitted my resume to a few of the larger companies: Google, Yahoo, Amazon, and Microsoft. I got callbacks from the first three. Microsoft still had that big ole X on my folder.

My Google interview was first. I'll describe it in another post, but I bombed it. I didn't study and they didn't give hints. They were a great group of people, but it just wasn't my day.

Next up was the Yahoo! interview. I thought I had bombed it as well, but apparently not. I got an offer to work with the Pig team. However, by this time I also had an interview with Amazon upcoming, so I requested that they wait for my decision until after that interview. On a side note, I think the Pig team is great and I wish them all the best in the future.

Needless to say, I was very excited after receiving the Yahoo! offer. Perhaps I wasn't an idiot after all (I had begun to wonder after the Google interview - and my wife was making fun of me!). The first thing I did was announce it on twitter. The funny thing is, Gretchen, of JobsBlog fame, follows me on twitter. Her response? "Congratulations! Sounds like we'll have to do something about that." (Note: Since twitter is public, I don't have a problem reposting her words here). By the end of the day, I had three Microsoft teams contacting me. Among those teams was the Live Search team. Since I was interested in machine learning and information retrieval, I requested that team be the one I interview for.

I wasn't too worried on the day of the phone screening. After all, I had passed two phone screens for each of the three other companies; how hard could this one be? Turns out, it could be pretty hard. The screener started out by asking if I primarily used live search. My response, "No, I prefer Google." Once it escaped my mouth I immediately knew I bombed. How could I interview for a product that I didn't even use! She then asked if I had ever used Live Search, to which I responded positively. I told her I didn't see much difference in the results, which was true. She then moved on to the "coding" question. I won't go into the question, but I will say I didn't do too well on it. I started out trying to use a dynamic programming algorithm. She quickly informed me that the problem could be solved in linear time. Ouch! We worked on the program for quite some time. I got down the right path, but needed quite a bit of help. She then took questions from me and the interview was over. I knew I wouldn't be moving to the second round. I even sent out a few text messages saying "When interviewing with Microsoft, the answer to 'Do you use live search?' is not 'No, I prefer Google'".

A few days later I was driving my family to a local water park when I got the call from Microsoft. They wanted to fly me out! Wow! Apparently it is OK to use Google after all! I certainly didn't expect that. I was already going to be in the Seattle area for my interview with Amazon, so I asked if they could schedule their interview at the same time. It required some fast moving on their part as my interview with Amazon was only a week away. However, they responded brilliantly and set up my accommodations and new return flight. The only thing left for me to do was choose which teams inside of live search I would prefer to interview with. They gave me a list of teams and their descriptions and I ranked them.

At this point, I'll skip over the Amazon interview and move forward in time to the day before the Microsoft interview. Amazon does not provide a rental car, but instead reimburses you for taxis. Therefore, I had to take a Taxi back to the airport and then get the rental car from Microsoft. From there, I drove to Redmond and found my hotel. It was in the Redmond Town Center, which provided a great venue for eating and shopping. I got there in the afternoon and I found greek diner in the town center. After lunch I went back to my hotel and watched some Ars Digita University algorithms classes. In addition, I had also spent some time reading the CLRS Algorithms book. Those two things, coupled with an online MIT course on algorithms would be my primary study guide. Unlike Ben, I didn't work too many problems out on my own, just geeked out over videos :) On a side note, the hotel that Amazon provided didn't have free in-room internet, so it was nice to be in a hotel that did.

At this point, my worst nightmare happened. My stomach began to churn and I started spending more time in the bathroom than out. Why did this keep happening to me? Was it nerves or do I REALLY not like Seattle food? I tried a couple of times to wander around the Redmond Town Center, but each time I kept having to run (literally) back to my hotel room. If this didn't pass by the next day, I was going to just die.

Luckily it went away. I ended up eating something light for supper instead of all the greek and italian food I'd been eating. That seemed to help. By the morning, I was going to the bathroom at a much slower pace, so maybe I'd be ok.

I left very early in order to get to Building 19 on time. I didn't map out the route the day before, so I wanted to be sure I could find it. I'm glad I did leave early because the signs to it aren't overly visible and I looped the Microsoft campus a few times before finding the right building.

The receptionist inside the Lobby of Bldg 19 took my name. I commented on her ear thingies. She had things in her earlobes like they have in Africa. I asked her what they were called and she said, "Gauges." I told her I was from Arkansas and we don't see too many things like that, but I thought they were cool. She thanked me and pointed to the waiting area. Yes, right, don't flirt with the receptionist...go sit down.

The waiting area came complete with an XBox 360 and a copy of Guitar Hero, which another candidate was playing. Well, at least I thought it was a candidate. I have to admit, she was really tearing up Guitar Hero - definitely a pro! After her turn ended, she looked back over at the receptionist and said, "Ok, your turn!". It turns out she was the OTHER receptionist. They swapped places and Gauge Girl began playing Guitar Hero (well, she offered it to me first, but I politely refused). Sadly, I began wondering if that was a test. Maybe they only hired people that played Guitar Hero when given the chance? (yeah, I'm sad like that)

After a bit of waiting, my recruiter came in. He took me back to his office and we began to talk about Microsoft. He gave me a great spiel about the company; he was a good salesman. We ended up talking longer than we should have and I had to hurry to get to a bus. Unfortunately, all the buses were gone and we had to wait for one to come back. It made me late to my first appointment :( He said not to worry, he would call over and tell them I was going to be late. Furthermore, like Ben, I was give a schedule that only went until 2:00. If I didn't perform, I'd be done then.

My first interview went ok. I never do great in the mornings, but I answered his questions satisfactorily. I forgot one simple case which finally came to me, but other than that, I did fine. I mentioned this failing to the next interviewer who said not to worry about it. The next interview was more challenging, I had read a bit about what he was asking, so I had some background, which I explained to him. However, I only had the broad theory, not the intricate details, so we proceeded to hammer out the details over the board. It was actually a lot of fun because I knew certain things to be true, but didn't know why. We discovered why together over the board. It caused a lot of "Aha!" moments. The only downside is that I missed a key part that caused my runtime to explode. I figured this out as he was chatting with the next interviewer and when they returned I mentioned the optimization to him. He nodded his agreement and passed me off.

At this point, it was lunchtime. My interviewer took me to the cafeteria. I got Chinese food because I thought I could eat the rice without it upsetting my stomach. We talked over lunch and I didn't eat much. We mainly discussed coding styles, agile methods, etc... Turns out he was interested in a book club I had started with my current company because he was running one for his team.

After lunch, we returned to his office for some interface design. I teach a UML class at The University of Arkansas at Little Rock so I sketched out my interface and design in UML. We went into detail around some of the decisions, like whether to use a visitor pattern and factory pattern. I think I did ok, but it is hard to design an interface without seeing use cases for it first. I mentioned this toward the end and he agreed. At the end of this interview it was 2:00...and...he took me to the next interview!

During this interview I was back to coding. Actually, I never got around to coding too much as I spent most of my time determining the algorithm. This is a big difference from my first Microsoft interview as I would have gone straight to the code. In this interview, I stepped back, looked at a number of examples and came up with the right solution first. I coded it pretty quickly, but no major mistakes. He showed me some of the cool things his team had been working on. I was really impressed! Then, he took me to the next interviewer. This interviewer focused me on a "real world" problem. In other words, this problem was one that they had seen and solved in the past. It took me about half the interview, but I came up with the solution. He seemed impressed and said that not many of their interviewers come up with that solution and it is the one that they actually used in production. I was pretty pleased with myself at that point. We spent the rest of the time talking about their projects, team structure, etc... It turns out that both teams I interviewed with spend a lot of time working with Microsoft Research, which is really cool for an academic like me :)

That was the last interview before the "big boss", who took me to get a drink and a snack. I was hungry since I didn't eat much lunch, so I took him up on a granola bar and a bottle of water. He spent a lot of time telling me about Microsoft and asking me about my previous experience and the work I did with my current company. I told him what I could without violating any NDAs. He seemed pleased with what I told him and I was very impressed with what he was saying about the future of the team. He described a lot of their internal systems and frameworks, all of which excited me. Like the recruiter, he was a great salesman. That must be a Microsoft thing :)

After our discussion, he said that I should meet the other team's "big boss" (my words, not his). He left me in the lobby of his building and went to hunt the other one down. Turns out the other "big boss" had just gotten done playing softball with the interns and needed to clean up, but offered to take me to dinner. I graciously accepted and sat down to wait as he got ready. I went to eat with him and one of his team leads (who I had interviewed with previously) at an Italian restaurant in the Redmond Town Center. We talked about Microsoft, the Yahoo deal, Google, our mutual desire to WIN, etc... He was also a great salesman.

I was pretty pumped after leaving there that night and couldn't sleep a bit on my red-eye flight back home. I called my wife and told her that I was pretty sure we'd have an offer from Microsoft to consider. Turns out we would also have an offer from Amazon.

I won't go too much into my decision making process other than to say that I did not like the Silicon Valley area. It just felt dirty to me. I was much more at home in Seattle. I liked the contemporary vibe and the fact that there were actual trees. Lots of trees. Yeah, I know it rains, but I don't like the sun much, anyway :) Therefore, though the Yahoo! job was very attractive, I just could not accept it. My decision was between Amazon and Microsoft.

At one point, I thought I wasn't going to accept any of the offers. We are settled, the kids are in school, we own our home, and life isn't too bad. However, I think the ability to work with some amazingly smart people and have Microsoft on the resume is too good to pass up. It is not often that you get to work with internet scale data. My work at Acxiom is on billions of records, but nothing like what you see when you consider search. The playing field is very, very different and you have to think WAY outside the box, which I love to do. Moreover, I think it would benefit our kids to be in an environment like Seattle. There's a lot to see and do there and there are many more opportunities there than there are here in Arkansas. Finally, the school systems there are very good and I think the kids will benefit greatly from that.

I start on August 25th and I am very excited. I'll be sad to leave a great team behind, but I know they wish me the best as well. Now, I'm looking forward to starting the next phase of my life as a member of the Live Search team. Google, look out!

New Job

I'm excited to announce that I am joining Microsoft to work on their Microsoft Live Search Engine. It's going to be a big transition, but I've never lived in the northwest, so it is a very exciting time as well. I begin there on August 25 and am very excited!

Please keep me in your prayers during this exciting, but stressful time.

The last month

Hopefully my employer doesn't have my blog in his RSS feed :)

Over the last month I have interviewed with a number of great companies. I have had a blast going and visiting with the brilliant people that inhabit the halls of Google, Yahoo!, Amazon, and Microsoft. I have, or am receiving, offers from three of the four. It is definitely an exciting time as I rush to look at places to live, schools for the children and compare things like benefits, stock prices, growth potential, and perks.

It will be sad to leave my family and friends; adjustments will be necessary all the way around. However, I am very excited about the opportunities that lay ahead.

I won't describe the interview process or questions. However, I will say that all of the questions were very intelligent and relevant. It helps to know core algorithms and data structures such as lists, queues, and trees. Graph algorithms and advanced data structures like heaps and splay trees are also good to know. More generally, you just need to be able to tear a problem apart and reduce it to its essence. They want to see that you can analyze a problem and coming up with the right solution immediately is not as valuable as coming up with many solutions and being able to weigh them.

All of the companies had extraordinary employees, a great culture, and innovative systems. They all operate at "web scale" which means their problems are MASSIVE. No matter which company I choose, it will be a great choice.

I'm looking forward to the journey and I'll keep you all updated.

ArsDigita University

There are a lot of great free videos from Ars Digita University. Check them out!

Researching in a Search 2.0 world

A lot of my time is spent researching. A LOT of my time is spent researching. I research things around record linkage. I also research clustering, classification, natural language processing, and machine learning, in general. Quite a few times, I have to get up to speed. I need to understand what Felligi and Sunter did in the 1960s before I can understand what Winkler added to it in the 90s and what the general entity resolution research is all about now. Or, perhaps I just want to be a better programmer. Perhaps move from a O(N) to O(log N) on the Programmer Competency Matrix.

For Search 2.0, much of the hullabaloo has been about Natural Language Processing (NLP). Companies such as Powerset have touted their products as being able to understand a human query. For instance, the powerset engineers have given demos where they ask their engine "Which politicians died of disease?" and it gives back a list. This approach is great if I'm after general information, or if I'm helping my kid with her homework. However, it doesn't give me perspective about research. Why am I asking about politicians and disease anyway? Am I trying to get a statistical view of politicians that die of disease vs the health of the rest of the populace? Am I trying to understand the effects of an ill politician on the society? I might wish to see the sites that others also searched for, much like the Amazon feature. Or, maybe I want additional statistics about that country during the time period. In other words, I need more than just the answer to my question. I need a path that others have followed that I can follow as well. Eventually, I'll have to get off the path, but I want to stay on it as long as possible.

In addition, I want to quickly understand an author's position. I want to know, with my search results, whether this author is an expert or a novice in the field. I want to know where his or her funding comes from. I want to know, based on statistical analysis of their previous posts, if they are conservative or liberal. Have they published papers? If so, in what journals? Are they top journals? It is this context that will make search valuable. Whether or not I can ask a specific question is irrelevant to me. I'll figure out a way to ask the question; however, I want more information back in an easy to understand manner. I want the site's PageRank, I want a general view of how other sites have posted about the site in question (positive or negative), I want to see complaints or complements if it is a potential employer. I want CONTEXT. It seems to me that people get on the internet a lot for research. You research a good book to buy or what digital camera to get or where to go on vacation. All of these things could be enhanced by adding more context, more data mining, and better presentation of the information.

That will be search 2.0.