DEV Community: MrCodeDev

Consejos en el camino del Frontend Developer

MrCodeDev — Mon, 01 Mar 2021 09:51:50 +0000

El camino del Frontend Developer es largo, son muchas tecnologías las que tenemos que dominar durante toda nuestra andadura. Podemos pensar en todo momento que no somos competentes, y nos puede venir el gran temido síndrome del impostor. También podemos creer que es mucho lo que nos queda por aprender, haciendo que nos desanimemos y en ocasiones, queramos abandonar.

En este artículo, voy a intentar daros unos consejos para el día a día, y también algunas recomendaciones para cuando comencéis en vuestro primer empleo o si sois junior sin tanta experiencia. Todo lo que escriba aquí siempre va a ser desde mi punto de vista y desde mi experiencia.

No dudes en pedir ayuda cuando tienes problemas

Tenemos la percepción de que pedir ayuda cuando empezamos es malo, y debemos de quitarnos este pensamiento. Estamos empezando en algo que es nuevo y no tenemos experiencia en ello. Pide ayuda a cualquier persona del equipo o a alguien responsable que te pueda ayudar que tenga esos conocimientos. Te han contratado en un puesto junior, y lo normal, es que te tengan que echarte una mano.

Pregunta todo lo que no sepas

Podemos pedir ayuda y que nos digan la solución, pero si no entiendes lo que te dicen, no vas a aprender nada. No tengas miedo en decir que no entiendes cierta cosa, hay que realizar un ejercicio de sinceridad plena, y no mentir, ya que, el día de mañana puede ser algo que vaya a ir en nuestra contra.

Ten en mente que necesitarás más tiempo al realizar tareas

¿Te acuerdas la primera vez que te hiciste tu primer nudo en las zapatillas?, pues esa es la actitud. Al principio nos fijábamos dónde teníamos que meter el cordón, hasta que poco a poco, lo hacías más rápido, y al final, lo acabas haciendo sin mirar.

Programando te va a pasar igual, al principio te va a costar asimilar conceptos y cómo transformarlos en código. Poco a poco tu mente, se va a adaptar a todo ello, e irás cogiendo experiencia, hasta que llegue un día que lo hagas todo más rápido.

Equivócate mucho

Para aprender bien, vamos a tener que equivocarnos muchas veces, es la única manera en la que vamos a adquirir conocimientos. Se tiende a creer que quienes son senior nunca se han equivocado o que en ese nivel, nunca se equivocan, y no es así.

Un símil muy parecido para esto, sería el de montar en bicicleta, te vas a caer muchas veces y te vas a tener que levantar para volver a intentarlo. Habrá un momento que aguantarás más tiempo sin caerte, y finalmente no te caerás. Después pasará que de vez en cuando, te caerás, porque has encontrado una piedra, o el terreno en el que estabas no lo dominas. La actitud es que cuando nos caigamos, nos levantemos y aprendamos el motivo por el que nos hemos caído.

No tengas prisa cuando empieces

Nunca debemos de tener prisa en nuestro camino, tenemos que ir paso a paso sin saltarnos pasos importantes. Es algo común ver a personas usar un framework o librería sin saber bien el lenguaje de programación. Esto nos va a crear más frustraciones y que vayamos más despacio, sin que podamos aprender bien.

Invierte tiempo en el lenguaje de programación, porque pueden haber millones de frameworks o librerías, pero al final el lenguaje va a estar ahí. Aprende bien sus peculiaridades y experimenta con él, puede ser un paso costoso y difícil, pero esto es como meterse en el mar sin saber nadar, nos podemos ahogar fácilmente.

Lee documentación

Tendemos a menospreciar la documentación oficial, pero es nuestro manual de instrucciones para cualquier framework o librería. En la actualidad suelen tener buena documentación y por ello debemos de leerla bien, porque quienes realizaron esa tecnología saben realmente cómo utilizarla.

Siempre recomiendo leer la documentación en inglés (si no la tienen en español), para así acostumbrarnos a leer documentación técnica en este idioma. Si tienes problemas con el inglés, siempre puedes traducir la documentación con algún plugin del navegador, pero no es la mejor práctica desde mi punto de vista.

No te agobies con los bloqueos

