En mi nuevo trabajo a veces cometo errores. Por lo general, estos errores se deben a suposiciones que hago en función de otros trabajos que he tenido, otras herramientas que he usado y otro software que he desarrollado en este mismo equipo.
Inevitablemente, cuando hablamos de lo que salió mal, pregunto "¿Dónde está escrita esta información?" o "¿Cómo puedo evitar esto en el futuro?" y la respuesta siempre está en la línea de "Recuerde que X en el contexto Y es diferente de X en la mayoría de los demás contextos". La falta de estandarización en cualquier práctica está afectando mi moral, productividad y percepción entre el equipo (me ven como algo negativo y no quiero fomentar un lugar de trabajo tóxico). Si tenemos que tomar una decisión, solemos hacer un poco de ambos; tampoco salimos completamente de las viejas prácticas.
Las excusas que me dan para esto son algo como esto:
¿Cómo le digo a mi equipo:
Como solución alternativa, me veo con estas opciones:
Estas "soluciones" no son mutuamente excluyentes.
No siento que pueda cambiar esta cultura por mí mismo, y me gusta mi equipo inmediato, pero es muy agotador pisar constantemente estos charcos de lodo que los verdaderos profesionales no tolerarían.
Editar: no puedo comentar, por lo que mis respuestas a los comentarios están en línea a continuación:
Jimbo: eso es parte de la tercera "opción", supongo. Trabaje diligentemente para documentar todo, haga multas para que algún día las cosas se arreglen y trate de no frustrarse a medida que se profundiza la madriguera del conejo.
Vietnhi Phuvan: No tengo autoridad sobre este equipo. No estoy seguro de lo que quieres decir con entrometerse. No tengo la responsabilidad de arreglar el software y los procesos con los que trabajamos todos los días, pero nos afecta a todos y afecta nuestro rendimiento. No tengo "construir una coalición". Otros tienen fuertes opiniones sobre ciertas cosas, pero por lo general simplemente las aceptan y continúan con su trabajo diario, o intentan obtener recursos para solucionarlas. No soy el único que despotrica, pero soy el más desanimado de mi equipo; parte del problema es que el "problema con una solución alternativa aceptable" ya no es un problema para la mayoría de las personas por aquí, y "solución alternativa aceptable" significa "cualquier solución alternativa". Estoy trabajando en un plan de acción. Voy a investigar cómo otras empresas resuelven estos problemas, por qué Es más efectivo resolver estos problemas en lugar de vivir con ellos y encontrar una ruta de actualización clara. Alternativamente, voy a desarrollar mis habilidades hasta que pueda irme. La credibilidad que tengo tiene que ver con el tipo de preguntas que ya me hacen mis compañeros.
Kent Anderson: Gracias por la atenta respuesta. Trataré de mantenerme positivo en el futuro. El punto que más me sorprendió fue "tratar de entender cómo/por qué tus compañeros de equipo piensan como lo hacen". Tal vez pueda descubrir sus motivaciones/procesos/intenciones y ser más eficaz. PD: no soy el que siempre habla en las reuniones, de hecho, me detuve casi por completo, eligiendo en su lugar tratar de ayudar a formar un consenso en lugar de tratar de poner nuevas ideas sobre la mesa.
Finalmente, me gustaría aceptar la respuesta de Kent, pero olvidé el correo electrónico de la primera cuenta descartable :(. Gracias a todos por sus comentarios. Trabajaré en esto.
Esto va a parecer que me estoy metiendo contigo. No lo soy, solo trato de ser objetivo...
Ten mucho cuidado con declarar a todos los que te rodean como poco profesionales. No es cierto, especialmente si son trabajadores veteranos. Como la persona nueva en el equipo, es probable que desconozca las razones históricas por las que hacen las cosas de la manera en que lo hacen. Claro, hay comportamientos poco profesionales en el lugar de trabajo. Quejarse y acusar a otros de no ser profesionales es un ejemplo de ello.
¿Cada reunión contiene un elemento de usted vocalizando que las cosas no son lo que desearía que fueran? Si es así, existe alguna base para que su equipo lo considere difícil o quejoso. Si este es el caso, intente identificar una solución y ofrézcase a implementarla. (Mantenga una página wiki para el equipo, por ejemplo).
Estoy seguro de que eras mucho más positivo cuando empezaste a trabajar en este equipo, y ahora estás abatido y harto. Intenta recuperar algo de esa positividad y tolerancia con la que empezaste. Serás más feliz. Haz lo que puedas para tratar de entender cómo y por qué tus compañeros de equipo piensan como lo hacen. Tome notas personales que pueda revisar si se encuentra en una de estas áreas en las que cree que podría estar "metiéndose en un charco". Resista la tentación de mostrar una página de notas como "prueba" de que su equipo está siendo inconsistente o caprichoso. Eso nunca mejora las cosas.
Si llega al punto de rescatar (ya sea del equipo o de la empresa en general), recuerde, no existe un equipo que haga todo bien, todo el tiempo. ( ¿Qué significa "correcto" en este contexto? ) Irte podría ayudarte a sentirte mejor y podría ser lo correcto para ti. Simplemente no se embarque en una carrera nómada en busca del equipo perfecto. No lo encontrarás.
De nuevo, no me estoy metiendo contigo. Recuerdo las frustraciones que sentí al principio de mi carrera de desarrollo de software porque otros no estaban a la altura de mis ideales o de mi "estándar" de excelencia técnica. La paciencia, la tolerancia y el ofrecimiento de ayudar a arreglar las cosas son las mejores maneras de aliviar sus frustraciones y alentar a que se realicen cambios.
En situaciones como esta, a menudo la mejor solución es simplemente encontrar una nueva situación. No todas las tiendas funcionan como la tuya. Hay equipos de desarrollo que se esfuerzan activamente por la mejora continua, que no dependen de individuos para recordar soluciones oscuras o dependencias extrañas, que entienden las mejores prácticas actuales y las siguen o tienen una muy buena razón para hacer algo diferente. En mi larga experiencia, las tiendas como la suya eventualmente cierran. Puede tomar un tiempo, pero eventualmente serán superados por un competidor más inteligente. Ahora que conoce el tipo de lugar en el que no le gusta trabajar, puede tener más cuidado con la próxima oferta que acepte.
Ponte en sus zapatos.
Si el código base con el que tienes que lidiar no es bueno, ellos lo saben. Es muy probable que no se deba a que sus nuevos colegas no sean programadores decentes, sino a que existe la presión de entregar las cosas más rápido de lo posible mientras se hace un trabajo correctamente. Las cosas no están documentadas porque alguien no pudo cumplir con una fecha límite y documentar lo que estaba haciendo, y cuando entregó en la fecha límite, surgió un nuevo trabajo antes de que alguien pudiera comenzar con la documentación.
Es posible que algunos de ellos hayan llegado a la empresa recientemente y hayan tenido exactamente las mismas ideas que usted tiene ahora, y luego resultó que no pudieron hacer nada al respecto.
Pero, ¿qué van a decir si dices "tu código es basura y necesita cambiarse"? Lo mismo que harías dentro de dos años el tiempo de la próxima nueva adición al tiempo te dice exactamente lo mismo. Estarán a la defensiva. Nadie quiere admitir que su trabajo (sin tener la culpa) no es de la más alta calidad. Si es por su propia culpa, será aún menos probable que lo admitan.
Jaime
Vietnam Phuvan
Vietnam Phuvan
brandon
brandon
Where is X documented?se pregunta cuando una pieza de código tiene sorpresas o comportamientos confusos. Contestaría sobre la base de que el código no debería haber estado lleno de sorpresas y debería haber sido escrito de manera menos confusa. Pero siento su dolor por la documentación.Kent A.