Cómo hacer una pregunta a un programador sin obtener "Por qué" como respuesta

31

Todos hemos tenido esta experiencia. Vas a alguien que sabes que tiene la respuesta a una pregunta, le haces la pregunta a esa persona y ellos responden con la respuesta típica: "¿por qué?" Explicas por qué necesitas saber e intentan resolver tu problema.

Se necesita tiempo, giro de brazos y paciencia para dirigir la conversación de regreso a la pregunta original y obtener esa maldita respuesta.

¿Por qué los programadores hacen esto constantemente y por qué el comportamiento empeora a medida que el programador se vuelve más senior?

¿Cómo puede hacerle una pregunta a un programador de la manera más eficiente para extraer la respuesta a la pregunta original?

Reactgular
fuente
54
Es muy probable porque saben que es muy probable que no necesites esa respuesta. How do I walk on water? Why? I want to cross the river Build a boat.
Daniel Gratzer
30
Es un truco, diseñado para evitar que pierdas nuestro tiempo. Aprenderá a ser preciso o dejará de preguntar.
Yannis
17
Porque más programadores senior saben que la mayoría de las preguntas que se les hacen son preguntas XY.
Marjan Venema
12
"Muchos de los comentarios pertenecen a explicar por qué el desarrollador se comporta de esta manera ... Esta no es una respuesta a la pregunta anterior". Es una respuesta directa a la pregunta "¿Por qué los programadores hacen esto constantemente y por qué el comportamiento empeora a medida que el programador se vuelve más importante?" que se incluye en el cuerpo de la publicación. Esto también demuestra por qué los programadores actúan así: las personas que hacen las preguntas con frecuencia no quieren las respuestas a las preguntas que hacen , sino que quieren las respuestas a las preguntas que querían decir .
8
"¿Cómo puedo conseguir un poco de plutonio?" No no. No hay preguntas por favor. Solo dime como.
Erik Reppen

Respuestas:

91

¿Por qué los desarrolladores preguntan "por qué" cuando alguien les pregunta cómo implementar una solución?

Porque requiere más conocimiento para evaluar si una solución es apropiada que para implementarla realmente.

Es muy difícil creerle a alguien cuando dice: "No sé cómo hacer esto, pero sé con certeza que es lo que tengo que hacer". Los programadores insisten constantemente en profundizar porque las personas insisten constantemente en hacer las preguntas equivocadas. Sí, a veces eventualmente vuelve a su pregunta original, pero no siempre.

Como analogía, imagine si alguien se acercó a un mecánico y le preguntó cómo reemplazar la batería de un automóvil. Por lo general, si está calificado para diagnosticar una batería defectuosa, está calificado para cambiar una, por lo que el mecánico le preguntará cómo debe reemplazarla.

Él sabe que si no hace esto, y resulta que no necesitas una batería, entonces volverás haciendo más y más preguntas hasta que finalmente descubras que tienes que apagar las luces cuando el motor está encendido. no corras. Al preguntarles por adelantado, se siente como si estuviera perdiendo el tiempo, pero realmente sabe por experiencia que potencialmente les puede ahorrar mucho más tiempo.

Entonces, si desea evitar la línea de preguntas, debe convencerlo por adelantado de que sabe de lo que está hablando.

Karl Bielefeldt
fuente
44
Exactamente esto. Los clientes que no tienen idea de lo que quieren son un fastidio. Los clientes que saben exactamente lo que quieren a menudo son peores. No omita el requisito comercial cuando solicite información. Cada pequeña cosa que hacemos a menudo es altamente relevante para el contexto.
Erik Reppen
14

"La pregunta es específicamente cómo interactúa uno con otro programador para hacer una pregunta, dónde el otro tiene la respuesta y omite el debate sobre por qué se hace la pregunta".

No puedes, al menos no de manera determinista. El otro programador es una persona, no una computadora, y no su servidor. Si les haces una pregunta, pueden elegir cuál creen que es la mejor respuesta. Si piensan que necesitan más contexto, pueden solicitarlo.

Puede intentar introducir su pregunta con una afirmación de que solo está buscando una respuesta breve y resumida, pero que aún pueden responder como mejor les parezca.

Charles E. Grant
fuente
13

La pregunta es específicamente cómo uno se relaciona con otro programador para hacer una pregunta, donde el otro tiene la respuesta y omite el debate sobre por qué se hace la pregunta.

No puedes Los programadores, especialmente los buenos, están diseñados para resolver problemas y ser eficientes . Cuando un cliente o un compañero programador busca una respuesta, se asegurarán de conocer el problema que están resolviendo antes de presentar una solución. De esa manera, son eficientes (no están desperdiciando su tiempo al dar una respuesta que no resolverá su problema) y están resolviendo problemas reales (al darle soluciones / respuestas a las preguntas que debe hacer).

Ejemplo: cuando un cliente acude a usted y le dice que quiere implementar una función X. A veces, el cliente realmente necesita una función X y, a veces, realmente tiene que profundizar e interrogar al cliente solo para descubrir que no quiere X sino algo completamente diferente. Cuanto más viejos y experimentados sean los programadores, más probable es que se hayan quemado en el pasado al no llegar al corazón del problema antes de presentar una solución.

Para resumir, si desea que sus preguntas sean respondidas con precisión, debe asegurarse de que:

  • haciendo las preguntas correctas (por lo tanto, debe investigar el problema de antemano)
  • proporcionando el contexto para el problema
  • compartir algunas de sus investigaciones para dirigirlas más rápido al problema

La mayoría de los humanos que conozco son humanos y no computadoras. Si solo quieres respuestas, intenta buscarlo en Google.

Christian P
fuente
2
+1 exactamente. ¡Cuántas veces los clientes solicitaron implementar una función que costará miles de dólares en términos de desarrollo, mientras que la necesidad comercial real se puede resolver fácilmente con una herramienta que ya existe, a menudo sin costo!
Arseni Mourzenko
3
Por analogía, es como decirle a un cirujano que realice un conjunto específico de operaciones en usted. Apuesto a que él le preguntará cuál es exactamente su problema de salud, luego le dirá que no necesita cirugía en primer lugar, ya que su problema puede resolverse yendo a un quiropráctico.
Arseni Mourzenko
Exactamente :) Y probablemente esperarías de un cirujano que hiciera exactamente eso.
Christian P
9

¿Por qué los programadores hacen esto constantemente y por qué el comportamiento empeora a medida que el programador se vuelve más senior?

Desafortunadamente, está tan lejos de la verdad general como parece.

Ese comportamiento está restringido a la minoría de los realmente buenos. Y es mejor que también lo aprendas.

Simplemente responder a la maldita pregunta saltando los porqués es una buena manera de conducir a un abismo, rápido y seguro.


Si realmente desea omitir la parte educada, puede anteponer su pregunta con algunas oraciones sobre limitaciones y su deseo de omitir preguntas; puede obtener alguna respuesta o simplemente enviarlo. Presentar un resumen de su propia investigación es una mejor idea.

Balog Pal
fuente
No es tanto si son buenos como si piensan que lo son.
Florian F
4

Cada respuesta aquí es una buena respuesta a la pregunta "por qué", pero nadie realmente ha respondido la pregunta de los OP.

¿Cómo puede hacerle una pregunta a un programador de la manera más eficiente para extraer la respuesta a la pregunta original?

La respuesta es sorprendentemente simple: dígales por qué esto debe hacerse antes de preguntarles cómo.

Lo mejor que puede hacer es incluir a los desarrolladores en algunas reuniones de alto nivel en torno a un producto: darles una idea más amplia para que puedan ver por qué es necesario hacer esto. Incluso pueden sorprenderte al pensar cómo hacerlo primero.

HorusKol
fuente
Que simple es. Dar un poco de contexto y explicar por qué ahorra mucho tiempo. Hace que el desarrollador piense en el camino correcto para ayudarlo desde el principio.
joshp
3

Los buenos programadores no solo quieren implementar ninguna solución; Quieren implementar la mejor solución para el problema específico. Esto requiere información. Las preguntas son la forma de recopilar información. Sin toda la información, el programador sabe que está en peligro de implementar una solución que no cumpla con todos los requisitos y se quedará atrapado haciéndolo nuevamente. No ocultes información de tus programadores. Ocultar información desperdicia tiempo, destruye la moral y conduce a soluciones inferiores.

ancho de banda cero
fuente
1

Los programadores están "conectados" para resolver problemas.

Los buenos programadores intentarán resolver los problemas "correctos".

Simplemente proporcionar lo que alguien está pidiendo es [a menudo] el problema incorrecto que hay que resolver.

En los días en que la automatización de MS Office estaba de moda, recibías una serie de preguntas, generalmente en el transcurso de unas pocas semanas, preguntando cómo hacer "esto" en un producto de Office, luego "aquello" en otro producto , entonces algo más otra vez en otro. Cada uno de estos se resuelve rápidamente, pero el "problema", que aún no se ha declarado completamente, no se resuelve. Siguen regresando para el próximo "eslabón" en su cadena.

Si los detiene y les pregunta "¿Por qué?" luego tienen que dar marcha atrás y explicar más ampliamente lo que quieren lograr y no solo describir el problema inmediatamente frente a ellos. (Por cierto, los programadores sufren de esto tanto como (si no más que) cualquier otra persona, a lo que foros como estos dan testimonio).
La cadena del usuario de "Obtener los datos de la gran Base de datos en Access, luego en Excel para darles un poco de masa, luego en Word para que puedan combinar los resultados por correo y enviarlos por correo electrónico a las personas cada semana" se reemplaza rápidamente por un trabajo por lotes que hace todo eso, con los resultados en las bandejas de entrada de las personas a primera hora del lunes por la mañana, sin ninguna participación manual del usuario.

A los usuarios les gusta eso.

Necesitamos saber a dónde intenta llegar antes de poder ofrecerle la mejor manera de llegar allí.

Alternativamente, (parafraseando a Monty Python): "¿Desea la respuesta de 5 minutos o la media hora completa"?

No tiene sentido que el Programador recite todas las minucias de una función en particular cuando solo desea saber si funcionará si le da un número con tres tres decimales.

Conocer su perspectiva a menudo puede cambiar radicalmente la respuesta que obtiene.

Phill W.
fuente
0

Su pregunta final es "¿Cómo puede hacerle una pregunta a un programador de la manera más eficiente para extraer la respuesta a la pregunta original?"

Primero se confunde "eficiente" y "eficaz". Para ser más eficiente , simplemente escriba "¿Cuál es la respuesta?" en un trozo de papel y muéstralo al programador. Esa es una manera muy eficiente de hacer una pregunta. También es muy ineficaz para obtener una respuesta.

Y en segundo lugar, está asumiendo que los desarrolladores de software responden preguntas. No son. Son solucionadores de problemas. Tu actitud muestra claramente que no entiendes la resolución de problemas. La forma más efectiva de resolver un problema es comprender el problema hasta el punto en que pueda describirlo a un solucionador de problemas y luego presentarlo a un solucionador de problemas. El otro método es comprender el problema en la medida de lo posible, luego presentar su comprensión incompleta a un solucionador de problemas, quien primero le hará las preguntas que le temen para convertir esto en un problema completamente comprendido y luego resolverlo.

Una forma muy ineficiente es el método que está probando: obtenga una comprensión incompleta del problema, adivine cómo se podría resolver este problema y pregúntele a un solucionador de problemas cómo se puede lograr esta solución. El solucionador de problemas ha visto este comportamiento antes. 10 veces si no tiene experiencia, mil veces si tiene experiencia. Entonces, el solucionador de problemas sabe que te diriges a una dirección completamente equivocada. Y el solucionador de problemas hace lo que debe hacer para llegar a la dirección correcta, que es hacer preguntas para comprender el problema real. Primeras preguntas para comprender su comprensión incompleta del problema, y ​​segundas preguntas más para comprender el problema real.

gnasher729
fuente
0

Comience la pregunta explicando qué quiere lograr y cuál es el contexto en el que está trabajando. Si da suficiente contexto , no obtendrá un "¿por qué?" , obtendrás un "¿es esto realmente necesario?"

Porque, estadísticamente , la mayoría de las características propuestas apestan , y no vale la pena implementarlas.

Una refutación típica sería "pero ese es su trabajo". Su trabajo es escribir un buen código , y agregar características generalmente va en contra de eso, porque la mayoría de las características requieren un rediseño de la base de código de trabajo y esta "cosa de rediseño":

  1. toma una eternidad
  2. agrega nuevos errores
  3. rompe cosas que solían funcionar
  4. hace que el mantenimiento sea impermeable

Ese no es un buen código, un buen código es mínimo.

ZJR
fuente
El trabajo del programador no es escribir un buen código. El trabajo del programador es generar valor para la empresa que los contrata. En muchos casos, escribir un buen código es parte de esto. En muchos casos, ensamblar rápidamente código desechable que funciona es parte de esto. Sin embargo, estoy de acuerdo en que muchas características apestan: hice un contrato para una empresa que quería agregar nuevas características que nunca fueron utilizadas por sus clientes porque no fueron concebidas a través de un proceso inteligente, sino solo por alguien que pensó "oye, esto podría ser útil ".
Maurycy