What I do at Yahoo!

What I do at Yahoo!
Originally uploaded by jmeyer.

Here is a screenshot of what I have worked on at Yahoo over the past 12 months. It's called Contextual Shortcuts and it's running as part of Yahoo! Mail. As of today, you will have to use the old style interface, we are hoping to add it to the new Yahoo! Mail Beta sometime this year.

You can read about what it is in the Yahoo! Mail help pages in the Shortcuts section.

The system has many parts to it but in short the Contextual Shortcuts platform tries to indentify interesting and relevant pieces of text and then offer you an in-place user experience that is appropriate for the detected item. For example, if we detect an address, we will show you a map and let you add it to your address book. If we find the name of a place (e.g., New York City) we offer you Search results and a map. All of this without requiring the user to leave their current context (that's one of the reasons we named it Contextual Shortcuts).

We are adding more features and improving detection right now and if all goes well you will see this elsewhere too. Wish us luck.

Painful Presentations at Work

We have probably all witnessed one of these, either at school, at work or at some event in our spare time. A painful presentation. What makes a painful presentation you may ask? Here is my list of things that indicate a painful presentation:

1. The presenter apologizes for the readability of his/her slides. Never a good thing, if you know it's unreadable, don't use it or break it into more than one slide. Making good slides takes skill and a few tries but everyone who gives presentation should know that a picture says more than thousand words and is a good thing. On the other hand, too much text on a slide and too many slides make for a bad presentation.
   
2. Soft-spoken presenters. I know not everyone can have a booming voice and assert himself well and look confident. However, if the entire audience has to collectively hold their breath to be able to hear the words than you are witnessing a painful presentation because a listener spends all his concentration on making out the words.
3. Presenters that can't speak the language. I know, sometimes they don't have a choice but to me it's the same issue as #2. It is so tiring to make out the words and try to understand what the hell is being sad that I lose interest and look out the window. The inability to master a language coupled with a monotone voice simply sucks.
   
4. A presenter who tries to be funny but who is not. Yeah, I know, we all like to be comedians but very few can pull that off. So , unless you have a good feel for an audience and what kind of style they respond to, keep to your roots. After all, in my line of work, most presenters are scientists or engineers and teh majority is not funny.
5. A color-blind presenter. How can you tell? Look at the slides. They may be readable but looking at them makes you want to vomit or reminds youof wallpaper from the seventies? Than you are witnessing a presentation by someone who is blind, color-blind or simply has bad taste.

So, I think you can survive a presentation if only one of the above holds true and the presenter can offset one shortcoming like crowded slides with being a good speaker. But if you can check off more than one of the above issues in a presentation then it is time get out. Reminds me of the Southwest slogan: Want to get away? All I can say is run, run fast otherwise you will be wasting an hour or more of your life that will never get back. What else can save a bad presentation. Well, free food of course but it'd better be good or else your brain and your stomach will hurt.

Debugging skills -- It's not Rocket Science!

Every programmer knows all too well that there will be times when (non-trivial) code does odd things. Yes, I am talking about bugs. Often times they are simple because they easily reproducible and the faulty behavior can be seen in a simplified environment. But what if the bug is not easily reproducible. That's where good debugging skills come to play.

Sometimes debugging feels like detective work but in almost all cases it really isn't much more than breaking a big problem into many smaller problems. Yes, simply breaking an input down to smaller pieces until a problem disappears is often a good way of making one's life a lot easier. Besides having a good grasp of eliminating possibilities, a decent knowledge of debugging techniques and tools is certainly helpful. On my last project, more than once I was asked to help fix some bugs by other developers. When I asked them what they have tried so far or found out they usually said nothing. They just needed help. My first thought was that it was laziness. ASking someone else to fix a problem is certainly easier than fixing it yourself. But after interacting with them it dawned on me that they often had no idea of how to get a handle on the problem. Just asking questions about how and when the problem presents itself are often not asked. Well, bugs never come with a manual on how to fix them so you better ask questions if you want to fix them.

Another helpful aspect for debugging is to know the code itself. A lot of times I have found that developers didn't even know how to debug their own code. Having a good knowledge of the structure of the code helps to eliminate potential sources of errors. I can't claim for myself that I am the world's best debugger nor do I want to do that. But I was surprised how few people actually can debug and provide useful information when helping to find fix a bug. Makes you wonder if the CS curriculum should be extended by a mandatory class: "Introduction to Debugging"

It's not rocket science -- like so many other things applying common sense and using the good ol' divide and conquer technique helps a good deal.

Ever heard of "Seagull Management" ?

A coworker and I were chatting about our current project at Yahoo! which we are about to release to the public. As we talked about who was really helpful, not so helpful, entirely useless or simply a pain in the butt, he brought up the term seagull management. Wonder what that is? It's managers, that fly in from time to time, aren't really well-informed, flap their wings and make a lot of noise and leave a bunch of crap behind for those people that actually do the work.

Anyway, on one or two occasions we had this happen on our project but overall it's looking good. Stay tuned for more on this? I am pretty excited about getting some of my work out to a large number of people. Never really had that IBM. I mean, we did cool stuff but unfortunately we never made anything available to the public because either IBM did not want to, could not decide in time or wanted to turn it into a secret ...
Let's see how things go. More later.

Hiring great people is hard ...

Back in those days when I worked at IBM I did a lot of interviewing candidates for jobs we had available there. What I noticed back then is that pretty much all candidates sound reasonable on paper but very few were actually as good as the paper made me believe. It even appeared as if only mediocre people would apply for the jobs we posted. What's the problem there? Well, Joel's blog provides some good explanations for this and I encourage anyone who is hiring or interviewing people to read his post on finding great developers. I completely agree with him on the one point that truly great people never really send resumes out to job postings, heck, they never even enter the job market. Why? For one thing, good people carry a reputation and will go to new places through friends, former co-workers that now work for someone else. Or they get approached approached by the same circle of people. So who is left on the job market? Probably those who were rejected before or those who just start out. I for one think that is almost always better to take someone who is fairly junior with good basic skills over a medicore candidate who may have some (worthless) experience already. We are currently looking for someone in my group and I am interviewing again. Let's see how that goes and hopefully we will find someone great. But what makes someone great? Well, for one thing it is hard to find that out in 30-45 minutes. And anyone who is not a complete idiot and has worked on a topic will sound like an expert in that particular field. Unless the interviewer works in the same field it is somtimes hard to determine whether the candidate is phony or not. What matters to me? Well, when interview I look at how people approach problems. I don't expect anyone to know all the answers to my questions in the area of programming or algorithms. But I expect them to come up with a reasonable/feasible way of attacking the problem. Should someone be able to write the source code for QuickSort in an interview? I don't think so because I couldn't do that either and it does not really prove anything. What is more important to me that someone could tell me about its properties or where he would go to find out about it.

Things to know about Management

Over the years at IBM, Yahoo and in other jobs I had my share of managers. With them came different management styles. Some of them were good managers, some of them were medicore and some of them plain sucked. I had very old guys as my manager and I had managers that were my peers and my age and then "moved on" to have their manager bit flipped. When I read Joels series of posts on management styles it reminded me of some of my previous managers and the way they interacted with me and my peers. There were the guys who felt they had to make a decision simply because they were the manager, ignoring the fact that they had no background or in-depth knowledge to even make such a decision. Then there were those that were afraid to make a decision. Or maybe not afraid to make a decision but rather afraid or scared to stick up for it. I admit it's probably not easy managing programmers because a lot of them have a self perception problem and think they are better than they really are. But what happened to "common sense"? I think if some managers would start thinking how they would like to be treated as a managee they would do things differently. So along those lines, here are some things a manager of a programmer should avoid:

1. Don't make decisions based on traditions. Hearing "This is how we used to do things" drives me nuts. Listen to your people what they have to say.
   
2. Don't treat everyone the same. Some people like to be told directly what's going on and others can't handle the truth. I don't suggest that lying should be part of a managers repertoire but it always drove me nuts hearing managers beating around the bushes and saying the most brutal things in such flowery words that it was almost impossible to figure out what they wanted to say. Let's face it, work is no kindergarten and if someone can't stand being told how things are they should find a different lien of work.
3. Becoming a manager for the wrong reasons. You shouldn't become a manager because it is the natural advancement on the career ladder. If you are kick-ass programmer, researcher that doesn't mean that one will be a great manager. I for one hate to deal with all the personal BS and I can't see myself becoming one soon. However, if one becomes a manager they often stop to think like a programmer because they have to fit into the management chain.
4. Not givning people some freedom. Micromanagement sucks. Constantly breathing down someone's neck sucks too. There are times when things like that are justified but again, these tools shouldn't be used in general but rather based on the individual managee. Some of them need the daily dose of manager interaction, others can go a week without it.
5. Not sticking up for your people. I once had a manager who seemed threatened by me and the work I was doing. Don't know why but we never hit it off. When evaluations rolled around he wrote a one sentence evaluation like this: "Joerg did outstanding work!" What's wrong with that you may ask? Well, sounds pretty good but it was just an attempt to hide the fact that he did not want to push upper management for also giving me the best rating which really mattered in terms of recognition (by upper management and through compensation). So I talked to him and it turned out that he never even tried, had no idea what my contributions were. So I told him he sucked, went to his manager and told him what I had said. Now, don't try this at home. You should be very certain to do such a thing. I probably owuld have done it anyway even without being in very good standing. But it does raise the point why some people become managers when they truly suck and how they remain in that position for so long.
   

There is certainly more and I do want to add that I did have some good managers. The ones that I considered good were usually very direct, straightforward and demanded a lot. But they were also giving back a lot. So, whoever is a manager or becomes a manager, remember the times you were fed up with your manager and try to avoid exactly those things. That's the best way of becoming a great manager.