WR 233: Bus Factor igual a 1 y currantes solitarios con Abel Fernández

El desafío del trabajo en solitario ¶

La sensación de estar solo en un proyecto puede resultar abrumadora y, sin embargo, es en esa soledad donde se forja una verdadera comprensión del arte de construir software. Cuando trabajas solo, cada decisión –desde el código que escribes hasta la documentación que dejas para los demás– se vuelve una apuesta contra la incertidumbre. La soledad, al igual que la escritura, es un ejercicio de precisión y de asunción de riesgos. Trabajar solo obliga a poner en claro las ideas y a transformarlas en acciones concretas, sin contar con otras voces que corrijan o complemente el razonamiento.

En ocasiones se siente como si todo dependiera de ti, y es precisamente esa percepción la que pone en evidencia el peligro de lo que se conoce como “bus factor”: el número de personas sin las cuales el proyecto se vuelve insostenible. En ese contexto, la responsabilidad de construir algo perdurable recae únicamente en tus hombros. Este desafío nos lleva a reflexionar sobre la importancia de no solamente trabajar, sino de hacerlo de forma que lo construido tenga la capacidad de seguir adelante, aun cuando la persona que inició el proyecto ya no esté presente.

Descubrir el valor del bus factor ¶

La idea del bus factor es sencilla pero crucial: se trata de medir cuán dependiente es un proyecto de una única persona. En el trabajo en solitario, este concepto se vuelve especialmente relevante. Si te dejas llevar por la rutina y construyes soluciones que solo tú comprendes, el día en que ya no puedas estar presente –por cualquier imprevisto– el proyecto podría paralizarse. Los métodos para mitigar este riesgo son tan variados como necesarios:

• Diseñar la arquitectura del software con alta cohesión y bajo acoplamiento
• Documentar de forma clara cada parte del proyecto
• Estructurar el código y los archivos de manera lógica
• Evitar la personalización excesiva que dificulte la comprensión a otros

Una cita directa de la conversación que resuena en este tema es:
“El ‘buff factor’, que también se llama ‘track factor’ o ‘pony factor’”
Esta frase encapsula la preocupación por asegurar que el proyecto no dependa únicamente de la presencia y el conocimiento implícito de una única persona.

Cada decisión que tomas al desarrollar —desde la selección de tecnologías hasta el modo en el que organizas tu documentación— afecta la resiliencia del proyecto ante la ausencia. Las siguientes interrogantes son fundamentales:

• ¿Qué pasaría si mañana no estuvieras?
• ¿Se puede seguir el proyecto sin tu intervención directa?
• ¿Has dejado suficiente conocimiento explícito para que otros lo puedan continuar?

La respuesta a estas preguntas es vital para transformar un buen proyecto en uno verdaderamente sostenible.

El reto de la documentación ¶

Una de las grandes dificultades a la hora de trabajar solo es la tarea de comunicar de manera efectiva lo que haces. Escribir documentación no es solo una actividad técnica; es un acto de humildad y de honestidad con uno mismo. Cuando documentas, reconoces que existen detalles que no se capturan en el código y que, a veces, solo tú entiendes de forma intuitiva lo que has construido. Esa comunicación escrita se convierte en la voz que explica lo que, en un principio, se dio por sentado.

La documentación sirve para:

• Mitigar el riesgo de tener conocimiento “oculto” en la cabeza de una sola persona
• Facilitar la incorporación de nuevos colaboradores en el futuro
• Evitar que el conocimiento se diluya o se malinterprete en momentos de crisis

Cuando se debate sobre la forma correcta de documentar, surge un dilema común: ¿debe el código ser autodescriptivo o debe acompañarse de comentarios para aclarar intenciones? La respuesta, aunque aparentemente simple, se complica en la práctica. La documentación no es para quien la escribe, sino para el que la lee. Escribir para uno mismo implica dejar de lado muchas suposiciones que, al no ser compartidas, se transforman en puntos de confusión para el próximo lector.

La elección de frameworks y la simplicidad pragmática ¶

El proceso de elegir las herramientas apropiadas para un proyecto es otra faceta complicada del trabajo en solitario. La decisión no debe estar basada únicamente en la novedad o en la popularidad de un marco de trabajo; debe ser un acto reflexivo que considere la fiabilidad, el soporte de la comunidad y, sobre todo, la capacidad de adaptación en el largo plazo. Herramientas conocidas y ampliamente utilizadas aportan una garantía implícita de que, aunque su implementación pueda tener algún defecto, estarán respaldadas por una comunidad que sabe cómo resolverlo.

Algunas claves para elegir de manera consciente son:

• Revisar el número y la calidad de los comentarios en GitHub
• Evaluar las issues abiertas y cerradas para medir el estado de madurez
• Considerar la facilidad de integración con otros componentes del sistema
• Valorar la estabilidad y la capacidad de mantenimiento a largo plazo

La decisión de utilizar frameworks conocidos surge, en muchos casos, de la necesidad de evitar reinventar la rueda. Cuando trabajas solo, simplificar tu entorno de desarrollo te permite centrar tus energías en lo que realmente importa. La filosofía “no me complico la vida” se convierte en la palabra de orden. Utilizar un boilerplate, aprovechar librerías consolidadas o recurrir a sistemas que ya han sido ampliamente probados, son estrategias que no solo ahorran tiempo, sino que reducen el riesgo de deslizarse en problemas inesperados.

Decisiones en solitario, incertidumbre y aprendizaje continuo ¶

