Trabajar en Big Tech es malo
Exceso de planificación
El video de Theo “Build first, plan second” es el punto de partida perfecto.
Ese video nos muestra la siguiente captura de tuit:
Cuando los equipos priorizan la documentación teórica sobre prototipos tangibles, se arriesgan a:
- Alucinación de complejidad: Los ingenieros a cargo (que muy probablemente no escribieron una sola línea de código en años) crean soluciones sin experiencia práctica, lo que lleva a diseños inflados.
- Innovación estancada: Los documentos se convierten en dogma, desalentando la iteración.
- Necesidades de usuario desalineadas: Sin una interacción temprana con los usuarios, los equipos construyen soluciones en el vacío.
Los documentos de diseño no son malos, son herramientas. Pero cuando se usan demasiado pronto, anclan a los equipos a ideas no probadas. Construir primero basa las decisiones en la realidad.
Negligencia en la calidad del código
La prisa por entregar a menudo deja de lado la salud del código, generando consecuencias a largo plazo:
- Deuda técnica: Los prototipos rápidos y sucios se convierten en sistemas legados. Una funcionalidad que hoy "funciona" podría desmoronarse bajo demandas de escalabilidad.
- Barreras de colaboración: Código mal estructurado confunde a los compañeros, ralentizando el progreso. Imaginá heredar un código base desordenado – un asesino silencioso de la productividad.
- El mito de la velocidad: Sacrificar calidad por velocidad es contraproducente. Refactorizar un sistema frágil lleva más tiempo que construirlo bien desde el principio.
Desinterés
La mentalidad de "no es mi trabajo" — ya sea por agotamiento o por definiciones de roles rígidas — erosiona la dinámica del equipo:
- Innovación en silos: Los desarrolladores que se adhieren estrictamente a sus tareas pueden perderse insights de otros equipos.
- Desconexión con el usuario: Si nadie se hace cargo del feedback de los usuarios, los productos se alejan de las necesidades reales. Imaginá a un ingeniero backend ignorando las preocupaciones de UX, asumiendo que es "problema del frontend".
- Crecimiento sofocado: Limitarse a los límites del rol frena el aprendizaje. El software prospera con la curiosidad interdisciplinaria.
¿Por qué persisten estos problemas?
Porque subyacente a estos problemas hay una cultura que a menudo recompensa las métricas equivocadas:
- Ascensos por papeleo: Las empresas valoran a las personas que escriben documentos y asisten a reuniones por encima de las que escriben código, incentivando la burocracia.
- Victorias a corto plazo: Los gerentes priorizan la velocidad del sprint sobre prácticas sostenibles, ignorando la deuda técnica.
- Conformismo: "¿Si funciona, para qué cambiarlo?", se convierte en un mantra, matando la innovación.
El camino a seguir
La conciencia es el primer paso. Ahora que sos consciente, tenés dos caminos:
Involucrate más allá de tu rol
La historia de Theo es un plano para este camino. En Twitch, él no solo "hacía su trabajo" — desafiaba suposiciones, construía prototipos para exponer diseños defectuosos y se comunicaba con otros equipos para desmantelar propuestas innecesarias. Su proactividad no se trataba de ser un "héroe"; se trataba de negarse a dejar que la burocracia dictara los resultados.
- Por qué funciona: Al salir de los límites del rol, descubrís ineficiencias ocultas. El enfoque de prototipo primero de Theo cortó debates teóricos, demostrando que la acción supera al papeleo.
- El costo: Este camino exige trabajo emocional. Vas a luchar contra la inercia, defender tus hallazgos ante stakeholders escépticos y arriesgarte al agotamiento.
- La recompensa: Impacto real. El trabajo de Theo ahorró meses de esfuerzo desperdiciado y alineó productos con las necesidades de los usuarios.
Este camino no es para todos, pero es cómo los sistemas mejoran — si estás dispuesto a preocuparte más de lo que el sistema espera de vos.
Actuá según tu salario
Aquí está la verdad incómoda: el código limpio no paga las cuentas. Trabajé con desarrolladores brillantes cuyos códigos base están llenos de atajos. Al principio, asumí que se debía a la inexperiencia o los plazos. Ahora, veo el patrón: aprendieron que pulir no importa.
- Los ascensos van a quienes entregan funcionalidades, no a quienes refactorizan. Los gerentes rara vez notan código elegante — pero siempre notan retrasos.
- Si tu empresa recompensa "terminado" sobre "bien terminado", ¿por qué invertir esfuerzo extra? El desarrollador que escribe tests unitarios que no testean nada pero mejoran la cobertura de líneas no es perezoso; está optimizando para la supervivencia.
- El código se pudre, los equipos se resienten mutuamente y los desarrolladores futuros heredan el desorden. ¿Pero el individuo? Protegen su tiempo y cordura.
Ambos caminos existen porque la industria está rota. El método de Theo prospera en culturas que valoran los resultados sobre la política, pero esas son raras. Mientras tanto, "actuar según tu salario" es un síntoma de entornos donde los desarrolladores son tratados como recursos descartables.
Tu elección depende de:
- Cuánto amas el proyecto.
- Qué estás dispuesto a tolerar.
- Qué crees que mereces.