¿Cómo es trabajar con desarrolladores de software muy malos?

Probablemente muy similar a trabajar con trabajadores de la construcción muy malos, dentistas, bancos, supermercados, fabricantes de automóviles, cirujanos, etc.

Es parte de la vida. Algunas personas son malas para trabajar.

Agruparlos a todos en función de la ocupación y las crecientes opiniones sobre ellos como grupo es la base fundamental de lo que el grupo piensa y por qué es tan ridículo participar.

Sí, estar cansado No contrates a un dentista que viva en otro continente a menos que hables con fluidez su idioma nativo para que no termines con el diente equivocado. La misma idea básica se aplica aquí.

La programación es en parte escritura, en parte matemática, en parte ciencia, también es una forma de arte de algún tipo. Es tan abstracto y cambia rápidamente que es un obstáculo forzar una forma de enseñarlo. No se puede enseñar a la gente a ser grandes artistas de una vez. Puedes pedirle a cualquier artista un autorretrato, pero el artista no puede arreglar tu figura o hacerte lucir bella o no será lo que pediste.

Si realmente le preocupa trabajar con malos desarrolladores, no olvide que USTED está en la mitad de la conversación y usted juega un papel importante en ella. Intentar generalizar sobre grandes grupos de personas sin tener en cuenta su rol nunca es una buena idea. Hay un billón de formas de escribir una aplicación.

No soy desarrollador, pero he trabajado con desarrolladores malos y me he ocupado de las consecuencias que causan.

Cabe señalar que los malos desarrolladores y los desarrolladores de aprendizaje son bestias diferentes. El desarrollador de aprendizaje podría exhibir inicialmente algunas de las características de un desarrollador malo pero mejorará con el tiempo.

Un mal desarrollador nunca aprenderá

Uno de los peores desarrolladores con los que trabajé se llamaba Leo (no es su nombre real). Él era un chico de front-end que había traído para ayudar a nuestra capacidad de interfaz en la agencia de marketing que dirigía en ese momento. Las consecuencias de contratarlo fueron inmensas.

Leo había superado la prueba de algoritmo que le dimos y tenía un buen currículum, por lo que lo incorporamos al equipo.

Lo que descubrimos fue que era realmente bueno con los algoritmos, como el que creó como un huevo Faberge. Muy intrincado, delicado y complejo como este:

Fuente: https://media.giphy.com/media/12 …

¿Te imaginas cuánto tiempo llevó hacer eso? Probablemente mientras Leo tardó en escribir sus algoritmos. En lugar de utilizar recursos externos, insistió en hacer todo por sí mismo. Esto no solo tomó mucho tiempo, sino que fue muy difícil para otras personas regresar y trabajar en su código.

Lo que comenzó a suceder es que el resto del equipo comenzó a tener que hacer su propio trabajo, más el trabajo que Leo debería haber estado haciendo. Esto habría sido perdonable si estuviera progresando para ser más eficiente, pero en lugar de eso se aferró obstinadamente a sus armas

No solo eso, sino que se burló abiertamente del código que escribieron sus compañeros de equipo y a menudo cambiaba lo que producían para que coincidiera con sus preferencias estéticas. Cuando se enfrentaba a que no estaba cumpliendo, se le ocurrían un millón de pequeñas excusas que no aguantaban.

Un par de personas simplemente renunciaron antes de que finalmente dejáramos ir a Leo. Eso significaba que teníamos que reemplazar a tres personas, poco después de contratar a una. Era una presencia venenosa que tardó un tiempo en exorcizar de nuestra organización.

Eventualmente llegamos a darles a los desarrolladores pruebas de muestra de trabajo después de eso. Estas pruebas implican dar a los candidatos tareas que reflejan las que deberán hacer cuando comiencen a trabajar para usted. En lugar de centrarse en conjuntos de habilidades como los algoritmos, ven cómo el candidato utiliza todos los recursos disponibles para proporcionar una solución limpia y eficiente.

Este artículo tiene más información sobre cómo hacer una prueba de muestra de trabajo para un puesto técnico.

El peor de los casos posibles es que está trabajando con una persona no calificada pero arrogante. Entonces puede verse así:

a) Realmente piensa que “cascada” es la mejor manera de hacer software. Él cree que en la fase de diseño no se le permite escribir una sola línea de código fuente para verificar sus suposiciones.

b) le dice permanentemente que algo es posible incluso sin verificarlo. Él piensa que cualquier verificación sería una pérdida de tiempo.

c) todavía está buscando una solución de cinco líneas para cualquier problema menor. Si ofrece una solución de 30 líneas (o incluso más), él nunca cree que Microsoft (dios para todas las compañías sw) no ofrezca una solución más simple. Todavía continúa encontrando una solución más simple para problemas muy menores, incluso si hay muchas otras tareas más importantes en espera.

d) funciona extremadamente lento, pero no puede hacer todas las pruebas y depurarlo correctamente. Tienes que notarlo, que algo no está funcionando bien.

