Llevo un tiempo pensando en lo que es para mí ser un buen desarrollador de software y los puntos que nos pueden hacer ser justo lo contrario.
Desde hace bastantes años trabajo y comparto proyectos con un número variado de profesionales, bien personas o agencias a las que delego trabajo o bien que me lo delegan ellos a mí. Este texto se basa en esta experiencia.
Por otro lado debo decir que, algunas de las cosas “malas” que destaco en este texto no solo las he visto en otros profesionales, sino que también las he visto en mí mismo cuando empezaba bastantes años atrás o al cometer errores a lo largo de mi carrera profesional.
Por lo tanto es una visión muy personal de nuestro mundo y no pretendo tener la razón absoluta. Los comentarios siempre se agradecen.
No tener una actitud de gilipollas
Somos unos privilegiados al dedicarnos a desarrollar software en estos momentos. Podemos asegurar que no hay paro en nuestro sector y que siendo inquietos, actualizándonos y currándonoslo un poco podemos trabajar desde prácticamente cualquier sitio del planeta (siempre que tengamos visado y conexión a Internet).
Es posible que en un futuro esto cambie y que mucho del trabajo o tipo de proyectos que estamos realizando en estos momentos se podrán sustituir por APIs o servicios cloud. Pero el presente es el que es y se puede vivir genial desarrollando software.
Pero este privilegio no nos da derecho a comportarnos como cretinos. Chantajeando a quien nos contrata o criticando en público a quien oferta porque en Londres cobrarías en triple y te irían a buscar a casa en un taxi de esos negros molones. Hablaré de este tema más en detalle más adelante en esta misma entrada.
Dominar el framework javascript de moda no te da derecho a ir por la vida con la actitud de un House desarrollador de software. House era un payaso pero al menos salvaba vidas (en la ficción).
Mejor un trabajador responsable que un ninja
Puedes cambiar el término “ninja” por lo que desees, incluidas siglas de certificaciones oficiales.
Al final de lo que se trata es de sacar trabajo adelante. Y de poco sirven las charlas que hayas dado, los tags que uses en Twitter o las pegatinas que tengas en tu Mac.
Tener capacidad de respuesta es algo muy valioso en un desarrollador para mí, mucho más importante que sus títulos o marca personal.
Es muy habitual la decepción que puedes llevarte al comprobar como una persona que es rockstar en Twitter u otros escenarios, desaparece en mitad de un proyecto para finalmente salir del mismo porque se ha visto saturado o simplemente no le gusta que se use una tecnología o herramienta X. Me parecen actitudes de chavales de catorce años. Sin ánimo de ofender a los chavales de catorce años.
Al final lo que se desea es tener en tu equipo gente con la que puedas contar. Puede que no controlen a un nivel brutal la última versión de Angular o hayan participado en un proyecto de gran tráfico o que hayan escrito libros sobre la última librería javascript de moda que dentro de dos años no utilizará nadie, pero es que la mayoría de las ocasiones tampoco hace falta.
Lo que sí hace falta son profesionales responsables que acaben el trabajo de forma correcta y sin tonterías.
Comunicación
La comunicación es otro valor clave.
A todos nos surgen imprevistos, nos equivocamos o puede que pase algo fuera de nuestro control que nos impida hacer nuestro trabajo. Comunicar cuanto antes cualquier imprevisto ayuda a poder resolver la situación, callarse siempre es una mala opción.
Lo mismo que si una frase o acto de otra persona en el equipo te sienta mal o no estás motivado por algún problema.
Personalmente valoro mucho quien sabe comunicarse cuando las cosas van mal o hay presión en un proyecto. El coste de comunicación es un precio muy alto que se puede pagar al trabajar con un equipo o una persona equivocados.
Saber comunicar correctamente tus ideas cuando trabajas en equipo, escribir bien y expresarte bien es una habilidad que en mi opinión nos hace mejores desarrolladores.
Esto me parece especialmente importante cuando se trabaja en remoto. Cuando no ves la cara del otro ni escuchar su voz, el texto lo es todo. Es crítico en estos contextos cuidar mucho cómo escribimos.
Comunicar también es escuchar.
Algunos podemos tener carácter, prejuicios por falta de perspectiva o simple cabezonería, somos humanos. Muchas veces incluso teniendo experiencia caemos en estas cosas. Y muchas veces, debatimos con ímpetu aun estando equivocados.
Creo que tanto si eres el que argumenta estando o no equivocado como si eres el receptor, debes escuchar lo que esa persona te está diciendo, sobre todo si tiene experiencia. Las lecciones más valiosas las aprendemos cuando estamos equivocados y cuando nos argumentan el por qué. Y son doblemente valiosas cuando el/la que nos alecciona tiene menos experiencia que nosotros.
Y aunque en ese momento no lo veamos, sin duda quedará en nuestra mente y será un recurso muy valioso cuando toque darse cuenta de nuestro error.
Pragmatismo VS curriculum oriented development
No es “sexy” (y madre mía con lo de “sexy” para hablar de frameworks y lenguajes…) desarrollar una API REST en php y mysql, teniendo Go, lenguajes como Erlang y OTP que existen desde los 80 pero que las hemos descubierto hace cuatro años o bases de datos como MongoDB que “escalan”, “son rápidas” (porque sí y ya está) y que las usan en esa empresa que tiene un “CEOfounder” de 24 años.
Estás desarrollando un producto y lo que importa es el valor. Entregar el máximo valor, con la calidad mínima necesaria consumiendo la menor cantidad de recursos de tiempo y dinero.
La tecnología es algo crítico pero no es lo más importante. Son nuestras herramientas, pero ya está. Nuestro recurso más valioso es la capacidad de crear con ellas usando nuestro criterio. El dominio de las mismas es importante, entrenar con ellas es importante, pero no tan importante como el entregar y entender lo que estamos desarrollando.
Creo que un desarrollador orientado a la herramienta no es un buen desarrollador, es mi opinión personal y mi opinión como cliente.
Por otro lado valoro también mucho el pragmatismo.
Está muy bien que la plataforma web tenga una arquitectura basada en servicios con una implementación de Inyección de dependencias muy currada y que también, se haya tenido en cuenta la separación de orígenes de datos para poder distribuir la carga entre varios frontales web, varios servidores de lectura y escritura a nivel de base de datos y las operaciones pesadas gestionadas por sistemas de colas asíncronas. Todo esto está muy bien. Pero al final si el proyecto es nuevo y va a tener un crecimiento natural, es posible que no se vaya a necesitar orquestar una arquitectura de ese tipo en seis máquinas o instancias virtuales en la nube de turno y puede que con un servidor en un hosting tradicional vayamos sobrados.
No necesitamos añadir coste al cliente de mantenimiento de sistemas o coste extra de servicios cloud porque a nosotros nos ponga cachondos tener una arquitectura de las que salen en blogs como High Scalability.
Y por último: el pasar de frameworks, ORMs y complicar el mantenimiento por trucos de rendimiento cuando no tienes este tipo de problemas, personalmente me parece condenar al proyecto a tener que reescribirse en un futuro por la cantidad de esfuerzo que puede suponer hacer cambios mínimos y el terror también de subirlos a producción.
Trabajando por cuenta ajena y las ofertas de trabajo
Muchas veces me quedo atónito al escuchar las experiencias que han tenido empresarios con su equipo técnico en ciudades como Madrid, Londres o San Francisco.
Cretinos sin ningún tipo de escrúpulos que hacen chantaje a sus empleadores amenazando con irse de la empresa porque han recibido en el último mes un montón de peticiones de amistad de recluiters en linkedin.
Chantajes que van desde imponer el uso de una tecnología/frameworks “o se van”, irse sin avisar ni decir nada una tarde de la oficina porque tenían un partido de fútbol o simplemente porque había un evento en la oficina molona de turno de Madrid.
La verdad me sorprende el aguante de sus jefes por miedo a perder “talento” o capacidad de ejecución, reteniendo un equipo tóxico a ese nivel.
“Que cierre su empresa si no sabe llevarla” He llegado a leer esto cuando un empleador anuncia una oferta de trabajo por debajo de los 32000 euros anuales a un desarrollador, sin entrar a valorar su nivel.
“En Londres me pagarían X” Pues ve a Londres y disfruta de este sueldo. Es posible que al irte, la gente que contrata a programadores en este país se de cuenta del vacío que has dejado, la gente que organiza eventos deje de hacerlo porque ya no merece la pena y el mercado del desarrollo y de Internet en España se colapse. Que se jodan, por no valorar el talento que alguien que va a comisión ha visto en tus aptitudes de Linkedin.
Pero desde luego yo no quiero trabajar con gente así. De hecho no quiero personas así a mi lado.
Montar un negocio se ha convertido en un espectáculo en el que cualquiera puede opinar sin vivir la experiencia de hacerlo. Pero la realidad es que los ataques a empresarios que están empezando y ofrecen sueldos humildes, no mejora el mercado.
Me parece muy respetable buscar el mayor sueldo posible, pero la mayoría de los lugares en los que te van a ofrecer trabajar no van a poder competir con otras empresas en eso. Y es respetable que no quieras trabajar por menos de lo que vales o creas que vales, pero montar un espectáculo en Twitter o en foros me parece bastante infantil y tóxico.
Al mundo real le dan igual las pataletas y la gente realmente competente habla poco y hace más.
Los programadores que realmente pueden elegir dónde trabajar lo hacen sin montar espectáculos. Si no les interesa lo que se oferta, se van a otro sitio sin montar un drama.
Todo lo demás
Y en último lugar es importante todo lo demás. Escribir buen software, mejorar como desarrollador día a día, mejorar nuestro nivel de inglés para comunicarnos y aprender de otros desarrolladores, aplicar calidad y entrega continua, autoformarnos en nuevas herramientas para que con criterio, las podamos utilizar cuando sea el momento y contexto adecuado.
Personalmente, algo que últimamente me parece importante es volver a repasar conceptos y mejorar mi nivel de matemáticas. Al margen de todo el postureo relacionado con algoritmos (otra moda-pesadilla), mejorar en esto viene muy bien para comprender cómo funcionan algunos sistemas y tras años de experiencia programando se ven de otra forma los conceptos que cuando los estudiábamos no los veíamos para nada útiles. También es útil para delegar trabajo en matemáticos que se encarguen de idear los algoritmos que implementemos en nuestras aplicaciones o software.
Considero también importante dominar otros campos y tener hobbies. Nos dan perspectiva, conocemos a gente distinta y salimos de nuestra zona de confort.
De hecho veo importante conocer otras personas muy distintas del mundo del software, creo que nos pueden dar puntos de vista e inspiración que nos hacen mejores desarrolladores aunque no seamos plenamente conscientes de ello.
