Name: TechLead Conference 2023
Start: 2023-03-09T15:00:00.000Z
End: 2023-03-10T20:00:00.000Z

Ser un Tech Lead suena como mucho trabajo. Y no del tipo de codificación divertida tampoco. ¿Por qué querrías eso? ¿Cómo se siente cuando lo consigues?En esta charla, Swizec explica por qué dio el paso hacia el liderazgo técnico, cómo cambiaron sus prioridades y por qué significa que está haciendo más ingeniería que nunca. Un mundo completamente nuevo donde escribir código es la parte fácil.

Sobre convertirse en un Tech Lead

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.

Swizec Teller

Seamos realistas: la deuda técnica es inevitable y reescribir tu código cada 6 meses no es una opción. La refactorización es un tema complejo que no tiene una solución única para todos. Las aplicaciones de frontend son particularmente sensibles debido a los frecuentes cambios de requisitos y flujos de usuario. Nuevas abstracciones, patrones actualizados y limpieza de esas viejas funciones - todo suena genial en papel, pero a menudo falla en la práctica: los todos se acumulan, los tickets terminan pudriéndose en el backlog y el código legado aparece en cada rincón de tu base de código. Por lo tanto, un proceso de refactorización continua es la única arma que tienes contra la deuda técnica.En los últimos tres años, he estado explorando diferentes estrategias y procesos para refactorizar el código. En esta charla describiré los componentes clave de un marco para abordar la refactorización y compartiré algunos de los aprendizajes acumulados en el camino. Espero que esto te ayude en tu búsqueda de mejorar la calidad del código de tus bases de código.

Un Marco para Gestionar la Deuda Técnica

Today's Talk discusses the importance of managing technical debt through refactoring practices, prioritization, and planning. Successful refactoring requires establishing guidelines, maintaining an inventory, and implementing a process. Celebrating success and ensuring resilience are key to building a strong refactoring culture. Visibility, support, and transparent communication are crucial for addressing technical debt effectively. The team's responsibilities, operating style, and availability should be transparent to product managers.

Alex Moldovan

Tus habilidades de comunicación afectan tus perspectivas de carrera, el valor que aportas a tu empresa y la probabilidad de tu promoción. Esta sesión te ayuda a comunicarte mejor en una variedad de situaciones profesionales, incluyendo reuniones, mensajes de correo electrónico, propuestas y presentaciones.

Comunicación Efectiva para Ingenieros

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.

Naz Delam

"Tal vez estoy engañando a todos... No soy lo suficientemente bueno para esto, y en este punto, es solo cuestión de tiempo hasta que todos se den cuenta". Estas podrían ser las palabras que cruzan tu mente cuando tu compañero te felicita por hacer otro trabajo fantástico al entregar una nueva funcionalidad. A medida que creces en tu carrera, también lo hace tu incertidumbre. Dedicas horas extras, aprendes todas las nuevas tecnologías y te unes a todas las iniciativas que puedes, pero al final del día, nunca parece ser suficiente. En este punto, ese sentimiento está guiando tus acciones y decisiones. Es lo que impulsa tu carrera. Solo una pregunta persiste: ¿Realmente eres un impostor?

Desarrollo impulsado por el síndrome del impostor

Imposter syndrome is a common experience that can lead to self-doubt and feeling like a fraud. The speaker shares their personal journey with imposter syndrome in school and throughout their career in software development. They discuss the challenges and doubts they faced, as well as the strategies they used to overcome imposter syndrome. The importance of support from managers, celebrating achievements, and sharing experiences to help others are highlighted. The talk emphasizes the need to embrace imposter syndrome and use it as a motivator for personal growth.

Daniel Afonso

Todos hemos experimentado la solicitud de empleo que nos obliga a realizar una prueba de codificación en línea. Tienes que repasar tus algoritmos, estructuras de datos, complejidad temporal y al final estás estudiando como si fuera un examen universitario. Ahora que somos nosotros los que generalmente entrevistamos a los candidatos, una buena pregunta para hacer es: "¿las pruebas de codificación en línea son el mejor indicador de la competencia y habilidad de un candidato?" En esta charla, exploraremos:<ul><li>- Los problemas de las pruebas similares a Leetcode</li><li>- Lo que deberíamos buscar en los candidatos</li><li>- Cómo la programación en pareja es la mejor manera de ver cómo un candidato trabajaría con el equipo</li><li>- Además, una pequeña demostración de una entrevista de programación en pareja remota</li></ul>

Por qué Leetcode está obsoleto y la programación en pareja para las entrevistas es el camino a seguir