e) Todavía subestima la complejidad del problema, se atrasa permanentemente en cualquier tarea. Si quieres darle un consejo, entonces él te culpa “¿Cómo puedes atreverte a pensar en mi tarea?”. Probablemente entienda que estás robando su oportunidad de brillar.

f) En realidad, está obligado a realizar el 90% de todo el trabajo (si desea terminar el proyecto a tiempo). Pero su colega piensa que usted es quien está tratando de sacarlo del proyecto tanto como sea posible (sin ver que c) d) y e) es el verdadero problema)

g) todavía quiere actualizar a una tecnología más nueva en el medio del proyecto. Más tarde, te culpa de que tú eres la razón por la que no pudo aprender ninguna tecnología nueva (solo por ti).

h) No puedo ver ningún riesgo real. También a menudo significa que su código fuente nunca se depura bien.

No está bien. Si están dispuestos a aprender, entonces pasas mucho tiempo asesorando. Lo más probable es que estés mejor solo haciendo todo el trabajo tú mismo. Porque probablemente eres mejor programando que enseñando. Por lo tanto, su carga de trabajo aumenta mucho, pero la gerencia espera un mejor rendimiento debido a la mayor cantidad de empleados. Es muy difícil describir los obstáculos diarios adicionales aquí sin colocarte en una especie de luz menos que perfecta.

Si no están dispuestos a aprender, terminas con una base de código horrible y reimplementas constantemente otra pieza de código basura o te rindes. Lo cual es más fácil decirlo que hacerlo, porque cuando ha desarrollado sus hábitos con un enfoque de calidad, es difícil integrarlo en un enfoque de basura, hasta el punto de que reimplementar la basura existente es más fácil. Y es una gran cantidad de trabajo de guerrilla de fondo que pones con casi cero posibilidades de reconocimiento de margen de maniobra. Un buen gerente puede relacionarse con él con un punto, pero solo con un punto. Cuando los cambios que ingresas rompen algo (y lo harán porque eres solo un humano) obtienes un montón de mierda.

Lo que puede aliviar el dolor es si sus cosas están separadas de las cosas malas de alguna manera, preferiblemente por algún tipo de API. Entonces puede comenzar a disparar tickets contra los componentes defectuosos y eso generalmente está bien porque los tickets se ven como unidades, es un trabajo programable y no se cuestiona automáticamente.

Honestamente, no hay malos desarrolladores, sino desarrolladores desmotivados, no impulsados ​​por sí mismos, sin ningún tipo de entusiasmo por la programación o la ingeniería de software. Estas personas son el peor tipo para trabajar.

Por falta de ambición, podríamos decir que algunos desarrolladores consideran la programación como un trabajo de escritorio de 9 a 5 (cualquiera que sea la cantidad de horas) y solo trabajan para pagar con cheque. Nunca están dispuestos a aprender tecnología más nueva, solo hacen lo que se les dice y solo se preocupan por el trabajo que se les da para terminar. Nunca discuten ideas, se aventuran fuera de su zona de confort, hablan de tecnología o mentores o incluso tratan de mejorar. Este tipo de desarrolladores abundan en mi país (India). No es que esté regañando a las personas que trabajan así, pero arrastra a las otras personas motivadas y proactivas que trabajan con ellos a su mediocridad.

La parte triste es que se vuelven redundantes en el rol después de ciertos años y tratan de ocupar los roles gerenciales después de ciertos años, lo cual es desastroso para el equipo que manejan. Estos gerentes son arrogantes, no escucharían ninguna idea nueva, perderían tiempo en reuniones inútiles y harían sufrir a los desarrolladores y otras personas técnicas.

He tenido la suerte de trabajar principalmente con buenos desarrolladores y un par de fantásticos.

Sin embargo, he tenido una mala experiencia. Al principio de mi carrera, cuando era bastante joven y no tenía tanta confianza en mis habilidades, tuve que trabajar para y con un desarrollador senior que finalmente fue despedido debido a quejas sobre su incapacidad para trabajar bien con los demás.

Mi experiencia personal con él fue en el desarrollo de un programa que convirtió un formato de archivo de gráficos estandarizado a un formulario que podría ser impreso o exhibido por una variedad de dispositivos de salida. El programa consistió en un par de capas primarias: un front-end que maneja la conversión del formato de archivo a un formulario interno estandarizado, y un back-end para convertir ese formulario interno al formulario del dispositivo.

Eligió empujar ciertas partes del esfuerzo de transformación hasta el final. Dado que eventualmente habría múltiples back-end y que el trabajo de hacer esa transformación siempre sería necesario, sentí que debería hacerse correctamente desde el principio. No solo rechazó mi idea directamente, sino que incluso se negó a hablar sobre por qué había tomado esa decisión. Simplemente me dijo que lo haríamos a su manera y que eso era todo.

Me preguntaron aproximadamente un año después de que lo enviaran a empacar por qué los cálculos se realizaron en el back-end, porque era más difícil hacerlos allí y el código seguía teniendo que ser trasladado al siguiente dispositivo de salida. Todo lo que podía decirle a la gente era que había tratado de convencer al desarrollador principal de que ese era el caso, pero él me había anulado.

