Cinco minutos en LinkedIn o X, notarás un fuerte debate en la industria de la ciencia de datos. Ha estado disponible por un tiempo, pero esta semana finalmente me llamó la atención.
Por mucho que se pueda pensar, no se trata del último modelo o biblioteca de Python, sino de lo que realmente distingue a los profesionales junior de los senior.
Y me hizo pensar.
¿Qué separa realmente a un científico de datos junior de uno senior?
Pregúntele a la mayoría de los profesionales que inician su carrera y generalmente le dirán que los mayores simplemente saben más: más algoritmos, más bibliotecas de Python, técnicas de aprendizaje profundo más avanzadas.
Y durante mucho tiempo yo también lo creí.
Recuerdo haber trabajado en un pequeño proyecto de análisis interno. Como de costumbre, puse mi corazón en ello y me sentí orgulloso de lo “limpio” que estaba todo.
Mi cuaderno estaba organizado, las funciones eran modulares y las visualizaciones se veían bien. Y, oh, incluso experimenté con un par de enfoques diferentes sólo para ver cuál funcionaba mejor.
Ese proyecto me hizo darme cuenta de algunas cosas muy importantes que he visto que la mayoría de los profesionales de la industria de datos descuidan o tratan con menos importancia.
Este artículo no trata de restar importancia a las habilidades técnicas ni de pretender que el código no importa.
He pasado la mayor parte de las noches limpiando datos y reescribiendo cuadernos, por lo que sé que el aspecto técnico de esta industria es muy real y desafiante.
Pero la verdad es que la brecha definitoria no aparece en las métricas del modelo ni en el código claramente escrito.
Es un cambio de mentalidad.
Es la transición de simplemente ejecutar tareas a decidir qué es lo que realmente se debe hacer, por qué es importante y cómo generar impacto en el mundo real.
Los jóvenes resuelven tareas. Las personas mayores resuelven los problemas correctos.
Una de las mayores diferencias entre los científicos de datos junior y senior aparece en el momento en que un problema llega a su escritorio.
Cuando era junior, mi instinto siempre fue sumergirme. Recuerdo un momento en el que me pidieron que analizara un conjunto de datos de ventas y proporcionara información al equipo directivo.
Pasé horas limpiando los datos, creando varios modelos y puliendo las imágenes. Más tarde me di cuenta de que la mayor parte de lo que había hecho en realidad no respondía a la pregunta empresarial clave.
Había estado tan concentrado en crear un análisis perfecto que no me había tomado el tiempo para comprender qué pretendía informar el análisis.
“Una de las habilidades más importantes de un científico de datos es la capacidad de enmarcar un problema del mundo real como una tarea estándar de ciencia de datos”.
John D. Kelleher
Después de un par de meses de crecimiento, aprendí que las personas mayores abordan los problemas de manera diferente.
Hacen una pausa antes de tocar el teclado. Se toman tiempo para comprender el objetivo, el contexto y el impacto de su trabajo en el mundo real. Hacen preguntas como:
¿Qué decisión se pretende apoyar con esto? ¿Cómo se medirá el éxito? ¿Podría una solución más sencilla lograr el mismo resultado?
Esas preguntas rara vez aparecen en una competencia de Kaggle, pero aparecen en todas partes en el trabajo real.
La diferencia es que los jóvenes tienden a considerar que el problema está solucionado, mientras que los mayores hacen una pausa para asegurarse de que están resolviendo el problema correcto.
Consideran el contexto, el impacto y las realidades prácticas antes de escribir una sola línea de código.
Este tipo de pensamiento cambia todo. Identificar el problema real evita ingeniería innecesaria y garantiza que su trabajo marque la diferencia.
La precisión no es lo mismo que el impacto
Hay una fase por la que la mayoría de nosotros pasamos como jóvenes científicos de datos en la que parece que todo el trabajo consiste simplemente en optimizar las métricas de su modelo.
Optimizas con un error del 0,7% y, de repente, estás actualizando el cuaderno como si fuera una cartera de acciones.
Agregas otra característica u otro algoritmo y, de repente, los números se mueven lo suficiente como para sentir que estás haciendo algo.
Si lo piensas bien, es una especie de equivalente científico de datos a obtener XP en un videojuego.
Estás subiendo de nivel, pero no estás realmente seguro de si estás jugando la misión principal o si solo estás haciendo misiones secundarias.
Solía pensar que así era el “buen trabajo”. Si el modelo era mejor, el trabajo era mejor. Simple.
Una vez pasé una semana entera intentando introducir un modelo muy complejo en un proceso que nunca estuvo destinado a manejarlo.
Fue como meter un motor de Fórmula 1 en un carrito de golf, técnicamente audaz pero prácticamente inútil.
Un colega senior examinó mi proceso durante cinco minutos y recomendó comenzar con una heurística simple solo para verificar si la señal era lo suficientemente fuerte como para justificar un modelo de aprendizaje automático.
Cinco minutos.
Había pasado una semana.
Esa no fue una brecha de codificación. Esa fue una brecha de juicio.
Cuando optimiza el impacto sobre la precisión, su trabajo técnico mejora. Dejas de hacer demasiada ingeniería y comienzas a seleccionar métodos apropiados para el problema.
Modelas porque debes, no sólo para demostrar que puedes.
Las personas mayores se comunican más de lo que codifican
Otra diferencia que me ha sorprendido es la cantidad de tiempo que los científicos de datos de alto nivel pasan sin codificar.
Cuando era junior, mi atención se centraba en los cuadernos. Pensé que el código hablaría por sí solo.
No es así.
A las partes interesadas no les importa su proceso de ingeniería de funciones; lo que les importa es lo que los resultados significan para sus decisiones.
Las personas mayores lo entienden y lo aprovechan al máximo. Traducen los hallazgos técnicos al lenguaje empresarial sin complicar las cosas a su audiencia.
También hacen mejores preguntas, no sólo sobre los datos, sino también sobre el contexto.
Estas conversaciones informan el análisis mucho antes de que se entrene cualquier modelo.
Según mi experiencia, descubrí que la comunicación no es una “habilidad blanda” en la ciencia de datos. En realidad, es una necesidad técnica difícil porque determina si su trabajo se utiliza o no.
Un modelo que no se comprende no se implementará. Una idea en la que no se confía no se aplicará.
Pensamientos finales
Las habilidades técnicas siempre serán la base. No se puede salir del código incorrecto o de las malas prácticas de datos mediante código, y los buenos fundamentos no son negociables.
Pero el código es la puerta, no el destino.
El viaje de desarrollador junior a desarrollador senior no se trata de acumular más algoritmos o superponer más herramientas. Se trata de reconocer cuándo aplicarlos, cuándo ignorarlos y por qué lo estás haciendo en primer lugar.
Al final, el verdadero crecimiento ocurre cuando mides el éxito no por cuánto mejor es tu modelo, sino por si tu trabajo cambia algo en el mundo real.
Esa es la diferencia entre escribir un buen código y hacer ciencia de datos eficaz.
¡Antes de que te vayas!
Estoy creando una comunidad para desarrolladores y científicos de datos donde comparto tutoriales prácticos, analizo conceptos complejos de informática y, ocasionalmente, despotricaré sobre la industria tecnológica.
Si ese le parece su tipo de espacio, únase a mi boletín gratuito.