Jeff Atwood:
Anecdotally, my personal search results have also been noticeably worse lately. As part of Christmas shopping for my wife, I searched for “iPhone 4 case” in Google. I had to give up completely on the first two pages of search results as utterly useless, and searched Amazon instead.
People whose opinions I respect have all been echoing the same sentiment—Google, the once essential tool, is somehow losing its edge. The spammers, scrapers, and SEO’ed-to-the-hilt content farms are winning.
Marco Arment:
Google was designed to play the role of a passive observer of the internet: web content was created for people, not specific Google queries, and Google would look around, take inventory of what was available, and give it to people who asked. Google’s general, big-picture algorithms probably haven’t changed much since the days when this was relatively accurate.
But that’s no longer what web content looks like.
I’ve been noticing these problems, too. Very specific, phrased queries used to be gold, but now they often bring up perfectly tailored spam pages.
Mark Alldritt:
This design seems to allow one to have a minimalist Find & Replace panel within an editing window while still offering a usable and discoverable range of search options to the user.
Inline Find bars work great for quick searches, but for Find and Replace I want a resizable, moveable window with large fields, large buttons with keyboard shortcuts, etc. It seems like popover-style attached windows combine the disadvantages of both approaches.
Update (2011-01-09): Andy Lee comments.
Michael Feathers:
If you take a program with structure A and want to transform it to structure B, how large are the steps you have to take to get there? In a low-level language you can make many small changes to get from A to B, but as the level of the language rises, it’s often easier to rewrite some bit of code than to refractor it into a different shape. […] To me, this is granularity. When you use lower level constructs, you have more waypoints. I don’t think this is good or bad necessarily, but it does make the work different. When the grain of a language is coarse, we may have fewer steps when refactoring, but we may also have a bit more work to do to see the next step. When the grain is fine, we can often have more confidence that we are going to get to the structure we’d like to arrive at and we’re tempted to take it a little slower, with many more intermediary steps.
Programming Refactoring Testing
