articulos on luis angel ortega

¿Para quién estamos digitalizando la educación? Una llamada urgente a la accesibilidad

hey@luisangel.me (Luis Angel Ortega) — Thu, 26 Jun 2025 17:00:00 +0000

Desde hace más de dos décadas, hablar de transformación digital en la educación se ha vuelto casi obligatorio. Se invierte en plataformas, se promueven nuevas metodologías y se celebran los avances tecnológicos en las aulas. Pero hay una pregunta que rara vez se formula con claridad: ¿para quién estamos digitalizando?

El entusiasmo por la innovación ha dejado fuera un elemento esencial: la accesibilidad. No se trata solamente de si una persona tiene internet, sino de si puede usar, entender y beneficiarse de las herramientas educativas disponibles desde su contexto. Y en México, ese contexto suele ser un celular de gama media, una conexión móvil intermitente y la ausencia de una computadora en casa.

Según datos del INEGI (2024), más del 97% de las personas usuarias de internet en el país se conecta desde su celular, mientras que menos del 44% de los hogares tiene una computadora. Además, la velocidad promedio de conexión móvil —25 Mbps— es apenas suficiente para navegación básica, no para plataformas pesadas llenas de animaciones, videos incrustados y carga visual innecesaria.

Pese a esta realidad, seguimos impulsando plataformas que no están pensadas para esa mayoría. Herramientas como Genially, Canva o incluso Moodle con temas pesados se convierten en un obstáculo para muchos estudiantes. No por falta de interés, sino porque simplemente no cargan o saturan el equipo. El mensaje es claro: si no tienes el hardware o la conexión correcta, estás fuera.

No se trata de rechazar la tecnología. Se trata de exigir que se piense desde el usuario real y no desde el escritorio del diseñador o del tomador de decisiones. Una plataforma educativa que no funcione sin conexión, que no se adapte a pantallas pequeñas o que requiera equipos costosos no está pensada para incluir, sino para excluir.

Docentes, directivos y desarrolladores deben comprender que la transformación digital no es sinónimo de sofisticación ni de estética. Es una oportunidad para hacer las cosas mejor, para cerrar brechas, no para abrir nuevas. Apostar por sitios ligeros, diseño responsivo, estándares abiertos y software libre no es solo una decisión técnica: es una postura ética y pedagógica.

En un país con tanta diversidad social y tecnológica, no basta con ofrecer acceso. Hay que pensar en el uso real, cotidiano, situado. Mientras no tomemos en serio la accesibilidad digital, cualquier intento de inclusión será solo una promesa vacía. Y la brecha, lejos de cerrarse, seguirá creciendo… cargando lento.

Referencias

Covarrubias Hernández, L. Y. (2021). Educación a distancia: transformación de los aprendizajes. Telos: Revista de Estudios Interdisciplinarios en Ciencias Sociales. Recuperado de la base de datos Gale: Informe Académico https://doi.org/10.36390/telos231.12
Fernández-Enguita, M. (2023). La quinta ola: la transformación digital del aprendizaje, de la educación y de la escuela. Ediciones Morata, S. L. Recuperado de la base de datos eLibro Cátedra https://elibro.net/es/lc/bibliotecauveg/titulos/232678
Instituto Nacional de Estadística y Geografía. (2025, mayo 6). Encuesta Nacional sobre Disponibilidad y Uso de Tecnologías de la Información en los Hogares (ENDUTIH) 2024: Principales resultados. https://www.inegi.org.mx/programas/endutih/2024/
Speedtest by Ookla. (2024). Speedtest Global Index – Mexico. https://www.speedtest.net/global-index/mexico
The Competitive Intelligence Unit. (2024). Mercado de smartphones en México, 1T-2024. https://www.theciu.com/publicaciones-analisis/2024/03/smartphones-en-mexico-1T-2024

Públicado originalmente en el blog de El telar

Dropdowns y Toggles con puro CSS

hey@luisangel.me (Luis Angel Ortega) — Sat, 05 Nov 2022 11:53:11 -0500

