Ama a tus Mantenedores

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Ningún desarrollador es una isla y ningún desarrollador es perfecto. Esto significa que no puedes crear nada sin usar componentes escritos por otra persona y estos componentes tendrán defectos o características faltantes. En algún momento de nuestra vida, todos hemos pedido apoyo a alguien más.

Pero ser un mantenedor no es una tarea fácil en absoluto. Piensa en recibir toneladas de informes con información parcial o faltante, o ser gritado por extraños por no ser lo suficientemente receptivo o rápido.

Para la salud de nuestra industria, debemos amar más a nuestros mantenedores: en esta charla mostraré cómo pedir ayuda de manera educada y cómo asegurarte de proporcionar toda la información necesaria.

This talk has been presented at C3 Dev Festival 2024, check out the latest edition of this Tech Conference.

Paolo Insogna
Paolo Insogna
19 min
15 Jun, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
El código abierto es un modelo de desarrollo de software descentralizado impulsado por la pasión, que mejora la calidad del software. La amabilidad es crucial en la comunidad de código abierto para prevenir el agotamiento y mantener una dinámica saludable. Al pedir ayuda, realiza una investigación exhaustiva y comunícate de manera efectiva. Los informes de problemas deben ser detallados y proporcionar información relevante. El seguimiento y la participación son importantes para encontrar soluciones y expresar gratitud a los mantenedores.
Available in English: Love Your Maintainers

1. Introducción al código abierto

Short description:

Hola, bienvenidos a Ama a tus Mantenedores! Soy Paolo, miembro del TSC de Node y ingeniero principal en Platformatic. El código abierto es un modelo de desarrollo de software descentralizado impulsado por la pasión de las personas. Ha demostrado mejorar la calidad del software y los servicios. El código abierto permite el acceso a una base diversa de desarrolladores y diferentes puntos de vista, lo que resulta en una mayor calidad.

♪♪♪ Hola. Bienvenidos a Ama a tus Mantenedores. En primer lugar, permítanme presentar mi empresa, que es Platformatic, la mejor manera de construir tu API de Node y construir tu backend de Node. Ofrecemos una solución automatizada integral para API, GraphQL, y servidores y servicios integrados. Échale un vistazo.

Ahora, el secreto está en las formas. Es cómo le pides a la gente que haga cosas. Permíteme demostrarte cómo. En primer lugar, me gustaría presentarme. Soy Paolo. Soy miembro del TSC de Node y también ingeniero principal en Platformatic. Puedes encontrar todos mis contactos allí abajo, especialmente mi sitio web, que acabo de rediseñar. Así que te animo a echar un vistazo y darme tu opinión, por favor. De acuerdo. Ahora, sigamos adelante.

¿Qué esperas, finges, del código abierto? ¿Cuál es el verbo correcto a usar? En primer lugar, aclaremos qué es en realidad el código abierto. El código abierto es un modelo de desarrollo de software descentralizado que fomenta la colaboración abierta y está impulsado, y aquí está la clave, por la pasión de las personas. Ahora, está funcionando y definitivamente está funcionando. El código abierto ha demostrado ser realmente efectivo cuando se trata de mejorar la calidad del software, los servicios, y en cierta medida, la vida de las personas.

Todo comenzó en los años setenta, en el movimiento del software libre que desafió el desarrollo tradicional basado en lucro como de costumbre. El problema es que en inglés, como te podrás imaginar, free significa demasiado. Significa tanto gratis como en no pagado como libre como en libertad. Es ambiguo. No pagado era el significado más entendido de la palabra. Por lo tanto, se cambió a código abierto, que es una rama del movimiento del software libre, para tener una comprensión clara de lo que significa. El código abierto es un software que se puede utilizar con fines comerciales sin renunciar, perdón, sin renunciar a la libertad. La libertad se mantiene. Ahora, ¿por qué alguien querría ir al código abierto? Porque, y permíteme citar aquí, puedes obtener lo mejor de lo mejor de lo mejor. Puedes acceder a una base de desarrolladores que ni siquiera está remotamente cerca físicamente de ti, y puedes acceder a diferentes culturas, antecedentes y capacidades, lo que significa diferentes puntos de vista. En todos los aspectos de la vida humana, esto ha demostrado ser un aumento en la calidad.

