Manejando a mi anticuado compañero de trabajo

Soy un programador bastante joven y trabajo en el departamento de TI de una empresa mediana. Tengo un compañero de trabajo y es un muy buen programador de Visual Basic 6. Y quiero decir muy bien. Honestamente. Puede entregar aplicaciones de trabajo, que contienen muy pocos errores, en el tiempo que necesito para tomar mi primera taza de café y arrancar mi máquina. Él es así de bueno.

La cosa es que estamos trabajando con un equipo y su estilo de trabajo es completamente anticuado. Él no cree en el software de versiones (si solo te aseguras de que tu código sea correcto, no necesitas todas esas tonterías). No cree en la implementación (puedo entregar un ejecutable que funcione. La forma en que se implementa es para que los administradores del sistema lo descubran). No cree en la abstracción. ('si desea crear una subrutina, continúe, pero no llame a ninguna subrutina desde esa subrutina. De ese modo, se vuelve desordenado y el código es difícil de seguir. De esta manera, todos pueden seguir cada paso del camino. 'o' sí, seguro que puedes usar esa biblioteca para hacer eso por ti, pero de esa manera no entiendes realmente lo que está sucediendo ') y ciertamente no cree en OOP. (trabajamos en VB.net)

Es tan bueno en lo que hace que puede entregar aplicaciones mucho más rápido que yo. Pero simplemente no funciona en un equipo. Nuestro otro miembro del equipo es callado y no le gusta hablar, aunque tiende a estar de acuerdo. Nuestro gerente cree que hago puntos válidos, pero no es un programador.

Me cuesta mucho mantener los programas que ha escrito, y no es un buen ambiente de equipo. ¿Qué crees que es lo mejor que puedo hacer?

Esto suena como uno de esos "Él es un buen tipo pero ..." donde sabes que la verdad está llegando. Y la verdad parece que no es realmente tan bueno como ingeniero. Un buen software no se trata solo de la velocidad de trabajo y desarrollo. También se trata de las otras cosas que mencionó: mantenibilidad, compatibilidad, abstracción (para eficiencia futura), etc.

Entonces, dicho esto, parece que tienes un desarrollador de problemas en tus manos. Lo que es peor para ti es que está probado y probablemente establecido en sus caminos. ¿Entonces que puedes hacer?

• Trabaja a su alrededor.
• Esfuércese por producir sus proyectos en un horario tan apretado como él.
• Y si no puede, produzca un mejor resultado.
• Con el tiempo, esos conceptos probados que él descarta comenzarán a dar sus frutos.

Por otro lado, si te ves obligado a trabajar a su manera, vete.

No intentes cambiar a tu colega. Lo estás describiendo como alguien capaz de entregar software de trabajo. Probablemente sea demasiado tarde para integrarlo en el equipo tampoco.

Entonces tienes dos opciones:

• Adáptate a ti mismo. ¿Tal vez con el tiempo podrá convencerlo de la utilidad de un sistema de control de fuente? Tendrás que aumentar tu círculo de influencia . Cuanto más resistente sea al cambio, más tiempo necesitará.

• Retírate de la team. Tienes muchos puntos para justificar esto. Tal vez deberías dejar que mantenga solo sus propias aplicaciones y dedicarte a cosas nuevas.

• Retírate de la company. A veces, esta es la única solución.

Si yo fuera usted, establecería mi propio sistema de control de fuente ahora mismo. Comience a usarlo para todo lo que codifique y adminístrelo para que los otros miembros de su equipo tengan cuentas y puedan acceder a él. Sus otros compañeros de trabajo probablemente estarán entusiasmados con su uso.

Su colega que no cree en tales prácticas puede no ser fácil de persuadir. Sin embargo, cualquier código con el que se vea obligado a trabajar y que haya sido escrito por él debe ir al control de versiones para que pueda trabajar con él. Cuando necesite acceso a sus cambios, envíele un conjunto simple de instrucciones paso a paso sobre cómo extraer su código del repositorio.