Podríamos imaginar las tecnologías de la plataforma en la cual trabajo, Build It, como un platillo; donde Ruby on Rails es nuestro platillo principal pero está acompañada de una buena porción al lado de JavaScript a través de Stimulus JS, y mientras esta trae la funcionalidad y ese sentimiento mágico de una aplicación de una sola página (SPA, por sus siglas en inglés) hay cosas que queremos mantener simple en lugar de usar una bomba para matar una hormiga, como un profesor de la universidad solía decir. Por ello decidimos tomar nota de la página de Apple a la hora de manejar menús desplegables o dropdown y hacerlo por medio de puro CSS y HTML; sin requerir una línea de JavaScript.

Los pilares

Nuestros dos pilares en la vista serán los elementos <input> de tipo checkbox y las etiquetas <label>. Formaremos nuestro esqueleto básico de la siguiente manera:

<input id="toggle" type="checkbox"></input>
<label for="toggle"></label>

Estaremos usando la propiedad checked de los inputs tipo checkbox para poder controlar el contenido que mostramos y cuando lo mostramos. Para esto nos estaremos apoyando del elemento <label> ya que al relacionarlo a través de su propiedad for también será afectado por el cambio de clases cuando la propiedad checked de nuestro checkbox se encuentre presente.

Todo nuestro código realmente se encontrará dentro de <label> en dos secciones: container y toggle como se muestra a continuación.

<input id="toggle" type="checkbox"></input>
<label for="toggle">
 <div class="toggle">
 <!-- El elemento con el cual el usuario va a interactuar -->
 </div>
 <div class="container">
 <!-- Lo que queremos mostrar-->
 </div>
</label>

La magia

Ahora que ya tenemos nuestro esqueleto con HTML listo, es hora de agregar el CSS que le dará el toque mágico a nuestro componente:

#toggle {
 display: none;
}

.container {
 display: none;
}

#toggle:checked + label .container { 
 display: inherit; 
}

Nuestro input con el id de toggle nunca se mostrará para que no tengamos la checkbox presente en nuestra página, lo que mostraremos y con lo que interactúa el usuario es lo que esté dentro de nuestra div con clase de toggle. Una vez que le den click a nuestro toggle el input tendrá el valor de checked y con #toggle:checked+label afectamos el estilo de nuestro <label> para obtener un resultado como el siguiente

Y con un poco más de estilo (cortesía de Thulio Philipe) podemos tener resultados como este

O como los ejemplos que tenemos dentro de Build It

Un pequeño popover que siempre está presente, dando información vital al usuario

O un menú de filtros que puede ser mostrado con facilidad.

Como podemos ver, el CSS moderno nos permite hacer páginas interactivas sin necesidad de hacer un script para ello; dándonos una nueva solución a un problema con infinidad de maneras de resolverlo, por lo que habrá que considerar las necesidades del proyecto y que es lo que más conviene.

Finalmente les dejo un repositorio con un par de ejemplos vistos en este artículo para referencia futura y los invito a ver la plataforma y en especial mi perfil, donde podremos conectar para proyectos futuros.

Docker + Rails: Una solución para tus dolores de cabeza

hey@luisangel.me (Luis Angel Ortega) — Thu, 02 Sep 2021 15:15:49 -0500

¿Has llegado a pasar una semana solamente tratando de correr el proyecto al que te acabas de unir? ¿O tu aplicación no corre en producción como corría en local?
Hay una multitud de factores que pueden contribuir esto, por ello Docker nos ofrece una solución con la cual podemos tener un mayor control sobre estas variables a través de las computadoras que sean necesarias.

Dicho esto, en este articulo veremos como falicitarnos la vida al tener toda nuestra aplicación de Ruby on Rails corriendo sobre Docker; incluidas las bases de datos que sean necesarias.

Prerequisitos

Para poder seguir esta guía necesitaras tener Docker instalado así como un proyecto el cual quieras dockerizar, si solamente quieres prácticar puedes usar este proyecto de ejemplo el cual necesita una conexión a Postgres y a Redis para funcionar.

¿Eres impaciente? ¡Puedes clonar esta rama del proyecto donde ya se encuentran los archivos necesarios para correr el projecto dentro de Docker!

Primero viene el Dockerfile

Lo primero que haremos será hacer una imagen personalizada para nuestro proyecto, así que crearemos un archivo en la raíz del mismo llamado Dockerfile

touch Dockerfile

La primer linea de nuestro archivo definirá la imagen de la cual nos basaremos, en este caso será la imagen oficial de Ruby, pero usaremos la versión de Alpine para tener una imagen más ligera como resultado.

FROM ruby:3.0.1-alpine

⚠️ Asegurate que la version de Ruby (ruby:X.X.X-alpine) sea la misma que en tu proyecto, o tendrás errores a la hora de tratar de construir la imagen. Puedes encontrar la versión que usa tu proyecto en tu Gemfile.

Después sigue la parte más dificil de este Dockerfile, instalar la dependendencias necesarias para que funcione el proyecto; las que se muestran aquí son las que funcionan para nuestro proyecto de ejemplo, que incluyen las necesarias para realizar una conexión con Postgres, pero tendrás que descubrir cuales son necesarias para tu proyecto.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

Puedes esperar a construir la imagen (docker build .) para revisar el error que imprima Docker, con eso podrás ir averiguando que depenencias hacen falta 😉

La última linea (rm -rf /var/cache/apk/*) borra los paquetes de las dependencias que acabamos de instalar, esto ahorrará espacio en la imagen.

Lo siguiente que debemos de realizar es crear un directorio dentro del contenedor donde podamos copiar el código de nuestra aplicación para su ejecución, eso lo haremos con el siguente comando dentro de nuestro Dockerfile.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

¡Recuerda cambiar el docker-rails por el nombre de tu proyecto!

Así como le dimos un hogar a tu proyecto dentro del contenedor que crearemos, las gemas del mismo necesitan una carpeta también. Por ello, le informaremos a bundler donde colocarlas a través de una variable de ambiente.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

Y aunque ya instalamos las dependencias necesarias para correr Rails dentro del contenedor, tu proyecto necesitará algunas gemas y algunos paquetes de JavaScript para funcionar de manera correcta, vamos a encargarnos de eso de la siguiente manera.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

COPY package.json yarn.lock /docker-rails/
RUN yarn install
COPY Gemfile Gemfile.lock /docker-rails/
RUN bundle install

Ahora que ya tenemos todo lo necesario para que funcione tu proyecto, vamos a copiar el código al contenedor dentro de la que carpeta que creamos con el comando WORKDIR.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

COPY package.json yarn.lock /docker-rails/
RUN yarn install
COPY Gemfile Gemfile.lock /docker-rails/
RUN bundle install

COPY . /docker-rails/

¿Por qué copiamos primero los manifiestos (package.json, Gemfile, etc.) y después el resto del proyecto? Esto nos evita tener que reinstalar las dependencias (dado a que se quedan en caché) después de cambiar el código base y reconstruir la imagen; de esta manera solo cuando cambien los manifiestos se volverá a correr sus comandos de instalación.

Finalmente le diremos a Docker que comando correr cuando iniciemos nuestro contenedor (rails), así como los argumentos de este (s -b 0.0.0.0) y que puerto exponer para que nosotros podamos accesar a nuestra aplicación.

FROM ruby:3.0.1-alpine

RUN apk add --update --no-cache --virtual run-dependencies \
build-base \
postgresql-client \
postgresql-dev \
yarn \
git \
tzdata \
libpq \
&& rm -rf /var/cache/apk/*

WORKDIR /docker-rails

ENV BUNDLE_PATH /gems

COPY package.json yarn.lock /docker-rails/
RUN yarn install
COPY Gemfile Gemfile.lock /docker-rails/
RUN bundle install

COPY . /docker-rails/

ENTRYPOINT ["bin/rails"]
CMD ["s", "-b", "0.0.0.0"]

EXPOSE 3000

El puerto default sobre el que Rails corre es el 3000, pero si has designado otro puerto dentro de tu aplicación asegurarte de exponerlo de manera correcta.

Y con esto tenemos listo nuestro Dockerfile, aunque estamos lejos de tener nuestra aplicación lista. Si construyeramos nuestra imagen con docker build . y trataramos de correrla con docker start docker-rails nos encontraríamos con un error, ya que Rails no encuentra las bases de datos que necesita para iniciar de manera correcta; pero pronto nos encargaremos de ello.

Luego el docker-compose.yml

Para poder coordinar todos los servicios que necesitamos para el correcto funcionamiento de nuestra aplicación (en este caso 2 bases de datos: Posgres y Redis) usaremos docker-compose, esta útilidad de Docker nos ayudará a crear multimples contenedores de diferentes imagenes, conectarlos, darles variables de ambiente e incluso volumenes.

Empezaremos creando un archivo llamado docker-compose.yml.

touch docker-compose.yml

Y en su primera linea especificaremos que versión de la herramienta queremos usar, en este caso usaremos la más reciente a la redacción de este articulo.

version: '3.8'

Después indicaremos los servicios que queremos que corra docker-compose, esto lo haremos dentro de la etiqueta services. A cada servicio le daremos un nombre el cual será importante cuando estemos configurando nuestra imagen así que asegurate de nombrarlo de una manera que haga sentido para ti. Vamos como primer ejemplo servicio de Posgres, al cual llamaremos db.

version: '3.8'
services:
 db:
 image: postgres:latest
 container_name: docker-rails-db
 environment:
 - POSTGRES_DB=docker-rails-dev
 - POSTGRES_PASSWORD=password
 ports:
 - 5432:5432
 volumes:
 - 'dbdata:/var/lib/postgresql/data'

Los archivos YAML son sensibles a la identación, así que asegurate de tener todo en orden y andidado de forma correcta.

La etiqueta db es el nombre que le dimos al servicio y dentro de la cual especificaremos toda la configuración del mismo.

Lo primero con lo que nos encontramos es image que tal como su nombre lo indica es el nombre de la imagen que queremos usar para ese servicio, en este caso es la imagen oficial de Posgres en su última versión (puedes especificar una versión remplazando el latest por alguna otra versión válida).

Después nos encontramos con container_name, que también es autodescriptivo y el cual vendra útil a la hora de checar nuestros contendores con docker ps.

enviroment se refiere a las variables de ambiente, y si nos referimos a la documentación de la imagen de Docker de Posgres podemos ver que la única variable obligatoria es POSTGRES_PASSWORD pero nosotros también definiremos POSTGRES_DB para darle un nombre personalizado a la base de datos que crea la imagen por defecto.

⚠️ ¡Asegurate de elegir una contraseña segura para la base de datos!

ports son los puertos que necesitaremos pasar de dentro del contenedor a nuestra maquina, los indicados en el archivo son los que por defecto usa Posgres.

Finalmente los volumes son la infomación persistente que necesitaremos para no correr las migraciones cada vez que encendamos el contenedor, esto porque Docker borra todos los datos una vez que damos de baja la información, si quieres aprender más sobre este tema te recomiendo esta sección de la documentación.

Ahora, el siguiente servicio es el de Redis pero no ahondaremos mucho en el pues cuenta solo con un par de etiquetas las cuales ya hemos revisado, para más información puedes visitar la imagen oficial.

version: '3.8'
services:
 db:
 image: postgres:latest
 container_name: docker-rails-db
 environment:
 - POSTGRES_DB=docker-rails-dev
 - POSTGRES_PASSWORD=password
 ports:
 - 5432:5432
 volumes:
 - 'dbdata:/var/lib/postgresql/data'
 redis:
 image: redis:latest
 container_name: docker-rails-redis
 ports:
 - 6379:6379

Nuestro último servicio lo llamaremos web y será la imagen que hemos construido con nuestro Dockerfile.

version: '3.8'
services:
 db:
 image: postgres:latest
 container_name: docker-rails-db
 environment:
 - POSTGRES_DB=docker-rails-dev
 - POSTGRES_PASSWORD=password
 ports:
 - 5432:5432
 volumes:
 - 'dbdata:/var/lib/postgresql/data'
 redis:
 image: redis:latest
 container_name: docker-rails-redis
 ports:
 - 6379:6379
 web:
 build: .
 image: docker-rails
 container_name: docker-rails-web
 ports:
 - 3000:3000
 depends_on:
 - db
 - redis
 environment:
 - POSTGRES_HOST=db
 - POSTGRES_USER=postgres
 - POSTGRES_PASSWORD=password
 - REDIS_URL=redis://redis:6379

La primer etiqueta nueva con la que nos topamos es build, la cual indica el directorio donde se encuentra nuestro Dockerfile; dado a que nuestro Dockerfile está en la raíz solamente pondremos .; si tu Dockerfile no está en la raíz o tiene otro nombre es recomendable que leas esta sección de la documentación para asegurarte que Compose lo encuentre.

La etiqueta image en este caso servirá para nombrar la imagen que construirá Compose, ya que al estar presente build no irá al repositorio a buscar una imagen preconstruida.

Por último, la etiqueta depends_on informará a Compose que no se debe de tratar de iniciar el contenedor hasta que estén creados los servicios db y redis, así como los conectará de manera interna para que nosotros podamos accesar a ellos mediante un URL (como se puede observar en la variable de ambiente de Redis) o por sus respectivas credenciales (como es el caso de Postgres), si quieres aprender como Docker maneja eso puedes leer sobre Docker Network.

Ahora que ya terminamos con los servicios, lo unico que debemos es listar los volumenes que usaremos y a los cuales nombramos de la siguiente manera.

version: '3.8'
services:
 db:
 image: postgres:latest
 container_name: docker-rails-db
 environment:
 - POSTGRES_DB=docker-rails-dev
 - POSTGRES_PASSWORD=password
 ports:
 - 5432:5432
 volumes:
 - 'dbdata:/var/lib/postgresql/data'
 redis:
 image: redis:latest
 container_name: docker-rails-redis
 ports:
 - 6379:6379
 web:
 build: .
 image: docker-rails
 container_name: docker-rails-web
 ports:
 - 3000:3000
 depends_on:
 - db
 - redis
 environment:
 - POSTGRES_HOST=db
 - POSTGRES_USER=postgres
 - POSTGRES_PASSWORD=password
 - REDIS_URL=redis://redis:6379
 volumes:
 - .:/app
volumes:
 dbdata:

¡Y listo! Nuestro docker-compose.yml está listo, ahora solo falta un paso para empezar a crear nuestra aplicación contenida en Docker.

Ojos que no ven, .dockerignore que no siente

Muchas veces no queremos que ciertos archivos estén en nuestra imagen de Docker pues estos no son necesarios para su contrucción (o se generan en la misma) y solo terminan haciendo el proyecto más grande de lo que necesita ser, como puede ser el caso de los node_modules y la carpeta .git.
Para ahorrarnos este espacio crearemos un archivo llamado .dockerignore en la raíz de nuestro proyecto y añadiremos estas dos carpetas:

echo ".git \n node_modules" >> .dockerignore

Para más información sobre lo que puede contenener un archivo .dockerignore puedes consultar la documentación oficial de Docker

Unas bases de datos para llevar

Antes de correr el proyecto será necesario crear la base de datos que Rails espera, y crearla es tan sencillo que se puede hacer en un solo comando.

docker-compose run web db:create

Este comando le dice a Docker que use la imagen (que construirá) para correr un comando, en este caso db:create. Docker, con lo especificado en el docker-compose.yml sabe que como web depende de db tendrá que correr primero la instancia de Postgres, por lo que la base de datos se creará en este contenedor.

¿Por qué solamente db:create y no rails db:create o rake db:create? En nuestro Dockerfile dimos como punto de entrada el comando rails, por ello solo es necesario pasar los parametros. Si quisieramos efectuar otro comando dentro del contenedor esto tendría que ser a través de docker exec.

Nuestra aplicación en un contenedor

Con la base de datos creada, solo queda un comando que corra los contenedores en modo separado y podremos ver el fruto de nuestro trabajo.

docker-compose up -d

¡Y listo! Ya podrás accesar a traves de tu navegador a localhost:3000 y ver la página de bienvenida de Rails.

Conclusión

Puede que todo este proceso sea algo intimidante al principio, en especial si no sabes Docker, pero su resultado es un ambiente de desarrollo mucho más sencillo para todos los involucrados en el proyecto, pues ahora solo con tener Docker instalado podrán iniciar a programar; sin mencionar los beneficios que esta tecnología puede traer a tu ambiente de producción cuando se combina con Kubernetes o Docker Swarm.

Espero que te haya sido útil, cualquier cosa puedes contactarme y responderé lo más pronto posible.

Referencias

¿Home office o no home office? Esa es la cuestión

hey@luisangel.me (Luis Angel Ortega) — Tue, 20 Apr 2021 15:07:57 -0500

Durante este fin de semana que pasó me encontré a mitad de una plática familiar, en ella salió el tema del home office a lo que mi padre comentó que no era una práctica buena. “No es sano”, repitió múltiples veces mientras movía la cabeza de derecha a izquierda en manera de negación.

Mi primo y yo no estábamos de acuerdo con él, pues los dos (que como dato, ambos trabajamos en el ámbito de TI) hemos percibido beneficios enormes al trabajar desde nuestra casa. Tratamos de explicarle, pero él seguía negándolo con la cabeza y finalmente dejamos así la conversación.

Pero desde entonces no he podido dejar de pensar en ello ¿Realmente es sano el home office? ¿Realmente tiene los beneficios que yo promulgo? Después de un par de días de reflexión me encontré que este tema, como todo en la vida, es complicado.

Ya hemos pasado la marca del 1er año de pandemia, y desde mi experiencia y mi privilegio, el home office ha traído a mi vida un montón de beneficios (aunque aquí solo liste 3).

Lo bueno

Oportunidades laborales

Esta situación me ha permitido tener un empleo a distancia, cosa que si bien antes se podía, no estoy seguro que a mi como desarrollador junior me dieran la oportunidad de manera tan sencilla.

Más tiempo para mi

Creo que esta es la más obvia, pues sin tener que transportarse (o siquiera bañarme en las mañanas) para ir a una oficina he podido dormir más, pasar más tiempo con mi familia y darme tiempo para mi. He podido aventarme a más actividades, que aunque son dentro de mi casa o con un número limitado de gente, que antes no había podido probar; no sabía cuánto tiempo de mi vida se iba solamente en transporte a otros lugares.

Mayor paz mental

Este era el punto al que quería llegar, pues creo que no a todos les ha pasado así, pero para mi (después del golpe inicial del confinamiento) mi salud mental ha mejorado considerablemente. Verán, yo tengo un trastorno de ansiedad generalizada y hay días que la paso muy muy mal. Esos días, cuando llegué a trabajar en una oficina, los pasaba terrible. El día laboral se me hacía eterno, estoy seguro de que envejecía 4 años por cada día que era así; no me podía concentrar durante esas horas y me sentía horrible al respecto, sentía que no valía la pena mi trabajo y no estaba seguro de lo que hacía ahí. Era un momento en el que ni mi mente ni. mi cuerpo podían escapar de ahí, lo más que podía hacer era ver un par de vídeos de Youtube, hablar con colegas o salir a caminar; pero eso era todo, tus colegas solo pueden hablar un tanto contigo antes de que tengan que volver a sus labores y después de cierto número de caminatas tu jefe te empieza a ver raro (los vídeos de Youtube son infinitos, para bien o para mal).

Pero en el home office tengo el privilegio de trabajar desde mi cuarto, donde tengo todas las herramientas que necesito para lidiar con esos malos días, los cuales solo ya no son terribles ¡Pero han bajado en cantidad y frecuencia! Si bien tomó un par de meses en que llegara a una estabilidad en mi rutina y a tener la disciplina de trabajar desde casa, ahora si empiezo a tener un día particularmente terrible, tomaré un rápido baño, saldré al patio y jugaré con mi mascota; y eso funcionará como un reset a mi cuerpo, donde ya no perdí todo el día tratando de escapar de mi propia mente, en su lugar solamente 20 minutos en recobrar la compostura. En días menos terribles, pero igual difíciles, con parar cada descanso de pomodoro y caminar por la casa o jugar una partida de algo como recompensa por haber terminado una tarea servirá como suficiente incentivo para tener buen ánimo todo el día.

Lo malo

Esto no quiere decir que todo haya sido color de rosa, como mencioné, fue un trabajo de un par de meses llegar a este punto. Además yo sé que estoy hablando desde un privilegio enorme, porque no solo tuve la fortuna de tener el equipo para trabajar cómodamente desde casa; pero tuve un lugar donde hacerlo y un entorno tranquilo, cosa que muchas personas no han tenido.

Aún así, con todo mi privilegio, han un punto grande y un tema importante durante toda la pandemia: la socialización.

Socialización

Como “adulto” que soy, ya estoy empezando a notar algo que había escuchado de gente mayor que yo: cuando eres adulto cuesta hacer amigos. Y es que en mi primer empleo en TI lo mejor que me pude llevar fueron las amistades que hice, pues son gente que hasta la fecha frecuento y con quien hablo a diario; pasaron de ser colegas a ser amigos cercanos. Hablando con ellos me gusta comentarles que realmente esa oficina no era una oficina, pero que realmente estábamos en un reality show al estilo The Office donde grababan todo lo que pasaba.

Si bien, en los empleos/prácticas que tuve en durante la pandemia pude conocer a gente increíble, personas que considero mentores, no puedo evitar pensar que tendría una mejor relación con ellos si los pudiera haber visto en persona más seguido. Tampoco puedo negar que es mucho más sencillo conseguir ayuda de alguien si este está sentado enseguida de ti, aunque solamente sirva de patito.

En pocas palabras, extraño mucho la calidéz humana que traía trabajar en una oficina y sería mentira si no dijera que me preocupa que pierda la habilidad de hacer amigos si este modelo me esperara por el resto de mi vida.

Sin embargo, este es solo uno de los problemas que trae el trabajar desde casa; no he tocado cosas tan importantes como que los negocios se ahorran dinero si nosotros no estamos físicamente en una oficina mientras que nosotros gastamos más por el hecho de pagar los insumos que usamos al laborar sin tener un aumento de sueldo que refleje ese ahorro de parte del patrón. Este no era el punto que quería tocar en este escrito, pero no hay que quitar el dedo de ese tema.

Lo que propongo

¿Entonces cuál es la solución? ¿Qué sería lo ideal? Desde mi punto de vista, joven e ingenuo, y tomando en cuenta que esta es una solución para mis problemas en específico; yo creo que la solución sería un modelo híbrido, 2 días de oficina presencial y 3 de trabajo en casa. Podría funcionar de manera inversa también, pero en lo personal prefiero la primera opción.

Esto permitiría tener una dinámica ágil para situaciones como lo serían juntas, planeaciones o algún otro tipo de evento que se beneficie de estar físicamente en una habitación, dejando 3 días de espacio para que el empleado trabaje de una manera cómoda y a su estilo desde su casa. Además, si la oficina ya va a estar abierta algunos días ¿por qué no permitir a los empleados que quieran ir a laborar ahí? Esto podría beneficiar, por ejemplo, a quien no pueda contar con internet bueno en su casa o a quien tenga hijos en casa y no le permitan tener un lugar adecuado para concentrarse.

En este último ejemplo también funciona al revés, permitiría (si es que las cosas vuelven a algo que se parezca al pasado) que los padres que trabajan puedan ver más tiempo a sus hijos después de que lleguen de la escuela, incluso permitiendo que todos coman al mismo tiempo, en la misma mesa.

Al final, como muchas de las cosas bellas de la vida, creo que todo se debería dejar al libre albedrío de las personas; que ellos puedan escoger el modelo que mejor les funcione, pues creo que nosotros como humanos somos mucho más que un pedazo de carne capaz de producir dinero para una empresa y el home office puede ser un apoyo en nuestra búsqueda de sentido y de felicidad.

Si les interesa más sobre el tema de la vida post-covid, les recomiendo este vídeo de Ophelia Pastrana.