Día 1: ¿Por dónde empezar?
DÍA 1: ¿Por dónde empezar?
El reto #100DaysOfCode es uno de esos objetivos que he pospuesto varias veces, ya fuera por falta de tiempo o por alguna carga de trabajo que tenía pendiente.
De hecho, hubo algunas veces en las que empecé el reto y lo dejé después de una semana porque, bueno, sencillamente todavía no sabía lo suficiente.
Lo que quiero decir es que mi forma de aprender nunca fue muy estructurada. En vez de estudiar los fundamentos de una habilidad, solía saltar directamente a lo que necesitaba para resolver el problema que tenía delante.
Y sí, es una manera eficiente de hacer que algo funcione rápido. Pero no es demasiado sostenible. Tarde o temprano, la falta de bases te alcanza.
Puede que consigas resolver un problema, pero, cuando algo vuelve a fallar, de pronto te das cuenta de que no entiendes del todo por qué funcionó aquella solución.
No puedes saltarte el proceso
Otra cosa que siempre se ha interpuesto es mi propia manera de pensar.
Era más joven, tenía poca experiencia, pero mucho entusiasmo y empeño para lanzarme a los retos sin revisar antes qué hacía falta.
De verdad: de niño era divertido enfrentarse a cualquier cosa que te lanzara el mundo, porque así se enfrentan los niños a las cosas. Sin tonterías. Sin complicarse. Solo por diversión.
Pero, de adulto, o al menos de veintitantos, no siempre puedes agarrar un problema e intentar resolverlo sin examinarlo con cuidado primero. Para empezar, nuestras acciones tienen consecuencias.
Por pequeño que creamos que es un efecto, el verdadero problema comienza cuando esos efectos se encadenan y bajan como una bola de nieve por una montaña empinada.
Un día crees que no necesitas aprender estructuras de datos y algoritmos porque ya has conseguido montar un script con fragmentos de varias fuentes de internet.
Y al día siguiente te encuentras de frente con un problema que nadie ha preguntado todavía en Stack Overflow.
No puedes saltarte el proceso.
Puede parecer que aprender algo bien lleva más tiempo, pero oye, no se mueven montañas a la fuerza. Lo que haces es dividir el Everest en sus piezas más pequeñas y moverlo piedra a piedra.
Cambiar de lugar
He pasado a puestos para los que estaba solo parcialmente cualificado o, sinceramente, para los que no estaba cualificado en absoluto.
Supongo que el entusiasmo y la perseverancia me ayudaron a conseguir esos trabajos, pero he aprendido que los fundamentos siempre vuelven. Estás investigando un problema y, de pronto, otra vez estás buscando lo básico en internet.
Bueno, quizá exagero un poco cuando digo que nunca me preocupé por aprender los fundamentos de nada.
Sí empecé desde lo más básico de redes cuando volví a estudiarlo todo para mi CCNA el año pasado. Fue muy satisfactorio comprender bien las subredes, cómo funcionan las redes y cómo el enrutamiento permite que los datos lleguen a su destino.
Pero también sé que las redes son solo una de las bases que debería tener un profesional de TI.
Y, a medida que descubro más sobre el mundo de DevOps, he aceptado que saber de redes no basta si de verdad quiero tener éxito como ingeniero de DevOps o de la nube.
Por eso empecé a aprender Linux el pasado febrero.
Resultó bastante útil cuando pasé a mi trabajo actual, donde me encargo de algunos de nuestros sistemas de gestión de redes. Todas esas herramientas NMS están alojadas en servidores Linux Red Hat 7 con los que he tenido la suerte de experimentar.
Bueno, sobre todo en los servidores de laboratorio.
Practicar en servidores de producción es, obviamente, un NO rotundo.
Vale, creo que ya basta de historia y de memes.
Ya he dedicado más o menos una hora a investigar en qué me centraré durante este reto y, por supuesto, a buscar los estupendos memes que pondré aquí.
Por ahora, he reducido mi lista a esto:
-
Estandarizar mis convenciones de nombres: Sí, sé que parece algo bastante trivial, pero creo que ayudará a largo plazo, sobre todo si algún día vuelvo a revisar mis archivos antiguos.
-
Linux: Todavía me considero relativamente nuevo en Linux, pero ahora estoy mucho más cómodo trabajando en servidores Linux y en mis máquinas virtuales. Solo han pasado unos meses desde que me metí de lleno, así que todavía queda mucho por aprender.
Otro buen lugar para practicar Linux es KodeKloud. Entra en www.kodekloud-engineer.com, crea una cuenta e intenta completar tu primera tarea de administración de sistemas.
-
Git: Ya tengo una cuenta de Git y he aprendido a trabajar con mis repositorios locales, pero todavía no sé trabajar bien con GitHub.
Así que sí, el día 1 será para Git y GitHub.
Para ello usaré un proyecto guiado de Coursera llamado Git for Developers Using GitHub, que puedes encontrar aquí:
https://www.coursera.org/learn/git-for-developers-using-github/
-
Python: Entre tantos lenguajes, he decidido centrarme en Python durante, supongo, los primeros 50 días.
Eso incluirá resolver problemas en HackerRank y trabajar de verdad en proyectos.
Python es un lenguaje bastante cercano para mí porque llevamos un tiempo con una relación intermitente. Hay temporadas en las que me concentro mucho en hacer cosas con Python y luego paro de repente porque tengo otra carga de trabajo o porque estoy preparando otro examen de certificación.
Esta vez quiero ser más constante.
Usaré el certificado profesional Google IT Automation with Python de Coursera:
https://www.coursera.org/professional-certificates/google-it-automation
Certificado profesional Google IT Automation with Python
Para volver a aprender Python como es debido, empiezo con el Google IT Automation with Python Professional Certificate de Coursera, que se compone de seis cursos.
La plataforma indica que puede completarse en ocho meses dedicándole unas cuatro horas de estudio a la semana.
Como pienso trabajar en esto a diario, incluidos los fines de semana, y normalmente veo los vídeos al doble de velocidad, mi objetivo es terminar el certificado completo en unos dos meses.
Eso sí, a lo que realmente quiero dedicar más tiempo es a los ejercicios prácticos.
De momento, sigue siendo un plan aproximado.
Si has leído la sección de Python de arriba, esto es solo lo que tengo previsto para la primera mitad de los 100 días.
Para la segunda mitad, quiero trabajar en desarrollo web.
Puede que digas que 50 días son muy pocos para terminar ese curso.
Y sí, probablemente tengas razón.
Simplemente terminaré lo que pueda entre el día 50 y el 100. Lo que quede, lo continuaré en mi próximo #100DaysOfCode.
En definitiva, creo que este reto #100DaysOfCode es, para mí, más bien un reto de constancia.
Quiero comprometerme de verdad con algo y seguir hasta alcanzar cierto nivel de dominio.
Por supuesto, convertirse en experto lleva mucho más de 100 días. Pero creo que estos 100 días pueden, al menos, ponerme en el camino adecuado.
Además, todavía no tengo muy claro dónde publicaré todo esto, porque he abierto mis cuentas de Twitter e Instagram hace poco.
Supongo que usaré ambas.
El problema de Twitter es el límite de caracteres, así que quizá tenga que dividir las publicaciones: poner la primera mitad en el tuit principal y continuar en las respuestas.
O podría publicar todo también en dev.to o Hashnode.
Lo único que me preocupa es si todas las imágenes que pongo aquí se verán bien en esas plataformas.
En cuanto a Instagram...
Sí, eso todavía no lo tengo resuelto.
Y una última cosa: mis próximas publicaciones o tuits probablemente serán mucho más cortos. Serán, sobre todo, actualizaciones sobre cómo fue el reto ese día.
Luego, quizá al final de cada mes, haga un resumen más largo como punto de control y lo publique en dev.to, Hashnode o freeCodeCamp.
Bien.
Entonces, día 1. ¿Por dónde empezar?
Sí.
Git.