The Talk discusses the problems with online coding tests and the benefits of pair programming interviews. It emphasizes the importance of hiring and growth, including creating a positive interview experience and considering the cost of hiring. The job of a software developer extends beyond coding and requires multiple skill sets. Pair programming provides a more accurate assessment of skills required for software development. The Talk also covers implementing a tennis scoring system and customizing pair programming interviews for different roles and levels.

Mo Khazali

Casi nadie en el mundo de la tecnología disfruta cuando hay mucha deuda técnica. Y a la mayoría de nosotros nos gustaría que no haya demasiada. Pero, ¿cómo entendemos cuánta tenemos exactamente? ¿Dónde se encuentra exactamente? ¿Qué parte de ella es realmente la más molesta? ¿Cuál sería el beneficio para nosotros si dedicamos tiempo a deshacernos de ella? Cuando se trata de planificar cómo abordar tu deuda técnica, todas estas preguntas merecen respuestas. Especialmente cuando nos preguntan sobre el retorno de la inversión en nuestros esfuerzos para eliminar cosas antiguas molestas y construir un nuevo módulo o servicio brillante. Además, cuando trabajamos en la deuda técnica, queremos abordar primero las partes más impactantes, ¿verdad? Esta charla trata sobre todo eso: cómo medimos nuestra deuda técnica, cómo interpretamos los resultados de estas mediciones para que nos den las respuestas a las preguntas correctas, y cómo guiamos nuestra toma de decisiones con esas respuestas.

Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados

This Talk discusses the measurement and interpretation of tech lead, focusing on tech debt. Tech debt is a tool to temporarily speed up development but can have negative consequences if not managed properly. Various tech debt metrics, including heuristic metrics and second-tier metrics, can help identify and manage tech debt. Tech debt interest is crucial for measuring the impact of tech debt and allows for prioritization. It is important to collect and analyze tech debt metrics to ensure software and team health.

Anton Kazakov

Sé que los desarrolladores sienten dudas al elegir el rol de IC sobre un gerente o viceversa. Hablaré sobre mi propio camino para encontrar mi propósito haciendo las cosas que me gustan.

Propósito: Lo que aprendí al renunciar como líder de equipo dos veces

The Talk discusses the importance of finding purpose and learning from past experiences in software development. It emphasizes the need to test different areas and reflect on experiences to find direction. Understanding one's purpose and the value it brings is crucial. Mistakes are seen as valuable insights for improvement.

Alex Ptakhin

A medida que trabajamos para construir la mejor solución de ingeniería de software posible, nos encontramos con muchas decisiones que debemos tomar. A diario. A veces esto implica conversaciones muy activas y apasionadas, que a veces pueden tomar un camino negativo, creando un mal ambiente en el equipo. Además, es una gran pérdida de tiempo. Pero ¿qué pasaría si esas decisiones diarias pudieran ser mucho más fáciles y simples? En esta charla intentaré abordar y eliminar los puntos dolorosos de la toma de decisiones en la ingeniería de software y mostraré cómo ayudé a mi equipo a beneficiarse de un proceso de toma de decisiones más ligero.

La Teoría del Juego en la Toma de Decisiones de Software

Today's talk is about the Game Theory of Software Decisions, exploring how game theory can be applied to software development. The speaker shares tips on creating a productive team environment and effective decision-making. They emphasize the importance of letting go of unimportant things and focusing on what's best for the project. The talk also discusses handling coding dilemmas and decision-making, suggesting strategies such as defining KPIs and consulting a neutral jury. The speaker concludes by emphasizing the importance of staying rational, bringing data, and maintaining professionalism in software development.

Ziv Levy

Comienzas como desarrollador junior, entregando líneas de código felizmente. La vida es fácil, te encanta tu trabajo, estás aprendiendo mucho. Y luego alguien se acerca a ti y dice: "Necesitamos un líder técnico para un nuevo equipo, y tú eres la persona más experimentada disponible". O te vuelves miserable o encuentras tu nuevo llamado, pero tu trabajo ya no es realmente lo que era antes. Y luego alguien se acerca a ti y dice: "Estamos buscando un nuevo gerente de ingeniería, y tú eres la persona más experimentada disponible".¿Es realmente el camino de carrera más óptimo? ¿Qué podríamos hacer de manera diferente? Veamos tus talentos y los talentos necesarios para el trabajo.Hay muchos trabajos diferentes en tecnología: escribir código, liderar equipos, gestionar personas y proyectos, ayudar a otros a usar tu tecnología, enseñar, investigar, depurar.

¿Realmente tienes que convertirte en un gerente para avanzar en tu carrera?

