I met him a few years ago when he impromptu visited the gamedev studio where I worked (a mutual friend caught him on the street during lunch). During that brief visit he did come across to me as a really nice guy with a genuine interest in games and the tech that powers them.
I guess losing your giant ego driven career after telling people to "suck it down" because "John Romero's about to make you his bitch" does that to a man.
Also: "It's also important to take the time to really use the tool yourself, so you can experience what's annoying about it."
Even if programmers are willing to ask those questions, it's a two-way street, and users often don't know what to ask for, or what's possible [insert apocryphal Henry Ford quote about faster horses]. Obviously, asking those questions and pursuing answers is a key attitude, but maybe that attitude also has to be augmented by trying to dogfood what you're building for someone else.
Which is why exploratory UI/UX design with tools like Balsamiq , Sketch or Adobe XD is important.
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.
> A lot of times, ... programmers don't go far enough asking the questions about 'Why do you want that? What is it that you're actually trying to do?'
> 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.
When I was learning to program, designing a good interface was something I always considered to be part of the job. Maybe not graphic design but there's always an element of interface design somewhere in programming, such as API design
> programmers are not trained, nor have the time to go far enough asking the questions
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.
> Please state the fact: programmers are not trained, nor have the time to go far enough asking the questions.
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.
> A lot of times, ... programmers don't go far enough asking the questions about 'Why do you want that? What is it that you're actually trying to do?'
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.
> Please state the fact: programmers are not trained, nor have the time to go far enough asking the questions.
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.
> Please state the fact: programmers are not trained, nor have the time to go far enough asking the questions.
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.
19 comments
[ 0.51 ms ] story [ 67.1 ms ] threadI guess their background in writing tiny random apps for Softdisk explains it.
As somebody who is currently trying to push more UI/UX-centric ideas in their company, this quote really hits home.
Edit: maybe someday I'll get formatting right the first time.
Even if programmers are willing to ask those questions, it's a two-way street, and users often don't know what to ask for, or what's possible [insert apocryphal Henry Ford quote about faster horses]. Obviously, asking those questions and pursuing answers is a key attitude, but maybe that attitude also has to be augmented by trying to dogfood what you're building for someone else.
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.
Please state the fact: programmers are not trained, nor have the time to go far enough asking the questions.
Don't pretend that non-tech people are capable of doing anything tech-intensive.
I am tired of the unilateral narrative of "tech people really blabla...".
People are trained differently, and their time is focused on different areas.
If you want to talk, stop implicitly insult the other group of co-workers.
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.
However I do concede that they are easier to grasp for those that are stronger into graphics programming.
Qt, JavaFX, HTML/CSS, Android, UWP, WPF, random UI toolkit, are then just the tools how to bring those UI/UX ideas into life.
Article here: https://www.gamasutra.com/blogs/DavidLightbown/20180109/3094...
And relevant HN discussion: https://news.ycombinator.com/item?id=16110133