Primero nos dicen que como profesionales es nuestro deber decir que no, pero después nos dicen que decir que no solo nos lleva a alejarnos de los lugares donde se toman decisiones. No sabemos si decir siempre que si o siempre que no, muy probablemente tengamos que pensar un poco más.
Cuando comenzamos nuestro camino en el desarrollo de software, con mucha energía y poca experiencia, tratamos al máximo de cumplir todo lo que se nos pide, creando complicadas y a veces esotéricas soluciones, muchas veces recolectando cumplidos por nuestra habilidad de solucionar cualquier problema. Pero con el tiempo estas soluciones crean más problemas que necesitan más complejidad y los problemas escalan. Mientras ganamos más conocimientos comenzamos a reconocer la necesidad de tomarnos más tiempo en el diseño de soluciones escalables pero ya sea por la urgencia del problema a solucionar o la necesidad que comunica el negocio de aumentar la velocidad de entrega mantenemos la producción de lo que se parece más a una fábrica de bugs que a software.
Aprendiendo del trabajo de profesionales como, Dave Farley, defendemos la postura de elevar la calidad del código ya que esto elevaría la velocidad de entrega de software, pero sin éxito.
En algún momento, tal vez después de leer Uncle Bob, nos transforma la idea de que desarrolladores profesionales se diferencian por la habilidad de decir que no, entonces comienza una nueva etapa donde nos volvemos paladines defensores de la calidad negándonos a aceptar requerimientos que no hayan tenido analisis, a cambios de rumbo o hasta diseños que no nos parezcan lo suficientemente buenos. Pero las cosas no mejoran, siguen apareciendo nuevos requerimientos sin aviso, las decisiones tomadas cambian y tal vez también el clima laboral empeora. Notamos que nos convertimos en “el que siempre dice que no”, que ya no estamos donde se toman las decisiones y que el compromiso de nuestros compañeros no es el mismo, muy probablemente porque sus aportes son ignorados por desarrolladores con más seniority que eligen sus propias ideas que creen de mejor calidad.
Ahora llegamos a nuevos recursos, como el libro de Staff Engineer de Will Larson, y dejamos de creer en la negativa como mantra y tomamos la de minimizar la fricción, las cosas no son tan fáciles como elegir si decir que si o que no, tenemos que esforzaronos para incluir a todos los colaboradores para mejorar el producto y el trabajo en equipo, mantener alineación con los jefes para estar incluidos en la toma de decisiones y pensar un poco más en el si y el no. Es obvio, creo, que trabajar horas extra y/o fines de semana en detrimento de nuestra salud y relaciones familiares es algo a lo que tenemos que decirle que no, pero tambien podríamos considerar que en algunas situaciones es aceptable el esfuerzo extra, que el objetivo depende de nuestro negocio y que la tecnología es una herramienta para ese fin y no el fin en sí mismo.
Aprender a cuándo decir que no nos permite mantener el valor de la palabra y que tenga peso.
