DEV Community

Cover image for Desarrollar no es solo código
Nehuen Covelo
Nehuen Covelo

Posted on

Desarrollar no es solo código

El pensamiento común que la gente suele tener es que la tarea de un desarrollador es prácticamente solo programar lo que se le pide, y mi idea con esta lectura es un poco mostrar que no se trata solo de escribir código todo el día. Explicar para los que no han desarrollado una solución, o que no tienen tanta experiencia todavía en el rubro, el desafío que significa mejorar en este tipo de trabajo. Muchos han entrado porque se "paga bien", y se han encontrado con picos de frustración y stress que a veces pareciera que no lo valieran. Justamente no es solo escribir código, o como dicen muchos "copiar y pegar código de stack overflow", sino que se debe adquirir la mayor cantidad de conocimiento sobre la solución y los contextos en que se la debe usar. Y casi todos los conocimientos por fuera del aspecto técnico, muchas veces categorizadas a grandes rasgos como "reglas de negocio", son específicos de la empresa y/o rubro para el que trabajemos. De esta forma el trabajo como desarrollador puede ser muy variable, y personas que trabajan con los mismos lenguajes de programación pueden estar aplicándolo para situaciones extremamente diferentes, al punto que no podrán cambiar el código del otro sin tener un tiempo para incorporar y entender todo lo que se construyo antes.

Foto de Oren Yomtov en Unsplash

Antes de empezar a leer: Muchas cosas que escribo pueden deprimir a alguno que esté pensando en dedicarse a esto, pero también tómenlo como mi experiencia en este rubro, siendo una visión totalmente subjetiva. Puede ser que escuchen de otras personas algo totalmente diferente, como que es súper fácil, aprendes a programar y ya esta, no tenés que hacer ninguna otra cosa. No es mi intención destruir sus esperanzas, pero si destruir un poco esa visión simplista de este trabajo, la cual ha frustrado a muchos y ha engendrado monstruos(influencers), que al final no saben desarrollar, pero si vender la realidad ideal de "ser un desarrollador es lo mejor". Entonces, si probaste programar, y te gusta, termina siendo muy satisfactorio trabajar de esto, pero solo si sabes las horas de estudio y práctica que conlleva.

Lo básico para desarrollar

Esta sección es parcialmente omitible, pero no esta de más decirlo. Para desarrollar es necesario conocimiento en uno o más lenguajes de programación, y principalmente saber que no será el único que aprendamos, que será algo seguro que tengamos que aprender cosas específicas para cada entorno que vamos a trabajar. Es un rubro donde no existe un "esto es lo que siempre funciona", y siempre existe una necesidad de innovación. Lo cual significa que para uno progresar en este área es necesario acostumbrarse aprender cosas nuevas, sobre todo a nivel técnico.

Voy a parar a dar un aviso para aquellos que quieran empezar su carrera como desarrolladores, o ya estén haciendo algún curso/capacitación. No existe ningún tipo de capacitación que les certifique que ustedes "saben desarrollar", así como también ningún título universitario en Ingeniería los convierte automáticamente en Senior. Me parece bien, y apoyo, que la gente haga capacitaciones y/o estudie carreras formales, pero sepan que para el área de desarrollo necesitan más que eso. No esperen ser contratados, ni menos aún ser el mejor desarrollador/programador, por tener terminado un curso hecho online. No paren de estudiar y practicar una vez que terminan alguna capacitación, tienen que seguir desarrollando soluciones aunque sean videos tutoriales. Y lo más importante es no "copiar y pegar" lo que hacen los videos, es que realmente intenten entender por qué escriben el código que escriben. Antes de empezar a pensar en trabajar, sepan que no tienen que saltearse la parte de practicar mucho, porque aunque muchas cosas a nivel técnico vayan a aprenderlas con el mismo trabajo, es necesario que tengan una base sólida de conocimientos básicos. No piensen que tener hecho un curso de introducción a la programación va a ser suficiente, porque hacer un for loop no va a servir de mucho si no sabes en qué situación y para que cosa querés aplicarlo.

Como para no terminar este bloque con un sabor amargo, la alta demanda de desarrolladores es real, pero no buscan cualquier tipo de desarrollador, no buscan a uno más del montón que termina una capacitación, justamente hay un alta demanda por contratar desarrolladores competentes, que sobre todo no les dé miedo aprender cosas nuevas.

Lo básico para trabajar

Obviamente hay un checklist casi obligatorio a completar, como: portafolio o repositorio con código de nuestra autoría, tener un perfil en LinkedIn y un CV actualizado. Saber que las primeras entrevistas sean difíciles, y que probablemente no haya siquiera un feedback de las mismas(es lo que suele pasar). Si no tuvieron experiencia laboral todavía, definirse como fullstack puede ser un error muy grande, y lo que los ayude a estar más tiempo sin encontrar trabajo. Lo que yo siempre recomiendo es que se definan en especializarse en Frontend o Backend, porque en la práctica ser fullstack y saber hacer algo realmente requiere de mucha experiencia y conocimientos, entonces ser fullstack y no tener experiencia para muchos significa que no sabes ni de Front ni de Back. Además de que son muy pocas las empresas que emplean fullstack, y que llegado el momento realmente se desempañan como fullstack. Obviamente acá va a entrar un montón de gente diciendo "Ah no, porque la empresa X, Y y Z buscan fullstacks", puede ser, pero no van a contratar fullstacks que no sepan tengan una base mínima de conocimiento en las dos áreas. Y sepan también que las búsquedas laborales suelen ser hechas por gente que no sabe nada de los conocimientos técnicos que realmente se piden, y al llegar a la entrevista lo que quieren es un Fullstack barato, Junior o trainee, pero que tenga un mínimo de conocimiento como si fuese SemiSenior.

De las cosas más fundamentales para empezar un trabajo como desarrollador es mostrarse predispuesto a aprender, y sepan que lo van a necesitar. Sobre todo el primer tiempo no van a hacer código, o si lo hacen será muy poco. Las primeras dos semanas sobre todo, tendrán que empezar a ver los procesos que tenga la empresa, lo que sea referido a la producción de código(tests, PR review, deploy, etc.) y también a los procesos administrativos(solicitar tickets a otros equipos, solicitar vacaciones a RRHH, etc.). Además, y lo más importante, tendrán que hacer la instalación de todo el ambiente y software necesarios para desarrollar, lo cual suele ser un fastidio hasta para los desarrolladores más experimentados. Mientras hagan todo esto, van a tener dudas, no hay forma que no les pase que van a instalar alguna cosa del ambiente local y va a romperse porque van a faltar las variables de entorno(FACT). No tarden en preguntar, apenas tengan alguna duda vayan al grupo general de su equipo de desarrolladores y pongan lo más detallado lo que hicieron y muestren donde es que les dio error, y sobre todo muy importante: Digan(o compartan una screenshot) cuál es el error que les dio. Siempre, ante cualquier error, cuando vayan a solicitar ayuda por favor pongan que error están recibiendo, muchas veces es algo medio tonto y cuando una persona ve lo que estás recibiendo de error puede darte una respuesta mucho más rápida sin tener que esperar. A los desarrolladores no les molesta que les pregunten y pidan ayuda, pero intenten recordar lo que hicieron para solucionar un problema, si es necesario anótenlo en una libreta o algo, porque de esa forma ustedes van a poder ayudar a otro nuevo compañero que llegue al mismo error. Lo que si es molesto, y lo digo por experiencia propia, es que todos los días pregunten justamente por el mismo error, en la misma situación con las mismas condiciones.

¿Los desarrolladores siempre los van a ayudar que fuese posible? Sí. Pero es importante aprender a solucionar algunos problemas, sobre todo a nivel código. Cuando empezamos a ver el código con el que trabajaremos en el día a día probablemente usemos tecnologías y librerías que nunca escuchamos nombrar, y no tenemos ni idea de como funcionan. Es importante que estudiemos un poco esas tecnologías, al menos buscar un videotutorial de para qué sirve, para anticiparnos un poco al momento de cuando tengamos que hacer algo con eso. Si no empiezan a anticipar las tecnologías que necesitan aprender, van a quedar si o si esperando la ayuda de algún otro desarrollador todo el tiempo, el avance para interiorizar esa tecnología va a ser mucho más costosa. El no hacerlo, hará que sean una carga para el equipo. Aunque volviendo al punto anterior, no tengan miedo en pedir ayuda, hay problemas que realmente puede ser algo que no esté funcionando bien, o que esté mal planteado. Solo estén seguros de agotar algunas opciones antes, como por ejemplo hacer una búsqueda en Google con el problema que tenemos.

Lo básico para dejar de ser un básico

Acá ya son avances que tendrán que hacer como desarrolladores, y no necesariamente al principio de su carrera, para entrar en categorías como Semi Senior por ejemplo. Es importante marcar que no existe algo que pueda decir "sos Junior" o "sos Semi Senior" absolutamente, puede que haya grises, que estén en más cerca de uno o más cerca del otro. La diferencia principal está en la capacidad para resolver tareas sin necesidad de ayuda/supervisión directa, y esta característica aplica ampliamente al terreno técnico. Por lo cual es necesario evaluar otras características, sobre todo cuando quieran ser promovidos en la misma empresa que están trabajando. Una muy importante es interiorizar las reglas de negocio, o sea entender los requerimientos generales que tiene el sistema a nivel negocio. A la empresa no le va a servir promocionarte de su lado si después de un tiempo todavía no aprendiste siquiera lo básico de como funciona el producto en el que trabajas, y es necesario todas las veces utilizar un tiempo para explicarte contexto de la tarea. Conocer el producto, y entender la idea del mismo, es muy importante para avanzar y ser más eficiente en tu trabajo. Y por último quiero nombrar una característica muy necesaria en los desarrolladores más avanzados(que no siempre está presente) y que es vital para desarrollo del equipo, ser proactivo y saber como ayudar. Quiero parar a reflexionar en el como ayudar, porque hay una diferencia ínfima, pero muy importante que puede ayudar a que un equipo sea un equipo increíble, o un equipo tóxico. Para lo cual voy a plantear la misma situación, donde otro desarrollador tiene un problema que no puede resolver, y yo sé como podría ser resuelto(sea porque ya tuve el mismo problema, o tengo el conocimiento suficiente para lograr destrabarlo). Yo resuelvo el problema, y al enviarle la solución puedo:

  • No explicarle por qué hice lo que hice, evitar que me pregunte por qué o como llegue a ese arreglo, enviar la solución sin avisarle, etc.
  • Darle una breve explicación de lo que pensé, explicarle que era lo que estaba confundido o donde estaba haciendo mal, proponer diferentes soluciones para considerar, etc.

Son dos formas totalmente diferentes de llegar al mismo resultado donde se resuelve el problema, pero que alimenta una cultura buena y cooperativa, o una tóxica y egoísta. Resalto este último punto porque no dejamos de ser personas en lo laboral, y las actitudes que tengamos afectan de una forma u otra al equipo de trabajo.

Como ser un desarrollador completo

En este bloque intentaré apuntar algunas características que yo espero encontrar en lo que sería una persona Senior. Para lo cual es necesario marcar que la diferencia de experiencia y conocimientos entre Senior y SemiSenior, es mucho más grande que la que existe entre Junior y SemiSenior. Y sinceramente, lo que muchas veces se espera de una persona Senior es algo totalmente diferente a alguien considerado SemiSenior, debido a que los conocimientos más profundos y necesarios son a nivel infraestructura, y no tanto del código que pueda producir. O sea, ¿Un Senior no escribe código? Si, también escribe código y se espera en la gran mayoría de los casos que lo haga, y que lo sepa hacer con un nivel también muy bueno. En los casos que no se escriba código estaríamos hablando de un trabajo como Arquitecto de Soluciones, o algo por el estilo.