The Talk discusses the misconception that software career is a linear progression and shares a story of a software engineer turned engineering manager who wasn't happy. It explores the complexity of describing personality types in software engineering and the importance of considering talents, job meaning, and skill development when making career decisions. The Talk also emphasizes the significance of finding meaning in one's job, job crafting, and exploring different career paths. It concludes with the idea of challenging assumptions, assessing talents, and introspection for effective job crafting.

Marek Kalnik

Muchos de nosotros, al cambiar de trabajo o aceptar una promoción, nos sentimos abrumados por la oferta y o bien no pedimos más o pedimos un porcentaje más que la oferta. Hablemos sobre por qué eso no es suficiente y cómo podemos cambiar nuestra actitud hacia la negociación.

Negocia como si tu vida dependiera de ello

The Talk discusses the importance of negotiation, particularly in relation to the gender pay gap and gender parity. It emphasizes the need to address global reasons for negotiation and the impact of inflation and the cost of living. The Talk also highlights the values to consider when negotiating and provides tips on preparing for negotiation, making offers, and discussing perks. Recommended reading and references on negotiation are also provided.

Shivangi Das

Vamos a desechar todo y empezar de nuevo. Suena genial, ¿verdad? Aunque esto puede sentirse muy bien, rara vez acelera algo. Te mostraré por qué una reescritura completa generalmente no es lo que quieres.

La Trampa de la Reescritura

The Talk discusses the 'rewrite trap' in software development, where the urge to start from scratch often leads to poor outcomes. It emphasizes the importance of understanding the existing project before making big technical decisions and the benefits of gradual improvement. The Talk also highlights the challenges and pitfalls of a complete rewrite, such as false sense of productivity, problems with edge cases, and the accumulation of tech debt. It stresses the need to understand the system and its influences, cater to the needs of stakeholders outside of engineering, and focus on creating value.

Philipp Giese

La mentoría tiene la reputación de llevar mucho tiempo y trabajo. Pero, ¿y si no fuera así? Aquí te presentamos formas de conseguir un mentor, ser un mentor y cómo navegar por ello. Siempre he trabajado en conseguir mentores en cada etapa de mi carrera como ingeniero. Tengo mentores que ni siquiera saben que lo son. Pero me gusta así. Explicaré cómo conseguir un mentor en cualquier etapa de tu carrera como ingeniero y cómo ser un buen mentor/mentorado.

Cómo conseguir un mentor sin decírselo

This Talk explores the topic of mentorship, focusing on how to get a mentor without explicitly asking. It discusses the qualities of a good mentor and the importance of being a good mentee. The benefits of mentorship include personal growth, career advancement, and fostering a collaborative work culture. Strategies for finding mentors and mentees are provided, along with tips for navigating mentorship conversations. Overall, mentorship is seen as a powerful tool for learning, growth, and mutual support in the field of software engineering.

Erin Fox

Si eres un ser humano, es probable que en algún momento de tu vida te hayas sentido como un impostor. Uno de los mayores problemas con este síndrome es que es fácil quedarse atrapado con este sentimiento. No es fácil superar el síndrome del impostor. Requiere ofrecerte compasión y vulnerabilidad en lugar de juicio y autoduda. Pero... ¿cómo lograrlo exactamente? Analizaremos técnicas para lograr esto y superar el síndrome.

Cómo superar el síndrome del impostor

If you're a human being, chances are you felt like an imposter at some point in your life. One of the biggest risks we have to deal with in our day-to-day life is failure. Acknowledge your feelings of self-doubt and be specific about why you're feeling this way. Embrace self-compassion and vulnerability to overcome imposter syndrome. Take action by reminding yourself of your qualifications, seeking help from colleagues, and setting realistic goals. Embrace vulnerability, build confidence, and create a safe environment for your team.

Ursula Cervantes

El campo de las relaciones con los desarrolladores o DevRel está aumentando rápidamente en popularidad, con roles para defensores de desarrolladores, evangelistas, gerentes de programas y directores que parecen aparecer en todas partes. Es posible que también tenga colegas que trabajen en este campo. DevRel es una disciplina única alineada con todas las partes del negocio, desde ingeniería y producto, hasta marketing e incluso ventas, y actúa como un puente entre la empresa y la comunidad de desarrolladores en general. Nuestros incentivos alineados con el liderazgo de ingeniería son especialmente evidentes en el hecho de que existimos para servir y permitir a las audiencias de desarrolladores, ya sean externas o internas.Para los equipos de ingeniería, trabajar en estrecha colaboración con sus equipos de DevRel brinda una gran oportunidad para comprender mejor a sus audiencias de desarrolladores, elevar el perfil y las habilidades de sus colegas, y hacer que su empresa sea más atractiva para la contratación. Sin embargo, a pesar de que muchos equipos de DevRel son altamente técnicos, debido a la falta de enfoque percibida de DevRel, nuestros departamentos a menudo son descartados como "solo marketing" por parte de la ingeniería.En esta charla responderé la pregunta de "qué hacen las personas de DevRel" y presentaré algunos enfoques sobre cómo DevRel e ingeniería pueden colaborar mejor y derribar barreras para beneficiar a todos, desde la empresa hasta la comunidad de desarrolladores en general.