El trabajo en solitario es, en última instancia, un terreno donde se enfrentan cada día la duda y el aprendizaje. Decidir la mejor forma de proceder, adaptarte a los cambios o incluso admitir que lo actual puede ser mejorado, son todos pasos naturales en la evolución personal y profesional. La incertidumbre es inherente a la práctica de programar, y es precisamente esa incertidumbre la que te lleva a buscar la excelencia en la forma en que estructuras tus decisiones.

Una serie de reflexiones que se pueden extraer:

• La respuesta correcta a un problema solo se encuentra al actuar y luego evaluar los resultados
• Las críticas, incluso las más severas, pueden servir como oportunidad para aprender y crecer
• Las decisiones tomadas en solitario tienen un impacto directo en la sostenibilidad del proyecto y en la posibilidad de delegar o distribuir conocimientos
• La evolución continúa y el código de hoy inevitablemente será visto como inadecuado en el futuro; sin embargo, es el proceso de creación el que aporta el conocimiento

La experiencia, al igual que la escritura, revela que las ideas aparecen y se refinan a medida que se ponen en práctica. Un desarrollador solitario debe aprender a confiar en su juicio, entendiendo que la perfección es un proceso que se alcanza mediante iteraciones y, a veces, mediante el error.

El camino del trabajo en solitario se caracteriza por una constante autoevaluación en la que nunca se llega a un punto final. La documentación, la elección de frameworks, el análisis de riesgos como el bus factor y el incesante aprendizaje, son parte de una misma experiencia integradora. Cada línea de código, cada comentario, cada decisión, se convierte en una prueba de la capacidad de transformar incertidumbres en soluciones pragmáticas.

La importancia de actuar sin miedo al error ¶

La duda y el miedo a equivocarse pueden paralizar. Sin la presión de tener que complacer a otro, el desarrollador solitario se enfrenta a una elección crucial: actuar o estancarse. En este escenario, la práctica de escribir y reflexionar se torna en una herramienta para clarificar decisiones. Los errores son inevitables, pero son precisamente el motor del aprendizaje. Es decir:

• El código de hoy puede parecer imperfecto, pero será la base para el código de mañana.
• Las críticas internas y externas se transforman en guías para futuras iteraciones.
• Cada fallo se convierte en un paso hacia una arquitectura más robusta y resiliente.

La única forma de superar el síndrome del impostor y la parálisis del análisis es lanzarse a la acción. En el proceso, la experiencia se va acumulando y, con el tiempo, se aprende a reconocer patrones que permiten mejorar no solo el código, sino la forma en la que se trabaja. No existe una fórmula mágica; existe el coraje de actuar y la humildad de aprender de los errores.

Conclusión ¶

El trabajo en solitario es, sin duda, un reto que implica enfrentar la soledad, la incertidumbre y la constante necesidad de actuar sin vacilación. Cada decisión se convierte en un ejercicio de precisión, y cada error, en una oportunidad para mejorar. Lo crucial es transformar el riesgo en un impulso para construir soluciones que sean robustas y resilientes.

La reflexión que guarda este enfoque es que el conocimiento, al igual que en la escritura, se revela a medida que se plasma en acciones concretas. No se puede tener una idea del todo formada sin haberla expuesto y sin haber invertido en su ejecución crítica. La experiencia de transformar dudas en acciones y la resiliencia del código cuando ya no dependes únicamente de ti, es lo que forja a un verdadero profesional, capaz de superar el síndrome del impostor y de dejar una huella en cada línea de código.

En el camino del desarrollo, cada decisión –por mínima que parezca– está repleta de implicaciones. Es allí donde el balance entre la simplicidad pragmática y la búsqueda de calidad se hace esencial. La evolución es inevitable, y lo que hoy parece una limitación, mañana será la base de una mejor práctica. Es en ese constante pulir lo que reside la grandeza de trabajar en solitario.

Si trabajas en solitario o eres la única persona que se dedica al desarrollo en tu empresa este episodio te va a interesar.

Nuevo colaborador ¶

De todo esto hablaremos hoy con un nuevo colaborador de Web Reactiva: Abel Fernández.

Cada vez que nos visite Abel esta temporada tendremos un hilo conductor: el síndrome del impostor.

Un tema con muchas patas, aristas y sensaciones. Por eso nos hemos juntado dos impostores a hablar de ello.

¿Qué es el Bus Factor? ¶

Empezamos con matemáticas. Suena chungo, pero no lo es tanto.

Se trata de encontrar un número que identifique que el “número de developers que, si fueran atropellados por un autobús, dejarían al proyecto sin capacidad de reacción ni continuación”.

Si te quitan del medio, por el motivo que fuera (no siempre tiene que ser malo), ¿cuánto tiempo sobreviría el proyecto sin ti?

Trabajando en solitario ¶

Muchos nos enfrentamos a esto. También los proyectos grandes empiezan casi siempre con una sola persona detrás.

No sabes qué decisión es la correcta, no hay nadie a quién preguntar.

En el episodio repasaremos cómo se puede elegir un framework y qué documentación es la más adecuada para dejar al siguiente que llegue al proyecto.

¿Qué es aprender a programar en la "universidad de la calle"?

No lo sabemos, pero Abel nos lo contará cuando vuelva dentro de un mes. O no…

Enlaces de interés ¶

A Abel puedes encontrarlo en twitter como @abelintheuk.

Si quieres recibir 11 recursos nuevos sobre programación cada domingo apúntate a 🧨 newsletter de Web Reactiva, el newsletter que puedes leer mientras escuchas Webificando.

Una reseña interesante sobre Bus Factor y un proyecto para calcularlo en base a tu trabajo en github que nos dejó Sergi en el directo: Truck Factor Calculator.

¡Nos escuchamos pronto!