Muchas veces tendremos bloqueos, y hay que saber gestionarlos en nuestros inicios. Al estar mucho tiempo bloqueadas o bloqueados, podemos entrar en visión de túnel, no encontramos la solución deseada por agotamiento y no rendimos igual.

A veces podremos resolver estos bloqueos, pero cuando no los podamos resolver, os pueden ayudar los siguientes consejos:

Pregunta a alguien del equipo, a lo mejor ha pasado por lo mismo que tú y te da una solución.
Busca por internet, intenta buscarlo en inglés, vas a encontrar muchas más soluciones que en español.
Levántate y airéate: muchas veces por la visión de túnel no vamos a verlo todo lo bien que querríamos.
Haz otra tarea que no tenga nada que ver y retoma la tarea del bloqueo más adelante.
Si no encuentras la solución en ningún lado, escribe tu bloqueo en StackOverfow, red social o donde veas pertinente.

Lee código de terceras personas

Al empezar, sólo leemos nuestro código y es un gran error, deberíamos de leer código de mucha gente. A veces ese código puede estar mal escrito, pero a base de leer mucho, vamos a saber cómo mejorar o aprender nuevas formas de realizar las cosas.

Una forma de leer código de otras personas es ver repositorios de proyectos ya maduros, así nos podemos asegurar que el código sigue unas buenas prácticas. Esto nos va a ayudar cuando estemos en un proyecto con código legacy.

No hay que saber todo en un inicio

En nuestro sector al empezar, lo malo, es que tenemos que saber muchas cosas, y esto nos puede abrumar. Debemos de ir paso a paso, y todo lo que aprendamos, aprenderlo bien. Ya llegará el día que domines todo o que seamos especialistas en lo que sea. Mejor ser especialista en algo, que en na2da.

No creas que hay framework bueno o malo

Otra de las preguntas que se hace al empezar es: ¿qué framework o librería es mejor?. Para esta pregunta, tenemos una respuesta rápida: según las necesidades del desarrollo.

Siempre tenemos que pensar qué diferencias tienen, y lo vamos a ver también en la curva de aprendizaje. Esto es como los coches: tenemos millones de marcas y modelos, pero el fin es siempre el mismo, conducir. Habrá coches que sean más cómodos de conducir, que consuman menos o que tenga más prestaciones. No creo que queramos un Ferrari sólo para ir a comprar el pan. Es un derroche de gasolina y de dinero, que a lo mejor cuando con un sencillo patinete nos es suficiente. En el mundo del desarrollo nos pasa lo mismo, hay que saber qué herramientas tenemos y cuáles se pueden adaptar mejor a nuestras necesidades.

No te dejes llevar por modas, prueba o investiga cuáles hay, y a una mala, si estás buscando empleo, busca el que estén utilizando para presentarte al puesto. A lo largo de nuestra vida como developers, vamos a tocar distintos frameworks o librerías, no te cases con ninguna tecnología, busca los beneficios y contras que tienen.

Al final, en el fondo, la manera de trabajar que tienen son lo mismo. Llegará un momento que cambiar entre tecnologías, será como cambiarte de camiseta.

Aprende bien Git

No le damos la importancia que le deberíamos de dar a nuestro control de versiones. Es una herramienta que nos va a acompañar en nuestro día a día junto nuestro IDE de desarrollo. Vamos a tener conflictos, problemas en ramas, y mil tipos de problemas.

Un consejo que doy cuando te inicias en el mundo del control de versiones, es cogernos un papel y pintar las ramas, para hacernos un esquema visual. Esto nos va a ayudar mucho para ver qué queremos hacer, y conseguir una solución. En un futuro lo tendrás tan en mente que no necesitarás ningún papel.

Hay un recurso genial para poder aprender git haciendo katas, y es este: https://github.com/eficode-academy/git-katas

No te comprometas a algo que sabes que no vas a poder hacer

A veces nos preguntan si podemos hacer una tarea en un lapso de tiempo. Para querer contentar decimos que sí, pero realmente en nuestro interior pensamos que no vamos a llegar, o pensamos que vamos a tener problemas por el camino. Tenemos que ser sinceras o sinceros, decir en cuánto tiempo lo podemos tener y qué problemas nos pueden surgir.

