Muchos desarrolladores mid-level todavía miden su progreso por la cantidad de líneas que agregan al repositorio cada semana. Pero cuando ya te tocó apagar incendios en producción, aprendés algo incómodo: el código no es un activo; es un pasivo.
La mejor línea de código es la que no necesitás escribir.
Cada línea que subís es algo que tenés que testear, documentar y mantener frente al paso del tiempo. El verdadero seniority no se demuestra construyendo catedrales de abstracciones, sino teniendo el coraje de demolerlas cuando ya no sirven, reduciendo la superficie de ataque de tus bugs y liberando espacio mental para lo que realmente genera valor: el negocio.
El código es un pasivo, no un activo
Hablemos claro: cada línea de código es una responsabilidad. Es una potencial fuente de errores, un obstáculo para futuras refactorizaciones y una carga para el desarrollador que herede tu trabajo.
Si deseamos contar líneas de código, no deberíamos considerarlas como "líneas
producidas" sino como "líneas gastadas".
Cuando escribís código, firmás un contrato de mantenimiento perpetuo. Los seniors lo saben: la mejor línea de código es la que no necesitás escribir. Esta mentalidad choca con la cultura del "feature factory", pero si sos el que responde por el sistema un domingo a la tarde, valorás más la simplicidad que la "belleza" de una arquitectura compleja.
La arquitectura también se poda
No toda capa extra es arquitectura. Muchas veces aparecen capas extras por ansiedad técnica o por un deseo de "perfección" teórica:
- “por si migramos”
- “por si mañana cambiamos de ORM”
- “por si después usamos microservicios”
El senior sabe distinguir una frontera útil de una abstracción decorativa. El patrón del falso adaptador (crear un wrapper para una librería estable como zod o date-fns) es solo código muerto que vas a tener que mantener. El acoplamiento a un estándar de la industria suele ser más barato que el acoplamiento a una abstracción interna mediocre.
Como alguien que gestiona su "Chair-Time" con precisión quirúrgica, aprendí que no puedo darme el lujo de mantener código inútil. Si algo no sirve para la misión, se borra. El tiempo es el recurso más escaso; no lo malgastes manteniendo monumentos al ego técnico.
La falacia del costo hundido en el editor
Pasaste tres noches diseñando una arquitectura genérica increíble. Al final, el negocio solo usa un caso de uso. Te duele borrarlo. Sentís que "tirás a la basura" tu esfuerzo.
Aceptalo: ese tiempo ya se perdió. Mantener esa complejidad innecesaria solo va a seguir robándote horas en el futuro. Cada vez que toques esa zona, vas a tener que recordar cómo funcionaba esa abstracción para no romper casos que nunca van a existir.
Borrar código es admitir que hoy sabés más que cuando lo escribiste.
Cirugía Técnica: Cuándo y cómo podar
Identificá dónde la complejidad está asfixiando la agilidad. Robert C. Martin (Uncle Bob) popularizó la Regla del Boy Scout: "Siempre dejá el código más limpio de lo que lo encontraste". En 2026, limpiar a veces significa borrar el módulo entero.
Acá tenés el protocolo para identificar qué es hora de sacar con la tijera:
Protocolo de Poda Senior
Identificar el 'Dead Code'
Detectar Abstracciones Prematuras
Usar Characterization Tests
Eliminar el 'Just-in-case'
Ejemplo real: Simplificación de validaciones
A veces la mejor refactorización es reemplazar 50 líneas de lógica manual por una herramienta estándar. Como vimos en mi post sobre Astro 6 y SEO Enterprise, la validación de datos es clave para la integridad del sistema.
Mirá este cambio:
function validateUser(data: any) {
if (!data.email || typeof data.email !== 'string') return false;
if (!data.age || data.age < 18) return false;
if (data.role && !['admin', 'user'].includes(data.role)) return false;
// ... 20 líneas más de ifs manuales
return true;
}const UserSchema = z.object({
email: z.string().email(),
age: z.number().min(18),
role: z.enum(['admin', 'user']).optional()
});
const validateUser = (data: any) => UserSchema.safeParse(data).success;El ROI del minimalismo y el costo de lectura
Uncle Bob también señala que pasamos diez veces más tiempo leyendo código que escribiéndolo. Si tu codebase está inflada, estás multiplicando por diez el costo de cada futura feature. Menos código suele traer efectos inmediatos:
- Menos bugs en producción.
- Builds más rápidos.
- Menos superficie de mantenimiento.
- Onboarding más simple para nuevos devs.
- Más velocidad para entregar cambios reales.
Borrar código también es una decisión ética. Cada ciclo de CPU que ahorramos al eliminar JS innecesario aporta a la sostenibilidad. Como discutimos en mi post sobre Green Web en Itapúa, la eficiencia es una forma de respeto.
Conclusión: Seniority no es escribir más
La próxima vez que abras un Pull Request y veas que el balance de líneas es negativo, sentite orgulloso. Acabás de hacer que el sistema sea más ligero, más rápido y más mantenible.
Seniority no es saber cómo usar la última librería de moda; es saber cuándo no usarla. Es tener el criterio para borrar lo que ya dejó de servir y entender que la elegancia no está en lo que podés agregar, sino en lo que ya no podés quitar.
Aceptalo: borrar es evolucionar.
¿Necesitás recuperar la velocidad de tu equipo?
Especialidad: Consultoría de Arquitectura & Refactoring
Te ayudo a:
