- Aunque la suerte parece un factor externo imposible de controlar, puedes aumentar la probabilidad de encontrar buenas oportunidades publicando tu trabajo
- La superficie de suerte (Luck Surface Area) se define como el producto entre cuánto haces cosas (Doing Things) y cuánto se lo cuentas a otras personas (Telling People)
- Hacer el trabajo y publicarlo es un proceso esencial para creadores como desarrolladores y diseñadores, y una forma de mostrar la curiosidad y la experiencia de cada persona
- Más que esperar un resultado perfecto, lo importante es compartir también el proceso, lo aprendido y el ensayo y error, porque eso puede inspirar a otras personas
- El trabajo publicado puede generar oportunidades inesperadas, como nuevos empleos, colaboraciones, charlas y conexiones con comunidades; no es simple suerte, sino un resultado probabilístico creado por el acto de compartir
El concepto de superficie de suerte
- La suerte se define como “que ocurra algo bueno e inesperado”
- Ejemplos: el éxito de una librería OSS, una invitación a una conferencia, una nueva oferta de trabajo, conseguir clientes, aparecer en un pódcast, crear contactos dentro de una comunidad, etc.
- Según la definición de Jason Roberts, la superficie de suerte (Luck Surface Area) es proporcional al producto entre “el grado en que haces algo con pasión” y “la cantidad de personas a las que se lo comunicas de forma efectiva”
- En fórmula: Luck = [Doing Things] × [Telling People]
- Cuanto más haces y a más personas se lo cuentas, mayor es tu superficie de suerte
Hacer el trabajo (Doing the work)
- Antes de publicar, primero hace falta hacer trabajo real
- Los desarrolladores, diseñadores y creadores son, por naturaleza, personas que construyen cosas, y eso es la base de la suerte
- Hay dos tipos de personas
1. Quienes ya hacen muchas cosas, pero piensan que su trabajo no vale la pena compartirlo
2. Quienes quieren empezar algo, pero no logran ejecutarlo
- El primer grupo tiende a subestimar el valor de lo que sabe, y al observar lo que se comparte en la comunidad puede darse cuenta de que ya hay muchas cosas que puede aportar
- Para el segundo grupo, hace falta empezar con algo pequeño
- No hay que esperar la idea perfecta; hay que comenzar con proyectos pequeños o experimentos
- “El movimiento genera movimiento”
Mostrar curiosidad y experiencia
- Los proyectos personales son un buen espacio para explorar la curiosidad
- Ejemplos: crear una impresora de recibos que imprima issues de GitHub, convertir una bodega prefabricada en oficina, desarrollar una herramienta de dibujo SVG, escribir un newsletter extenso sobre infraestructura financiera, etc.
- Los proyectos del trabajo son un buen terreno para demostrar experiencia
- Los problemas resueltos o aprendizajes obtenidos en el trabajo pueden convertirse en blogs, presentaciones o proyectos open source
- Aunque algunos detalles sean confidenciales, todavía se pueden compartir conceptos, aprendizajes y patrones
- Si durante un mes registras problemas o patrones interesantes que aparezcan en tu trabajo, tendrás muchas ideas para compartir
Publicar (Hitting the publish button)
- Muchas personas sienten miedo en la etapa de compartir
- Las razones incluyen el miedo a la crítica, el perfeccionismo o el rechazo al marketing
- Pero compartir no es arrogancia, sino una forma de expandir el aprendizaje, un proceso que inspira y ayuda a otras personas a aprender
- La plataforma para publicar puede ser Twitter, GitHub, un blog, un newsletter, YouTube, etc.; basta con que esté “en algún lugar que no sea tu disco duro”
- Compartir es una habilidad que se aprende, y es importante no solo mostrar el resultado final, sino también el proceso, los errores y la forma de pensar
- Al principio se siente extraño, pero con la práctica se vuelve natural
Capturar la suerte (Capturing the luck)
- Cuando publicas tu trabajo, aumenta la posibilidad de que ocurran resultados positivos inesperados
- Ejemplos: ser reconocido como especialista en un tema, recibir comentarios de lectores, obtener propuestas laborales, consultas de clientes, invitaciones para dar charlas, crear contactos dentro de una comunidad, aumentar la visibilidad de un proyecto OSS, etc.
- Estos casos son experiencias reales del autor y muestran el resultado de expandir la superficie de suerte mediante el acto de compartir
- La fórmula central es simple
- Do the work. Tell people.
- Explorar a fondo la curiosidad y la experiencia propias, y compartir públicamente lo aprendido
- No se puede evitar por completo la crítica en internet, pero hay muchas más personas apoyando en silencio que criticando
- Y al final, una de esas personas puede ofrecer la oportunidad que te cambie la vida
3 comentarios
Una de las cosas que siempre les recalcaba a los juniors era
"organicen bien lo que resolvieron y déjenlo publicado en un post público".
Primero, al ordenarlo vuelves a revisar todo el proceso una vez más, así que es más fácil recordarlo,
y aunque te topes con el mismo problema, si lo buscas en Google aparece tu propio post y puedes resolverlo rápido (¡gracias, yo del pasado!),
y además puede ayudarle a alguien, así que también puede mejorar tu reputación.
Comentarios en Hacker News
Como alguien que ha trabajado en la industria del open source (OSS), de verdad espero que mis proyectos de GitHub no se vuelvan famosos
Tengo proyectos experimentales con más de 50 estrellas, pero por suerte no evolucionaron a OSS “de verdad”
También he perdido fines de semana por solicitudes de corrección de bugs en proyectos viejos o por revisar PRs que no me interesaban
Mantener OSS se parece más a un trabajo de medio tiempo sin paga. La fama también es limitada, e incluso grandes desarrolladores de OSS tienen dificultades para encontrar empleos adecuados en la industria
Creo que los mantenedores de OSS son como santos que sostienen el software del mundo
Estaría bien agregar insignias de estado en el README de GitHub como “PRs bienvenidos”, “solo corrijo fallos de seguridad o bugs críticos” o “se busca nuevo mantenedor”
Por eso últimamente surge la duda de “¿por qué habría que aceptar este contrato social?”
Una alternativa es la operación autónoma de proyectos mediante comunidades Git autohospedadas. Ese enfoque puede volver a hacer divertido el open source sin convertir el esfuerzo del mantenedor en mercancía
Por ejemplo, si llega un PR a un repositorio que no se toca desde hace 5 años, podría ofrecer automáticamente un resumen para code review o introducir una función para filtrar comentarios groseros
Si no publicas el código, es difícil construir confianza con la comunidad, y un enfoque tipo “déjanos tu email y te mandamos un PDF con el whitepaper” ya no funciona en 2025
El 100% de 0 dólares sigue siendo 0, pero el 0.001% de un mercado enorme también puede ser una gran oportunidad
Si uno ve el punto central de este post, al final la estructura es que alguien más (normalmente una empresa) obtiene el mayor beneficio de publicar open source
Ahí está también la razón por la que GitHub (=Microsoft) inevitablemente puede verse como una “máquina de extraer trabajo gratis”
Si fuera un texto equilibrado, debería haber advertido sobre este conflicto de intereses
A las empresas les encanta nuestro trabajo gratis, pero no contratan. Es algo como “gracias, nos sirvió mucho, pero no vamos a contratarte”
Y ahora además nuestro código es absorbido como datos de entrenamiento para LLMs y ni siquiera queda nuestro nombre
Siento como si arrojara textos al mar y no escuchara ninguna respuesta
La plataforma susurra “si publicas una vez más, vas a lograrlo”, pero a veces dudo de que eso sea cierto
Una persona tuvo éxito en 3 años con marketing guiado por el producto, y otra monetizó OSS después de construir audiencia durante 5 años con un blog
Al final, eso de “aumentar la suerte” se parece más a un eslogan motivacional, pero en la práctica hacen falta al menos 5 o 6 años de esfuerzo constante
Nuestros textos son absorbidos como datos de entrenamiento por empresas, los lectores les pagan a ellas, y nosotros ni siquiera recibimos un agradecimiento
La única excepción son las comunidades cerradas donde todavía es posible el intercambio directo entre personas
Yo también conecté profundamente con este texto
Gracias a OSS recibí propuestas de varias empresas sin currículum ni pruebas de código
Una vez, mientras hacía debugging de un bug junto con soporte al cliente de GitHub, un Microsoft MD me recomendó, y en Cloudflare me pasó algo parecido
Al final, OSS es una herramienta para construir una red basada en la confianza
Escribiendo libros y firmando ejemplares en conferencias, las oportunidades fueron apareciendo de manera natural
Las etapas del open source, como yo las veo, son estas
1. Encontrar un punto de dolor en mi trabajo
2. Crear una herramienta que resuelva ese problema
3. Compartirla de forma natural en Reddit, HN, Bluesky, etc.
El open source es una forma de emitir señales. Si sale bien, se vuelve una tarjeta de presentación y puede abrir puertas a consultoría o empleos
Por ejemplo, en abril de 2023 vi LangChain e hice Langroid LLM agent framework, y
también mantengo una colección de herramientas CLI llamada Claude Code Tools.
Ese proceso hace que el open source sea un medio para acumular confianza similar a la publicación académica
(Sátira) “¡Hola, siervos del open source! ¡Denos más datos para que nuestra IA pueda reemplazar sus empleos!”
He escrito algunos libros de matemáticas, y aunque mi suerte aumentó un poco, no recuperé ni siquiera el equivalente al salario mínimo por 1200 horas de trabajo
Yo también he conseguido buenos trabajos varias veces publicando cosas. No me hice rico, pero sí ayudó mucho a mi carrera
(Autor) Escribí este post hace algunos años, y me da gusto volver a verlo en HN
En el hilo de aquel entonces también hubo una discusión parecida
Mucha gente dice que esto es “alimentar a la máquina”, pero este post me cambió la vida. Espero que también le sirva a otros
Veo que el cargo del autor es “Aaron Francis, Marketing Engineer”, y me hace preguntarme si ahora también al marketing se le llama ingeniería
Mi perfil de GitHub
> Luck = [Doing Things] × [Telling People]
Creo que vi esta fórmula hace unos años también, pero no la puse mucho en práctica durante todo este tiempo.