2. Understanding the Open Source Community Dynamics

Short description:

El código abierto es similar al trabajo remoto, pero la gran diferencia es que las personas están motivadas por la pasión, no por el dinero. Recuerda que los mantenedores no te deben nada. Evita exigir correcciones o características de manera incorrecta para evitar alejar a las personas. Es importante recordar que hay personas reales al otro lado de la pantalla, y incluso un pequeño acto de rudeza puede llevar al agotamiento. Un mensaje grosero puede tener consecuencias graves, como se vio en el proyecto LWJS gestionado por James Sumner.

Además, tienes bajos costos de mantenimiento porque el software de código abierto es mantenido por otras personas para ti, por lo que no necesitas una oficina, y si adoptas el código abierto, solo necesitas un servidor de control de versiones. Ahora, no necesitas una oficina, ¿verdad? Esto es presumible, entonces, ¿algo, ¿verdad? ¿Te suena? Bueno, el código abierto es similar al trabajo remoto, pero no lo es. Ten cuidado con esto, y esta es la clave del resto de esta charla completa. La gran diferencia es que las personas en el código abierto están motivadas por la pasión, no por el dinero, y además, no eres su jefe. Recuerda eso. No eres su jefe, por lo que no puedes exigir nada. Puedes pedir, pero no puedes exigir. No puedes dar órdenes. No puedes dar ninguna orden, pero en general, todos son amables si las personas son amables.

Ahora, recuerda, las personas en el código abierto están motivadas por la pasión. A los mantenedores les encanta, simplemente les encanta que uses su software. De lo contrario, nunca lo habrían abierto, pero debemos dar respeto a todos. Los mantenedores no te deben nada. Están dedicando su tiempo, su tiempo libre, su tiempo personal, su tiempo de hobby de forma gratuita por la pasión, pero no les estás pagando a menos que los patrocines, pero ese es un tema diferente. Recuerda que las acciones tienen consecuencias, como siempre. Si pretendes correcciones, si pretendes características, o si simplemente exiges atención de manera incorrecta, alejarás a las personas, como siempre sucede en cualquier otro aspecto social en el mundo. No es solo el código abierto. Esto se aplica a todo. Esta es una lección de vida general, si me permites darte una lección.

Además, lo que quieres hacer es evitar el agotamiento. No quieres que las personas simplemente se agoten. Recuerda que al otro lado de la pantalla hay otras personas. Hay personas que, como tú, tienen sentimientos, tienen necesidades y tienen trabajo en tiempo real. Tienen una vida real, tienen pasatiempos, tienen familia, tienen hijos a los que cuidar, y así sucesivamente. Incluso un pequeño acto de rudeza puede agotar a las personas. No lo olvides. Lo que crees que puede ser solo un pequeño acto de rudeza puede ser el enésimo que el mantenedor ha visto en estos días, y las personas se agotarán, y eventualmente abandonarán el software. Como puedes ver en la captura de pantalla, hice una captura de la página de GitHub del proyecto LWJS, que fue gestionado por James Sumner, que recibió un mensaje desagradable, desagradable, desagradable, y honestamente, completamente sin sentido por parte de una persona que fue capaz de poner una gran cantidad de palabras malsonantes, ofensas y rudeza en solo seis líneas de texto. James se agotó y dijo, sabes qué, ya terminé. Nadie está pagando por esto, por lo tanto, estoy retirando el proyecto.

3. Importancia de la Amabilidad en el Código Abierto

Short description:

El proyecto está desactivado y ahora nadie puede beneficiarse de él. Sé amable con las personas. El lado humano es lo que más me importa hoy en día.

