Desarrollador frontend

Tomar una maqueta o una descripción y producir el marcado, los estilos y la estructura de componentes que la renderizan.

Vacío, cargando, parcial, sin conexión, error, lento, y aquel en el que el usuario pulsó el botón dos veces — decidir qué debe hacer cada uno y hacer que ocurra.

El teléfono viejo, la conexión lenta, el navegador dos versiones por detrás, el lector de pantalla, el paquete que se hizo demasiado grande.

Recorridos con teclado, semántica para lectores de pantalla, contraste, orden del foco — y, cada vez más, poder demostrar que lo hiciste.

La biblioteca compartida: decidir qué entra en ella, qué rompe un cambio y a quién hay que avisar.

Respuestas en streaming, incertidumbre, citas, botones de parar, y qué hace la pantalla cuando el modelo se equivoca o va lento.

El propio código de una empresa, publicado por esa empresa, con la estimación de la migración manual (un año y medio de tiempo de ingeniería) dada por la misma empresa y no comprobable desde fuera. Lo que hace el resultado reproducible es el mecanismo, que la publicación describe entero: la migración es una máquina de estados en la que cada paso tiene un árbitro automático — jest, eslint y tsc dicen pasa o falla — así que el modelo podía reintentar sin nadie mirando, y la primera tanda resolvió el 75% de los ficheros en cuatro horas. La cola que quedó es el número más útil: tras cuatro días de ajustes, el 97%; el último 3% se había reintentado entre 50 y 100 veces cada fichero y se terminó a mano. La publicación es además explícita en que el factor principal fue seleccionar los ficheros relacionados correctos para meterlos en la instrucción — que creció a entre 40.000 y 100.000 tokens arrastrando hasta 50 ficheros — y no la redacción de la instrucción. No informa de ningún cambio de plantilla, de contratación ni de puestos, y tampoco lo afirma.

Una empresa lo ha puesto en producción. Puede mover la línea de base, ponderado por la escala y por cuánto se parece ese entorno al tuyo.

La tarea para la que antes te habrían contratado primero — convertir un diseño en una pantalla — es la más expuesta de aquí. Eso conviene saberlo antes de pasar un año volviéndote rápido en ella. Las partes que aguantan son los estados que nadie dibujó y la exigencia de que funcione para todo el mundo, y ninguna de las dos se aprende construyendo páginas de portafolio.

Tu palanca se movió de producir pantallas a restringirlas: el sistema de diseño, los estados, el presupuesto de rendimiento, la obligación de accesibilidad. Es trabajo menos visible y más difícil de enseñar en un portafolio, lo que es un problema real la próxima vez que cambies de empleo — empieza a llevar un registro de qué rechazaste y por qué.

Quedarte y reforzarte

Ser dueño de la capa de restricciones

Cuando las pantallas salen baratas, lo escaso es la persona que mantiene coherente un producto — la biblioteca de componentes, los estados, el presupuesto de rendimiento.

Rehacer el puesto

Ser quien puede demostrar que es accesible

Esto se está moviendo de buena práctica a obligación en varios mercados, y una obligación necesita a una persona con nombre que pueda demostrar el cumplimiento en vez de afirmarlo.

Movimiento lateral

Acercarte a la decisión de producto

Los ingenieros de frontend ven lo que hace la gente de verdad más directamente que casi nadie, y esa observación es la materia prima del trabajo de producto.

Ningún número aquí sería honesto, y la pregunta se hace mejor tarea a tarea. Producir una pantalla a partir de un diseño lo hace ya en gran medida la máquina; decidir qué hace la pantalla cuando faltan los datos, no, ni tampoco responder de si funciona para alguien que usa un lector de pantalla. Una señal que puedes comprobar tú: cuánto de tu último mes fue teclear marcado frente a decidir comportamiento. Si fue sobre todo lo primero, la exposición es real y el movimiento es hacia lo segundo.

En su tarea más visible, sí, y la razón es mecánica y no un juicio sobre dificultad: la entrada es visual, la salida es texto, lo correcto se comprueba mirando, y los datos de entrenamiento son la web pública. Pero la mayor parte de un código de frontend real no es esa tarea — son los estados que nadie dibujó, los dispositivos en los que nadie probó, y las restricciones que mantienen coherente un producto que crece. Estar expuesto en la mitad visible no es estar expuesto en el trabajo.

La amplitud no es automáticamente protección, y ese es el encuadre que conviene soltar. Dos exposiciones superficiales son más fáciles de sustituir que una profunda; lo que protege es ser la persona en la que se confía para juzgar, y el criterio es específico de un dominio. Si cruzas, cruza por una razón — los estados y el modelo de datos están de verdad conectados, y entender los dos te hace mejor en la frontera, que es donde vive la mayoría de los fallos.

Se sigue pidiendo, y es una señal cada vez más débil por la misma razón que la primera tarea de esta página: quien lo revisa sabe ahora cuánto cuesta producir una pantalla bonita. Lo que no se ha debilitado es la evidencia de criterio — un componente que quitaste y por qué, un estado que manejaste y que nadie especificó, un presupuesto de rendimiento que sostuviste bajo presión. Eso es más difícil de reunir y mucho más difícil de generar.