Como ser un buen developer ?

Todos soñamos alguna vez ser buenos programadores como Linus Torvalds, Fabién Potencier, Rasmus Lerdorf, James Gosling o Guille Rauch, pero para ser sinceros ellos no son buenos programadores, ellos son unicornios, nacieron con ciertas capacidades y/o oportunidades que muy difícilmente la mayoría podamos llegar a tener.

Hace poco leía sobre los fundadores de Google, Serguéi y Larry, Sergei es hijo de científicos rusos, la madre trabajaba en Goddard Space Flight Center de la NASA y el padre era profesor de Matemáticas en la Universidad de Maryland. La madre de Larry era profesora de programación en la Universidad de Míchigan y el padre fue profesor de Ciencias de la Computación e Inteligencia Artificial de la Universidad de Carolina del Norte en Chapel Hill y de la Universidad de Míchigan, un pionero y autoridad en el campo de la Inteligencia Artificial. Tenían de donde inspirarse los muchachos no?

La verdad que ellos son mucho mas que buenos developers, por eso son tan destacados, no todos podremos ser como ellos. Varios tienen como el ideal de buen developer estos estereotipos, la verdad que no es cierto, ser un buen developer no requiere taaaaanto.

 

La industria

Después de varios años en la industria me di cuenta de ciertas verdades.

La primera es que la industria no es plana y el trabajo de developer no es único, hay developers que trabajan en empresas de servicios, otros que trabajan en empresas de productos, otros que trabajan freelance, otros que trabajan para ONGs, otros que trabajan para el estado, otros que trabajan para organismos sobre sistemas específicos (bancos, retails, etc), es imposible medir con la misma vara a todos los developers.

Las capacidades como developers dependen mucho de las oportunidades que se nos presentan (y que generamos), entre antes comencemos a codear mejor, si ya sabemos ingles de antes mejor, si estamos en Silicon Valley donde hay 2 startups por cuadra con challenges increíbles es mejor que un lugar donde solo hay empleos públicos y lo que mas se hace son reportes y ABMs. El contexto nos forma y limita, si o si.

La industria no gira en torno a la tecnología, gira en torno a las personas. La mayoría de los problemas se solucionan hablando, escuchando y negociando, no poniendo más y más plata en tecnología. Las personas de sistemas suelen tener esta falta de soft skills, por ellos las areas gerenciales suelen estar desconectadas de las areas de sistemas, los gerentes toman desiciones sobre sistemas sin consultar a su gente de sistemas (en todos lados pasa).

La tecnología es fácil, lo difícil son las personas.

Muchos esfuerzos de development se pierden por mala compresión de los requerimientos originales, la gran mayoría de los esfuerzos diría yo.

En sistemas, el cliente no siempre tiene la razón, hay que saber negociar, todo el tiempo estamos negociando. Muchos bugs se cierran simplemente hablando, 0 lineas de códigos involucradas.

Computer Science no es Engineering, los capos que generan lenguajes, frameworks, patrones, metodología son personas que se dedican a las Computer Science, el ingeniero usa esos estudios para hacer cosas reales de todos los días para la gente. Un ingeniero puede hacer un lenguaje de programación?, si podría, también un niño de 8 años.

Startups !== Organismos Públicos !== Empresas Privadas !== Empresas de Servicios !== Empresas de Productos !== Empresas Multinacionales.

Todas son diferentes, cada una necesita un tipo particular de developer, Rasums Lerdorf difícilmente quiera / pueda / sirva trabajando en el Banco Nación, pero si en una Startup que esta innovando en como vender más y mejores zapatos online con PHP. Debemos buscar donde encajamos mejor.

 

La pregunta que les hago es, ¿que es necesario para ser un buen developer?

Si miramos lo que las empresas buscan veremos que ellos NO saben que es lo que necesitan, buscan generalmente gente con conocimientos en un lenguaje en particular y años de experiencias sobre una plataforma especifica, alegando Señoritis para decir “que tanto debes saber”.

A la hora de la entrevista te hacen preguntas chetas pre fabricadas sobre patrones, objetos, librerías o frameworks que si lees todos los días la revista users o saliste ayer de la facu te las las sabes de memoria.

Si bien es la forma que se hace y nadie se fundió todavía por seleccionar personal de esta forma, no es la mejor pero funciona, por que eso que piden es una condición que surge de otras aptitudes que yo creo son las fundamentales.

UPDATE: En 42mate desde hace unos años, después de escribir este post, hemos decidido sumar estas preguntas “chetas” en las entrevistas por que nos dimos cuenta que la gran gran mayoría nunca siquiera las vio o las pensó (osea, leen poco, se involucran poco), consideramos que si puede responder las preguntas clásicas ya tiene un punto positivo. De todas formas sino lo hace, tratamos de ver como piensa y como puede llegar a la conclusión de la respuestas, lo ayudamos a llegar a la conclusión, de esta forma vemos como piensa y si puede conectar los puntos. Al final, esta es una de las tantas cosas que evaluamos para decidir si aceptamos o no a la persona para sumarse al equipo. 

 

Entonces ¿qué debe tener un buen developer?

Creo que esto es lo fundamental

• Un buen developer tiene pasión por lo que hace, ama lo que hace, por eso lee, se informa, prueba tecnologías nuevas, suma experiencia.
• Soluciona sus problemas cotidianos con tecnología, y si puede codearlo mejor.
• Es buen comunicador, tanto para expresar sus necesidades como para ayudar a los pares en necesidad.
• Sabe escuchar y entender lo que se necesita que haga.
• Sabe negociar, negocia requerimiento, bugs, estimaciones, planes, etc.
• Sabe estimar, es fundamental que pueda estimar con certeza cuanto tiempo tardará en hacer una tarea.
• No es un rock star, es un jugador de equipo. Primero esta el equipo y el proyecto, después esta el.
• No tiene miedo al cambio, sabe que es la única constante, lo acepta y trabaja para ello.
• Sabe que el objetivo no es solo cerrar tickets, el objetivo cumplir con lo que el equipo se comprometió.
• Trae soluciones, no problemas. Cuando surge un problema tiene un as bajo la manga para solucionarlo.
• Se preocupa por las pequeñas cosas, no subestima nada.
• Quiere entregar un producto estable y útil para el cliente, no se preocupa por solo tener 0 bugs.
• Tiene el NO fácil, NO es la mejor herramienta para cerrar bugs antes que aparezcan, acordate de KISS y YAGNI.
• Conoce la importancia de testear, y realiza tests (automáticos o no, testea).
• Se organiza, sabe manejar prioridades, sabe que es lo mas importante, que se puede postergar, cuando hay que alarmar.
• Es honesto, para con sigo mismo y con el equipo.
• Sabe hacer preguntas especificas.
• Sabe pedir ayuda.
• Conoce sus limitaciones.
• Sigue las buenas prácticas, pero es lógico.
• Se involucra en las comunidades.
• Sabe de redes y hardware.
• Escribe soluciones, no código.
• Conoce su lenguaje/s y maneja las herramientas de su ecosistema, (si, también tenes que saber codear bro).
• Un buen developer sabe que ganar dinero es una consecuencia de hacer lo que bien le gusta, y como sabe que es bueno se hace valer.

Sinceramente, esto cae a reflexión por que durante muchos años estuve muy focalizado en el código y tanto pensar en el código me distrajo de cosas más importantes, como la solución. Me hubiese gustado entender estos puntos de vista mucho antes.

Como hacemos para meter esto en un proceso de selección ? …. todavía no lo sé, cuando lo descubra escribiré otro post, se aceptan ideas 🙂

Críticas ? Comentarios ? …. bienvenidos