El proyecto está desactivado, y ahora nadie puede beneficiarse realmente de mi trabajo en eso. Aún puedes bifurcarlo, obviamente, porque James era una buena persona, podría haber eliminado este proyecto por completo, pero era una buena persona. Decidió simplemente decir que el proyecto ahora está archivado. Si quieres bifurcarlo, ahora es tuyo. Ya no voy a dedicar mi tiempo a esto. Entonces, ¿esa rudeza inútil no llegó a ninguna parte, verdad? Por favor, evítalo. Sé amable con las personas. Sé muy amable con las personas. El lado humano es lo que más me importa hoy en día. Debemos ser amables con las personas con las que nos relacionamos en el código abierto y en general. En realidad, nunca es un problema.

4. Formas Efectivas de Pedir Ayuda en Código Abierto

Short description:

¿Cómo se pide ayuda en un proyecto de código abierto? Comienza con una búsqueda detallada. Primero, verifica los problemas y las solicitudes de extracción. Luego, analiza la base de código. Por último, consulta la documentación actualizada. No confíes en alguien más sin hacer tu propia investigación. Verifica dos veces si tienes un problema trivial. Comunícate en exceso en un mundo distribuido.

Ahora, supongamos que somos amables, que finalmente podemos comportarnos de la manera correcta. ¿Cómo se pide ayuda en un proyecto de código abierto? Bueno, en primer lugar, y te sorprenderá, tienes que buscar. Comienza con una búsqueda muy detallada. Esta es mi lista de prioridades cuando realmente tengo que buscar cosas, porque, por supuesto, uso software de código abierto, que no he escrito, así que eventualmente tengo que buscar problemas, ¿verdad? Perdón, para resolver problemas. Y en este caso, esta es mi lista de tareas pendientes cuando tengo que hacer una búsqueda.

Primero, comienzo con los problemas. Veamos si tengo un problema que alguien ya ha encontrado. Cuanto más fácil sea reproducir este problema, mayor será la probabilidad de que alguien ya lo haya informado y también de que ya esté solucionado, pero eso es otro tema. Ahora, si no encuentro nada en los problemas, paso a las solicitudes de extracción. Tal vez alguien haya notado que en lugar de presentar un problema directamente, propuso una solución para él. Así que las solicitudes de extracción son las siguientes. Luego está el code. Intenta sumergirte en la base de code si es posible y busca si ya hay alguna pista sobre cómo solucionar tu problema. Tal vez estés usando el software de manera incorrecta. La documentación actualizada, esa es la última opción. Tal vez haya una página muy ingeniosa en la documentación que tenga una solución no convencional para el problema o que especifique que este problema no se cubrirá porque podría serlo. Por supuesto, esta lista es después de que ya hayas leído la documentación sobre cómo usar el software porque asumo que ya lo hiciste. En otras palabras, por favor, no hagas que alguien te responda sin leer el maldito manual, ¿de acuerdo? Pero de todos modos, esa es mi lista.

Ahora, también tenía una nota al margen para hacer. Si tienes un problema realmente trivial para reproducir y nadie lo ha informado nunca y nadie ha enviado una solicitud de extracción para eso, amigo, lo estás usando de manera incorrecta. Te lo digo porque me ha pasado muchas veces. No pude encontrar ninguna solución. No pude explicar por qué nadie ha encontrado mi estúpido problema y luego me di cuenta de que el estúpido en todo este panorama era yo mismo. Así que ya sabes, verifica dos veces de todos modos. Otra cosa muy importante. Vivimos en un mundo distribuido. Vivimos en un mundo donde estamos distribuidos por todo el mundo, donde las personas provienen de diferentes culturas, por lo que tienen diferentes expectativas y conocimientos y experiencia. No solo hablo de código abierto. Hablo en general. Así que nunca te preocupes por comunicarte demasiado.

5. Informes Efectivos de Problemas en Código Abierto

Short description:

Proporciona tantos detalles como desees. No temas comunicarte en exceso. Proporciona quién, dónde, qué, cuándo y cómo al informar un problema. Reduce el problema. Solo proporciona el por qué si sabes cómo solucionarlo. Evita abrumar a los mantenedores con información inútil.

Proporciona tantos detalles como desees, tantos. Volveré sobre esto más adelante. Y no temas molestar a las personas con una comunicación excesiva. Cuantos más detalles, detalles importantes puedas dar, mejor será, porque piensa en esto, los mantenedores tienen su propia vida, por lo que es posible que no tengan tiempo para solicitar información adicional y probablemente, por lo tanto, no procesarán tu informe si les faltan información crucial. Así que no temas comunicarte en exceso. Y olvida, y esto te sorprenderá, trabajar en código abierto e informar problemas e investigar problemas es como ser un periodista. ¿Recuerdas las reglas de los cinco W? Quién, dónde, qué, cuándo, por qué y cómo. Es lo mismo. Comenzamos con quién y dónde. Por lo general, si estás informando un problema con un software, el quién es el propio software, ¿verdad? Pero no siempre es el caso porque podría ser solo una parte del software. Así que trata de ser explícito si puedes. Por supuesto, no proporciones información inútil, pero puedes.

Luego, y esto es lo más importante, qué y cuándo. Explica qué sucedió, qué no sucedió, y qué esperamos que el software haga realmente. Y cuándo sucedió, qué estábamos haciendo cuando eso sucedió, trata de proporcionar el contexto más completo que puedas. Luego está el cómo. Y recuerda, esto volverá. ¿Cuál es la forma más simple de reproducir el problema? No importa, quiero decir, tienes una aplicación increíble, tal vez solo estés usando un paquete. No creo que la authentication de tu aplicación importe para este paquete si el paquete no es el paquete de authentication. Así que no nos importa. Trata de reducir el problema. Esto volverá en un momento.

Ahora, un lector muy atento podría decir, amigo, olvidaste mencionar el por qué en la lista de los cinco W, ¿verdad? No lo he olvidado. Por qué algo sucede es controvertido porque si conoces el por qué, como reportero, significa que ya sabes cómo solucionar el problema. En ese caso, por favor proporciona una solicitud de extracción, o al menos proporciona una explicación detallada o un problema sobre cómo eventualmente resolver la solución. Tal vez no tengas la experiencia para tocar el código base, pero entiendes lo que está sucediendo. Pero por lo general no conoces el por qué, excepto en algunos casos. Así que no lo he olvidado realmente. Es importante, pero no es parte del resumen de esto. Lo siento, me salté una diapositiva. Ahora, estaba hablando de comunicarse en exceso, pero asegúrate de no abrumar a los mantenedores con información inútil.

6. Comunicación Efectiva en la Información de Problemas

Short description:

No te excedas en la comunicación, encuentra un compromiso entre la información necesaria y excesiva. Crea repositorios reproducibles para problemas, asegurando detalles mínimos y eliminando información sensible. Proporciona repositorios públicos para que los mantenedores puedan solucionar fácilmente el problema.

No tienes que preocuparte por comunicarte en exceso, pero tampoco puedes, por supuesto, excederte. Como dicen en latín, in metastat virtus, así que la virtud se encuentra en el medio. No puedes enviar toneladas de salida o tal vez gigabytes de salida en un problema porque nadie lo leerá. Además, los informes con mucha información probablemente distraerán a los mantenedores, lo cual hará que pierdan interés y ni siquiera miren el problema, incluso si están dispuestos a ayudar.

Además, esto es una consecuencia directa de todo esto, es por tu propio bien. Cuanta más información superflua proporciones, menos probabilidades hay de que se solucione tu problema, porque si pierdes la atención del mantenedor, estás acabado. Si el mantenedor ve mucha salida sin información interesante, no solucionará tu problema y te dejará solo.

Trata de encontrar un buen compromiso entre lo que necesita ser comunicado y todo lo que puedes comunicar. Luego llegamos al núcleo de la idea. La mejor manera de solicitar un problema, solicitar un informe para solucionarlo o cualquier cosa similar, es crear lo que se llaman repositorios reproducibles. Así que si obtienes un software, lo estás usando, puedes crear un repositorio solo para ese problema que solo contenga los detalles mínimos necesarios para reproducir el problema. Por supuesto, quieres eliminar toda la información sensible o maximizar su obfuscación, y por favor proporciona un repositorio público. De esta manera, los triadores o mantenedores pueden clonar tu repositorio, iniciar el repositorio, ver el problema, aislarlo y solucionarlo. Esa es, con mucho, la mejor manera de obtener una solución, ¿de acuerdo? No te voy a decir cómo crear esto, puedes buscarlo en línea, pero lo importante es que sea mínimo, aislado, público, sin información sensible. Si cumples con eso, estás bien.

