Hace no mucho en Twitter se revivió un debate que, por lo que he visto, lleva tiempo dando vueltas dentro del ecosistema tech. La pregunta del millón es: ¿se puede ser ingeniero de software sin ir a la universidad o, lo que es lo mismo, sin tener un título que lo avale?

He notado que las opiniones son bastante opuestas: algunos responden con un tajante “no”, y otros creen (hablando desde su propia experiencia) que es posible triunfar y tener una carrera exitosa en el mundo IT sin contar con un título universitario. Es más, hay gente que llega a afirmar (aunque son los menos) que la universidad es una estafa y que no sirve para el mundo laboral actual.

Hoy por hoy no estoy en posición de brindar mi respuesta a este debate. Creo que me falta experiencia laboral para decir qué es mejor (suponiendo que existiese una respuesta definitiva, lo cual no creo). De lo que sí sé es sobre ser autodidacta, algo que vengo practicando desde poco más de 2 años. Estoy familiarizado con los desafíos que conlleva autoenseñarte: el sentirte abrumado por la cantidad de conocimiento que hay para adquirir, el pensar que no estás avanzando o que no sabés por dónde ir a continuación. Y en todos estos escenarios, es muy probable que la ansiedad cobre protagonismo. De hecho hablo de eso en este otro post y lo que hago para combatirla.

El punto es que hay personas dentro de este rubro que se vuelven absolutamente puristas e intentan tirarte abajo si es que no tenés un background universitario. Vaya uno a saber el motivo: sea por que tienen miedo a que las nuevas generaciones “le serruchen el piso”, o porque creen que los años de experiencia son una excusa para dejar que su ego los controle. De modo que autodenominarte “ingeniero de software” (o siquiera developer) es una herejía y una blasfemia para estos sujetos.

Puedo entender que haya gente sin experiencia que sea vaga e irresponsable, que no sea diligente ni que tampoco sea buena para colaborar. Pero de esos hay en los dos “bandos”: graduados y no. El punto es que para algunas de las personas con título, los “sin título” dan mala reputación a la industria. Y hasta hablan de que se debería regular el término ingeniero para así eliminar a los “impostores”.

Interiorizándome un poco más en todo este debate, me topé con un vídeo en YouTube de un canal que recomiendo mucho llamado Travis Media. En uno de sus tantos videos, que considero son excelentes, se habla sobre este asunto. Travis, el creador (quien no tiene un grado en Computer Science), llama a los devs sin universidad así: non-traditional developers (developers no tradicionales).

Sí, es una referencia a “Los Simpson”, pero volviendo al tema: mas allá de si tenés la posibilidad (o las ganas) de ir a la universidad o no, el camino autodidacta jamás termina. No hay una meta final ahí a lo lejos donde alcances la iluminación y en el camino hacia la trascendencia te vuelvas uno con el universo y empieces a levitar ya que aprendiste todo lo que hay para aprender acerca de la informática y la programación.

Incluso consiguiendo tu flamante título (si estás graduado, dejame felicitarte!), es importante que sigas actualizando tus conocimientos para mantenerte competente y relevante en el mercado si es que estás trabajando.

Ahora bien, ¿estás condenado por no tener título universitario? Por suerte para vos, y para mí también, no. De eso se trata este artículo. A veces no solamente es importante saber qué hacer bien, sino también qué errores evitar. No tendrás título, pero que eso no te impida ni sea una excusa para no mejorar y producir código de calidad.

Basándome en el video de Travis Media, te comparto un resumen y traducción del mismo, donde vamos a hablar de las 5 señales de falta de experiencia como developer autodidacta, y cómo solucionarlo. Arranquemos.

Solamente pensar en que tu solución funcione está bien al principio. Como es obvio, lo importante es que lo que estés codificando funcione, pero quedarse solamente en eso no es suficiente para ser un buen programador.

Si estamos encarando un proyecto por cuenta propia, o al resolver una tarea en el trabajo, a veces sentimos esa urgencia de querer abrir nuestro IDE de confianza y empezar a teclear. Spoiler: eso es un error.

Es importante hacer algunas observaciones primero, algo que de lo que me di cuenta hace relativamente poco. Hay que ejercitar el pensamiento analítico y matemático, comprender primero qué se está pidiendo de nosotros, analizar requisitos, etc.

