Los programadores tienen diferentes dichos sobre problemas difíciles. Probablemente mi opción favorita : "Hay dos problemas difíciles en informática: invalidación de caché, nombres y errores por unidad".

He estado escribiendo software el tiempo suficiente para enfrentar cada uno de estos problemas. Al mismo tiempo, hablo desde el lado de los negocios y les explico a los clientes la parte técnica de nuestro producto, por lo tanto, constantemente me encuentro con personas que no son programadores. Lo más importante es transmitir correctamente la idea o el concepto de tal manera que otros lo entiendan.

Y esto es muy difícil.

Como en todos los campos profesionales, los programadores han desarrollado su propia jerga para transferir conceptos rápidamente.

Technolepet

La jerga es muy importante. Si mi colega y yo elegimos un algoritmo para resolver un problema específico, podemos decir que "la primera opción O(n^2)con una sobrecarga mínima desde el principio, y la segunda se amortiza O(n log n), pero con una instalación y configuración costosas" .

Esta sola oración dice mucho, para qué escenarios se debe usar el algoritmo y cómo se implementan bajo el capó:

La opción A es excelente para un sistema con una pequeña cantidad de entrada.
La opción B es excelente para trabajar con una gran cantidad de datos de entrada, donde los altos costos de instalación y configuración del sistema se compensarán con un mejor rendimiento en el proceso.
Si tiene la intención de utilizar el algoritmo en un bucle, debe elegir la primera opción para evitar el costoso código de instalación y configuración.
Quizás podamos reducir el costo de instalación de la opción B usando el almacenamiento en caché.
Probablemente, en la opción A, cada elemento de los datos de entrada se compara con todos los demás (por ejemplo, for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
Probablemente, la opción B primero crea un árbol, luego realiza una búsqueda lineal, seguida de una búsqueda en este árbol.

Como puede ver, pudimos transmitir varios párrafos de información en una oración, simplemente usando los términos correctos.

En este caso, quise decir algoritmos para detectar colisiones, es decir, intersecciones entre dos o más objetos. El primero verifica todas las combinaciones posibles de datos de entrada, mientras que el segundo usa un árbol de cuadrante o una partición de espacio binario para verificar solo los elementos cercanos.

Pero si tiene una reunión con personas de fuera del mundo de la programación (por ejemplo, ingenieros mecánicos o eléctricos, gerentes, especialistas en marketing), esta jerga técnica solo insultará y confundirá a las personas, sin transmitir casi ninguna información valiosa.

Esto es lo que yo llamo technoleth, el murmullo de un programador.

Hablando francamente, generalmente estos detalles y términos no son necesarios para personas de otras áreas, y realmente no les importa.

Por ejemplo, está explicando una nueva función sorprendente que encuentra la ruta más corta de A a B, genera una cuadrícula de navegación y aplica la búsqueda A * .

En ningún caso necesita describir la nueva función como en la oración anterior. En cambio, di algo como esto:"Calculamos un montón de caminos posibles y luego aplicamos los algoritmos inteligentes que se utilizan en la industria del juego para encontrar la mejor ruta" .

No importa que estemos usando la búsqueda A * aquí (a diferencia del algoritmo Dijkstra o la búsqueda de ancho). No importa que en los juegos, la búsqueda A * se use no solo para mover personajes. Es suficiente que el interlocutor sepa que puede encontrar un buen camino de A a B y que utilizamos herramientas confiables que ya se han probado en otras áreas.

No está de más mostrar la ilustración de lo que quieres decir ...

Observé cómo los programadores más experimentados usan la jerga tecnológica para demostrar superioridad, mostrar su increíble inteligencia y establecer el dominio. Esto es realmente molesto.

No se equivoque, a veces hay situaciones en las que un interlocutor suficientemente competente pregunta: "Esto es muy difícil, ¿por qué no simplemente hacer X?" - y tienes que demostrar que eres un experto aquí, pero él no sabe de qué está hablando ... pero aún puedes hacerlo de diferentes maneras.

No trate de usar tecnolepet para satisfacer su ego, esto excluye a las personas y deshonra nuestra profesión.

El respeto

Entonces, gradualmente pasamos al siguiente punto ... no te olvides del respeto.

Muchas personas con las que trabajo son realmente inteligentes y expertos en sus campos, pero no necesariamente tienen el conocimiento y la experiencia suficientes para crear sistemas de información.

Al explicar un problema complejo, a menudo es mejor simplificar los conceptos. Pero trata de no ser condescendiente.

El ingeniero de software que mencioné a menudo respondió: "Es ... complicado" cuando una persona "normal" preguntó cómo funciona esta o aquella función. Es como si el código fuera tan sofisticado que sin 20 años de experiencia en programación no se puede entender.

No hagas así.

La mejor respuesta:"Si simplifica un poco las cosas, primero hacemos X, luego hacemos Y, y finalmente hacemos Z, pero debe tener en cuenta una docena de situaciones límite (tal vez explique una o dos), pero la esencia es esta" . Sus colegas son inteligentes y sin jerga tecnológica son capaces de entenderlo.

Otro truco realmente útil es usar un no programador como un mazo, como un pato de goma. Si está trabajando en un problema complejo, explíquele en palabras simples su solución y pregúntele si puede encontrar una mejor opción.

Nuestra empresa trabaja en el campo de CNC, es decir, tiene algo que ver con el mundo real (por ejemplo, cuando intenta implementar una compensación por el ancho del corte ). Los ingenieros son realmente buenos para analizar problemas relacionados con la física y la geometría.

Personificación, exageración y analogía.

Las personas son seres sociales. Estamos programados para comprender las relaciones y las analogías de amor para relacionar nuevos conceptos con los existentes. Cuando está hablando con alguien, puede usar estos trucos para ayudarlo a comprender temas complejos.

Digamos que su empresa tiene un sistema de compras en línea. El vendedor quiere entender toda la cadena desde el pedido en línea hasta la entrega del paquete para responder mejor a las preguntas de los clientes. Podría decir algo como esto:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

Todo esto suena un poco cómico, y el ejemplo es más que descabellado, pero puedo garantizar que esta es una explicación más comprensible que un gran diagrama de red con los términos "servidor web", "arquitectura de eventos" y "Apache Kafka" (consulte la sección sobre tecnolepte). )