7. Seguimiento y Participación Efectiva

Short description:

No olvides hacer seguimiento de los problemas que has reportado y proporcionar la información solicitada. Comparte tu opinión antes de que se resuelva el problema. Mantente actualizado con las notificaciones y participa en la búsqueda de soluciones. Prueba las nuevas características y proporciona comentarios de manera oportuna. Expresa gratitud y amabilidad hacia los mantenedores.

Sigamos adelante. El último advice que quiero darte es hacer seguimiento. Es muy molesto si presentas un problema y luego te olvidas de él, y finalmente regresas después de un mes diciendo, oh amigo, ¿se solucionó eso? Probablemente no lo esté. Si el mantenedor te pide inmediatamente más información, y tú nunca respondes, el mantenedor queda estancado. No tenemos una bola mágica, no podemos predecir el futuro, así que debes proporcionar toda la información que te pedimos para poder solucionar el problema.

Además, esta es tu única oportunidad de ser escuchado. Si el problema implica básicamente una funcionalidad que falta o una mejora que se puede hacer, y si quieres opinar y dar tu propia opinión, este es el último momento porque una vez que se resuelva el problema, se fusionará la nueva funcionalidad, se creará un nuevo PR, ya no tendrás voz. Por supuesto, puedes reportar un nuevo problema, pero el mantenedor puede que nunca lo cambie porque en realidad funciona. Y además, también está la versión semántica involucrada en el problema y demás.

Así que mi advice es configurar las notificaciones que leas. Por ejemplo, yo no uso las notificaciones de GitHub, prefiero recibir correos electrónicos de GitHub. Lo que más te convenga, asegúrate de estar al día con las tendencias y seguir la discussion.

Último paso, que es trivial ya que es de código abierto, pero probablemente es mejor decirlo, eres más que bienvenido a participar. Si tienes experiencia y entiendes lo que está sucediendo, proporciona una solución tú mismo. En lugar de presentar un problema, proporciona un PR. O si presentaste un problema y el mantenedor te dijo, oh, sabes que el problema está aquí, se soluciona de esta manera, eres más que bienvenido a proporcionar un PR que siga las indicaciones del mantenedor. No tienes que esperar a que el mantenedor lo solucione. Ahora, si no tienes la experiencia, en lugar de code, también puedes contribuir probando la nueva funcionalidad y el problema que el mantenedor solucionó para ti de inmediato. Así puedes apoyar realmente al mantenedor al decir que el problema ya no es un problema. He solucionado el problema, podemos seguir adelante con nuestras vidas.

Además, proporciona comentarios de inmediato. Simplemente quedarse en silencio y decir, está bien, he terminado. No es suficiente. Tal vez solo un comentario simple en el problema, decir, gracias amigo, lo solucionaste en la versión 1.2.3. Es absolutamente suficiente, pero al menos les haces saber que todo está bien, y luego pasas al siguiente problema. Y un último paso, no olvides agradecerles. De acuerdo, amigos. Una vez más, nosotros somos, y tú también si eres un mantenedor o si serás un mantenedor, seguimos siendo personas. Dependemos de la amabilidad, ¿de acuerdo? No olvides agradecer a las personas por el tiempo que te brindan. No es que el mantenedor te agradezca por el problema que presentaste, y tú les agradecerás por el problema que solucionaron.

8. Kindness and Gratitude in Supporting Maintain

Short description:

Recuerda la importancia de la amabilidad en el apoyo a los mantenedores. Sé amable al solicitar ayuda, apóyalos, contribuye si es posible, participa y expresa gratitud. Como dijo Esopo, ningún acto de amabilidad se desperdicia. Gracias y adiós.