Y esto tiene mucho sentido. Pensá que el proceso de desarrollo de software consta de 5 pasos. ¿Sabés en cuál lugar está la codificación? No en el primero, ni en el segundo. Recién el tercero. ¿Qué está antes? Especificación y diseño. Hay que investigar para luego definir la funcionalidad, características técnicas y condiciones de uso de una aplicación.

Tal como se dice en el video de referencia, agarrá un anotador (físico o digital), anotá y diagramá qué es lo que estás construyendo, cuáles son los requisitos y necesidades (lo que te llevará a recabar más información) y entender qué es lo que estás haciendo exactamente.

Ahora bien, ¿y si el proyecto ya está empezado, es decir, ya hay una codebase existente? Aplica igual. Analizá e intentá establecer el mapa mental de lo que estás haciendo mediante anotar los requisitos y necesidades, y pensá cómo puede encajar tu solución con el código existente, teniendo en cuenta la legibilidad, el mantenimiento y la escalabilidad.

Otro error que refleja poca experiencia como developer es introducir muchos cambios en la codebase al mismo tiempo, lo que implicaría que tus PR (pull request) sean enormes y no se pueda entender de manera significativa qué cambios estás introduciendo o proponiendo.

Hay varios inconvenientes en añadir muchos cambios a un proyecto e introducirlos en un solo commit. Uno de ellos es que al haber muchos cambios juntos, se vuelve casi imposible que puedan ofrecerte comentarios u observaciones significativos sobre tu trabajo. También aumentás las probabilidades de introducir bugs o problemas que sean difíciles de diagnosticar, debido a que modificaste muchas cosas al mismo tiempo.

La idea es que una PR contenga una sola feature (característica o funcionalidad) que refleje coherencia y demuestre cohesión. Ahora bien, si la feature es grande, quizá lo ideal sea descomponerla en componentes lógicos más pequeños para evitar introducir muchos cambios de golpe.

Ahora bien, ¿cómo se puede encarar esta situación? Hacé commits con regularidad y testealos. Siguiendo la línea del punto anterior, seguramente al diagramar y especificar los requerimientos del proyecto o funcionalidad, lo más probable es que te hayas armado una especie de “checklist” de pasos a seguir para que tu feature funcione. Cada paso podría ser un commit, y una vez los testeás y veas que este conjunto de commits forman un todo coherente y funcional, ahí podés hacer el push y crear la PR.

Pensalo de esta manera: que tengas varios commits te permitirá a vos y a tus compañeros (en caso de estar trabajando colaborativamente) tener un panorama más claro de qué fue lo que pasó en cada commit y llevar el proyecto a esos puntos en caso de necesitarlo, ya sea para detectar y corregir bugs, o ver con detalle qué cambios se introdujeron.

Algo importantísimo a tener en cuenta y que puede representar un diferencial en tu perfil, es que escribas buenos mensajes para los commits, siguiendo una convención para los mismos. Es algo que vengo practicando en mis proyectos (te invito a visitar mi GitHub para leer mis commits) y, cuando es momento de trabajar colaborativamente con otros developers, algo que propongo tratar en grupo bien al principio de cada proyecto. ¿Te gustaría saber más al respecto? Entonces estoy seguro de que este artículo te va a ser de mucha utilidad.

Esto es algo clásico y me ha pasado personalmente. Estás siempre aprendiendo nuevos lenguajes y frameworks. Ya sea porque es la “nueva moda” o simplemente decidiste aprender algo nuevo, estar aprendiendo constantemente algo nuevo puede ser contraproducente.

En esta industria es importante estar aprendiendo constantemente, eso es cierto. La pregunta de oro es: ¿qué estás aprendiendo? Es mucho más beneficioso aprender los conceptos de la programación y las bases, tal como comento en este otro artículo, y entender cómo funcionan las cosas internamente antes que estar saltando de lenguaje en lenguaje.

Los lenguajes son herramientas, igual que los frameworks. Están diseñados para ciertos casos específicos, por eso no hay una respuesta definitiva a “¿cuál es el mejor lenguaje?”, porque tal como las herramientas, el contexto determina su utilidad. ¿Sabrías decirme si un martillo es mejor que un destornillador? Exacto, depende del contexto.

