As we all know, giving estimates for the completion of a file transfer is almost unconditionally what makes programmers look like complete dolts to the casual observer. (Among the other contenders are things like this.) Mac OS X has in my experience been more consistent with underpromising and overdelivering, but it’s still sort of a “five minutes, no wait, ten minutes, no, two seconds… no wait! Green!” proposition. If only there were a way we could collect these estimates over the time of the transfer, measure the actual time and over time normalize away the error, weighting into the equation certain troublesome devices… Hey, wait a minute.
This is a detail. It’s a tremendously small detail, but it’ll have a great impact if it’s correctly implemented. If you’re employed as a programmer, how your company reacts to a suggestion like that will say a lot about its attitude.
In Monocle, my search tool, you can set up several search engines. The Preferences panel is faux-easy. There’s just the list of the engines with the name, icon, search bar color and notes. Wait — notes? Yes, newly invented rhetorical device man, in that list, there’s notes that you can affix to the engines, and they only show up there, and in the edit sheet. Yes, you have to pull down a sheet to edit the engine. (Except for the name. I’m not a total dolt. Uh, and you can also edit the notes.)
So let’s say you wanted to edit the icon? Here’s the number of pixels to edit the icon in Monocle 1.1b2 (sheet not overlaid to not obscure the Preferences window): 
Wow. That won’t do. And meanwhile, the most space taken up by any single user interface element (I think even eclipsing the title bar/toolbar) in that screenshot is the… notes column in the list. Huh.
Does anyone actually use those notes? Well, someone probably does. I can’t just remove them. Or maybe I can. But that’s not the point — the space can be put to better use. Therefore, introducing what the current Monocle development version looks like: 
That’s a lot less pixels. You can’t edit notes without pulling up a sheet now, but you can edit the icon, color and callword. (A callword is a small prefix you can type into the search field to unconditionally switch to that specific search engine directly. You know how you can type “g foo” or “wikipedia bar” in some browsers and search fields to search on different engines? This is a work-like-that feature.) There’s more subtle stuff to this yet though.
The Edit button was given a makeover by her Cuban surgeon of questionable legality and moved inside the “current engine” blob for way better locality - what you’ll edit will always be what’s inside the blob that, hey, the button itself is inside of. And since all the details that you’d usually care of (I’m thinking 90% of the time) are in there, a name change to “Advanced settings” makes sense. What’s left in the panel is the really advanced stuff and, for now, that damn notes field.
The “Add manually” button also took a hike. I have no idea if anyone added engines manually. But I know this - I wrote the app. I know exactly what the automatic search engine discovery can deal with and not. And despite this, I honestly can’t recall when I used it myself besides testing that it worked. When do you need to use it? When the discovery doesn’t work and when you’re migrating from another tool - both of these things are more worthwhile to improve than a scary button proposing manually adding engines. You don’t know how search engines work, you don’t want to do this “manually”, do you?
I don’t usually talk about software details here, at least not in my own software. I don’t want to come off as a blowhard drunk on his own excellence. Even if I’m fairly sure that’s not the way it’ll be interpreted, I still shy away. It’s generally good to save your breath for the really big features and not talk about details. The impression details leave are good impressions — the impression talking about details leave tend to be “we’ve managed to nail something small perfectly, and we’re going to talk about that since we have nothing of real value otherwise”.
People do care about details. They care about the specific detail they’re using right now. They care about details in the aggregate, whether they think about it or not. Sometimes they care passionately about some details. Assuming Monocle has many users and my email address is visible enough, some people will ask why the hell I’m removing / have removed the notes field (”universally,” maybe they’ll say, “renowned as the best thing since sliced bread”) or the Add manually button.
But that’s just the thing. Sometimes a detail makes an entire app. Evidence Based Scheduling, to which I linked way back at the start, something I’ve been craving since FogBugz 6 was released, is probably something that started out as a detail. And sometimes the detail… well, it’s just a detail, a triviality.
You don’t know which is which and for whom. You’ll have to take care of as many details as possible. And there’s nothing saying that even because it’s a detail, it won’t conflict with anything else. And you can market something as a feature although it’s a detail or vice versa but you’ll never know what people will read out of it. And you’ll have to prioritize them. And fit them in with real features, real bug fixes, real crashers. And rigorously defend the time you’re “wasting” to your boss, if you have any. To yourself. To your customers. To that looming killer feature you’ve been putting off because it’s so much work. To your deadline.
It’s easy to fall into complete detail apathy, to just implement what you need to implement. I’ve seen it happen several times. Some people just don’t have a developed way to deal with it yet, like some people don’t have a “sense” of UI design. I hope they can be reformed. You’ll have to trust that it’ll be worth it. (And when you do get credit for it, it feels good, I’ll admit.)
Because, hey. “That’s all your app is: a collection of tiny details.”