John Romero talks about creating TEd, the tile editor

A bunch of screens that can be used to discuss UI workflows with the actual users, before writing any line of code or setting decisions into stone that can turn into show stoppers.

> It's also important to take the time to really use the tool yourself, so you can experience what's annoying about it.

I've actually found both of these to be useful in discovering future side-projects, or the design of my future home.

What am I really trying to do? Maybe I should use a cloud-based option rather than a file-sync oriented one.

What annoys me so much about this? Push to open cupboards have no visual UI hints and the dishwasher requires you to knock to open it. Just add some handles and be done with it!

If this annoys me, will it annoy someone else? Maybe I could develop a product around this.

It may be hard to do right and it may be oblique to the typical reasons and interests for which someone becomes a programmer, but it absolutely is (or was, and should still be) part of the training for a programmer. And the time to do it must be part of the task, just like time to do proper testing or documentation.

Why be so hostile towards Romero's comment, which seemed to be made in a light-hearted context? He's describing the situation as he has seen it; perhaps he is mistakenly inclined to put the onus on programmers rather than cultural and historical factors because of how programmer culture is so steeped in self-driven destiny-controlling meritocracy. I agree that culture (which includes training) is a factor -- OTOH, that doesn't mean Romero's quip isn't useful to programmers who can use it to better themselves.

These are not questions anyone should be "trained" to ask. These are natural questions that should come up when asked to implement some requirement.

When I'm handed a requirement I don't go run off and start typing code. I ask clarifying questions because I have never once seen a req that didn't make me have questions. That should come natural.

Speak for yourself, bub. I ask questions all the time when I write software.

Usually, when I write software for someone other than myself, I have these things called "functional specifications", which is how I know if the thing I wrote does what the person I wrote it for expects. Sometimes those are in a big, boring document that some corporate department insisted we write in advance, other times they're in the form of "user stories", depending on how the people I write software for like to do their planning. But either way, I ask questions and try to figure out what they want, and I do it because I'm the skilled person who has to try to do that. And asking those kinds of questions is part of the job, unless you're making something for yourself or if you have no customers.

And if you want to talk, maybe you shouldn't insult all programmers everywhere by suggesting they share your lack of skill when it comes to talking to people.

The technical skills an engineer is trained in are much less than half of the actual skills you need in order to be a good engineer. Arguably communication is one of the most important. You're there to solve problems. Solving problems without creating more problems involves solving the right problems. Finding the right problem requires asking the right questions.