Otro ejemplo. Si intenta explicar a un extraño cómo funciona el algoritmo de búsqueda de rutas, no dice "las rutas visitadas tienen más peso", dice "el algoritmo realmente no quiere seguir las rutas donde ya se fueron".

Esta es una diferencia sutil, pero estamos haciendo la personificación del algoritmo. Decimos que "realmente quiere hacer X" o "se esfuerza mucho por evitar Y". A menudo esto ayuda a las personas a entender .

Analogías útiles con ejemplos (si corresponde). Probablemente ya haya notado que este artículo está lleno de ejemplos. En lugar de una explicación abstracta, cuento historias específicas que ayudan a explicar la tesis. Esto no es un accidente.

Dibuja hermosos dibujos

Suena cursi, pero a veces una imagen vale más que mil palabras.

Hace un par de meses estaba leyendo un curso en la radio, y la chica cercana no podía recordar qué botones presionar en el menú de esta pequeña pantalla LCD de 16 × 2.

Le pregunté si podía dibujar un diagrama.

Ella pensó que yo era un tipo inteligente y se burló de ella.

Pero no estaba bromeando.

En cambio, encontré una hoja de papel, y juntos hicimos algo como esto:

el programador reconoce inmediatamente el diagrama de estado de la teoría de los autómatas. Sin que lo supiera una niña, introduje la técnica informática básica en su cerebro y cómo la interfaz de esta radio está programada bajo el capó.

Pero a ella (y a todos los demás en esta etapa) no les importa la ciencia. Obtuvieron un mapa que pueden usar para navegar por la interfaz de usuario.

Hay un extraño placer en adaptar un concepto complejo para alguien de otra área. Especialmente cuando pueden determinar que el mapa es realmente un error: debe presionar y mantener presionado el botón Cancelar para volver al estado Inactivo, porque presionar este botón normalmente lo regresa al "Menú principal".

Siempre tengo un cuaderno grande con hojas en blanco en mi escritorio. Por lo general, escribo una lista de tareas o algunos dibujos durante la reflexión, pero a menudo me ayuda a explicar. La capacidad de dibujar algo durante una conversación ayuda a verificar el curso y asegurarte de que estás en la misma longitud de onda (juego de palabras) que tienes la misma idea.

Aceleré $ FEATURE diez veces

Supongamos que ha realizado algunos ajustes de rendimiento y ahora un determinado fragmento de código funciona mucho más rápido. ¿Cómo explicar esto a un no programador o alguien que no ve el código fuente?

Por un lado, a la pregunta de lo que hiciste la semana pasada, puedes decirle a la persona la verdad: "Agregué el almacenamiento en caché lookup_something ()para acelerar la búsqueda general y traducir el algoritmo de detect_collisions()c O(n^2)a O(n log n)" , pero con una alta probabilidad de que no entiendan nada (ver tecnolept ) .

También puede decir que "optimizó el rendimiento" , pero suena como una excusa, y el gerente pensará por qué lo contrató para trabajar.

A menudo, los desarrolladores dicen: "Aceleré $ FEATURE diez veces".(o algún otro número arbitrario) y esto es limitado. Tal frase le permite disfrutar de muchas felicitaciones de la gente del pueblo, pero a menudo es un poco ... engañoso.

En la mayoría de los casos, en realidad mejoró el rendimiento de varias funciones, pero si estas funciones no constituían un cuello de botella en el rendimiento, entonces con una alta probabilidad, nadie verá ninguna diferencia.

