El Profesor Smith era un académico estadounidense que vino a España a dar una conferencia.
Nivel de español: ninguno.
Pero se propuso hacer un esfuerzo para que los asistentes pudieran aprovechar mejor su charla: se aprendió de memoria su charla en español.
Durante las semanas previas, un ayudante suyo que sí hablaba español lo ayudó a traducirlo y a aprender a pronunciarlo.
Pero esas semanas no fueron suficientes y su español era tan malo que acabó siendo más difícil entender su español que lo que habría sido entender su inglés.
¿Qué puedes aprender sobre el profesor Smith (que por supuesto no se llamaba así pero no recuerdo su apellido real) que puedas aplicar a R y Python?
Antes de contártelo, te comparto 3 temas de actualidad que te vendrán bien si trabajas en temas de datos.
1️⃣ ¿Te da pereza la configuración que necesitan algunos programas cuando los instalas en tu ordenador?
Solución: no los instales.
Trabajar vía web está muy de moda y lo habitual suele ser Google Colab, Github Codespace, VScode web… No sé. Hay muchas. Kaggle también tiene algo.
Por mi preferencia por R, me gusta mucho RStudio. Y en ese sentido, llevo años usando posit.cloud cuando me apetece trastear (R o Python) sin liarme a configurar cosas.
Este jueves hay un evento online que te puede ser útil para introducirte en esta herramienta online (que, si te gusta un poco R, te vendrá bien).
2️⃣ ChatGPT, Bard, Claude.ai, Google, ¡diccionarios! Con utilidades así, tanto conocimiento escrito y accesible, aprender cosas de memoria parece que cada vez menos necesario.
¿O no?
Si eres humano, te gustará mínimamente socializar con otros humanos, charlar. Y si estás suscrito a esta newsletter, eres algo friki.
Así que, para mantener una conversación fluida (por lo tanto, agradable) con otro humano friki como tú, necesitas saber algunas ideas de memoria, para no estar consultando ChatGPT o enciclopedias en cada frase.
Aquí tienes 75 conceptos que deberías saber de memoria si trabajas en el mundo de los datos. Algún ejemplo del que no tengo ni idea: XLNet, YOLO, Yellowbrick…
3️⃣ ¿Lideras un equipo demasiado pequeño? ¿Demasiado grande? ¿Les pagas poco? ¿Demasiado?
Quizá no lo lideres, pero estás metido en uno y no entiendes las decisiones de liderazgo que se toman.
En este artículo hablan sobre dudas habituales sobre los tamaños de los equipos de desarrollos (como las de antes).
Plantean 5 preguntas frecuentes y explican cómo habría que reformularlas para que las respuestas se puedan convertir en algo acccionable.
Me ha gustado la 3, que originalmente plantea: ¿por qué el software de mi equipo no está aportando a la empresa el valor esperado?
Pero las razones de los fracasos en proyectos de software (y datos) no suelen estar vinculadas a un único equipo, sino que hay relaciones complejas.
Lo que realmente tienes que plantearte es:
- ¿Hasta qué punto te centraste en resolver las complicaciones de tus usuarios o solo hiciste algo que a ti te parecía interesante?
- Si lo hiciste así, ¿has comunicado a tus usuarios los beneficios de tu desarrollo?
- ¿Has planteado un sistema de implementación?
Lo que te enseña la historia del profesor Smith es que quedarte con lo habitual puede ser suficiente más de una vez.
Y es más, si haces es el esfuerzo de un cambio de última hora a algo que no conoces, puede ser contraproducente.
Si te piden un análisis para mañana, y lo importante es el resutado (no tanto el tener un código para ponerlo a automatizar cosas) es preferible que lo abordes con lo te sea más rápido.
¿Con Excel?
Puff, duro, pero quizá sí, con Excel.
Resérvate las tareas con más margen para aplicar lo que aprendes sobre nuevas herramientas que no conozcas tanto.
Porque aunque para esas tareas de última hora puedas recurrir a lo cómodo, no queda más remedio en tu día a día que reciclarte siempre.