Mi carrera en la programación comenzó de una manera extraña, lo único que estudié formalmente relacionado con alguna tecnología en particular fue Java (más allá de la universidad), por esas cosas del destino nunca pude conseguir un trabajo en Java y entonces me interesé por lo relacionado con Microsoft, asp 3, VB6 y también .NET y ahí comencé a trabajar y ganarme la vida como programador.
Luego de variadas experiencias ya trabajando con .NET allá por finales de 2006 comencé a participar de la lista de Agiles Spain desde Argentina, fue así que me puse al tanto de todo lo relacionado con las prácticas ágiles.
Entonces en 2008 hubo un quiebre, participé de la organización de las primeras jornadas de desarrollo ágil de latinoamérica en Argentina y fue cuando realmente creció mi interés por "hacer las cosas bien" y por olvidar los paradigmas de libros como el de Pressman.
A partir de allí hice varias cosas ligadas con lo relacionado con las buenas prácticas y el aprendizaje, organicé otros eventos, di muchas charlas, participé de altnet hispano y hasta di clases en la Universidad.
Puedo decir que trabajé de muchas maneras y aprendí de todo eso, he visto muchos tipos de empresas y muchos tipos de programadores, he tenido la suerte de compartir con gente muy talentosa y generosa con su conocimiento.
Para contactarme mi twitter es @leomicheoni y tengo un blog personal
El truco es que la programación puede parecer fácil, es decir, es sencillo escribir un hola mundo, pero desde ahí hasta hacer una aplicación hay mucha diferencia, creo que tal vez sea la profesión en la que las cosas parecen mucho más simples de lo que son con más frecuencia; a todos nos ha pasado que nos pidan un cambio minimizando la dificultad real del mismo. Y a todos nos ha pasado el subestimar una tarea.
Por eso creo que no cualquiera puede programar...sin ciertos conocimientos, es fácil caer en la trampa de hacer algo y pensar que uno ya es un programador, programar es difícil, como tocar la guitarra bien lo es, claro, cualquiera puede tocar un par de canciones y creer que es un buen guitarrista, pero tocar, lo que se dice tocar, requiere estudio, persistencia, práctica y paciencia.
Otro problema es que aparecen "cosas" nuevas todo el tiempo, si bien la mayor parte del desarrollo se sigue apoyando en las mismas bases de hace 20 años con algunas variaciones, es difícil no dejarse llevar por la moda del momento, hace falta experiencia para no subirse a "la nueva ola" cada dos meses.
Del lado de las habilidades técnicas yo creo en ser metódico y confiar en los métodos que uno aplica, digo esto porque es común ver que hay programadores que no soportan seguir los pasos lógicos del desarrollo, hacer las cosas bien en general es más lento que hacerlas mal (al menos da esa sensación) y al no confiar en los métodos y que estos los van a llevar a un mejor resultado toman el camino fácil (o más simple en su mente) hacer las cosas mal y a las apuradas. Con la experiencia uno va comprendiendo cuán bien merece la pena hacer algo dadas las circunstancias actuales.
No creo que uno tenga que ser apasionado para ser un buen programador (no digo ser un crack, sino ser bueno), siempre que escucho esto pienso en Gabriel Batistuta quien ha llegado a decir que para él el fútbol era solo su trabajo, pero llegó a ser goleador de la liga Italiana y el segundo máximo goleador de la selección Argentina (fue el primero hasta que llegó Messi). Por supuesto que si te gusta mucho mejor, vas a superar al que no le gusta, como a Messi. Pero con ser un buen profesional basta para hacer muchos goles.
Tampoco creo que haya que tener pasión para ser bueno programando. Una vez dije que un programador es tan artesano como lo eran los romanos que construyeron el Coliseo...o sea nada; no somos artesanos, tal vez obreros calificados, los artesanos hacen cosas con inspiración, más o menos como ellos quieren, nosotros tenemos que seguir reglas y ajustarnos a tiempos y presupuestos.
He hecho muchas cosas en software, de hecho comencé programando en assembler, programé controladores de tránsito también así que no creo tener un perfil definido, además de programar me gusta el diseño, he hecho front end y backend casi por igual pero no soy especialista en nada, soy más bien un programador de uso general orientado al desarrollo web.
Yo soy de los que creen que el aprendizaje formal (ir a la universidad por ejemplo) sí aporta valor si bien se puede ser un gran programador sin él. De todas las cosas que se pueden saber yo jamás recomendaría un framework o librería, para mí lo que va a llevar al conocimiento sustentable es el conocer las bases.
-
Conocimientos de base: Estoy totalemente convencido que es mejor comprender que recordar, en el desarrollo intervienen tecnologías y muchas nuevas que van a apareciendo, pero como dije antes, los principios en los que se apoyan son los mismos o son variantes de los mismos, conocer las bases nos ayuda a adoptar lo nuevo y nos da herramientas para solucionar problemas.
-
Paradigmas de programación: Hay muchos y cada uno tiene sus ventajas y desventajas, en mi caso uso mucho C# que es de uso general basado en POO con algunas cosas de funcional. También uso mucho Javascript que es prototipado. Es muy útil conocer cómo se hacen ciertas cosas en otros lenguajes, ayuda e cambiar la perspectiva de los problemas, un buen libro para esto es "Seven Languages in Seven Weeks"
-
El lenguaje que uno utiliza: No creo que conocer cada uno de los detalles del lenguaje sea necesario, pero tener presente la mayoría de las posibilidades, por ejemplo si al declarar una clase los métodos son virtuales o no, conocer cosas como el funcionamiento básico del Garbage collector, y antes de escribir una clase de utilidad por nosotros mismos buscar si nuestro lenguaje ya hace algo similar (que es lo más probable).
-
Modelos relacionales de datos: Conocer cómo hacer queries SQL, poder analizar un plan de ejecución, saber algo de optimización a mí me ha sido muy útil en optimizaciones de rendimiento.
-
Modelos NoSql: Comprender diferentes modelos de bases no relacionales (CAP), ventajas y desventajas para tener opciones a la hora de pensar en una arquitectura.
-
HTTP: Hoy en día pocas aplicaciones no usan internet o una red, conocer HTTP a un buen nivel es escencial, los métodos más importantes, cómo funciona la caché, cómo las cookies y demás cosas, conocer Fiddler o Postman, saber hacer un request a mano, no lo vamos a hacer todos los días pero nos ayuda e comprender por qué las cosas son como son.
-
Cómo funciona un servidor web: Hoy en día hay varios enfoques y dependiendo de qué estemos haciendo el modelo de ejecución puede ser diferente, comprender esto y poder (leyendo la documentación) comprender cómo configurar un servidor es muy importante, la forma en que se ejecutará la aplicación en el servidor web puede tener impacto en el desarrollo o en decisiones de diseño.
-
El DOM del navegador: Si uno es desarrollador web no puede pasarse la vida desconociendo qué pasa por detrás cuando hacemos un binding en Vue.js, conocer el DOM es importante.
-
Prácticas de código límpio: Tener presente y repasar los principios de código limpio es escencial para construir bien y poder mantener, para volver sobre lo hecho y poder leer como una historia nuestro código.
-
Patrones: Conocer y comprender los patrones más utilizados en el lenguaje que uno usa es muy útil y ayuda a comprender el código de otros y plantear soluciones, son herramientas que usaremos o no, pero es necesario conocerlas.
-
Diferentes formas de testing: Es necesario al menos conocer de qué se trata TDD, cómo se puede hacer una prueba de UI, una de integración, como automatizarlas.
-
Control de versiones: Es casi una locura no utilizar control de versiones, conocer al menos un par de ellos y saber hacer las cosas escenciales es determinante, es necesario para organizar nuestro trabajo.
-
Integración continúa: Al menos comprender qué es y poder comprender qué hace un entorno ya configurado.
-
Automatización: Conocer de automatización es un extra, pero ayuda mucho, los programadores somos perezosos por naturaleza, todo lo que es repetitivo en algún momento lo terminamos automatizando con un script.
-
Balanceo de cargas, proxies, cache, nube, servidores, etc.: Es un área más de la gente de IT, pero tener un conocimiento mínimo del impacto de utilizar un balanceador de carga en nuestra arquitectura puede ser crucial, comprender que si hay cachés en medio eso tendrá impacto en nuestro aplicación.
-
Inglés: Siendo realistas si no sabemos inglés nos vamos a perder de mucho, hay infinidad de material que no existe en otro idioma.
-
Prácticas y herramientas ágiles: SCRUM, Pomodoro, Kamban, retrospectivas, etc. todas estas herramientas nos serán útiles en el día a día, estoy convencido que las prácticas ágiles son la mejor marca para el desarrollo hoy en día.
-
Leer: Leer código de otros ayuda a aprender y a hacernos preguntas a nosotros mismos, es un buen ejercicio mirar el código de algún framework o librería que usemos, o simplemente código de un colega para ver otras formar de hacer las cosas.
-
Practicar: Si uno quiere destacar es necesario mantener ciertas habilidades siempre frescas, por desgracia no siempre nos toca un proyecto en el que podemos hacer TDD, automatizar, hacer queries SQL, aplicar patrones, etc. Entonces no nos queda más que practicar, cómo? haciendo katas de código, es muy estimulante y nos mantiene con la mente abierta.
-
Referentes: Seguir en twitter, leer blogs, participar en listas de correos, estar en contacto con referentes de las distintas áreas o tecnologías nos permite aprender de primera mano hacia dónde va la cosa y estar en contacto con gente experimentada o con visiones diferentes.