En un futuro, si no somos sinceras o sinceros, pueden darnos tareas incluso más difíciles y no vamos a poder entregarlas a tiempo. Si no lo gestionamos bien, nos agobiaremos, acumularemos estrés y se asomará nuestro síndrome del impostor con mucha fuerza.

Planifica las tareas con cabeza

Por experiencia propia, he podido ver que podemos tener el problema de planificar mucho una solución a una implementación, y hasta que no la vemos perfecta, no escribimos código. Puede estar bien planificar como abordar el problema, pero podemos perder mucho tiempo en no escribir código. Si empezamos a escribir código, vamos a poder ver problemas que no hemos visto en un inicio, e incluso, mejorar lo que teníamos pensado.

Mi mantra personal es: "código que no escribes, es código que no funciona".

Sigue o participa en comunidades

Siempre vamos a tener comunidades donde nos pueden echar una mano, o ser partícipe de ellas. Aquí es un lugar donde vamos a poder aprender nuevas tecnologías, o adquirir nuevos conocimientos. También podemos ayudar a gente con nuestros conocimientos, realizando talleres.

Sé autodidacta

Los cursos están bien, muchas veces son muy buenos pero, ¿pensaste alguna vez que te tienes que enfrentar a problemas tú sola o solo? En el curso siempre vas de la mano de una persona, y lo más seguro, que no vas a tener problemas. Pero cuando no tenemos a nadie apoyándonos, vamos a tener que saber realizar cosas a solas y enfrentarnos a los problemas.

Intenta hacer un proyecto similar y prueba añadirle alguna dificultad, así te pondrás a prueba, y podrás ver realmente si eres capaz de realizar dicha tarea.

Destaca en tu portfolio

Una de las preguntas que más leo es: ¿qué puedo hacer para que mi repositorio o proyectos destaquen? Es una pregunta que a veces es difícil de responder, pero os puedo dar unos consejos para intentar que sean más vistosos.

Muchas veces, los proyectos que tenemos son de cursos que realizamos, y eso no está mal, pero deberíamos hacer algo diferente, a lo que se nos pide en el curso. Imagínate que otra persona hace el curso, y tiene el mismo proyecto desde principio hasta el final, ¿qué valor puede tener esto?. Sólo vamos a tener algo idéntico y sin personalidad alguna. Intentemos siempre realizar el curso, hacer el ejemplo que nos ponen, y una vez finalizado, hacer otro desde cero, donde le demos nuestro toque personal. Nos podremos enfrentar a las dificultades (como he comentado en el punto anterior) y así resolver ciertos problemas que nos encontremos por el camino.

No hagas un curriculum Full Stack Ultra Ninja Developer

Cuando somos juniors, lo primero que queremos al adquirir conocimientos es la siguiente recompensa: encontrar nuestro primer trabajo. A continuación os digo unos consejos para mejorar nuestra empleabilidad:

LinkedIn es una selva de ofertas, pero es un sitio interesante donde empezar a buscar trabajo como developer.
Lo de Full Stack suena muy bien, pero tenemos que ser realistas: no podemos abarcar todo cuando empezamos. Si se os da mejor el Front, decid que sois Frontend Developer y si es todo lo contrario, decid que sois Backend Developer. Si en un futuro queréis convertiros en un unicornio Full Stack, informad que vuestra meta va a ser ésa. Por poner Full Stack no vas a encontrar trabajo más fácilmente cuando eres junior, puede ser hasta contraproducente.
No pongáis en vuestro currículum millones de tecnologías que no sabéis usar, poned las justas, a veces menos es más.
Si estáis aspirando a un puesto de Frontend Developer, no pongáis que sabéis Word o Excel, porque en el fondo, esto no va a aportar nada, sólo va a crear ruido.
No uséis las barras o círculos de porcentajes para skills, es algo que no aporta nada y no gusta.
Podéis complementar vuestro currículum con vuestro perfil de LinkedIn. En vuestro currículum poned con qué tecnologías trabajamos (acordaos, menos es más), y después poned los últimos empleos o proyectos, siempre indicando las tecnologías utilizadas. En LinkedIn podemos poner toda nuestra vida laboral al detalle, pero recomiendo que se ponga lo más relevante para los puestos a los que queréis ser candidatas/candidatos.
Intenta que tu currículum destaque sobre el resto, no utilices el típico que aparece en mil webs. Siempre deja un detalle, puedes usar los colores corporativos en el diseño.
Para acabar, el consejo más importante: sed honestas/honestos, es algo muy importante en todo este proceso.