Nota. Si está familiarizado con la ley de Amdahl, aumentar el rendimiento de una función que no es un cuello de botella es como usar más núcleos de CPU para una tarea que es esencialmente consistente.

La pregunta también plantea: ¿qué has hecho para aumentar diez veces la productividad? ¿Es este un número sorprendentemente específico? ¿Ha repetido su código fuente un trabajo varias veces? ¿O solicitó datos (digamos, del hardware o de un sitio de terceros) diez veces más lento de lo que debería? Incluso esto me hace dudar de sus habilidades, porque adivinó (mal) la velocidad de sondeo inicial, o aún sacrifica el rendimiento al utilizar el sondeo en lugar de una arquitectura de eventos más eficiente.

Me parece que es mejor tratar de encontrar un punto medio entre la precisión y la comprensión. Si realizó un cambio que mejora la complejidad algorítmica de un fragmento de código (por ejemplo, una función detect_collisions()cambiada O(n^2)a O(n log n)), puede decir:"La función X ahora puede escalar a una gran cantidad de entrada en un tiempo razonable, pero no podía antes" .

Es normal decir "No sé" ...

... y continúa así: "... pero si me das cinco minutos, te puedo decir" .

A menudo veo esto. Las personas tienen miedo de mostrar su ignorancia, por lo tanto, están en silencio, atormentadas o inventan algo.

Por ejemplo, si un gerente se le acerca y le pregunta: “El cliente solicitó la función X, ¿es esto posible? ¿Y cuánto tiempo llevará?

En nueve de cada diez casos, la respuesta honesta es "No sé", pero en realidad no ayuda al gerente a decidir el momento. Se dirigió a usted porque es un experto en el campo relevante y está mejor preparado para dar una respuesta.

Algunos intentan adivinar o hacer trampa (por ejemplo, "Sí, lo haremos en dos o tres semanas"), pero este enfoque generalmente no funciona a largo plazo. En el mejor de los casos, se retrasará un par de semanas y, en el peor de los casos, pasará meses trabajando solo para descubrir que esta función no puede funcionar con la arquitectura de la aplicación actual.

Esta es una excelente manera de perder el respeto de colegas y superiores.

Por otro lado, las palabras "No estoy seguro, pero de 5-10 minutos, y tendré una respuesta" muestra varias cosas a la vez:

Estás listo para admitir que no lo sabes todo (es decir, que no eres un egoísta narcisista).
Usted es responsable de sus palabras y no desea dar una respuesta inexacta.
Respetas a la persona lo suficiente como para pasar parte de tu tiempo ayudando a responder su pregunta.
Eres un buen chico :).

(Y tienes tiempo suficiente para resolverlo).

Se parece a una vieja parábola :

Otras personas (generalmente) no esperan que sepas todo en su campo. En cambio, esperan que tengas herramientas para investigar la pregunta y traducir la respuesta en términos que puedan entender.

El viejo ingeniero se retiró y, después de algunas semanas, la Big Machine se descompuso, lo cual es muy importante para los ingresos de la compañía. El gerente no pudo hacer que la máquina volviera a funcionar, por lo que la compañía invitó al viejo ingeniero como consultor independiente.

El acepto. Al llegar a la fábrica, miró la Big Machine, tomó un mazo y lo golpeó una vez. Después de eso, el auto comenzó a funcionar. El viejo ingeniero se fue, y la compañía comenzó a ganar dinero nuevamente.

Al día siguiente, el gerente recibe una factura del viejo ingeniero por $ 5,000. El gerente está furioso y se niega a pagar. El viejo ingeniero asegura que este es un precio justo. El gerente responde que si se trata de un precio justo, puede solicitar detalles de la cuenta.

Una cuenta nueva y detallada se ve así ...

Martillo: $ 5

Sepa dónde golpeó el automóvil con un martillo: $ 4995

Cualquiera puede buscar en Google cualquier pregunta. Pero solo un ingeniero de software sabe qué palabras clave usar y cómo interpretar los resultados.

recomendaciones

Por lo general, en mi blog publico artículos puramente técnicos con toneladas de código, pero a veces es útil recordar que hay algo más en este mundo además del código.

Los programadores (no sin razón) son percibidos como personas con habilidades sociales y de comunicación débiles. Pero una parte importante de nuestro trabajo requiere una comunicación efectiva. Espero que mi experiencia te ayude con algo.

Algunos pueden considerar que esto es "política de oficina" y la manipulación de las opiniones de otras personas. Esto es lo que responderé:

Bueno, sí. ¿Pero esto no se aplica a la mayoría de las interacciones interpersonales?

La psicología simplemente ayuda a los programadores a hablar el mismo idioma con los no programadores y a trabajar juntos para lograr un objetivo común.

Hablar es difícil. Ensayos sobre comunicación con no programadores