Sin embargo, entender cómo funciona internamente un bucle for, o una estructura switch es más provechoso que solamente aprender la sintaxis de los mismos en un lenguaje específico. En Python y Java un bucle for se escribe ligeramente distinto, pero funciona prácticamente igual en ambos lenguajes.

La idea es que profundices en un lenguaje o dos máximo, pero también que desarrolles bases fuertes en lógica, algoritmos, estructuras de datos, patrones de diseño, etc., y que cultives la habilidad de aprender leyendo documentación y buscar correctamente en Google y otras fuentes. Si un día te piden hacer algo en una tecnología que nunca usaste, aun así vas a estar prácticamente listo/a para empezar a contribuir productivamente.

Tal como dice Travis en el video (y por eso estoy aprendiendo Java luego de haber pasado por Python), si vas a aprender un lenguaje por el simple hecho de hacerlo, mandate por lenguajes de más bajo nivel como C, C#, Rust o incluso Go. Son lenguajes que van a “forzarte” a aprender ciertos conceptos y operar bajo ciertas limitaciones que realmente van a ayudarte mucho en tu carrera.

Como programador/a nuevo/a seguramente buscas que te vean como alguien competente y eficiente. Pero es importante echar un vistazo a los developers de más experiencia. En este apartado voy a citar textualmente a Travis:

Dios mío, en serio que este error me tocó de manera muy personal. Me reconozco como una persona ansiosa que a veces quiere hacer muchas cosas al mismo tiempo pensando que, mientras más haga, más productivo y eficiente voy a ser y por ende, más conocimiento voy a adquirir. Puede ser verdad hasta cierto punto, pero la realidad es que andar saltando entre varias cosas distintas lo único que va a asegurarte es que no termines haciendo correctamente ninguna, si es que llegás a terminarlas.

Concentrate en una sola cosa. Si estás aún aprendiendo, concentrate en una cosa y aprendela bien. Si estás desarrollando un proyecto, concentrate en ese solo proyecto, entendelo a profundidad y aprendé lo que haga falta según surjan las necesidades y problemas. Una vez completas algo y bien, podés pasar a lo próximo.

Te acompaño en el sentimiento si es que te pasa lo mismo, ya que es una trampa en la que suelo caer con frecuencia, aunque cada vez menos afortunadamente.

Y este es un error que personalmente he cometido y todavía no he solucionado. No voy a dibujarla, ni meter excusas. Me gusta ser honesto, aún si eso supone que me mande a mí mismo al frente. ¿Porqué es importante solucionar esta “mala costumbre”?

Básicamente porque impide que crezcas. Es difícil recibir críticas, y más si estas son algo duras, dependiendo de cómo las exprese quien esté revisando tu código. Pero así como nos gusta que nos alaben por un proyecto o aplicación bien hecho, es importante estar dispuesto a recibir correcciones de lo que estamos haciendo mal o podríamos hacer mejor.

No seas duro con vos mismo/a, sos un junior, y vas a escribir código de nivel junior y una gran forma de progresar es recibir críticas de gente que tenga más experiencia que vos. Incluso si quién hace la crítica lo hace de manera algo despectiva, no dejes que te desanime (más fácil decirlo que hacerlo, obvio) y usalo como combustible para ser un/a mejor programador/a.

Estas fueron las 5 señales del programador autodidacta sin experiencia. Te animo a ver el video original y a que te suscribas a ese canal. El contenido de Travis me parece excelente, muy didáctico y oportuno.

Aun así, con título o no, estos errores pueden ser cometidos por cualquiera. Sin embargo, es bueno tenerlos presentes, particularmente si no contás con un trasfondo universitario, ya que te permitirá destacar como profesional y colaborar productivamente con otros developers. No le des motivo a los "puristas" para que hablen mal de los autodidactas 😉​

Te invito a sentarte y someterte a un autoexamen para ver cuáles de estos 5 errores estás cometiendo y que pongas en práctica las soluciones sugeridas. Estoy seguro de que verás crecimiento en tu carrera y los beneficios te acompañarán por siempre.