Funciona así. Como normalmente agradeces a las personas cuando te pasan la sal, o algo así cuando estás almorzando, ¿de acuerdo? No lo olvides. Eso es muy importante.

Entonces, esa fue una breve descripción general de cómo puedes apoyar a tus mantenedores. Permíteme resumirlo para ti. Amabilidad, primero. Siempre. No te deben nada, y siempre es bueno ser amable cuando les pides a las personas que te ayuden. Apóyalos, estate disponible, contribuye si puedes. Participa y, una vez más, cortesía y amabilidad, y agradéceles. Una vez más, la amabilidad es la palabra clave.

Y por eso, como suelo hacer en mis charlas, me gusta terminar mis charlas con una cita famosa de alguien mucho, mucho, mucho más sabio que yo. Y hoy, elijo a Esopo, el escritor griego que dijo hace mucho tiempo, hablo de hace unos 2.600 años, o algo así. Ningún acto de amabilidad, por pequeño que sea, se desperdicia nunca. Siempre recordamos la amabilidad recibida, ¿de acuerdo? Recuerda eso. Eso es todo, he terminado por hoy. Muchas gracias, una vez más. Soy Paolo, NodeTSC e ingeniero principal en Platformatic, y fue un placer tenerte aquí hoy, escuchándome. Muchas gracias y adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós. Adiós.

9. Farewell and Goodbye

Short description:

Despedida, adiós y bye-bye.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Adiós.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Impacto: Creciendo como Ingeniero
React Summit 2022React Summit 2022
26 min
Impacto: Creciendo como Ingeniero
Top ContentPremium
This Talk explores the concepts of impact and growth in software engineering. It emphasizes the importance of finding ways to make the impossible possible and the role of mastery in expanding one's sphere of impact. The Talk also highlights the significance of understanding business problems and fostering a culture of collaboration and innovation. Effective communication, accountability, and decision-making are essential skills for engineers, and setting goals and finding sponsors can help drive career growth. Feedback, goal setting, and stepping outside of comfort zones are crucial for personal development and growth. Taking responsibility for one's own growth and finding opportunities for impact are key themes discussed in the Talk.
Sobre convertirse en un Tech Lead
TechLead Conference 2023TechLead Conference 2023
24 min
Sobre convertirse en un Tech Lead
Top ContentPremium
The role of a Tech Lead involves shaping the roadmap, helping the team be more effective, and working on important projects. Lessons learned include encouraging idea sharing, avoiding taking on all the work, and focusing on delegation. Tech Leads focus on the outcome, involve the team in decision-making, and make plans based on how different pieces will interact. The role of a Tech Lead is to focus on engineering and guide the team in figuring out how the whole system should fit together. Architecting can become problematic when it loses touch with the coding part, resulting in implementation issues.
Comunicación Efectiva para Ingenieros
TechLead Conference 2023TechLead Conference 2023
36 min
Comunicación Efectiva para Ingenieros
Top ContentPremium
Today's Talk covers the four building blocks of communication: people, message, context, and effective listening. It emphasizes the importance of considering the perspective of others and tailoring messages to the recipient. The Talk discusses different types and channels of communication, and the need to align them with the intended message. It also highlights the significance of soft skills in communication and provides techniques for effective communication and assessing soft skills in tech interviews. Cross-cultural communication and the impact of bluntness are explored as well.
Una Carrera Como Ingeniero de Software
React Advanced 2022React Advanced 2022
24 min
Una Carrera Como Ingeniero de Software
Code will be imperfect and perishable, so testing and debugging are crucial. Building relationships and being generous with code reviews are important for teams. Code ownership should belong to the team, not individuals. Prioritizing functionality over consistency can lead to more efficient development. Growing into a tech lead role requires building relationships and coaching skills.

Workshops on related topic