Aprende de las pruebas técnicas

Uno de los puntos más difíciles para encontrar empleo, son las pruebas técnicas. Vas a tener que demostrar (injustamente) tus conocimientos en un breve periodo de tiempo. Estas pruebas son de lo más variopintas, y hay muchos ejemplos por internet.

Yo para prepararme las pruebas técnicas, siempre intento hacer katas como las que hay en CodeWars. Normalmente te van a poner un problema que vas a tener que solucionar en ese momento, o tendrás que hacer un breve desarrollo.

Cuando te den el resultado, si es negativo, no lo veas como tal. Es siempre una mala noticia que nos rechacen para un puesto de trabajo, pero vamos a ver posiblemente nuestro puntos más fuertes y los que tenemos que mejorar. Vas a coger experiencia con las pruebas técnicas y quién sabe, en un futuro, puedes presentarte de nuevo y recibir buenas noticias.

No pares de aprender

Por desgracia nuestro sector es un mundo muy cambiante, donde salen nuevas tecnologías, y a veces vamos a tener que renovar conocimientos. Nunca vamos a acabar de aprender todo, y vamos a tener que mejorar cada día.

Acuérdate que fuiste Junior

Cuando ya hemos adquirido un cierto conocimiento, no debemos de olvidarnos que una vez empezamos nuestro camino sin tener alguno. En tu camino, alguien te habrá ayudado y debemos de hacer lo mismo, ayudar a quienes empiezan. Podemos ayudar en nuestro lugar de trabajo impartiendo talleres o apoyando a la gente más junior. También puedes realizar talleres, artículos o vídeos en directo o en diferido. Este material lo van a agradecer, y que en el día de mañana, esas personas podrán hacer lo mismo que estás haciendo tú ahora.

Disfruta de lo que haces

Intenta disfrutar siempre de lo que haces, aunque estés en un proyecto que no te es interesante. Puede ser una gran oportunidad para adquirir experiencia y en un futuro, cambiar a un proyecto o empleo que nos guste más.

Conclusión

Espero que estos consejos os sean de utilidad, en ellos está reflejada mi experiencia y mi punto de vista en cada una de las cuestiones que os planteo.

Si os parece interesante este artículo, compartidlo y dadle difusión. Si me he olvidado de algo importante o echáis algo en falta, dejad un comentario, o buscadme en Twitter con el usuario de mrcodedev.

Apple M1: experiencia de un Frontend Developer

MrCodeDev — Wed, 24 Feb 2021 22:31:26 +0000

He visto distintos artículos o vídeos de gente hablando sobre el nuevo chipset de Apple, y me gustaría aportar mi granito de arena. Llevo trabajando con un MacBook Pro desde hace 3 años, y he tenido en mis manos distintos portátiles de Apple (todos ellos MacBook Pro). En mi actual empresa mi portátil de trabajo, es un MacBook Pro de 13”, con el nuevo chip Apple M1. Así que planteo dos preguntas: ¿realmente se nota tanta la diferencia en mi día a día? y ¿es recomendable comprar o cambiar de equipo con el chip Apple M1?.

A continuación os explico que cambios han habido en la arquitectura, y os digo mi experiencia después de un mes de uso.

Cambio de arquitectura de x86 a ARM

Apple llevaba mucho tiempo utilizando la arquitectura x86, y ha dado un giro bastante grande hacia una arquitectura ARM.

La arquitectura x86 fue acuñada gracias a la familia de procesadores de Intel, el Intel 8086. Utilizaron los dos últimos dígitos para llamar así a dicha arquitectura. Los beneficios de esta arquitectura es una mayor potencia frente a un mayor coste energético.

Mientras que la arquitectura ARM, es una tecnología que se ha usado mucho en dispositivos móviles y que siempre ha dado una mayor eficiencia energética en contra de un menor rendimiento.

