Hace un año comencé a trabajar en una startup muy ágil. Fui el primer desarrollador no interno en unirse y trabajé en estrecha colaboración con el CTO para armar una versión beta de una canalización y un producto. Debido a la velocidad requerida y al hecho de que el dominio no había sido explorado previamente, construimos algo irregular pero que funcionaba. Se han saltado muchas cosas, incluidas las pruebas y algo de documentación (realmente no había tiempo).
Ahora han pasado algunos meses desde que se unieron un par de otros desarrolladores. No son desarrolladores de pila completa, por lo tanto, cada uno de ellos tiene responsabilidades sobre algunas partes de mi código. Pero sus áreas no se superponen. Esto los convierte en compañeros de trabajo ideales ya que cada uno no puede criticar realmente el trabajo de la otra persona.
En cambio, lo que enfrento ahora es una crítica constante sobre todo lo que he desarrollado. Sin importar la velocidad que se requería ni la falta de conocimiento en el dominio.
Intenté hablar con el CTO, pero solo dice que están aprendiendo y mejorando, sin embargo, lo que creo es que simplemente no quiere lidiar con estos asuntos.
¿Alguien tiene alguna idea de cómo hacer frente a esta situación sin vivir cada día con miedo y ansiedad?
Tomó la decisión táctica de aceptar una deuda técnica para entregar un producto terminado que fuera funcional. Trabajó a partir de una hoja de papel en blanco e hizo algo que es lo suficientemente bueno como para que los clientes e inversores quieran usarlo. Enorgullécete de eso: debería ser una de las primeras líneas de tu currículum.
Ahora el sistema está creciendo en madurez. Tiene otros desarrolladores que pueden ver de manera objetiva lo que se desarrolló y tener ideas (quizás válidas) sobre cómo mejorarlo.
Tu papel ahora no es ser un mono de código. Su posición es elevarse por encima y administrar sus codificadores. Tiene un conocimiento de dominio que ellos no tienen: sabe por qué se tomaron ciertas decisiones. Deben sentirse libres de discutir ideas con usted sobre cómo mejorar el producto: más rápido, más funcional, más seguro, más escalable. Si un desarrollador no le está dando estas sugerencias, entonces tal vez no sea el desarrollador adecuado para el puesto.
Es difícil aceptar críticas cuando se trata de 'tu bebé', pero si lo miras desde el punto de vista de que si el sistema es bueno, todos tienen un trabajo y ganan dinero, entonces verás que los desarrolladores están empujando misma dirección (si no, asegúrese de que sea la puerta de salida contra la que están empujando). Incluso si todo su código base termina reescrito, seguirá siendo la persona que escribió la primera versión.
Dudo que el clima mejoraría si le dijera que se toma estas críticas como algo personal y que le gustaría que cesaran, ni si escalara el asunto. Podrías ganar que dejen de criticarte abiertamente, pero eso no cambiará lo que puedan pensar y será perjudicial para tu relación como compañeros.
Criticar el trabajo del otro desarrollador es parte total de la cultura del desarrollador, y tienes que lidiar con el hecho de que no siempre se hace de manera constructiva o con mucho tacto. Si les falta el entendimiento, podrías educarlos con las razones por las que hiciste tales sacrificios. Al recordarles las altas tasas de mortalidad de las nuevas empresas, podría ayudarlos a darse cuenta de que hay cosas por encima de la calidad del código, como la presión del dinero, que son muy reales.
Como consejo práctico, trate de disociarse de su trabajo y tome los comentarios a la ligera siempre que no se implique nada sobre su profesionalismo. Si siente que se desvían hacia la negatividad, puede intentar guiarlos hacia la positividad, respondiendo a los comentarios "olores de código xxx" con "tendremos la oportunidad de mejorar eso en la fecha yyy".
Pueden superarlo. Ese código que están criticando es el mismo código que abrió la oportunidad que requirió la contratación de desarrolladores adicionales (también conocidos como ellos). Sin él, no hay razón para que estén allí.
La historia corta es que los desarrolladores están ahí para mejorar el código (la misma historia en cualquier otro lugar). Si no está haciendo algo que debería hacer, hacer un código para hacerlo. Si está roto, para arreglarlo. Si esperan lo suficiente, pondrán un código allí para que otros lo critiquen.
De acuerdo con la respuesta de @PeteCon.
Es posible que esté entrando en un modo defensivo, porque es su código y, en cierto modo, un reflejo de su habilidad. Usted dice que no tiene en cuenta las limitaciones que enfrentaba al momento de escribir, pero eso realmente no importa. El código malo es un código malo. Si creó algo funcional, pero no mantenible, entonces hay que refactorizarlo. Esto no significa que sacar algo que funcione en un corto período de tiempo no haya sido un logro.
Como se mencionó en la otra respuesta, debe dejar de dedicarse a la codificación a tiempo completo y hacer la transición a la administración de recursos. Además, no estoy de acuerdo contigo al pensar que tus desarrolladores trabajando en partes estrictamente separadas de tu base de código es algo bueno, ¡no lo es! Si desea adoptar cosas como revisiones de código, donde los desarrolladores pueden comenzar a revisar las solicitudes de combinación de los demás, entonces deben estar familiarizados con la base de código que están revisando. Además, está creando islas de conocimiento y cuando uno de sus desarrolladores finalmente se vaya, nadie entenderá cómo funcionan sus implementaciones, porque nadie trabajó con su parte del código base y nadie aseguró la calidad, la legibilidad y la documentación de su código. a través de la revisión.
Me gustaría compartir una experiencia, porque suena muy similar a tu historia.
En el pasado me uní a una startup tecnológica. Era mi segundo trabajo de TI a tiempo parcial, todavía asistía a la universidad en ese momento. El equipo era genial y me gustaban mis tareas, pero había algunos problemas organizativos.
El desarrollador principal fue una de las personas más grandes y experimentadas con las que he trabajado. Muy hábil, muy bien informado. Sus proyectos también eran su bebé. Sospecho que podrían haber ocupado un puesto mucho mejor con un salario mucho más alto, pero les encantó su proyecto y permanecen allí hasta el día de hoy, que yo sepa. También fue bombeado a una velocidad asombrosa, más rápido de lo que yo podría haberlo hecho, pero por lo tanto vino con una gran deuda técnica.
Con el tiempo, más estudiantes y no estudiantes se unieron a las filas de desarrollo, pero el líder siguió trabajando en la base de código, porque esto es lo que les gustaba hacer y lo entiendo. Pero con más y más proyectos, simplemente comenzaron a arder. Más tarde y más tarde, tratando de terminar esto, tratando de terminar aquello, codificando y manteniendo los servidores los fines de semana, de vacaciones, durante la baja por enfermedad, etc.
Mientras tanto, la política de la empresa no tenía protocolos de revisión o prueba establecidos. Varios desarrolladores, incluido yo mismo, le pedimos al líder menos codificación y más administración, porque necesitábamos una estructura de control de versiones adecuada, una organización de repositorio adecuada, etc., pero eso simplemente no sucedió. Realmente prometieron que lo haríamos, pero siempre estaban sobrecargados de trabajo para hacer DevOps.
Y así, se desarrollaron dos cosas. Una cosa eran las islas. Mantuve mi proyecto, que era una gran fuente de ingresos para la empresa, como estudiante por mi cuenta. Conocía todos los caminos secretos, todas las complejidades del código, pero no había suficiente tiempo para hacer todo lo que se me pedía. Desarrollé funciones, traté de encontrar alguna organización en el repositorio, hice soporte al cliente y seguí apagando incendios. La segunda cosa: nuestra base de código se deterioró. Nadie revisó mi código, nadie pudo en algún momento, no hubo tiempo para documentación y siempre parches ad hoc.
Esto también fue cierto para otros colegas.
Así que todo se ralentizó cada vez más en el desarrollo de funciones en todos los proyectos, excepto en los más nuevos, porque cada vez más la deuda técnica comenzó a pasar factura y estábamos bajo la presión constante de la gerencia. Presión psicológica. Una vez atrapé a un colega llorando en el baño, hablé un poco con ellos, me di cuenta de que había estado descargando mi estrés en mi familia y mi pareja durante casi un año, y decidí que era hora de irme.
Hasta el día de hoy, me avergüenzo de dejar este código base en un estado tan desordenado, porque trabajé mucho en él, gran parte son cosas que puse. Pero si alguna vez solo haces patchwork, cosas rápidas y sucias, etc , entonces su código se convierte en un desastre irredimible. Cuando renuncié, algunas otras personas también se fueron. Otras dos islas. Nadie estaba nunca familiarizado con sus bases de código, excepto el líder hasta cierto punto.
La conclusión de esta historia: estos proyectos están en su mayoría muertos. La compañía todavía gana dinero con ellos, pero no ha habido más desarrollo, excepto por algunas cosas que el líder puede haber cambiado. Los puestos quedaron vacantes, los desarrolladores recién contratados aparentemente no pudieron seguir manteniendo las bases de código respectivas.
Ahora estoy trabajando en una empresa con revisiones de código adecuadas, pruebas, canalizaciones automatizadas, procesos... es muy bueno. Claro que tenemos nuestras especialidades en el código base, pero efectivamente no hay conocimiento de la isla en absoluto, además hay revisiones de código, por lo que ningún código llega a la rama maestra, que no haya sido visto por otra persona. Mi salud mental en relación con mi lugar de trabajo también mejoró y mis habilidades ahora también son mucho más nítidas.
Lo entiendo, es difícil lidiar emocionalmente con las críticas a tu trabajo, pero deberías ver las críticas como algo bueno, eso significa que tus desarrolladores pueden mejorar la base de código, porque ven cosas que podrían ser diferentes. No cree islas de código base, porque perderá personas en algún momento y no intente arreglar todo usted mismo, trabajará en la UCI.
Para avanzar, sugiero una reunión estratégica con usted y los otros dos desarrolladores. El objetivo debe ser planificar las siguientes fases. Hay al menos tres cosas que necesitan ser cubiertas:
Los temas deben incluir cómo equilibrar el trabajo en estos objetivos, a qué nivel de prueba y documentación apuntar en la próxima ronda de desarrollo y cómo llegar allí. Si alguno de ellos comienza a hablar sobre las deficiencias del código inicial, regrese la discusión a la planificación de qué hacer al respecto.
¡¿Por qué te importa?!
Pueden criticar todo lo que quieran, siempre y cuando también hagan relaciones públicas buenas y válidas.
Como dijeron otros, el código que están arreglando es lo que obtuvo el dinero para contratarlos en primer lugar.
Es posible que desee recordarles eso. A diario.
Hablando en serio, déjalos que se quejen con todo su corazón, escribe mensajes de compromiso de una página, todo el tinglado.
Solo asegúrese de que, como su revisor técnico, hagan un buen trabajo al tomar su base de código anterior y mejorarla.
La única excepción es si se vuelven descarados y/o simplemente groseros con su crítica. Una cosa es pensar "¡Oh, chico, este código apesta!", y otra cosa es ventilarlo por completo con esas palabras exactas.
En cuyo caso, dispara sus culos en el acto.
Pero por lo demás... amigo, tú construiste el prototipo. Eres "el Woz" de tu empresa.
¡¿Por qué te importa lo que piensen?!
Reúnalos para una pequeña charla. Dígales tal como son: Usted arma este código rápidamente para que la empresa llegue a un punto en el que obtenga fondos que se utilizan para pagar sus salarios. Sin el código del que se quejan, no estarían trabajando allí.
Diles: si no te gusta, arréglalo. En silencio. Sin quejarme.
PD. Si producen "arreglos" en lugar de arreglos, entonces se requiere una gran regañina. Si organiza su trabajo a través de trabajos atrasados, entonces hacer cualquier cosa sin que esté en el trabajo atrasado necesita una reprimenda. SIN EMBARGO, es completamente apropiado y la mejor práctica al realizar una tarea para mejorar el código relacionado con ella.
patricia shanahan
chris stratton
otrotrabajador
delinear
Puñal