Lo que tienen en común la ciencia de datos y la ingeniería de software es escribir código. Pero si bien el código es el resultado principal de la ingeniería de software, los proyectos de ciencia de datos suelen terminar con modelos, resultados e informes. En consecuencia, en la ciencia de datos, la calidad, la estructura y la entrega del código suelen ser, en el mejor de los casos, una ocurrencia tardía.
La expectativa implícita en los proyectos de ciencia de datos es que se pueda confiar en los resultados reportados al final.
Esto significa que si alguien le pidiera que volviera a ejecutar su análisis o el de otra persona, podría obtener los mismos resultados. independientemente de cuánto tiempo haya pasado desde que realizó el análisis por primera vez.
De manera similar, si está desarrollando un componente para un producto, la expectativa implícita es que el componente que desarrolló represente el mejor rendimiento posible dado lo que es razonablemente posible dentro de los requisitos del producto.
Estas afirmaciones pueden parecer obvias, pero satisfacer ambas expectativas puede resultar bastante difícil.
Si no me crees, piensa en tus proyectos pasados.
¿Alguna vez ha tenido dificultades para ejecutar su código anterior o para descubrir qué versión de sus datos o qué hiperparámetros utilizó para obtener un resultado específico?
Este es el segundo artículo de una serie en la que hablo sobre habilidades prácticas en ciencia de datos de las que, según mi experiencia, no se habla en los cursos de ciencia de datos, pero que ocuparán gran parte de su día a día como científico de datos. Esta publicación está inspirada en un curso que impartí en la Universidad de Tennessee en Knoxville: DSE 511, y en un fantástico curso del MIT que acertadamente se llama “el semestre que falta de tu educación informática.”
Esta segunda publicación se centra en las habilidades que le ayudarán a hacer que sus resultados sean más confiables y su código más reutilizable.