Las diferencias principales es que las instrucciones que utilizan ambas, son muy distintas, y por ello un programa hecho para una arquitectura no vale para la otra. Por ejemplo en la arquitectura x86, el tamaño de las instrucciones son distintas, mientras que en ARM siempre son del mismo tamaño. Aquí sale beneficiado la arquitectura x86, ya que puede tener muchas instrucciones con un menor tamaño o hacer más cosas en una sola instrucción.

Uno de los mayores problemas de la arquitectura x86, es que tenemos un gran rendimiento pero, los equipos se calientan muchísimo, y Apple ha tenido muchos problemas con esto.

En resumen: la arquitectura x86 tiene mayor potencia perjudicando la eficiencia energética, mientras que ARM tiene más eficiencia energética y menor potencia.

¿Qué es Apple M1 y por qué hay tanto hype?

El Apple M1, es el primer chip que crean ellos con una arquitectura ARM. Promete ofrecer un rendimiento espectacular, duración de la batería más elevada, y que nuestro equipo se caliente mucho menos.

Antiguamente Apple montaba CPUs Intel (x86), donde teníamos distintos chips que hacían distintas cosas (gráfica, RAM...). Ahora con Apple M1, montan un sólo chip que incluye el procesador, la memoria, seguridad y funciones de E/S. Han reducido mucho los transistores (ahora tienen 16.000 millones de transistores) y han podido meter todo esto en un sólo chip (SoC) de 5 nanómetros.

Al unificar todo en un mismo chip, incrementan la fluidez a la hora de trabajar con datos, ganando ancho de banda, y sin tener que copiar instrucciones o datos en otro sitio.

Tenemos una CPU de 8 núcleos (4 núcleos que hacen tareas de alto rendimiento y 4 núcleos que hacen tareas de alta eficiencia). Nos prometen mucha más potencia con un bajo coste de consumo energético.

La GPU, también la tenemos integrada dentro del Apple M1. Vamos a tener un mayor rendimiento y mayor eficiencia energética gracias a ello. Con esto podremos hacer más con menos.

Gran problema: las aplicaciones en x86

Antes hemos hablado que cada arquitectura ejecuta instrucciones de distinta manera (una es variable y la otra es siempre del mismo tamaño), por ello vamos a tener problemas a la hora de ejecutar aplicaciones que no estén preparadas para ello. Cuando pasa esto, tenemos que compilar el código a ARM a un bajo nivel, y así conseguiremos que funcione. O también tendremos que usar intérpretes que traduzcan el código a ARM.

Otra solución a este problema, es que el propio sistema operativo utilice Rosetta. Rosetta es un virtualizador que emula una aplicación desde el principio hasta el final y lo ejecuta el hypervisor del propio sistema operativo. Así podremos utilizar todo lo que esté adaptado a ARM y sólo virtualizar la parte que no esté implementada.

MacBook Pro Intel(x86) o Apple M1(ARM)

Ya os he contado un poco por encima, los principales cambios que ha realizado Apple, y qué diferencias hay entre las distintas arquitecturas. Ahora vamos con las diferencias que he visto entre un MacBook Pro con arquitectura x86 y otro con arquitectura ARM.

MacBook personal Intel(x86)

Mi portátil personal es un MacBook Pro de 15” del 2019, con un procesador Intel i7-8850H (x86), 16GB de RAM, gráfica integrada Intel UHD Graphics 830 y tiene 4 salidas salidas USB Thunderbolt 3.1.

Es un portátil con el que estoy contento, aunque una cosa que no me gusta nada de nada es su teclado. En mi día a día he notado que se calienta mucho si le metes muchos procesos y cuando pasa esto notamos mucho el consumo de la batería. Pero en potencia la verdad que tenemos más que de sobra para desarrollar aplicaciones. No me ha dado ningún problema con aplicaciones y he podido trabajar con mis 2 monitores externos 4K.

MacBook trabajo Apple M1(ARM)

Vamos con el portátil protagonista del artículo: MacBook Pro de 13” con Apple M1 (ARM), 16 GB de RAM y tiene 2 salidas USB Thunderbolt.

