¿Qué debería decir en mi currículum si me ascendieron por dejar de lado la calidad del código para cumplir los plazos?
Tenía un contrato de 12 meses (vivo en un país donde esto no es habitual para los nuevos desarrolladores) hasta que hace un par de semanas la dirección de mi empresa me hizo una oferta y un aumento de sueldo para convertirme en empleado fijo para ellos. Me gusta tener mi currículum siempre al día (sobre todo teniendo en cuenta el COVID) así que busqué en Google cómo incluirlo en mi currículum.
El consejo que encontré fue que, por lo general, debía indicar el logro que había motivado la contratación. Me parece justo.
El problema es que el logro era siempre cumplir con los ajustados plazos de los clientes y, francamente, lo hice decidiendo que la ingeniería podía ser menos que estelar en casos puntuales (con lo que la dirección estaba de acuerdo).
Soy un desarrollador relativamente junior en un equipo de 6 desarrolladores. Sin embargo, me he convertido rápidamente en uno de los desarrolladores en los que más confía la dirección para entregar cosas cuando digo que las entregaré y les mantengo informados de los compromisos relativos para conseguirlo. En el poco tiempo que llevo aquí, siempre he sido capaz de entregar algo cuando he dicho que podía hacerlo.
He tenido algunos casos como este, pero este es el que hice justo antes de que me ofrecieran el trabajo permanente. Uno de nuestros productos es una API por lotes que es llamada una vez al día por un solo cliente. No necesita devolver nada, salvo un CSV de entradas fallidas por correo electrónico. Querían que se añadiera una nueva función y el vendedor se había comprometido por contrato a tenerla para finales de mes. Por diversas razones, esa solicitud de función no llegó a nosotros hasta el lunes de la última semana del mes.
El desarrollador principal le dijo al gerente que el desarrollo no podía hacerse correctamente y que le dijera al cliente que no podía hacerse. Yo no contradigo a los desarrolladores sénior en las reuniones de planificación de sprints, pero quizá era obvio que estaba en desacuerdo con el sénior. No estaba en desacuerdo, sino que existía una opción con ciertas contrapartidas. Los otros desarrolladores también son bastante pasivos, así que nadie más le contradijo tampoco. El director no estaba contento con esto, ya que el cliente está enfadado con nosotros por no cumplir con lo prometido. El gerente me citó en su despacho después de la reunión para preguntarme si veía una alternativa. Le dije que podía conseguir algo que funcionara, pero que probablemente duplicaría el tiempo de procesamiento de la API (lo que añadiría 4 minutos), ya que no tengo conocimientos especializados de SQL. El director estuvo de acuerdo y, al parecer, el cliente ni siquiera se dio cuenta.
No estoy seguro de cuáles habrían sido las consecuencias de no cumplir con el plazo, pero fueron lo suficientemente fuertes como para que el director general de nuestra empresa de 1000 personas me enviara un correo electrónico de agradecimiento por haberlo conseguido.
Otro caso no atrajo tanta atención, pero había un proceso que necesitábamos ejecutar en una base de datos. La forma correcta de hacerlo habría sido escribir un proceso por lotes adecuado en el mega sistema Java que utilizamos, enviarlo a través de todos los procesos regulares de control de calidad y dejar que saliera al final dos semanas después. Le ofrecí al director un script en Python que tendría que ejecutarse manualmente y sería terriblemente ineficiente (tenía que ejecutarse durante la noche), pero si se activaba una vez al mes, mantendría el problema a raya hasta que llegara una solución permanente. Se trataba de un problema de producción, así que accedió a ello como medida provisional. Se trataba básicamente de un bucle for barato que comprobaba las filas en busca de un determinado tipo de datos erróneos y los reformulaba.
¿Existe una forma de incluir este tipo de cosas en mi currículum que no me haga parecer un programador de pacotilla que socava a los desarrolladores senior? Admito que mis soluciones no son técnicamente sólidas, pero eran sólidas para las necesidades del negocio en ese momento y la compensación de ineficiencia era en gran medida irrelevante en la mayoría de los casos.
Encontraste varias formas efectivas (no eficientes) de resolver los problemas sin sobreingeniería y "Lo hecho es mejor que lo perfecto"
Encontrar una solución que sea lo suficientemente buena es una habilidad importante para un ingeniero, ya que, de lo contrario, se perdería mucho tiempo optimizando algo que no merece la pena optimizar. Si algo no se utiliza a menudo, a menudo no vale la pena optimizarlo. Hay un bonito XKCD-Comic con una tabla que te dice cuánto tiempo debes invertir en algo.
Una solución sólo tiene valor si se usa (o puede usarse), así que con un hack le permites al cliente seguir trabajando hasta que tengas una solución.
No hay razón para decirle a nadie que no está de acuerdo con su supervisor. Simplemente, opta por algo como "capaz de producir soluciones eficaces bajo presión de tiempo".
Tenías un trabajo: "encontrar una solución que se ejecute dentro de los límites de tiempo que resuelve el trabajo". Y eso es exactamente lo que hiciste.
Tengo la sensación de que sólo la dirección ha estado dando respuestas aquí, porque no había nada más que elogios en el cumplimiento de plazos poco razonables.
Hay otro punto de vista aquí. No debes subestimar los disturbios sociales que se encienden dentro del equipo de desarrollo cuando la gerencia corta las esquinas e ignora las opiniones de los desarrolladores principales. Hay un dicho que dice más o menos así:
Una cosa es si una o dos veces te metes en el camino de los hackers porque te obligan a hacerlo, y otra completamente distinta si se trata de una norma. Y por tu descripción me parece que la gerencia se ha vuelto bastante cómoda con la práctica de usarte para tomar atajos. Deberías considerar seriamente plantear este tema a tu dirección y a tus superiores para mantener un ambiente de trabajo saludable. Una empresa es un equilibrio entre desarrollo y gestión y no simplemente una estructura de arriba hacia abajo. Hay una razón por la que la palabra "no" existe y deberías practicar su uso.
Sin embargo, esto es aún más una cuestión de gestión que la suya. Por lo tanto, no hay razón para mencionarlo de alguna manera en tu currículum. Así que yo estaría de acuerdo:
Como dice el refrán, "lo perfecto es enemigo de lo bueno": hacer concesiones técnicas para satisfacer las necesidades del negocio es prácticamente de rigor. Los buenos desarrolladores/programadores/ingenieros son los que saben identificar los compromisos aceptables que se pueden hacer.
En tu ejemplo de la API, el cliente estaba claramente dispuesto a aceptar un retraso de 4 minutos en el procesamiento a cambio de algo que funcionara y se entregara a tiempo.
Lo ideal sería minimizar la deuda técnica al hacer estas concesiones, pero eso es parte de la experiencia y de saber dónde se puede ahorrar tiempo y cuándo hay que asegurarse de que algo se hace "bien" para ahorrar más tiempo a largo plazo.
Cuando se trata de la parte superior de tu CV no es necesario entrar en los detalles de tu solución - puedes simplemente decir que tienes un buen historial de entrega en los plazos de los proyectos sensibles al tiempo y mencionar los ejemplos sin detalles de la implementación real.
Lo que haces NO es "hackear", es "encontrar soluciones".
Trabajo como desarrollador y consultor desde hace 20 años, y esta habilidad es la que buscan los empleadores: No lo dejes fuera de tu currículum, sino que enfatiza exactamente eso: Tratas de encontrar soluciones, incluso si eso significa ir por caminos "inusuales".
No escribas que lo haces a espaldas de los desarrolladores más veteranos, sino que lo haces siempre que te piden soluciones, aunque los más experimentados no estén de acuerdo o digan que no es posible.
Hay una gran cita que se dice que viene de Albert Einstein que describe exactamente tu situación:
He trabajado con muchos desarrolladores y conozco todas las facetas de esto:
Trabajé con un desarrollador que está entre el 1% de los mejores expertos en JavaScript en stackoverflow. Es un genio y realmente admiro cada línea de código que escribe. Pero muy a menudo no terminaba sus proyectos: Prefería no terminar algo que terminarlo cuando no estaba satisfecho con la belleza del código.
Y trabajé con desarrolladores que eran extremadamente eficientes, pero que tomaban muchos atajos que hacían que las soluciones fueran casi imposibles de mantener (rutas codificadas, números mágicos, etc.).
Y siempre he preferido lo "hecho" a lo "bonito" y al final mis clientes también: Prefieren tener "algo" cuando el plazo está ahí que "nada pero será hermoso en algún tiempo más X"
Sólo una cosa: Las soluciones / atajos / "hacks" tienen que ser comprensibles, documentados y mantenibles, entonces no hay nada en contra de las soluciones como tú
Así que creaste un software que tardó cuatro minutos en ejecutarse (porque tu código no era muy bueno). Si me lleva 12 horas hacer el trabajo a mano, tu software me ahorra 11 horas y 56 minutos. Si escribiste un código mejor que se ejecuta en 1 segundo, me ahorra 11 horas, 59 minutos, 59 segundos. Si el mejor código se entregó una semana después, así que tuve que hacer el trabajo a mano cinco veces, los 3 minutos 59 segundos adicionales nunca compensarán el tiempo que perdí.
O lo hacen más extremo. El software necesita funcionar en 24 horas. Tu código es malo, así que necesitamos un ordenador de 5.000 dólares para ejecutarlo en 24 horas. Con un código mejor, un ordenador de 2000 dólares podría ejecutarlo en 24 horas. Un ahorro de 3.000 dólares. Si te toma dos semanas hacer el código más rápido, es una pérdida total.
Ser capaz de entregarlo cuando se necesita es algo muy, muy bueno. Además, un desarrollador muy bueno puede escribir código malo de manera que pueda ser mejorado más tarde fácilmente. Los malos desarrolladores escriben código malo que es un dolor para refactorizar en una buena forma, los buenos desarrolladores bajo la presión del tiempo escriben código malo que es fácil de mejorar.