No tienes que ser combativo o ir por encima de él para involucrarlo en procesos más modernos. A veces, simplemente seguir su propio camino y ser un líder con acción es más efectivo que tratar de convencer a alguien con palabras. Pequeños pasos. Si comienza a responder mejor al control de versiones, comience a refactorizar las subrutinas y a agregar pruebas unitarias para protegerse contra los cambios. Automatice las pruebas y muéstrele cómo puede acceder a los resultados tan pronto como se registre.

Muchas veces las personas simplemente son resistentes porque no les gusta el cambio. Pero si se les presentan los cambios de manera gradual y de manera que les sea fácil seguirlos, a menudo verán los beneficios muy rápidamente.

Sobre todo, que sea todo lo más simple posible para él (Keep It Simple Stupid). Permítale comenzar a seguir estas prácticas en sus propios términos. Pero no dejes que te arrastre hacia abajo.

Seré sincero, no estás pintando una buena foto de él Métodos arcaicos, software difícil de mantener, terco a las nuevas formas de trabajo, contra la abstracción, etc.

Por lo que ha dicho, si él está produciendo software en gran medida libre de errores MÁS RÁPIDO que usted sin el uso de bibliotecas reutilizables y patrones de diseño dirigidos al desarrollo rápido de aplicaciones, entonces dice más sobre usted, que sobre él ...

... sobre él ... sí, encuentre una manera de NO trabajar con él y NO estar asociado con su trabajo. Parece que tiene una actitud egoísta típica hacia su trabajo. No puedes trabajar con alguien así, solo puedes observarlo trabajar y ordenar después de ellos (como lo eres actualmente).

He visto esto antes ,

Y estoy casi dispuesto a apostar: este tipo de hombre solo parece "rápido" porque tiene un conjunto de "patrones" probados en su cabeza. El 99% de las aplicaciones de Line of Business son CRUD , cosas básicas.

Probablemente use una tonelada de Copiar y Pegar de su propio código existente (nada de malo en eso).

Pero..

En el momento en que encuentra algo remotamente complejo, se cae, ¿por qué? porque ya no se ajusta a ninguno de los "patrones" básicos.

Un pequeño reto ...

Crearía un proyecto adicional, uno complejo que realmente se beneficie de la OOP y la reutilización del código.

Luego muéstrele ese proyecto y pídale que lo implemente característica por característica.

Entonces apostaría a que su código seguramente será 10 veces más grande y 10 veces más feo si lo hubiera implementado a su manera.

Mira esto desde el lado comercial.

Tomas más tiempo para producir código con errores. Produces menos ingresos, por lo tanto apestas.

Si, con el tiempo, puede revertir esto, entonces puede revertir esto.

Pero tal vez, solo tal vez, este programador anticuado realmente puede enseñarle un par de cosas sobre la producción de código rápidamente que es tan libre de errores. ¿Quizás sus técnicas no son tan antiguas como piensas?

Me parece sospechoso que alguien pueda producir un código tan bueno sin algunas prácticas muy buenas. Es posible que pueda aprender esas prácticas y aplicarlas a las "mejores prácticas" y cosas de moda que entienda.

Si su gerente no es un programador, intente ponerlo en términos que él entienda.

• Deberíamos usar sourecontrol porque si no lo hiciéramos, podríamos tener grandes problemas para recuperarnos

• Me lleva x tiempo más tiempo porque se niega a seguir algunos procesos bastante básicos.

Por otro lado, asegúrese de no quedar demasiado atrapado en la perfección, es decir, esta es una mejor práctica que debemos seguir. Es probable que su compañero de trabajo tenga mucho que agregar, es posible que tenga que empujarlo lentamente en la dirección correcta.

Parece que tu compañero de trabajo nunca se ha desarrollado en un equipo. Ese tipo de compañero de gurú solitario no permite una buena dinámica de grupo. Por lo tanto, cuéntele a su superior y trate de discutir los pros y los contras con su compañero para hacerlo. Si pudieras hacerlo de la mejor manera, pero si él se niega, sube al mando

Hable con su gerente, así de simple como lo hizo aquí. Aquí hay potencial para el crecimiento: si su compañero de trabajo es bueno como usted dice que es, no debería llevarlo demasiado convincente para que comience a convertirse en usar el control de fuente y .Net con los conceptos adecuados de OO.