La primera diferencia notoria es que se calienta mucho menos, y gracias a ello la batería lo agradece mucho, durando más. Tiene una refrigeración pasiva, con esto no tendremos el problema de tener el ruido de los ventiladores como le pasa a mi otro portátil personal. He notado algo más de velocidad a la hora de mover la posición de los monitores (en el personal tarda un poco) y a la hora de abrir la tapa (la imagen se pone enseguida). Sinceramente, no sé si esto es por el hardware o por software, pero no es algo que me haga decantar por un portátil u otro.

Mi primer problema que me decepcionó mucho, es que SÓLO puedes conectar un monitor (aunque tengas dos salidas USB Thunderbolt). Es un problema muy grande para un portátil que cuesta bastante dinero y que mucha gente como yo, utiliza más de un monitor externo para trabajar. Por suerte, podemos “arreglar” este problema, utilizando una base dock con DisplayLink (yo me compré este https://www.amazon.es/gp/product/B077XZ1P6G). Es una solución no oficial, no es 100% configurable como si tuviéramos otro monitor conectado de forma nativa, pero no me ha dado ningún problema desde que lo uso.

El siguiente problema son las incompatibilidades con las aplicaciones. Aún no están todas las aplicaciones adaptadas a ARM. He tenido problemas con dependencias como puppeteer y con otras que no recuerdo ahora mismo cuales son exactamente. No vamos a poder estar seguros de poder arrancar todo a la primera sin tener que ajustar ciertas cosas. He tenido suerte de ir saltando estos problemas sin que me bloqueen al 100%, pero te va a tocar invertir tiempo si necesitas algo para usarlo en tú día a día. Hay aplicaciones como Docker (ahora parece que empieza a haber algo) o ciertas aplicaciones que hay que esperar a que saquen versión para ARM (por ejemplo el software de mi webcam Logitech StreamCam).

Por el resto, en mi día a día no he tenido más problemas, tampoco he notado una gran mejoría en rendimiento para que sea clave y plantearme vender mi portátil para cambiar a los futuros MacBooks con mayor pantalla. Tampoco he hecho una gran prueba comparando los dos portátiles, pero yo no lo he notado. Puede que sea más rápido en ciertas tareas como la edición de vídeo, pero yo no trabajo con ello ahora mismo.

Conclusión final

Puede ser que un MacBook Pro con Apple M1 puede ir más rápido en ciertas cosas, pero yo en mi día a día no lo he notado mucho.

He tenido problemas a la hora de utilizar dependencias o aplicaciones que puede ser problemático si tampoco tienes mucha experiencia con la consola o no quieres invertir tiempo en intentar buscar una solución

Creo que el cambio de Apple a una arquitectura ARM, ha sido un buen comienzo, pero yo os recomiendo desde mi experiencia personal: debemos de esperar un poco para adquirir un Mac con chip Apple M1 (ARM).

Aún faltan aplicaciones o dependencias y podemos tener problemas en nuestro día a día. Con un portátil con arquitectura x86 vamos a poder utilizar todo sin preocuparnos de que algo pueda fallarnos y con un rendimiento más que bueno. Si queremos tener lo último de lo último, probar sin miedo y quedarnos sin alguna aplicación, esta puede ser una opción para ti. También es verdad que el precio de un MacBook Air (ARM) y un MacBook PRO (x86), también puede ser una ventaja al ser algo más barato.

Espero que os haya sido útil y que os haya despejado dudas si tenéis en mente adquirir un portátil con esta arquitectura. Cualquier duda que tengáis podéis decirla en los comentarios.

¿Quién es MrCodeDev, y qué va a hacer en Dev.to?

MrCodeDev — Sun, 18 Oct 2020 11:57:09 +0000

Bienvenidxs a todxs en este mi primer artículo 🤗. Voy a empezar presentándome, para así tener ese primer contacto con vosotrxs, y podáis conocerme un poco.

Me llamo José Luis o Horse Luis, pero en el mundo del desarrollo soy más conocido por MrCodeDev. Soy en la actualidad Frontend Developer en una empresa que gestiona contenidos musicales y audiovisuales 👨‍💻, rasco cuando puedo el violonchelo 🎻 (lo tengo bastante olvidado), hago fotografía 📷 (idem), y vivo en Madrid 🏡 después de haberme recorrido casi todo el mediterráneo (soy de Castellón) acabando en esta gran ciudad sin esperarlo.

Mi afición con los ordenadores 👨‍💻 empezó desde bien pequeño, rodeado de cassettes y revistas. En casa había un Sinclair ZX Spectrum, yo quería poner los juegos yo sólo (siendo un renacuajo 👶), así que aprendí poner el cassette del juego, y ejecutar él mítico comando load "". Sin saber leer, empecé a ver (a ver si, ya que no sabía leer) la revista MicroHobby, y no sé porqué, pero me quedaba embobado viendo código que no sabía ni lo que era, me resultaba curioso. Creo que ahí nació un vínculo con el mundo del código, que no iba a explotar hasta pasado bastante tiempo. Mi infancia está siempre ligada a la música 🎵, a los videojuegos 👾 y a la programación 🚀.

Empecé con un PC con un MS-DOS y un Windows 3.11., los cuales aún se acordarán de mí por las veces que me los cargaba ⚒ y volvía a instalar, era una tortura poner todos los disquetes 💾 esperando a que hicieran su magia. Ahí es cuando realmente aprendí a realizar scripts, utilizar la consola, y conseguir ejecutar los juegos que me gustaban.

Fueron llegando a casa avances tecnológicos como el CD-ROM 💿 junto las revistas de Micromanía y PcManía, internet con mi primera partida al Doom en modo multijugador 🕹 y así sucesivamente. Pero todo cambió cuando salió FrontPage de Microsoft. Un día me aburría en mi habitación, no sabía cómo iba el código HTML, pero quería hacer una página insultando a mi hermano. Creé una página con un enlace a otra, dónde en la siguiente salía una imagen de un burro 🐑 con el nombre de mi hermano. Después de esto intentaba hacer páginas mucho más complejas, hasta que me di cuenta que Frontpage ponía mucha basura en el código HTML, y dejé de lado este programa usando el editor de texto hasta que llegó Dreamweaver.

Pasó un tiempo y salió el CMS por excelencia de aquella época: PHP-Nuke 💀. Era un CMS que dabas un pasó y tenía un agujero de seguridad enorme (SQL Inject), pero se hizo muy popular. Gracias a PHP-Nuke, pude aprender indirectamente MySQL y PHP, el stack con el que he estado una buena temporada. Empecé hacer páginas para comunidades de juegos, para empresas pequeñas, hasta que salió Wordpress. Con Wordpress seguía desarrollando para gente o clientes, haciendo mis propios themes y plugins.

Durante este periplo, yo empecé a dominar herramientas de diseño gráfico como InDesign, o Photoshop, pero también tuve una gran temporada donde estuve enganchado a 3D Studio Max 🖲. Me acerqué al mundo del diseño gráfico, realizando trabajos de cartelería para pequeños clientes, y lo combinaba con el desarrollo de páginas web en Wordpress.

Llegó JavaScript, lo revolucionó todo, yo estaba con PHP feliz, pero veía que tarde o temprano tenía que abandonar mi stack para pasarme a eso que llamaban JavaScript. No fue hasta hace 3 años escasos (dedicándome profesionalmente desde hace 2 años), que abandoné PHP para dedicarme plenamente a JavaScript. No me arrepiento para nada del cambio, disfrutando cada día de este lenguaje de programación junto a todo su ecosistema de librerías y frameworks.

Este es un resumen muy por encima de mi vida como Frontend Developer o como diseñador (saltándome que he tocado Visual Basic, C++ y JAVA). Actualmente estoy enfocado en seguir afianzando todo el ecosistema de JavaScript que muta mucho (frameworks, librerías...), ayudar a gente que empieza con artículos o con vídeos y como no, seguir disfrutando de esta profesión.

Gracias si has llegado hasta aquí, espero que os haya gustado, y os gusten los artículos que vaya realizando en esta plataforma. Estos, estarán enfocados sobre todo a cosas relacionadas con JavaScript. Escribo actualmente en español porque creo que debemos de crear también contenido en nuestro idioma, y llegar a gente que aún no se lleva bien con el inglés, facilitando así su aprendizaje sin que sea una barrera.

Nos vemos por aquí y en Twitter 🐦: (@MrCodeDev). Podéis dejarme comentarios sobre temas que queráis que os acerque, avisos de erratas, o simplemente: lo que os apetezca. Muchas gracias por vuestra atención 🙋‍♂️