In the interest of not scaring off employers of both the "current" and "potential future" variety, it's perhaps useful for me to follow up and clarify my comments originally made here. 

In general, I meant what I said... code reuse is usually more trouble than it's worth. Usually, you're better off not trying too hard to make it work, because you'll probably fail, and waste a lot of time. Even if you're smart, and certainly if you're not.

I come by this point of view honestly... I've personally failed more often than not in trying to build "The One Reusable API to Rule Them All". I don't think it's a big secret that most others fail at this, too. I like to think I've gotten better as I've aged... but it's still a tough nut to crack.

IMO, the characteristic most often desired in "software that shall be reusable" is FLEXIBILITY. Truly flexible code that is widely applicable across multiple disparate problem domains is a thing of beauty... and extremely rare. The fact that any such code exists isn't the telling point; the fact that it represents an infinitesimally small percentage of all code ever written is.

Most "flexible" code I've personally witnessed was anything but. I've concluded that flexibility (and the goal of wide-scale reuse) is wildly overestimated as a desirable (and achievable) code characteristic for most classes of software.

So I say all this to say, reusable software is hard. It has instant sex appeal for non-technical manager types (which makes it even more dangerous), which is probably one reason it perpetuates. And certainly, there exist many fine counter-examples in the wild (none of this really applies to SDK vendors, obviously).

But I think the world would be a better place if we software types focused on building for today, and not For All Time To Come. Try it, and use your extra free time to read up on refactoring and test-driven development... there's your flexibility, cowboy.