Imagina ser un caballero preparándose para un torneo de justas, pero tu caballo está más interesado en las pacas de heno de la feria que en tu duelo inminente. Eso es lo que a veces puede sentirse al preparar tu departamento de tecnología para una ronda de inversión o una salida. Esta charla proporciona una mirada en profundidad al papel de un ingeniero de frontend, especialmente trabajando con React, en la preparación de un departamento de tecnología para una ronda de inversión o una salida. A través de una lente única de diligencia técnica, la presentación descubre la importancia de las buenas prácticas, la arquitectura sólida, la documentación eficiente y más.
This talk has been presented at React Day Berlin 2023, check out the latest edition of this React Conference.
FAQ
La due diligence tecnológica es un proceso exhaustivo utilizado para evaluar la dirección futura de un producto o de toda una empresa. Implica un análisis profundo de la tecnología, procesos y personas para entender la robustez técnica, la escalabilidad y la sostenibilidad futura de la tecnología que soporta una empresa.
Durante un TechDD, se exploran varias áreas clave como la estructura del equipo técnico, la cultura del equipo, la escalabilidad del producto, la pila tecnológica utilizada, los activos tecnológicos, la gestión del producto, el desarrollo del producto y un análisis competitivo. También se incluye una evaluación legal y de propiedad intelectual.
El resultado de un TechDD es un informe detallado que ofrece insights sobre la salud técnica de una empresa. Este informe identifica fortalezas, debilidades, oportunidades de mejora y riesgos potenciales, a menudo respaldados por visualizaciones gráficas para facilitar la comprensión.
El proceso de due diligence tecnológica suele extenderse durante unas pocas semanas. Este tiempo permite realizar un análisis en profundidad sin interrumpir significativamente las operaciones diarias de la empresa.
Los ingenieros de software pueden prepararse para un TechDD asegurándose de que siguen buenas prácticas de desarrollo, manteniendo la documentación actualizada y asegurando que su código y dependencias estén bien gestionados y actualizados. La preparación incluye también entender y gestionar correctamente las licencias de software y optimizar la automatización y la infraestructura de código.
El uso incorrecto de licencias open-source puede llevar a riesgos legales significativos durante un TechDD. Es importante entender las restricciones de cada licencia y mantener un seguimiento riguroso de sus actualizaciones para evitar complicaciones que puedan afectar las operaciones y el cumplimiento legal de la empresa.
Las 'señales de alerta' en un TechDD son problemas o hallazgos que indican preocupaciones serias con la estrategia tecnológica de una empresa o su implementación. Estas señales se evalúan en función de su gravedad, el esfuerzo necesario para resolverlas y el tiempo estimado para su solución, y pueden influir significativamente en las operaciones tecnológicas y el éxito empresarial.
La diligencia técnica es un examen exhaustivo que puede influir en el futuro de un producto o empresa, e implica analizar la arquitectura técnica, la base de código, la cultura del equipo y más. Los ingenieros de frontend juegan un papel crucial en el puente entre el diseño y la funcionalidad. La automatización, la infraestructura y la documentación son áreas clave en la diligencia técnica. Las mejores prácticas, el código limpio y las conexiones de mercado son importantes para la venta. La diligencia técnica requiere acceso a datos y medidas de seguridad, y las empresas pueden ser reacias a cooperar plenamente.
Antes de sumergirnos en el mundo de la due diligence tecnológica, permíteme compartir un poco sobre quién soy y mi experiencia en ingeniería frontend. Nuestro papel en Tech Miners es guiar y elevar a las empresas a través de la due diligence tecnológica basada en datos. Nos familiarizaremos con los aspectos esenciales de la due diligence tecnológica y proporcionaremos ideas prácticas sobre cómo prepararse para el proceso.
Muy bien. Antes de sumergirnos en el mundo de la due diligence tecnológica, permíteme compartir un poco sobre quién soy y mi experiencia en el ámbito de la ingeniería frontend. Y no te preocupes, planeo mantener las cosas ligeras. Un agradable cambio de ritmo de las charlas más técnicas a las que podrías estar acostumbrado durante el Día de React en Berlín. Así que empecemos. Mi nombre es Armin. A lo largo de los años, he trabajado en varios proyectos, utilizando React extensivamente, y he visto de primera mano cómo las decisiones que tomamos como ingenieros frontend pueden dar forma a la trayectoria de un producto, equipo, o incluso de toda la empresa. Así que pasemos a la imagen más grande aquí. ¿Qué nos impulsa en Tech Miners y cómo sienta las bases para nuestra charla de hoy? En Tech Miners, nuestro papel no es solo evaluar, sino guiar y elevar. Nuestro enfoque único de la due diligence tecnológica es data-driven, profundizando en procesos, personas y tecnología. Hemos ayudado a innumerables empresas a prepararse para hitos significativos, desde rondas de inversión hasta salidas. Pero toda esta charla sobre la due diligence tecnológica podría hacerte preguntarte, ¿qué es realmente? Así que vamos a desmitificar eso. Nuestra presentación de hoy está estructurada en dos segmentos principales. Primero, nos familiarizaremos con los aspectos esenciales de la due diligence tecnológica, qué es y por qué es tan importante en nuestro papel, en nuestro campo. Después de eso, profundizaremos en algunas ideas prácticas sobre cómo podemos prepararnos de manera efectiva
2. Resumen de la Due Diligence Tecnológica
Short description:
Al final de nuestra charla, espero que comprendas mejor la due diligence tecnológica y tengas ideas para mejorar tu trabajo. La due diligence tecnológica es un examen exhaustivo que puede influir en el futuro de un producto o empresa. Es fundamental para los inversores entender la robustez y escalabilidad de la tecnología. El proceso implica analizar la arquitectura técnica, la base de código, la cultura del equipo, la escalabilidad del producto, la pila tecnológica, los activos tecnológicos, la gestión del producto, la hoja de ruta de desarrollo y la sección legal/PI. El resultado es un informe detallado que identifica fortalezas, debilidades, oportunidades y riesgos. Las señales de alerta indican problemas graves que pueden afectar las operaciones tecnológicas de una empresa y el éxito empresarial.
para tal proceso. Así que al final de nuestra charla, espero que no solo comprendas mejor la due diligence tecnológica, sino que también tengas algunas ideas sobre cómo mejorar tu trabajo, ya sea tu equipo o tu producto. Así que antes de empezar, quiero hacerte una pregunta aquí. Levanta la mano si ya estás familiarizado con lo que es la due diligence tecnológica. Bien, ¿cinco, seis quizás? Eso está bastante bien. Para eso estoy aquí. Así que no te preocupes. Lo esperaba. La verdad es que, en el acelerado mundo del desarrollo de software, ya seas parte de una startup ágil, ansiosa por su primera ronda de financiación, o un jugador clave en una empresa tecnológica bien establecida, considerándola una adquisición estratégica, el concepto de due diligence tecnológica es uno que es muy probable que encuentres en algún momento de tu career. Tenemos varias forms de due diligence, pero hoy nuestro foco está en TechDD, que nos involucra directamente como ingenieros de software.
Así que la due diligence tecnológica no es solo una casilla para marcar. Es un examen exhaustivo que puede influir en la dirección futura de un producto o de toda la empresa. Por supuesto, por otro lado, también es bastante crítico para los inversores, los stakeholders y los posibles compradores entender la robustez técnica, la scalability, y la prueba de futuro de la tecnología que sustenta la empresa que realmente les interesa. Un robusto, digamos, TechDD implica varios pasos clave, desde comenzar con una sesión de inicio para definir los alcances y objetivos, hasta el análisis exhaustivo de la architecture técnica y la base de código. El proceso se suele extender durante unas pocas semanas para asegurar un análisis en profundidad sin interrumpir significativamente las operaciones diarias de la empresa. Las áreas que se explorarán durante un TechDD son el equipo técnico, la cultura del equipo, de los cuales estamos aquí, la scalability del producto, la pila tecnológica, por supuesto, qué frameworks están usando, lenguajes, elección de herramientas. Los activos tecnológicos, que es básicamente donde obtenemos acceso a los data, obtenemos la mayor cantidad de data posible que podemos, y procesamos para extraer algunos insights. Gestión del producto, hoja de ruta de desarrollo del producto, quizás también incluso un análisis competitivo. Y por último, la sección legal y de PI, que podría ser bastante crítica para empresas quizás en el sector de la ciberseguridad o del seguro, digamos.
El resultado de un TechDD es un informe detallado que proporciona insights sobre la salud técnica de una empresa. Identifica fortalezas, debilidades, oportunidades de mejora, y riesgos potenciales. Los hallazgos son casi el elemento más importante de cualquier informe de TechDD. En este contexto, un hallazgo se refiere a una pieza de información significativa que se ha descubierto durante el proceso de TechDD. Cada hallazgo es impulsado por data y a menudo está respaldado por ayudas visuales como gráficos para una mejor comprensión. Miran diferentes cosas, como cuán serio es un problema, o si podría resolverse fácilmente. Este enfoque, por supuesto, nos ayuda a clasificar qué problemas son importantes y cuáles no, y a detectar cualquier preocupación importante o señales de alerta. Las señales de alerta en la due diligence tecnológica son esencialmente una combinación de problemas o hallazgos que señalan problemas potencialmente graves con la estrategia tecnológica de una empresa o su implementación. Las señales de alerta no son solo algunas alertas simples. Se evalúan en función de cuán fácilmente se pueden solucionar, la cantidad de esfuerzo y recursos necesarios para abordar el problema, y la duración estimada para resolver el problema. Aunque no es, diría yo, aunque no es relativamente frecuente que cualquier empresa que se someta a un TechDD tenga una señal de alerta, tener una señal de alerta es algo de lo que definitivamente hay que preocuparse, porque podrían afectar significativamente las operaciones tecnológicas de una empresa, y por extensión, su éxito empresarial. Ahora que hemos entendido el concepto de TechDD, te preguntarás, ¿dónde encajo yo, como ingeniero de software, en esta imagen?
3. Ingenieros de Front-end y Preparación para la TechDD
Short description:
Los ingenieros de front-end juegan un papel crucial en el puente entre el diseño y la funcionalidad. Para prepararse para la TechDD, familiarízate con el proceso y comprende la importancia de la infraestructura de código. Los ejemplos del mundo real proporcionarán información sobre problemas comunes. Recuerda que las señales de alerta y los hallazgos son relativos. Ahora, vamos a profundizar en el área crítica de las dependencias y las licencias, donde el código abierto no siempre significa uso sin restricciones. Comprender la licencia y el mantenimiento es esencial.
Así que vamos a desentrañar eso. Los ingenieros de front-end, como muchos de nosotros aquí, son el puente entre design y funcionalidad. Nuestro papel es fundamental, pero ¿cómo se entrelaza con la TechDD? Todos ustedes están como, como si ser un ingeniero de software ya no fuera como un paseo por el parque, codificación sin fin, mantenerse al día con la pila siempre cambiante, como estoy hablando de dos grandes lanzamientos de Next, supongo, cada seis meses, ¿verdad? Sí, ya estás familiarizado con eso. Pero no te preocupes. En realidad no necesitas hacer demasiado extra para estar preparado para una TechDD. Eso es, por supuesto, si ya estás haciendo las cosas bien. Así que vamos a la parte de cómo prepararse. La preparación es la clave del éxito en casi todos los empeños. En el ámbito de la TechDD, nuestra infraestructura de código sienta las bases. Los ejemplos que vamos a explorar en los próximos minutos son algunos de los problemas más significativos o comúnmente pasados por alto basados en nuestra experiencia de la TechDD del mundo real. Creo que este enfoque nos ayudará a obtener una mejor comprensión de cómo se ve esto en la práctica y cómo pueden impactar en el entorno tecnológico. Sin embargo, es crucial recordar que las señales de alerta y los hallazgos son altamente relativos. El mismo problema o hallazgo podría ser en la situación de una empresa un gran problema, un caso enorme, pero el mismo problema podría ser como nada realmente importante, por supuesto, de nuevo, basado en la situación de la empresa. Así que por eso cada situación exige una respuesta personalizada, considerando las características y necesidades únicas de la empresa. Así que vamos a prepararnos. La primera parte de la preparación para cualquier cosa es conocer la cosa en sí. Aquí tampoco hay excepción. Afortunadamente, ya estamos familiarizados con los aspectos esenciales de la TechDD, como sus pasos, objetivos y lo que busca. Así que el primer paso ya está hecho. No fue difícil, ¿verdad? Así que hasta aquí, un rápido resumen. Hacemos TechDD. Aprendes qué es TechDD. Ahora vamos a ver algunos ejemplos del mundo real de nuestras TechDDs, y eso nos ayudará a prepararnos mejor para tal proceso, o en general a mejorar en eso. Ahora, vamos a profundizar en nuestra primera sección, dependencias y licencias. Esta es un área crítica en la TechDD, especialmente para los productos SaaS. Lo importante aquí es recordar que open-source no siempre equivale a libre de usar sin ninguna restricción. Malinterpretar esto puede llevar a riesgos legales significativos y potencialmente convertirse en una señal de alerta por sí sola. Eso fue un poco de retraso. Muy bien. Así que no se trata sólo de usarlos. Se trata de entender la licencia, de llevar un seguimiento
4. Ejemplo de TechDD, Automatización y Documentación
Short description:
Considera un escenario en el que más del 40% de las dependencias de un proyecto requieren actualizaciones importantes. Este gráfico no solo señala posibles riesgos de seguridad, sino que también indica la necesidad de que el equipo de desarrollo mejore sus procesos de monitoreo y actualización. La elección de las licencias de código abierto requiere una cuidadosa consideración. Dirijamos nuestra atención a la automatización y la infraestructura. El monitoreo, la automatización de licencias y los ganchos pre-commit son cruciales. Se esperan deficiencias, pero los problemas insolubles en el futuro son una preocupación. Una documentación completa y accesible, especialmente el material de incorporación técnica, es esencial.
de sus actualizaciones, y conociendo su estado de mantenimiento. De hecho, vamos a tener un ejemplo aquí. Considera un escenario en el que más del 40% de las dependencias de un proyecto requieren actualizaciones importantes. ¿Qué nos dice este gráfico? Si lo ves, es como si este gráfico no solo señalara el potencial riesgo de security dentro de un producto, mientras tenemos como más del 40% de las bibliotecas que necesitan actualizaciones importantes, sino que también indica la necesidad de que el equipo de desarrollo mejore sus procesos de monitoreo y actualización. Además, la elección de ciertas licencias open-source requiere una cuidadosa consideración. Eso es porque usar algunas licencias sin una razón sólida puede ser arriesgado, afectando potencialmente las operaciones y cumplimientos del negocio. Así que nosotros vigilamos esa parte. Todos podríamos saber acerca de la licencia MIT, que usamos a diario, pero es definitivamente útil conocer algunas otras licencias open-source y sus implicaciones, Avanzando en nuestra serie de Cómo Prepararse para la Compra, ahora vamos a centrar nuestra atención en la automation y la infraestructura. El objetivo aquí es casi claro, como automatizar tanto como sea posible. Los beneficios de la automation en la tecnología son bien conocidos por todos nosotros. Eficiencia, consistencia, scalability. Sin embargo, hay ciertos aspectos que pueden levantar banderas rojas. Primero, hablemos sobre el monitoreo. ¿El enfoque de la empresa es reactivo o proactivo? ¿Tienen sistemas de mensajería en tiempo real en su lugar para notificarles inmediatamente de los problemas? Porque esto es, por supuesto, realmente crucial para las respuestas oportunas a los problemas, ¿verdad? Volviendo a las licencias, automatizar el monitoreo de licencias es definitivamente una jugada inteligente. Eso es porque las licencias no cambiarán, pero pueden cambiar durante el tiempo, y el cambio en realidad puede afectar nuestro producto realmente muy fuertemente. Así que tengamos eso en mente. Algunos puertos parecen podrían estar implementando ganchos pre-commit en los pipelines. Esto puede prevenir muchos problemas al asegurar que el código cumple con ciertos standards antes de que se fusione. Por último aquí, veo que es importante mencionar que en un proceso de tech D.D., algunas deficiencias son totalmente esperadas y aceptables, por supuesto dependiendo de la situación de la empresa. Pero lo que importa, no es no tener ningún problema. Es no tener problemas insolubles en el futuro. Curiosamente, si una startup parece demasiado perfecta, ella misma podría convertirse también en una bandera roja. Ahora vamos a cambiar nuestro enfoque a la documentation. Este viejo dicho captura perfectamente la importancia a menudo pasada por alto de una documentation completa y accesible en los procesos tecnológicos. ¿Cuántos de nosotros aquí preferimos escribir código que documentation? Manos arriba. Véase, todos estamos de acuerdo con eso. Esto a menudo lleva a un escenario en el que en las startups, la documentation puede ser casi inexistente, lo cual es aceptable en algunos casos. Pero sorprendentemente, incluso en empresas más grandes, no es raro en absoluto encontrar lagunas significativas en los documentos técnicos. Diría, uno de los tipos de documentación más críticos es el material de incorporación técnica. Considerando cuán frecuentemente las startups cambian sus equipos, es ideal que un documento de incorporación sea lo suficientemente completo para que un nuevo ingeniero pueda empezar a contribuir de manera significativa
5. Documentación, Frameworks y Calidad del Código
Short description:
Aunque herramientas como Google Drive y Google Docs tienen su lugar, se quedan cortas en términos de capacidad de búsqueda e indexación. La documentación debe ser centralizada para la accesibilidad y disponibilidad del conocimiento. La elección de frameworks y herramientas requiere decisiones informadas basadas en razones justificables y en la consideración de los costos de mantenimiento. La calidad del código depende de la consistencia, herramientas automatizadas como ESLint, y evitar valores y configuraciones codificados para la seguridad y mantenibilidad.
a un producto dentro del primer mes o dos. Una trampa común es el uso excesivo de herramientas generales como Google Docs para la documentación técnica. Aunque estas herramientas tienen su lugar, por supuesto, se quedan cortas en áreas como la capacidad de búsqueda e indexación. A menudo vemos documentos importantes dispersos en plataformas como Google Drive, Google Docs, lo que dificulta encontrar información cuando se necesita. Si nos preguntas sobre el enfoque ideal, cuando se trata de documentación, se trata de la accesibilidad del conocimiento y la disponibilidad del conocimiento. La documentación debe ser centralizada, asegurando que está ahí cuando la necesitamos. Asignar un propietario a cada documento puede definitivamente ayudar a mantener la responsabilidad y mantener la información actualizada. E incluso podemos integrar la creación de documentación en tu proceso de desarrollo. Quizás incluso ponerlo en tu definición de hecho en tus tickets e historias. Estoy bastante seguro de que sería un lugar perfecto para eso. A continuación, está la elección de frameworks y herramientas. Normalmente, la elección de frameworks o lenguajes no es en sí misma un gran problema, ya que la mayoría tienen soporte a largo plazo. Por ejemplo, incluso un lenguaje como COBO, aparentemente obsoleto, no es una bandera roja automática. Sin embargo, la razón detrás de la elección de dicha tecnología antigua es lo que importa. ¿Hay una razón justificable fuerte para su uso? O si está obsoleto, ¿hay un plan en marcha para migrar a tecnologías más modernas? Centremos nuestra atención en otro ejemplo en esta área. Imagina un caso en el que una empresa debe elegir entre el desarrollo de aplicaciones móviles nativas en comparación con soluciones híbridas como React Native. Si la empresa, en este caso, opta por la primera opción, debe estar respaldada por un razonamiento sólido considerando los costos de mantenimiento más altos del desarrollo de aplicaciones móviles nativas en comparación con las soluciones híbridas. Así que después de todo, más allá de simplemente elegir una biblioteca o un framework o un paquete, se trata de tomar decisiones informadas. En general, es mejor evitar reinventar la rueda y optar por frameworks ampliamente soportados y bien establecidos, a menos que haya una necesidad convincente de algo más vanguardista o antiguo, digamos. Bien, hemos llegado al último paso. En el último paso, vamos a centrar nuestra atención en la calidad del código en nuestra preparación para la diligencia debida. Un aspecto crítico de la calidad del código es asegurar la consistencia en todo el tablero. Aquí es donde herramientas automatizadas como ESLint se vuelven invaluables. Junto con Comethooks, estas herramientas ayudan a mantener un estilo de codificación consistente en todo el equipo, haciendo el código más legible y, por supuesto, más mantenible. A menudo nos encontramos con el problema de los valores y configuraciones codificados. Esto incluye casos como configuraciones codificadas específicas del cliente o secretos codificados dentro del código. Aunque es un problema muy común, lo vemos mucho, es uno que podría ser realmente, realmente fácilmente solucionado, pero a menudo se pasa por alto. Para el desarrollo de front-end, quizás nosotros, los ingenieros de front-end recordamos que cualquier secreto utilizado en dispositivos del lado del cliente puede suponer un riesgo de seguridad considerando que la mayoría de las aplicaciones de front-end se construyen y sirven en el lado del cliente. Por supuesto, hay algunas excepciones. Me encantan herramientas como Next.js, Remix, BigFan. Pero en general, si intentas mantener el secreto lo más lejos posible del lado del cliente, deberías estar seguro. Así que el foco aquí no es sólo escribir un buen código, sino escribir un código seguro, escalable
6. Diligencia Debida Técnica y Hallazgos
Short description:
Siempre recuerda la importancia de tomar la diligencia en serio. Diferencia entre las mejores prácticas de desarrollo de software y la diligencia debida técnica. La diligencia debida técnica asegura la robustez de las operaciones tecnológicas de una empresa. Las mejores prácticas contribuyen a un producto saludable. Los hallazgos en el informe están basados en datos, respaldados por gráficos y ejemplos. El hallazgo más extraño durante la diligencia debida técnica fue copiar y pegar jQuery en React.
y código mantenible. Y sólo para mantener las cosas en perspectiva, siempre recuerda este consejo. La próxima persona que lea tu código podría no ser un junior, sino un asesino en serie senior, y él sabe dónde vives. Con esta increíble noticia, hemos llegado al final de nuestro viaje. Espero que esta sesión te haya proporcionado una perspectiva clara sobre la importancia de tomar la diligencia y desenrollarla. Gracias por tu tiempo y atención. ¿Por dónde queremos empezar? Quizás diferenciemos entre las best practices de desarrollo de software y la diligencia debida. Por supuesto. ¿Dónde está la diferencia? Porque esto también podría ser como, hey, best practices para el desarrollo de software. Lo siento, no entendí tu pregunta. Quiero decir, todo eso también se aplica para un desarrollo de software general. Si yo no quiero preparar como una adquisición. Exactamente. Así que sí, todo lo que tiene que ver con la diligencia debida es como, quiero decir, cuando hacemos diligencia debida, porque queremos saber si una tecnología es robusta, que es, quiero decir, si las operaciones tecnológicas de una empresa son lo suficientemente robustas para invertir o adquirir o lo que sea. O incluso una diligencia debida podría ser un chequeo de salud. Sólo por ejemplo, un CEO o un CTO quiere saber si todo va bien dentro de su empresa, ¿verdad? Principalmente los CEOs. Y por supuesto, tener un producto saludable, quiero decir, las best practices están ahí para eso, ¿verdad? Y ese es todo el propósito de tener best practices. Y cuando escribes el informe, ¿cómo formulas realmente algunos hallazgos que tienes? ¿Dices, OK, bueno, la base de código parecía un poco extraña y no seguían las prácticas? Básicamente, bueno, diría que cada empresa hace la diligencia debida un poco diferente. Pero generalmente lo que hacemos es, como mencioné también en la charla, todos los hallazgos son impulsados por data. Así que tenemos como data adecuada o un caso adecuado para mostrar o ejemplos. Y generalmente vienen con algunos gráficos proporcionados por nuestras herramientas internas e increíbles ingenieros de data. Y si escribes el informe, ¿cuál es la cosa más extraña que encontraste durante la diligencia debida? Ah, esa es una buena pregunta. Primero que nada, necesito aclarar aquí que yo mismo no hago diligencia debida porque para poder hacerlo, necesitas tener realmente una gran experiencia detrás de ti. Correcto. Así que lo que hacemos en realidad, tenemos un increíble equipo de SCA que tiene más de 50 años de experiencia como CTO. Y ellos son realmente los líderes principales de cada diligencia debida, porque para poder, al mirar el gráfico o los data y los insights, ellos simplemente tienen una sensación intuitiva de si todo va bien o no. Así que definitivamente necesita un background realmente rico. Lo que yo hago en realidad, yo trabajo principalmente en las herramientas internas que tenemos e ingeniería. Pero definitivamente me enfrento a casos, diría quizás, no sé, algo que se me viene a la mente, copiar y pegar jQuery en tu React. Vale. Sólo recuerdo eso en este momento.
7. Proceso de Diligencia Debida Técnica y Mejores Prácticas
Short description:
La diligencia debida es altamente relativa e implica el análisis de datos, así como entrevistas en persona con ingenieros de software senior, líderes técnicos y gerentes. Las mejores prácticas para la diligencia debida técnica pueden variar dependiendo del mercado de nicho y la ubicación, pero es importante esforzarse por ser el mejor. En cuanto a la ubicación de la documentación, prioriza la accesibilidad y disponibilidad. La responsabilidad de impulsar la diligencia debida técnica dentro de una empresa puede recaer en los gerentes de ingeniería o CTOs, dependiendo de la situación de la empresa. Adquirir más experiencia en la diligencia debida técnica implica seguir las mejores prácticas e investigar la documentación y la automatización de la infraestructura.
Vale. Y si encuentras eso, ¿cómo respondes? ¿Intentas mejorar la situación con los clientes? Quiero decir, como mencioné, la diligencia debida es altamente relativa a la empresa, ¿verdad? No es solo que obtenemos acceso a data y los analizamos. También hay muchas entrevistas, como has visto en las diapositivas del proceso. Los SDAs tendrán, tienen entrevistas en persona con ingenieros de software senior, líderes técnicos, gerentes. Así que no es solo data lo que tenemos, pero si ven algo en los data y en la base de código, definitivamente lo discutirán en las entrevistas. Y si aún no están convencidos, por supuesto algo está mal. Sí. Y mencionaste que depende mucho de la empresa, pero ¿existe alguna práctica acordada para hacer esto y cuánto difieren? Diría que no realmente, porque es un mercado de nicho, ¿verdad? Quiero decir, no esperas, depende de dónde estés trabajando, cuál es tu mercado, pero no es un mercado realmente grande y por lo tanto tampoco hay muchos grandes jugadores ahí fuera. Pero intentamos hacer lo mejor, intentamos ser los mejores, al menos en Europa. Eso es bueno, siempre apunta a ser el mejor. Y tal vez podamos pasar a algunos ejemplos prácticos. Seguro. Como, ¿tenemos una guía sobre dónde colocar la documentation, qué debería permanecer en el repositorio y qué debería ir a alguna wiki de la empresa? Diría que es lo que mejor funcione para tu equipo y, de nuevo, los data deben ser accesibles y disponibles cuando los necesites. Creo que solo con estos dos puntos, todo debería estar bien. No importa realmente qué herramientas estés usando. Por supuesto, si es una, si es una herramienta que tiene, como, no sé, una gran curva de aprendizaje y todos tus equipos no pueden seguir el ritmo, eso es un problema. Pero en general, sí.
Sobre mantenerse al día con las cosas, como deberías impulsar las cosas técnicas de TV dentro de la empresa, debería ser como un gerente de ingeniería para asegurarse de que todo se sigue o debería ser los desarrolladores individuales? ¿Y cómo educas al resto de tu empresa sobre las best practices relacionadas con eso? También puedes leer la pregunta, porque no entendí tu pregunta. ¿Podrías elaborar más sobre eso? Sí. Entonces creo que muchos de nosotros nos preguntamos, ¿quién debería impulsar esto en la empresa? ¿Debería ser un esfuerzo de base de los ingenieros? ¿Quieres decir, la persona que es el primer punto de contacto en el proceso de diligencia debida técnica? Por lo general, son los CTOs. ¿Y el CTO debería asegurarse a largo plazo de que su empresa esté preparada para eso? En realidad, depende. Como si esperan recaudar algunos fondos en su futuro. Quiero decir, basado en su situación, como mencioné, de nuevo, todo es muy relativo aquí. Por eso los chicos super experimentados viven cada TD técnico con mucho background y estando en la industria durante, ya sabes, 10 o 20 años. Pero sí, en realidad, esa es la razón. Así que es altamente relativo. Pero de nuevo, si esperan algo así, podrían estar preparados. ¿Y cuál es la mejor manera de obtener más experiencia allí? ¿Si quieres avanzar en ese camino?
8. Venta de Mejores Prácticas y Privacidad de Datos
Short description:
Es importante seguir las mejores prácticas, tener un código limpio y priorizar las conexiones de mercado y la red de contactos. Las empresas a menudo se someten a diligencia técnica para asegurar la financiación. Herramientas de automatización como Dependabot y Sonar pueden ayudar con las verificaciones de licencias y el monitoreo. En términos de privacidad de datos, las empresas comparten la información necesaria para el proceso de diligencia debida, y se toman medidas para garantizar que los datos se utilicen de manera adecuada.
Quiero decir, no fue como si algo mágico estuviera sucediendo allí. Fueron todos los puntos que mencioné, puedes encontrarlos fácilmente si buscas como best practices sobre documentation o best practices sobre, no sé, automation de infraestructura. O básicamente, hay como toneladas de artículos ahí fuera sobre best practices. Y lo que acabo de mencionar en esta charla fue como los puntos con los que nos enfrentamos con frecuencia. Y no fue solo querer mencionar, porque también podemos sentirlo mejor. Pero en general, es seguir las best practices, tener un código limpio como estoy en esto, entre las cosas que todos conocemos como principios de ser un ingeniero de software, ¿verdad? Así que no es algo mágico lo que está sucediendo allí. Y ¿cómo venderías ese no mágico suceso a las personas no técnicas de la empresa para asegurarte de que están dispuestas a gastar en el negocio? Esa es una buena pregunta. Quiero decir, pensé que teníamos ingenieros aquí. Pero estoy bromeando. Básicamente, a veces, no sé si es correcto decir la mayoría de las veces o no. Pero esta conexión de mercado y la red de contactos es realmente importante. Y la mayoría de las veces tienes como un cliente, que tal vez es un VC que quiere invertir y una empresa objetivo, que quiere por ejemplo, en este caso, imagina que quiere recaudar algunos fondos. Así que la empresa objetivo no tiene otra opción si quiere el fondo, necesita someterse a diligencia técnica. ¿Y cómo nos eligen los VCs? Tal vez porque somos los mejores tal vez. Bueno, quiero decir, supongo que no hay otra opción entonces. Y supongo que acabas de decir que podría haber algunos desarrolladores en la audiencia. Creo que todos nosotros como desarrolladores, amamos la automation y las herramientas. Y definitivamente hay herramientas para hacer verificaciones de licencias y cosas así. ¿Tienes alguna recomendación allí? ¿Y también tienes alguna recomendación general de herramientas para rastrear tu propio?
Sí, de nuevo, si puedes buscar esas herramientas, hay muchas de ellas ahí fuera, puedes comparar y elegir la que se adapte a tu situación y que más se ajuste a tu empresa. Pero las cosas más famosas ahí fuera por ejemplo, dependabot tal vez es un, es un, es un bot que puedes integrar en tus flujos de trabajo de GitHub. Y simplemente verificará si tienes alguna dependencia desactualizada y simplemente creará un PR automatizado para que puedas revisarlo y fusionarlo. Haciendo las cosas mucho más fáciles, no necesitas siempre revisar todo. Y en cualquier lugar te dirá si por ejemplo, esta actualización tiene alguna corrección de alguna vulnerabilidad crítica de security o no, así que muchas buenas entradas allí. Podemos incluir otras herramientas como Sonar tal vez en tu, si ya estás al tanto de eso, en tus pipelines de desarrollo, también tiene toneladas de características, una de ellas podría ser el monitoreo. Vale, y terminemos con una última pregunta. Especialmente en la UE, la privacidad de los data es cada vez más y más importante. Y dijiste que en realidad analizas los data de las empresas en las que estás interesado. Entonces, ¿qué pueden compartir las empresas contigo? ¿Y cómo te aseguras de que esos data se utilicen solo para tu proceso? De nuevo, me gustaría mencionar que. Quiero decir, si una empresa por ejemplo, imagina un caso en el que tienes una empresa y quieres recaudar algunos fondos, recaudar fondos no es fácil, ¿verdad? Y si encuentras un VC y el VC quiere que te sometas a un Tech TD, y luego te encuentra, definitivamente te someterás a Tech TD. Así que es como, de alguna manera, la mayoría de las veces, es para lo mejor someterse
9. Acceso a Datos en la Diligencia Técnica
Short description:
Algunas empresas pueden dudar en cooperar plenamente, pero garantizamos la seguridad de los datos y el anonimato a través de acuerdos de confidencialidad y estrictas regulaciones europeas. En la diligencia técnica, buscamos acceder a la mayor cantidad de datos posible, incluyendo códigos fuente, sistemas de tickets, organigramas, y más. Los procesos automatizados nos ayudan a analizar grandes bases de código e identificar archivos importantes y lógica de negocio. Si tienes más preguntas, por favor, procede a la sesión de preguntas y respuestas con el ponente.
Diligencia Técnica. Y por lo tanto, tienen que cooperar. Y claro, algunas empresas, por ejemplo, no cooperan de la mejor manera. Quizás no quieren entregar algunos data críticos. Pero quiero decir, firmamos acuerdos de confidencialidad, todo es legal. No hay preocupación sobre fugas de data o algo así. Todo es anónimo. Quiero decir, vivimos en Europa, ¿verdad? Tenemos reglas estrictas al respecto. Pero en general, si hablamos sobre qué datos solemos tener acceso, en el mejor de los casos, diría todo lo posible, como acceso a todos los códigos fuente, cada proceso de códigos fuente. Y tenemos muchos diferentes procesos de ingeniería de data que pueden extraer algunos datos e insights increíbles. De los sistemas de tickets, hay insights valiosos escondidos en los sistemas de tickets. Podemos recopilar mucho conocimiento de eso. Y un organigrama tal vez la estructura salarial, básicamente todo puede estar en medio de un proceso de Diligencia Técnica. Además, los STA podrían pedir documentos significativos, tal vez de nuevo, para asegurarse de algo. Así que cualquier cosa sería, quiero decir, cuantos más data, mejor podemos. Bueno, eso es probablemente del siglo 25. Cuantos más data, mejor. Una última pregunta mía allí. Estás diciendo que también quieres el código fuente, pero ¿hasta qué punto realmente te adentras en líneas individuales en el analizador de código fuente? ¿Necesito estar pensando, tener miedo de que Amin venga y revise mi código fuente del lunes por la mañana? En realidad, quiero decir, a veces una empresa que va a hacer una Diligencia Técnica podría tener toneladas de repositorios, millones de líneas de código, y definitivamente no es muy eficiente revisar todos ellos, ¿verdad? Así que tenemos procesos automatizados como automatizar, en realidad estamos revisando códigos dentro de los procesos de data que tenemos, y recopilamos algunos insights como, por ejemplo, no sé cuánto detalle se me permite dar, pero por ejemplo, podemos entender tal vez qué archivo podría ser un hotspot tal vez, o en general incluso los STA. Quiero decir, si eres un tipo experimentado, podrías descubrir de alguna manera qué archivo es importante, cuál no lo es, cuál contiene alguna lógica de negocio importante, y echarle un vistazo. Eso revelaría tantas cosas.
Eso suena súper interesante, pero necesitamos cerrar aquí. Pero si tienes más preguntas, puedes ir a la sesión de preguntas y respuestas con el ponente ahora. Así que por favor, vuelve de nuevo.
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.
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.
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.
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.
This Talk discusses the process of building a toolkit and applying neurolinguistic programming techniques to succeed in software development. It emphasizes the importance of self-promotion and setting effective goals for career advancement. The concept of a brag bank is introduced as a tool to collect and remember achievements. The NNQ method is presented as a way to build a compelling case for promotion using names, numbers, and quotes. It also explores the idea of having a backup plan and considering alternative options when promotion is not feasible. Finally, the Talk touches on the importance of positive thinking, knowing when to move on, and avoiding excessive specialization.
Software engineer, lecturer, podcast host, author — is there something Emma Bostian hasn't done? She moved from America to Sweden, started working at Spotify, and took up a few challenges along the way. And now she has some career tips to share. What led you to software engineering? I was raised in the ecosphere of tech because my dad is a software engineer at IBM, and my mom was a designer there, too. My dad always encouraged me to join STEM and take a look at computer science — however, I was convinced I wanted to be a medical doctor. In my first year of college, I declared a biology major and quickly realized I was not too fond of it. In my second semester, I switched to an actuarial science major where I took Introduction to Computer Science, and the rest is history. In my second year of college, I declared a computer science major and began my journey from there. What is the most impactful thing you ever did to boost your career?Writing blog posts and documenting my learning journey on Twitter has far been the best career boost. I wrote purely for myself to reference the things I learned over time, and I even utilized my design skills in Figma to create custom graphics depicting difficult concepts like CSS specificity. By sharing my blogs on Twitter and engaging with the people reading them, I was able to grow an audience extremely quickly. I began receiving conference speaking opportunities, podcast requests, and course invitations to teach with LinkedIn Learning and Frontend Masters. Ultimately, I landed my job at Spotify through Twitter, too, when a friend and follower of mine asked if I would be interested in interviewing. Now I live in Stockholm working my dream job. It still blows my mind how tweeting about my blog led me to some of the most amazing career opportunities. What would be your three tips for engineers to level up their career? First, be patient. I often see posts on Twitter or LinkedIn about developers who were promoted to a senior position after a year. And while this is wonderful, I think we forget that each company has a different standard for what constitutes a senior developer, and everyone's journey will be different. Second, don't be afraid to ask questions. If you try your best to solve a problem or answer a question you have, but you can't figure it out after a reasonable amount of time, ask a team member or mentor for help. And lastly, invest in the right resources for learning. When I started my journey, I didn't know which platforms worked for me to learn. Now, I have a few trusted platforms such as Frontend Masters, Free Code Camp, or Level Up Tutorials that I go to when I need to learn a new skill. You're currently working as a software engineer at Spotify. What does a typical day of yours look like there?I begin my day answering emails. Then we have a team breakfast and a standup remotely as we're all still remote at Spotify. After that, we might have a web tech sync with the other squads in our business unit. The day usually includes some form of pair or mob programming, depending on the work stream. My team always has Fika, a traditional Swedish coffee break, scheduled every afternoon. Every couple of Fridays, we have team games planned to release some stress. Also, I tend to have a lot of free time to focus, which is nice but makes for a boring answer to this question! Do you have some rituals or tools that keep you focused and goal-oriented?I'll admit that I've been struggling with staying motivated in the time of remote work. I've been remote with Spotify since onboarding a year ago, but my team is wonderful, and they help me when I'm down. Apart from that, I use Todoist to keep track of my tasks, and, naturally, I listen to Spotify while working. But other than that, not really. Maybe I should adopt some new tools to keep me on track! My current favorite Spotify playlist is Brand New Chill: https://open.spotify.com/playlist/37i9dQZF1DX6uQnoHESB3u?si=380263b3c853442e I also love Chillout Daily: https://open.spotify.com/playlist/7ozIozDp260fjNOZy1yzRG?si=66d6c839ec9b458a You wrote a book called De-coding the Technical Interview. What was the impulse to do it?I wanted to give the community a manual of the essentials of computer science knowledge to ace the technical interviews. The book covers data structures like stacks, queues, or linked lists, tackles algorithms, and deals with systems design. You'll also learn about the interview process from start to finish, get tips on how to submit an amazing take-home project, or understand how to problem solve. You'll also gain knowledge on the frontend coding skills needed to excel at a frontend interview. If you could stress one piece of advice on surviving a technical interview, which would it be?Do not lie your way through an interview. If you don't know the answer to something, just admit it. There's no shame in admitting you don't know the answer to something. There is shame in faking it and pretending like you do know the answer. What's the single best practice everyone who writes code should follow?Remember that while you are technically writing code for computers, you're also writing it for humans. Your code should be readable and have as little complexity as possible without sacrificing accessibility or performance. In addition to the book, you co-host the Ladybug Podcast. What inspired you to enter this field, and what are the podcast's main topics?We talk about everything tech and career on the podcast, from Java and GraphQL to how to start a business and cross-cultural communication. The podcast is a way for me and my co-hosts to share our experiences in tech, having taken different paths. And I'm really glad for doing it — it has allowed me to meet so many incredible people, learn many new things, and support my dream of teaching. What pieces of your work are you most proud of?My technical interview book was a huge feat for me as well as my courses with LinkedIn Learning on building a tech resume. I enjoy creating things that help other people advance their careers, so I'm also proud of my courses with Frontend Masters on design systems and CSS.
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.
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.
¿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.
¿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
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.
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.
Comments