De Ingeniero a Líder: Un Masterclass para Líderes Tecnológicos Primerizos
TechLead Conference 2024TechLead Conference 2024
144 min
De Ingeniero a Líder: Un Masterclass para Líderes Tecnológicos Primerizos
Workshop
Andrew Murphy
Andrew Murphy
Transicionar de un rol de contribuidor individual a una posición de liderazgo, especialmente en la industria tecnológica de ritmo acelerado, es enormemente desafiante. La mayoría de los nuevos líderes no reciben ningún tipo de capacitación en los primeros 10 años de sus nuevas responsabilidades.Nuestro completo masterclass está diseñado para ayudar a los nuevos y emergentes líderes tecnológicos a comprender sus nuevos roles y adquirir las habilidades para convertirse en líderes seguros, felices y efectivos.
Managers Are From Mars, Devs Are From Venus
TechLead Conference 2024TechLead Conference 2024
111 min
Managers Are From Mars, Devs Are From Venus
Workshop
Mo Khazali
Mo Khazali
Una Guía para Desarrolladores sobre Cómo Comunicar, Convencer y Colaborar Efectivamente con los Stakeholders
Es una historia tan antigua como el tiempo: la colaboración entre desarrolladores y stakeholders de negocios ha sido durante mucho tiempo un desafío, con una falta de comunicación clara que a menudo deja a ambas partes frustradas. Los mejores desarrolladores pueden comprender profundamente las necesidades de sus contrapartes de negocios, comunicar efectivamente la estrategia técnica sin perder a la audiencia no técnica y convencer al negocio de tomar las decisiones correctas. Trabajando en una consultoría, he fallado y tenido éxito en arquitectar y “vender” visiones técnicas, aprendiendo muchas lecciones en el camino.Ya sea que trabajes en una empresa de productos, seas consultor/freelancer, o quieras aventurarte más allá de ser solo un desarrollador, la capacidad de convencer y comunicar claramente con los stakeholders puede diferenciarte en la industria tecnológica. Esto se vuelve aún más importante con el auge de GenAI y el mercado de desarrolladores cada vez más competitivo, ya que la resolución de problemas y la comunicación efectiva son clave para posicionarte.En esta masterclass, compartiré ejemplos del mundo real, tanto buenos como malos, y te guiaré a través de poner la teoría en práctica mediante dojos.
Diseñando una Carrera de Freelance Sostenible
React Advanced 2021React Advanced 2021
145 min
Diseñando una Carrera de Freelance Sostenible
Workshop
Alexander Weekes
Rodrigo Donini
2 authors
¿Te gustaría perseguir tus pasiones y tener más control sobre tu carrera? ¿Te gustaría tener flexibilidad de horario y ubicación y variedad de proyectos? ¿Te gustaría tener la estabilidad de trabajar a tiempo completo y recibir un pago constante? Miles de empresas han adoptado el trabajo remoto y se dan cuenta de que tienen acceso a un grupo de talentos global. Esto es ventajoso para cualquier persona que haya considerado o esté considerando trabajar como freelance.>> Envía tu interés en convertirte en un ingeniero freelance con Toptal y recibir una llamada de un especialista en adquisición de talento <<

El trabajo freelance ya no es una elección de carrera inestable.

Este masterclass te ayudará a diseñar una carrera de freelance a tiempo completo (o parcial) sostenible y rentable. Te daremos herramientas, consejos, mejores prácticas y te ayudaremos a evitar errores comunes.
Tabla de contenidos

Módulo 1: Desmitificando los mitos comunes sobre el trabajo freelance
Módulo 2: ¿Cómo se ve el trabajo freelance en 2021 y más allá?
Módulo 3: Elecciones freelance y qué buscar (y qué evitar)
Módulo 4: Beneficios del trabajo freelance desde la perspectiva de un freelancer + estudio de caso
DESCANSO
Módulo 6: Cómo comenzar a trabajar como freelance (experiencia, currículum, preparación)
Módulo 7: Caminos comunes hacia el trabajo freelance a tiempo completo
Módulo 8: Aspectos esenciales: establecer tu tarifa y conseguir trabajo
Módulo 9: Próximos pasos: establecer contactos con colegas, mejorar tus habilidades, cambiar el mundo
Módulo 10: Preguntas y respuestas con freelancers
Cómo Diseñar una Carrera de Freelance/Contratación Sostenible + Desafío de Codificación Rápida
React Summit 2022React Summit 2022
75 min
Cómo Diseñar una Carrera de Freelance/Contratación Sostenible + Desafío de Codificación Rápida
Workshop
Shane Ketterman
Shane Ketterman
¿Listo para comenzar tu carrera como freelance o recién estás comenzando en tu viaje freelance? Estás en el lugar correcto. Aprende de la fuerza laboral totalmente distribuida más grande del mundo.
El movimiento de talento independiente es el futuro del trabajo. Si estás considerando dejar el empleo a tiempo completo para una carrera como freelancer, ahora es el momento de encontrar tu espacio exitoso en la fuerza laboral de talento independiente. Más personas están trabajando como freelance hoy que nunca antes, y el mercado freelance ahora contribuye con $1.2 billones a la economía de los Estados Unidos. Algunos de los roles más demandados para freelancers en este momento son desarrolladores senior con experiencia profesional en React, Python, Blockchain, QA y Node.js.
Este masterclass te ayudará a diseñar una carrera de freelance/contratación sostenible y rentable a tiempo completo (o parcial). Te proporcionaremos herramientas, consejos, mejores prácticas y te ayudaremos a evitar errores comunes.
Al final del masterclass habrá una sesión de preguntas y respuestas con un Desarrollador Freelance que puede responder tus preguntas y brindar información y consejos sobre su propio éxito.
¡Durante el descanso del masterclass, realizaremos un desafío de codificación rápida! Al final del masterclass, otorgaremos un premio al ganador y mostraremos la tabla de clasificación.
Te haremos iniciar sesión en nuestro portal y completar el desafío lo más rápido posible para ganar puntos. Los puntos se asignan en función de la dificultad y la velocidad con la que resuelvas las tareas. En caso de que completes todas las tareas, obtendrás puntos extra por el tiempo restante. Verás tu puntaje, clasificación y la tabla de clasificación una vez que completes el desafío.
Estaremos regalando tres Tarjetas de Regalo de Amazon ($200, $100, $75) para los tres primeros ganadores.
Fuera de la sartén, al fuego: Guía para gerentes sobre cómo ayudar a los nuevos desarrolladores a prosperar
TechLead Conference 2024TechLead Conference 2024
35 min
Fuera de la sartén, al fuego: Guía para gerentes sobre cómo ayudar a los nuevos desarrolladores a prosperar
Workshop
Andrew Coleburn
Andrew Coleburn
Integrarse a un nuevo proyecto puede ser difícil, sin importar tu experiencia y antecedentes. Pero puede ser especialmente desafiante para los nuevos desarrolladores recién salidos de la escuela o de un bootcamp de programación. Basándose en su experiencia personal como graduado de un bootcamp y consultor de JavaScript, esta charla discutirá consejos y estrategias para que los gerentes ayuden a los nuevos desarrolladores de sus equipos a familiarizarse con un código desconocido, para que puedan tener un impacto más rápido y efectivo.
Aterrizando tu Próximo Trabajo de Desarrollador
React Summit Remote Edition 2021React Summit Remote Edition 2021
121 min
Aterrizando tu Próximo Trabajo de Desarrollador
Workshop
Sadek Drobi
Nouha Chhih
Francois Bohyn
3 authors
Renaud Bressant (Jefe de Producto), Nathanael Lamellière (Jefe de Éxito del Cliente e Ingeniero de Soluciones), Nouha Chhih (Gerente de Experiencia del Desarrollador) estarán analizando los diferentes trabajos de desarrollador que puedes encontrar al buscar tu próximo rol de desarrollador. Explicaremos los detalles de cada rol para ayudarte a identificar cuál podría ser tu próximo movimiento. También compartiremos consejos para ayudarte a navegar por el proceso de contratación, basados en los diferentes roles para los que hemos entrevistado como reclutadores, pero también como candidatos. Esta será más bien una sesión de Pregúntanos lo que quieras, así que no dudes en compartir tus pensamientos y preguntas durante la sesión.