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

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?

¿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.

"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.

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.

¿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.

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.

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.

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.

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.

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.