10 ideas de publicaciones en LinkedIn para desarrolladores de software (2026)

Tres días. Una línea. Les cuento toda la historia, por vergonzosa que sea.

Nuestro flujo de checkout fallaba al azar para cerca del 2% de los usuarios, sin ningún patrón que yo pudiera encontrar. Agregué logs, hice bisect de commits y empecé a dudar de mi cordura alrededor de la hora 30.

El culpable: una comparación con == en lugar de === sobre un valor que a veces era el string '0' y a veces el número 0. Truthy en un contexto, falsy justo en el caso límite que importaba.

Lo encontré cuando por fin leí el diff línea por línea en lugar de confiar en mi modelo mental de lo que el código 'obviamente' hacía.

La lección no fue sobre la coerción de tipos. Fue que, después de una hora sin encontrar algo, hay que dejar de razonar sobre el código y empezar a leerlo, carácter por carácter.

El código limpio está sobrevalorado.

El código que sale a producción paga tu sueldo.

Asumo las críticas por decirlo.

Teníamos una funcionalidad con una fecha límite atada al contrato de un cliente. Escribí un servicio genuinamente feo:

• Lógica duplicada
• Unos cuantos números mágicos
• Cero abstracción

Salió a tiempo. El cliente renovó un contrato de 200 mil USD en parte gracias a eso.

Lo refactorizamos como se debe tres meses después, cuando ya sabíamos qué partes de la versión fea importaban de verdad a largo plazo.

Refactorizar con datos de uso reales siempre le gana a diseñar la arquitectura a partir de suposiciones.

El oficio importa. Pero el oficio al servicio de algo que nunca sale a producción es solo un hobby caro.

Lo suficientemente bueno que se lanza le gana a lo elegante que todavía no existe.

Cómo reviso pull requests en menos de quince minutos sin aprobar a ciegas.

Primero, leo los tests antes que la implementación. Los tests me dicen qué cree el autor que debería hacer el código; si faltan o son débiles, ahí ya está la revisión.

Segundo, agrupo los detalles menores en un solo bloque de comentarios al final, no repartidos por todo el código. Diez comentarios de estilo dispersos se sienten como mil cortes para el autor; una lista agrupada se lee como ayuda.

Tercero, apruebo con comentarios cuando la lógica es sólida pero falta pulir, en lugar de bloquear. Bloquear es para problemas de correctitud y seguridad, no para preferencias.

Quince minutos, señal real y cero desgaste para los dos.

Registré cada interrupción durante dos semanas. Total: 47 cambios de contexto. Mensajes de Slack, reuniones que aparecen de la nada, alguien que se acerca a hacer una pregunta rápida.

Tiempo promedio para volver a concentrarme de verdad después de cada una: unos 9 minutos, medido según cuándo mi ritmo al teclear volvía a parecerse a resolver problemas y no solo a escribir.

Eso son unas 7 horas por semana recuperándome de interrupciones, sin contar el tiempo de la tarea que me interrumpió.

No lo compartí para quejarme. Se lo mostré a mi manager, con el número incluido, y como resultado directo bloqueamos dos mañanas sin reuniones por semana.

Las quejas vagas por las interrupciones generan empatía. Un número genera un cambio en el calendario.

El sistema legacy que nadie en mi equipo quería tocar se convirtió en el mejor maestro que he tenido en diez años.

Era un servicio de facturación que nadie entendía del todo, sostenido por comentarios como 'no tocar, pregúntale a Javier'. Javier se había ido dos años antes.

Pasé un mes haciendo arqueología: leí cada mensaje de commit, rastreé cada ruta del código y fui escribiendo mi propia documentación. Ninguna capacitación formal me enseñó tanto sobre tradeoffs del mundo real, deuda técnica y por qué se toman ciertas decisiones bajo presión.

Los proyectos desde cero te enseñan cómo construirías algo ideal. Los sistemas legacy te enseñan cómo sobrevive el software a años de necesidades de negocio que cambian. Me quedo con la segunda lección siempre.