De un Senior esperamos:

  • Que tenga un conocimiento amplio de la infraestructura que utiliza para desarrollar sus soluciones, tanto a nivel productivo como del entorno de desarrollo. Que pueda modificar esos entornos de desarrollo, y que en caso de ser necesario adaptarse a una nueva infraestructura.
  • Que pueda diagramar punta a punta cuáles serán los servicios y/o flujos necesarios para satisfacer una nueva necesidad de negocio, a veces conocido como "System Design"(no confundir con Design System). Y cuando se solicitan modificaciones estructurales de un producto o servicio, por lo menos tener una idea de donde debe llevarse a cabo la modificación.
  • Saber delegar tareas, porque un Senior en teoría tendría que poder hacer todo, pero física y temporalmente no es tan fácil. Tiene que tener una mínima idea de cuál es la dificultad que conlleva hacer cada tarea, de esa forma será fácil saber que personas podrán ejecutarla según el seniority y experiencia de cada uno.
  • Entender los límites que existen, a nivel infraestructura, código, tiempo, servicios, etc.
  • Que sepa transmitir conocimientos, a través de documentación o dando mentoría directa a otros desarrolladores. Lo cual es esencial para el desarrollo del equipo como un todo.
  • Poder entender la viabilidad técnica para realizar una tarea. Porque no será nunca el fin de solicitudes de misiones imposibles de los stakeholders.
  • Amplio conocimiento en diferentes patrones, paradigmas y organización de código. Porque una persona con muchos años de experiencia diciendo que Java con POO es lo único que necesitas, es probablemente un tiro en el pie.
  • Ser una persona(opcional).

¿Por qué cierro la lista de esta forma? Sencillamente porque lo que realmente se suele espera de un Senior es mucho, y sobre todo pensando que hoy en día se espera todo eso de una persona que tenga mínimo 4 años de experiencia laboral, para lo cual puede no ser tiempo suficiente para lograr tener un check en cada una de estas cosas. Esto seria desde mi perspectiva un Senior ideal, para lo cual he tomado de referencia los pocos ejemplos reales con los que he tenido el gusto de trabajar. Así como también tengo un montón de ejemplos negativos de muchos que me costaría siquiera encasillarlos siquiera como SemiSenior. Para lo cual es necesario saber que el seniority de una persona siempre estará dado desde la perspectiva de quien lo analiza, en este caso yo soy más minucioso y exigente en las características que uno debe tener para cierto Seniority. Las empresas en general usan otras cosas, como por ejemplo el tiempo de experiencia laboral, donde hay casos que de empresas que piden que un Junior tenga 2 años de experiencia, u otras que piden un Senior con solo 4 años de experiencia. En mi caso no utilizo mucho como referencia el tiempo laboral(excepto que sea caso muy extremo, no hay forma que alguien sea Senior con solo 2 años de experiencia), porque he visto casos, me atrevo a decir que muchos, donde gente que tiene 10 años o más de experiencia no puede llegar a plantear soluciones simples y básicas. Me refiero a que haber estado 10 años desarrollando landing pages(solo hacer maquetado y alguna que otra llamada a un backend para enviar un formulario), no puede automáticamente convertirte en Senior, o como mucho serás Senior en maquetado de páginas institucionales.


TL;DR:

El trabajo como desarrollador va mucho más allá de saber principios básicos de programación, aunque aprender eso sea un comienzo para esta carrera. Para desarrollarse como profesional en este área exige capacitarse y aprender más que una única tecnología, y para lo cual no existe un curso que los deje listos para trabajar. La alta demanda de desarrolladores es real, pero no significa que contratan a cualquier persona que tenga hecho una simple capacitación, tienen que crear y mantener un portfolio y/o repositorio con varios proyectos que demuestren su conocimiento.
Una vez en su primer trabajo, deberán adoptar ciertas actitudes si es que no las tienen todavía para poder adaptarse mejor al rubro, como solicitar ayuda siempre que no podamos resolver un problema y ser más proactivos al momento de alguien tener inconvenientes. Y entre los diferentes Seniorities(Jr, SSR, SR) se pueden remarcar cuáles son las diferencias esenciales que hay entre ellos. La diferencia de Junior a SemiSenior es más fluida y acotada, pero hay un abismo de conocimientos y características que difieren a un SemiSenior de un Senior.

Top comments (0)