Often I'll ask people what they think of a program, and then when they say reasonable things about how they'd like it to work I explain the technical reasons I've not done what they'd like. I'm trying to keep myself from doing this. Instead I should talk to them and figure out what the right way to do it is. Then, once I understand whether this would really improve the interface, I should start thinking about how I would implement it. [1]

I didn't do this very well with julia's most recent suggestion. I had modified my mbta plotting program to show little bubbles over upcoming stops indicating how long until your bus arrives in response to a click on the bus:

When julia pointed out that as time passes the bubbles just stayed there without keeping up to date, I was good and didn't just say "it would have been too hard to do that". That would have been a false explanation, claiming the limit was from the technology instead of from me. I was dumb, though, and let ease of implementation distract me from the most usable solution: I said "ok, then, I'll just make them go away after a minute" instead of "ok, then, I'll make them update automatically". This was me looking for an easy solution instead of the right one. The easy one is to hide inaccurate information; the right one is to make the information accurate. Thinking about how I would want the program to work if I were using it might have helped. Which I guess is another thing for me to work on.

[1] In theory I might decide instead that it would be too much trouble, but for the most part as this is something I'm doing for fun I want to make it be as good as I can. People tend to ask for doable things, at least the people I've asked.