Últimamente, he ganado mucho respeto por los programadores de vibración. Estamos aquí en nuestros pedestales, diciéndoles que su código es una mierda y que los modelos no pueden arreglar sus líos, pero a ellos simplemente les da igual. Muchos de estos simplemente están optimizando para un resultado diferente. Para ellos, el código es solo un medio para un fin. No les importa la mantenibilidad, la elegancia o la corrección porque no planean tocar el código. Les importa lanzar su idea antes de que se les olvide. ¿Sabes cuántas ideas he tenido que nunca he ejecutado porque no tuve tiempo o me daba pereza levantarme del sofá? Puedo aprender un par de cosas de personas dispuestas a hacer que las cosas sucedan, incluso cuando tantos aristócratas les dicen que no deberían.

He asesorado a 100+ empresas en los últimos 3 años, y aquí van algunas de mis recomendaciones favoritas: (Te sorprendería la cantidad de desarrolladores fuera de la burbuja online que necesitan ayuda.) 1. Algunos equipos no utilizan ningún sistema de versionado de código. Sé que cuesta creerlo, pero tengo testigos. Honestamente, este no es común, pero lo he visto con mis propios ojos. 2. Analizar el cultivo es poco frecuente. Una forma sencilla de mejorar lo que hace un equipo es enseñarles a escribir pruebas unitarias y de integración automatizadas. 3. Las hojas de cálculo son la solución más popular que he visto en el mercado. Por ejemplo, una de mis recomendaciones más comunes es usar MLFlow para rastrear experimentos y modelos de versiones. 4. La mayoría de los equipos siempre quieren implementar la solución técnicamente correcta para un problema. He aprendido a identificar soluciones que cumplen con muchas más restricciones (como presupuesto, plazos, capacidad del equipo, percepción, etc.) A esto lo llamo "encuadre problemático", y es de gran ayuda para las empresas. 5. Siempre recomiendo los contenedores de desarrollo a esos equipos donde cada persona usa un sistema operativo diferente y tiene problemas con la configuración y la portabilidad. 6. Intenta escalar una aplicación sin perder tiempo en observabilidad y trazabilidad. La mayoría de las veces, esto es tan sencillo como registrar la información correcta. A veces puedes dedicar tiempo a configurar las herramientas adecuadas para una observabilidad más seria. 7. En sistemas de aprendizaje automático (el 90% de los proyectos en los que trabajo), la monitorización siempre es una ocurrencia secundaria. He llegado bastante bien ayudando a los equipos a integrarse con Evidently AI. 8. Dedico mucho tiempo a ayudar a los equipos a construir flujos de trabajo de extremo a extremo, repetibles y automatizables con marcadores de relleno que puedan completar más adelante. Por ejemplo, construir una cadena de entrenamiento que comienza con el procesamiento de datos y termina con el despliegue del modelo. Muchos entrenamientos diferentes siempre forman equipos distintos: • Cómo implementar CI/CD • Cómo versionar conjuntos de datos • Cómo saber qué significa "hecho" • Cómo gestionar los secretos correctamente • Cómo gestionar la configuración • Cómo configurar los registros • Cómo probar en producción (pruebas a/b, despliegues en sombra, etc.) • ... La gente que trabaja para grandes empresas tecnológicas está años por delante de los demás, pero el mercado para este conocimiento fuera de las grandes tecnológicas es enorme.

Conocí a un tipo que gana siete cifras cada año haciendo esto una y otra vez: • Se une al equipo de desarrollo durante una semana • Identifica de 3 a 5 posibles mejoras para su proceso • Redacta una propuesta breve y concreta para cada mejora • Opcionalmente, ayuda al equipo a implementarlos • Documenta los resultados • Hojas Lo ha dominado casi como una ciencia: es un proceso repetible con algunas recomendaciones "básicas" que casi cualquiera podría usar. A la alta dirección le encanta. A los equipos les encanta. Te aburrirás muchísimo si escuchas su día a día, pero a él le encanta.