¿En qué se confunde la gente de negocios con los programadores?

Answer 1

No soy una “persona de negocios”, por supuesto, pero conozco bien a un desarrollador senior.

Creo que lo que más le resulta frustrante al tratar con los profesionales de negocios es que no entienden lo que motiva a los programadores y lo importante que es para ellos lograr y mantener un “flujo” para cumplir con los plazos de sus proyectos. Si el día de un programador se divide con 3 a 4 “check ins” y reuniones además del almuerzo, y otras interrupciones, está disminuyendo su productividad. Tener un informe de estado al final del día, y tal vez una proyección al comienzo del día sobre lo que esperan lograr realmente debería ser suficiente.

Si su oficina utiliza software para que los programadores verifiquen el código y proporcionen actualizaciones de estado en los elementos de trabajo individuales, por amor de Dios, USE. Aprende a leer los informes por ti mismo. No haga que los programadores participen en una reunión de 45 minutos todos los días, de modo que todos puedan CONTARLO individualmente, lo que ya existe para su visualización EN el software de seguimiento.

Además, la gente de negocios (“Gestores de personas”) no parece entender cómo salir a la calle en una caminata de 10 o 15 minutos cuando NO ESTÁ fluyendo es realmente beneficioso para el desarrollador y el proyecto. Estar de pie en su oficina durante tres horas un viernes hablando sobre el fútbol, ​​aparentemente “crea camaradería” y no se ve como debería ser … una interrupción y una distracción para las personas que ESTÁN DETENDIENDO REALMENTE TRATAR QUE HAGAN ALGUNOS TRABAJOS. Desaparecer durante 15 minutos para despejar la cabeza y obtener algo de aire fresco al aire libre es, en comparación, mal visto.

Demasiados gerentes (tanto los “gerentes de proyecto” como los “gerentes de personas”) tienen una idea equivocada de que “estar encadenado a su escritorio” es la forma en que el trabajo se realiza de manera más eficiente, efectiva, económica y puntual. Eso puede ser cierto para algunos tipos de trabajadores, hacer algunos tipos de trabajo … pero la programación no es uno de ellos.

Gran parte de la lluvia de ideas y la resolución de problemas que implica el diseño e implementación del código necesitan tiempo para ser preparados antes de que estén listos para ser implementados. Investigar y pensar mucho antes de comenzar a crear la arquitectura o de escribir el código es realmente importante. Pero eso no es realmente reconocido y acomodado adecuadamente en la Planificación Agile / Sprint. Y la realidad es que el no darle tiempo en la parte delantera de un proyecto agrega días o incluso semanas de mantenimiento, resolución de errores y se vuelve a escribir en otros sprints posteriores. La industria debe dejar de presionar tanto para el desarrollo “rápido” y volver a considerar la idea de hacer que las cosas sean buenas / estables / seguras en el primer paso.

Hay tanto una ciencia como un arte. Necesitan aprender a reconocer y apreciar ambos lados del proceso.

PD. Al programador también le disgusta en gran medida que la compañía decida externalizar la creación de nuevos productos y códigos a los programadores en un país extranjero, “porque es más barato en una base por hora”. No le pida a sus desarrolladores experimentados que dominan el inglés pasan los próximos cuatro años de su vida tratando de “mantener sin reescribir completamente” un producto escrito en cuatro semanas por un puñado de rumanos. Cuando realmente observa el ciclo de vida completo del producto, no está ahorrando dinero y está privando de derechos a su equipo de desarrollo y clientes en el corto plazo al forzar una solución inadecuada para todos ellos.

Answer 2

Los programadores no son partes intercambiables que pueden reemplazarse simplemente rompiendo el paquete y conectando el nuevo. Si tiene un programador antiguo que es bueno en lo que hace, reemplazarlo con una nueva persona puede parecer que es rentable, pero a menudo resultará en una moneda de un centavo y no tendrá sentido. Pierdes mucho conocimiento y habilidad acumulados.

Al contratar a alguien nuevo, no necesita a alguien que sepa todo sobre cada herramienta en su caja. Si tal persona existe, es probable que no sepan mucho más porque habrán dedicado tanto tiempo a esas herramientas. En su lugar, estará mejor con alguien que tenga un historial comprobado de adaptación a nuevos entornos. Un programador que puede aprender cosas nuevas se pondrá al día en su entorno. También traerán nuevas herramientas e ideas, y no quedarán obsoletas a medida que cambie la tecnología.

Los buenos programadores pueden o no conocer algún algoritmo o patrón de diseño en particular, pero pueden aprenderlos según sea necesario. Saben cómo hacer un uso eficiente de los motores de búsqueda para encontrar soluciones y modificarlas para que se ajusten a sus necesidades particulares. Usted está mejor con alguien que sabe aprender que alguien que ha memorizado los detalles específicos de los algoritmos A, B y C. Tarde o temprano, es posible que necesite X, Y o Z, que nunca antes habían visto. y aún no han memorizado.

Answer 3

En mi experiencia, los empresarios se confunden cuando se reúnen con los programadores.

Primero, generalmente esperan encontrarse con un niño nerd sin habilidades sociales y que habla como Data en Star Trek. Cuando ven que en realidad somos personas y sí, podemos comer con un tenedor y un cuchillo, pierden un poco el equilibrio.

Segundo, no están preparados para responder preguntas básicas sobre su propio proyecto. Cosas simples como “¿qué hace que tu idea de Facebook sea mejor que la de Facebook que ya existe?”, Quítalas como si les hubieran preguntado sobre la masa de Júpiter los jueves por la mañana.

Tercero, tienden a pensar que construir el producto es solo una formalidad. Después de todo, ya tienen la idea, han comprado el nombre de dominio y saben qué hacer con el dinero que ganarán con él; ¿Seguro que los desarrolladores pueden simplemente construirlo y dejar de ser una molestia al respecto? Seguramente ese es su trabajo, ¿verdad?

Como advertencia, debo decir que: 1. No todos los empresarios son así. Muchos son experimentados y realistas, y yo también soy una persona de negocios, además de programadora.

Answer 4

Soy el programador del que estás hablando, pero lo sé. Necesitaré iterar la búsqueda de la tabla SQL para el ID de sesión para poder identificar el nodo IP del intento de crack . Bueno, eso fue algo sin sentido. Sé que tal cosa no puede suceder, pero por favor tengan paciencia conmigo. No tengo mejor ejemplo ahora.

Al escuchar esto, ¿qué piensa la persona de negocios? ¿Cuáles son estos términos? ¿Iterar una búsqueda? Tabla de SQL? ¿ID de sesión? Nodo de IP? Eso fue rápido. Una línea digo, y él necesita cien más para entender. Esa es la causa de la mayoría de los problemas. De hecho, estaba interactuando con un hacker principiante, y acabo de decir que una fuerza bruta es todo lo que necesita . Simple verdad? Solo si sabes lo que significa la fuerza bruta . Ellos no lo harán Esta es la razón. De hecho, algunos de ellos ni siquiera lo entenderán cuando dices que necesito un servidor más grande para esto o incluso una mejor RAM podría hacer mucho para esto . ¿Cómo no pueden ser confundidos?

¿Sabes que? Sabemos lo que estamos diciendo. Ellos no Y si lo hicieron, ¿por qué se molestaron en contactarnos? Debemos conocer su nivel, y hablar en consecuencia. Tomar algunos términos que les parezcan técnicos de las declaraciones será útil, creo.

Answer 5

Las estimaciones requieren un alcance.

Dilbert cartoon from: Pins from madhusudhan.info en Pinterest