Lo que los líderes de ingeniería deben saber sobre DevRel (pero estaban demasiado ocupados para preguntar)

DevRel is about understanding the audience and collaborating with different departments. Dev Advocates bridge gaps between engineering and marketing, provide feedback, and stay updated on industry trends. DevRel helps raise team profiles, assists with editing and getting on podcasts, and aims to make engineers successful. Collaboration is key in DevRel.

Zan Markan

Los equipos de ingeniería a menudo enfrentan desafíos difíciles con recursos limitados. Si el trabajo requiere 1 ingeniero, asignamos uno al trabajo. Si requiere 2, dividimos los temas en partes accionables y los asignamos a individuos. Pero hay varios beneficios de hacer las cosas en pares: ayuda a detectar errores y bugs, permite una mejor comunicación y colaboración entre los miembros del equipo y también puede llevar a un código más eficiente y de mayor calidad, ya que los ingenieros pueden desafiar las suposiciones de sus compañeros y sugerir enfoques alternativos.

El poder de los pares

Pair programming is a collaborative software development technique where two developers work together at one workstation. It offers benefits such as easier code maintenance, faster code reviews, and reduced likelihood of bugs. Implementing pair programming involves finding compatible partners, setting goals, and establishing clear communication protocols. To address challenges, provide training and support, involve team members in decision-making, and carefully select partners. Pair programming can help achieve goals like collaboration, knowledge growth, code stability, and maintenance.

Octave Raimbault

Una forma de obtener una buena queja de tu equipo es mencionar la palabra "proceso". Los ingenieros en particular se preocupan de que el proceso signifique que su impulso se ralentizará o se detendrá, y generalmente tienen experiencia para justificar esa preocupación. Con una comprensión del flujo de trabajo y la individualización a alto nivel, esto no tiene que ser así. Como líder técnico y ahora gerente que ha convertido a muchos escépticos del proceso, estoy emocionado de mostrarte mis procesos para el proceso.

Procesos para los que evitan los procesos

This Talk discusses the foundation, formation, and iteration of process, emphasizing the benefits and building trust. It highlights the importance of optimizing processes, using life cycles and meetings to streamline workflow and avoid mistakes. Exposing work through demos and documentation fosters collaboration and provides more exposure opportunities. The Talk also emphasizes concise communication, tailoring processes to individual team members, and addressing challenges through effective communication. Automation is recommended to save time and streamline workflow, while maintaining a balance with personal interactions.

Tara Z. Manicsic

Todos hemos pasado por reorganizaciones de empresas, probablemente más de una vez. Si algunas son comprensibles y producen buenos resultados, otras no lo son, creando inseguridades, falta de confianza en el liderazgo, cambios innecesarios e incluso caminos de comunicación o toma de decisiones más complejos. ¿Cuál es la diferencia entonces? ¿Existe una forma probada de escalar o cambiar el panorama actual de las organizaciones de las empresas? Sí, la hay. En esta sesión, repasaré, respaldado por un caso de estudio real en la industria, la Ley de Conway y la importancia del panorama y las interacciones de los equipos, y cómo los gráficos de equipos bien diseñados pueden mejorar la independencia, autonomía y motivación de los equipos, lo que conduce a una entrega más rápida y de mejor calidad.

¿Por qué escalar de abajo hacia arriba? Cómo las interacciones de los equipos deben afectar la estructura organizativa

The Talk discusses the importance of organizational layout and Teams interactions in software development. It explores the challenges of organizational shards and the need for problem thinking to optimize team communication. The concepts of loose coupling, high cohesion, and clear domains of responsibility are explained. The Talk also emphasizes the three essential team interaction modes: working closely together, X as a service, and facilitation. Furthermore, it highlights the significance of understanding domains, boundaries, and domain-driven design for efficient work and fast delivery.

Vânia Santos

TechLead Conference is an online event for middle and senior software developers to get knowledge of how to become a tech lead of a team, how to grow professionally. The conference will be held on June 15 &amp; 19.

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

The conference is about leadership and seniority in teams. 20 engineers, managers and HR from leading companies will give talks on topics as careers and soft skills. We'll discuss how to become more senior and get more influence in the company, get a promotion and achieve what you want in your career.

TechLead Conference 2023

Evento sobre liderazgo y senioridad

Available in other languages: