El vocabulario del desarrollo de software va mucho más allá de los lenguajes de programación y los frameworks. Existen términos únicos, creados dentro de la industria, que describen situaciones cotidianas con las que todo desarrollador se encuentra. Conocerlos no solo mejora tu comunicación con equipos de trabajo, sino que te permite sonar profesional y entender conversaciones técnicas sin perderte ningún detalle.
¿Qué significa bikeshedding y por qué deberías evitarlo?
El término bikeshedding tiene un origen curioso. Imagina que estás construyendo una planta nuclear y el equipo pierde tiempo discutiendo de qué color pintar el cobertizo de bicicletas. Eso es exactamente lo que ocurre en software cuando el debate se centra en detalles irrelevantes, como si un botón debería tener dos píxeles más de margen [0:42]. Cuando alguien en tu equipo dice "you're bikeshedding", te está indicando que estás perdiendo el foco en algo que no impacta el resultado final.
Por otro lado, yak shaving es algo muy diferente. Los yaks son esos grandes animales del Tíbet cubiertos de pelo. Si necesitas obtener su leche, primero tienes que hacer mucho trabajo de shaving (afeitado). En desarrollo, yak shaving se refiere a todo el trabajo necesario pero que no es el núcleo del problema que intentas resolver [1:10]. A diferencia del bikeshedding, este trabajo sí debes hacerlo para avanzar.
¿Cuál es la diferencia entre boilerplate y scaffolding?
El término boilerplate proviene del ámbito legal y describe el conjunto estándar de archivos y configuraciones que necesitas para arrancar un proyecto [1:47]. Herramientas como Create-React-App generan el boilerplate de un proyecto React: archivos como README, package.json y otras configuraciones iniciales.
El scaffolding, en cambio, funciona como los andamios de una construcción. Son archivos y funciones temporales que levantas al inicio para poder trabajar, y que vas reemplazando a medida que construyes versiones más complejas [2:10]. Mientras el boilerplate permanece, el scaffolding es transitorio.
¿Qué implica el onboarding en equipos de desarrollo?
Cuando un nuevo empleado se une al equipo, pasa por un proceso de onboarding [2:30]. No se trata solo de darle acceso a repositorios. Es una serie de pasos diseñados para que esa persona entienda el codebase, las herramientas que se utilizan y la arquitectura del sistema antes de poder contribuir de forma efectiva.
¿Por qué los desarrolladores practican dogfooding?
Hacer dogfooding significa literalmente "comer tu propia comida para perros" [2:47]. Si tu equipo construye una herramienta de gestión de proyectos y la usa internamente para organizar su propio trabajo, están haciendo dogfooding. Es una práctica valiosa porque te obliga a experimentar los mismos problemas que tus usuarios.
¿Qué son los proyectos greenfield, brownfield y la deuda técnica?
El concepto de rubber ducking es una de las herramientas más útiles en la resolución de problemas [3:14]. Consiste en explicar tu problema en voz alta a alguien, o incluso a un pato de goma literal. Al verbalizar los detalles, las ideas se organizan en tu mente y muchas veces encuentras la solución antes de terminar de explicar.
Todo desarrollador sueña con un greenfield project: un proyecto que comienza desde cero, sin código heredado, sin restricciones previas [3:42]. Solo tú, tu problema y la solución que quieres construir.
La realidad, sin embargo, suele ser un brownfield project, donde debes trabajar sobre un sistema existente con sus propios problemas y expectativas de usuarios [4:02]. Gran parte de esas dificultades se deben a la technical debt (deuda técnica), que son los atajos y decisiones que tomaron desarrolladores anteriores y cuyas consecuencias pagas ahora [4:12]. Sin embargo, hay una perspectiva optimista: si el sistema sigue vivo y funcionando, quizás esas decisiones no fueron tan malas después de todo.
Ahora es tu turno. ¿Puedes escribir una oración usando cuatro de estos términos? Comparte tu intento en los comentarios.
