Confesiones de un Ingeniero sin Base
En la universidad, creía que era el mejor. Sin entender realmente la importancia de los fundamentos de las Ciencias de la Computación (CS), solo me preocupaba por conseguir buenas notas.
Asistía diligentemente a las clases y hasta gané premios en concursos de programación y en el proyecto final de carrera. Cuando mis compañeros sufrían con errores de código, yo les daba consejos mirando por encima del hombro, sintiendo una extraña superioridad. Pero ahora, debo confesarlo: lo que creaba en ese entonces era, básicamente, basura.
Como me resultaba difícil conectar una base de datos (DB) real, guardaba los datos en archivos de texto (.txt) separados por comas. En lugar de usar una Raspberry Pi que requería control a nivel de sistema operativo, lo solucionaba todo con un Arduino y unas pocas líneas de código. Los profesores elogiaban esos resultados que solo funcionaban en apariencia, y yo caí en la trampa de creer que esa era mi verdadera habilidad.
La tragedia comenzó con una entrevista memorizada
Sin embargo, en cuanto fui lanzado al mercado laboral, esa confianza infundada se hizo pedazos. Fue una serie continua de rechazos. El título de «Ganador de Concurso» no podía ocultar mis pobres conocimientos básicos de CS.
A medida que la ansiedad crecía, me obsesioné con acumular conocimientos superficiales. Dejé de lado la comprensión real y empecé a memorizar respuestas modelo como una máquina para pasar las entrevistas. Las «100 preguntas típicas de entrevista» que copiaba de blogs técnicos se convirtieron en mi biblia.
Cuando el entrevistador preguntaba: «¿Cuál es la diferencia entre TCP y UDP?», yo respondía como un robot:
‘TCP está orientado a la conexión y garantiza fiabilidad pero es lento; UDP no tiene conexión y es rápido pero menos fiable.’
En realidad, no tenía ni idea de qué era un paquete ni de cómo ocurría realmente el ‘3-way handshaking’. Irónicamente, gracias a esa capacidad de memorización mecánica, logré engañar a los entrevistadores y conseguir un empleo. Pensé que era suerte. No sabía que era el comienzo de una tragedia donde pagaría por mis 4 años de negligencia.
Supervivencia Full Stack en un equipo pequeño
El lugar donde entré era un equipo pequeño (una Startup). Allí no existían distinciones amables como ‘Frontend’ o ‘Backend’.
Desde el primer día, tuve que enfrentarme a un tsunami de tecnologías. Pensé que bastaría con saber Java o JavaScript. Pero la realidad era una pantalla negra de terminal Linux (SSH), contenedores Docker de origen desconocido, pipelines de GitLab CI/CD, Spring Boot, Vue.js y hasta Redis… Todas esas tecnologías que había pospuesto pensando «ya lo haré luego» o ignorado diciendo «esto no hace falta», me atacaban desde todos los flancos.
El conocimiento que recité en la entrevista no servía de nada en la práctica. O mejor dicho, no sabía cómo ‘aplicarlo’. Para entender por qué mi contenedor Docker moría constantemente (OOM) o por qué Redis se comía toda la memoria, necesitaba desesperadamente esos conocimientos básicos de CS que solo había memorizado para el examen.
Un castillo construido sobre arena
Al final, me convertí en un «Desarrollador Copy-Paste» (Ctrl+C, Ctrl+V), pegando código a diestra y siniestra. Las funciones operaban de alguna manera, pero yo no sabía por qué.
- Error CORS: ¿Por qué mi navegador rechaza la respuesta del servidor? (Ignorancia sobre los encabezados HTTP)
- OOM (Out Of Memory): ¿Por qué el servidor muere de repente si funcionaba bien? (Ignorancia sobre fugas de memoria y Garbage Collection)
- Connection Refused: Funciona en local, ¿por qué falla al desplegar? (Ignorancia sobre puertos y firewalls)
Sin conocer los principios ocultos detrás de la comodidad que ofrecen los frameworks, no tenía capacidad para resolver problemas cuando surgían. Estaba construyendo un castillo precario con frameworks lujosos sobre un terreno de fundamentos CS inestables.
Re: Booting, volver al punto de partida
Por eso, decidí volver al principio. Sentí que era más urgente resolver la pregunta fundamental de ‘¿Cómo diablos entiende y ejecuta la computadora mi código?’ que crear otro portafolio llamativo ahora mismo.
Este blog es el registro de una batalla intensa de un graduado que solo tiene el título, volviendo a construir sus bases de CS desde el suelo. No voy a listar simplemente comandos de Linux o cómo instalar Docker. En su lugar, plantearé preguntas y buscaré respuestas:
- Language & OS: ¿Qué sucede desde que el código Java se compila hasta que llega a la CPU?
- Network: Cuando presiono Enter en la barra de direcciones, ¿qué viaje realiza el paquete?
- Virtualization: ¿Qué diferencia hay entre mi portátil y la computadora del servidor, y por qué necesitamos la virtualización?
- DevOps: ¿Cómo despliego mi código de forma segura y automática?
Más allá de localhost
Mi objetivo final es construir y controlar con mis propias manos entornos de Linux, Docker, CI/CD y hasta la Nube. Espero que observen mi proceso de convertirme en un ingeniero capaz de sobrevivir en el entorno salvaje de los servidores, saliendo del invernadero seguro llamado ‘localhost’.
Para aquellos que, como mi yo del pasado, dicen «Lo aprendí en la universidad pero no lo recuerdo», espero que este registro sea un pequeño hito que les haga golpear la mesa y decir: «¡Ah, esto es lo que quería decir el profesor en ese entonces!».