Depende de cómo reaccionas.

Puede ver esto como un desafío para guiar y compartir las mejores prácticas de ingeniería . Probablemente será difícil, toma tiempo, te costará un poco de tu cordura. Si tienes éxito, el sentimiento es abrumadoramente positivo.

O puedes rendirte por completo desde el principio. En este caso, es mejor dejar el trabajo.

¡La mejor de las suertes!

Hola,

Muchas gracias por esta pregunta que has hecho!

Aparentemente depende de su definición de la palabra “malo”. ¿Los desarrolladores junior son malos?

Acabo de escribir un artículo sobre el tema: podría querer echar un vistazo 5 señales de que necesitas un nuevo equipo de desarrollo móvil – Mind Studios

Imagina la situación como sucedió. Debería haberse sentido como una escalera al cielo. Has comenzado a rodar una rueda y deberías estar orgulloso de ti mismo. Tuviste una idea brillante del proyecto, fuiste y contrataste personas que seguían golpeando su pecho, diciendo que lo harán funcionar a un precio razonable. Sin embargo, se siente muy inquietante, hay esas desagradables señales de que su equipo de desarrollo lo defrauda. Cada vez que interactúas con personas, que se supone que están haciendo realidad tus sueños, no sientes serenidad; simplemente ya no satisface. Entonces, ¿dónde debe buscar una razón de esta vergüenza? ¿El problema está de tu lado o del otro lado, y cómo tratar con malos programadores si hay alguno?

Nuestro artículo puede ayudarlo a encontrar el significado que está buscando; continúe leyendo en nuestro blog 5 señales de que necesita un nuevo equipo de desarrollo móvil – Mind Studios

1. Si está pidiendo la opinión del gerente, los buenos gerentes no contratan desarrolladores malos. Y despedir a los que heredaron (después de dar suficientes advertencias, etc.)
2. Si tiene curiosidad acerca de la perspectiva de los compañeros, vea la de arriba. ¿Quién los contrató?

Trabajar junto a malos desarrolladores casi siempre significa trabajar para un gerente incompetente, en una empresa barata y abusiva sin futuro profesional. Comparado con eso, sus colegas incompetentes serían la menor de sus preocupaciones.

“El cliente X se queja de un error que acaba de encontrar. La última confirmación es de Y. Revierto la confirmación y empujo los cambios a producción. Todo vuelve a la normalidad “.

Es deprimente La mayoría de tus colegas hacen un buen trabajo mientras resuelven problemas, luego ese tipo viene y arruina todo. La peor parte es que los desarrolladores como este ni siquiera se molestan en estudiar y hacer un trabajo decente. Espero que nunca te pase a ti.

No solo los malos desarrolladores de software son un problema. Cualquier persona involucrada puede ser un problema y cuanto más alto y más alejado del proyecto, peor puede ser.

Dicho esto, en más de un proyecto ha habido un primer ministro o un gerente de cuenta que no lo hizo y se negó a creer lo que les dijo un número de personal técnico.

Recientemente, el director general de una empresa para la que estaba trabajando descartó de manera efectiva todo el trabajo de BA y decidió que él sabía más que BA, el consultor que trabajaba para el cliente e incluso el propio cliente.

¿Por qué fallan los proyectos? Porque mucha gente en la industria no entiende la programación.

¡Es muy, muy frustrante y estresante!
He trabajado con desarrolladores de software muy, muy malos y desarrolladores de doctorado de primer nivel. Los malos tardaron alrededor de 3 meses en finalizar una función para cargar algunos productos en un sistema que ya tenía la función básica y solo necesitaba algunos ajustes, incluso cuando no se realizó correctamente. Descubrimos que solo estaban ordeñando, lo que a su vez ordeñaba dinero. Cuando cambié a los desarrolladores rusos, ¡esto se completó en menos de 1 día! También uso y prefiero desarrolladores de Ucrania, República Checa, Italia, Bielorrusia, Letonia y Rumania.

Es extremadamente frustrante. Parece que me sangran los ojos.

Cuando comencé, estaba de acuerdo, ya que soy solo un nivel de entrada, así que lo que sé es mi propia experiencia y es probable que esté completamente equivocado. Después de un tiempo, tendría que ser estúpido para no encontrar estas tonterías. No estoy seguro de si son malos o si lo hacen a propósito para aumentar la LoC (creo que no medimos por LoC. No creo que haya una medida en absoluto). Puede encontrar cualquier pieza de código en el proyecto y puedo encontrar doscientos o trescientos lugares en los que se pega el mismo código sin cambiar ninguno o 1 valor. Esto también ocurre en los niveles de archivo (decenas de clases con implementación exacta).

Cómo el programa de otras personas realmente no es asunto mío para juzgar, pero cuando revisan las basuras que no cumplen con el control de calidad para que otra persona lo repare como un elemento de “error”, entonces se convierte en mi negocio.

Estos son problemas muy simples, pero causan fatiga ocular y migrañas que pueden evitarse por completo si toman un maldito curso de ingeniería de software.