Hablaría con otros para tener una idea más amplia de cómo se ven las cosas en donde estás. Tal vez hay algunas separaciones allí para que su código no tenga que mezclarse demasiado con otros, ya que existe el potencial de segregarlo en su propia área de una manera que esto pueda manejarse, aunque esto es más para un nivel superior como un director o CIO para hacer en lugar de un desarrollador.

Es posible que desee hablar con él para ver qué tipo de sistemas más grandes ha construido, ya que hay algunos sistemas de grandes empresas que tienden a ser una gran cantidad de bloques de construcción donde el código de espagueti puede entrar en la tierra de "Oh, esa es la razón por la que OOP ¡puede ser buena!" aunque esto a veces toma el caso donde resulta bastante útil ver cómo esto puede ser algo útil tener en la caja de herramientas de uno.

La apatía puede ser otro sospechoso para ver si es por eso que rechazaría algunas cosas que consideraría casi fundamentales en términos de cómo tiendo a diseñar el código, pero tal vez haya recibido demasiada ayuda de Kool.

Desafíelo (en el buen sentido) para demostrarle lo contrario, muéstrele el lado genial de las herramientas y prácticas. No seas condescendiente.

Por ejemplo, tal vez no cree en el control de versiones como una ayuda, pero muéstrele cómo ramificar / fusionar y cómo puede trabajar en varias características experimentales sin necesidad de tener una gran cantidad de archivos.

Con respecto a la POO, muéstrele algunos patrones de diseño geniales / complejos, como el patrón de comando, el patrón de tareas y cómo puede ahorrarle tiempo valioso, y a todo su equipo.

Si no lo tiene interesado en lo más mínimo ... podría ser un caso perdido, pero de nuevo, tiene las herramientas para que su equipo y usted lo superen. Intente utilizar un software de repositorio que muestre / envíe mensajes de correo electrónico de confirmación que su gerente pueda ver, que brindarán transparencia a su gerente y dejarán a su compañero de trabajo fuera de la imagen (bitbucket.org tiene repositorios privados gratuitos con espacio ilimitado, si usa mercurial).

Al final, no trates de convencer con palabras, sino con acciones irrefutables, esa es la mejor manera de tratar con personas obstinadas en mi humilde opinión (la psicología inversa también funciona a veces, jajaja).

bueno, las técnicas que mencionas son obviamente buenas, pero también debes preguntarte si las estás impulsando como ideología. Encuentro que los programadores más jóvenes tienden a ser un poco evangélicos sobre lo que aprendieron en la universidad. recuerda que estas técnicas son buenas debido a resultados: el control de versiones permite el desarrollo concurrente, un seguimiento más claro del diseño, desarrollo, prueba, etapas de corrección de errores. Si sus proyectos realmente son a corto plazo, mucho de eso es simplemente inapropiado y terminará haciéndolo menos ágil. Simplemente no es el caso que las mejores prácticas significan usar todas las mejores prácticas posibles. La abstracción, por ejemplo, definitivamente puede ser más una responsabilidad que una ayuda, al menos algunas veces. el control de versiones tiene más sentido cuando tiene líneas de tiempo de desarrollo extendidas, código complejo, múltiples programadores: hay una especie de sinergia, que es difícil de lograr con poco a poco.

Creo que el lugar para comenzar es estar atento a la posible reutilización: a medida que pasan los proyectos, piense en puntos en común o en marcos más generales. tratar de salir adelante de los proyectos sería un movimiento poderoso y podría permitirle trabajar con más técnica ...

Debe pedirle a su supervisor que haga una presentación para TODOS sobre por qué el software de "versionado" es bueno. No destaques a tu compañero de trabajo.

Soy un escéptico del software de control de fuente, porque veo que la gente lo usa mal todo el tiempo, como una forma de evitar el trabajo.

Mis compañeros de trabajo se están fusionando CONSTANTEMENTE, constantemente pisándose los pies de los demás. Pero una buena conferencia amistosa sobre sus beneficios sería algo agradable y estimularía las discusiones.