Fomenta una cultura de privacidad, no de secretos
El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”
Adam Thomas escribió brillantemente al respecto (traducido por mí):
La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.
En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.
Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.
A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.
Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación de secresía. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.
Durante los más de 12 años en la industria del software, he aprendido a identificar que si sientes que necesitan comunicar algo en secreto (por DM, en una llamada, o por medios fuera de la compañía), significa que inconscientemente no confías en tu compañía. La cultura está rota.
Legislatura en Washington obliga a que las vacantes incluyan información de salario completa
El Proyecto de Ley 5761-S, en la legislatura de Washington, dicta que las descripciones de vacantes deberán incluir detalles completos de la compensación que recibirá la persona contratada.
Puedes leer el documento final aquí. A considerar es que esto solamente aplicaría para compañías que tengan 15 o más empleados.
Espero que esto se vuelva práctica estándar eventualmente.
Un lenguaje de programación no es una tecnología
Me encontré este Tweet:
El lenguaje SQL se ha mantenido vigente por más de 40 años.
— The Coder Cave (@CaveCoder) February 18, 2022
¿Qué otro lenguaje crees que estará vigente en 50 años?
Y creo que es una excelente oportunidad para recalcar un punto que a muchas personas se les escapa: un lenguaje de programación no es lo mismo que una tecnología.
Los lenguajes son herramientas que te permiten razonar sobre problemas puntuales de maneras muy particulares.
Por ejemplo, intentemos razonar sobre el concepto del “paso del tiempo”. Para los que hablamos Inglés y Español, vemos el pasado como algo que está a la izquierda, y el futuro como algo que está a la derecha del presente. Los que hablan Árabe, al revés, ponen el pasado a la derecha y el futuro a la izquierda. Y los que hablan Mandarín, ponen el futuro arriba y el pasado abajo.[1]L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22
Un lenguaje no solamente te permite resolver problemas particulares, sino que, además, cambia la manera en que entiendes el problema en primer lugar. Puedes hablar Mandarín perfecto, pero si te sigues refiriendo al pasado como algo que sucede a la izquierda del presente, no te van a entender cuando trates de explicarle el paso del tiempo a alguien en China.
Hay una distinción, sutil, pero importante, sobre lo que queremos expresar, y el contexto en el que lo expresamos.
Cuando el autor del Tweet original dice que “el lenguaje de SQL se ha mantenido vigente por más de 40 años” no se refiere a que no ha habido avances en la tecnología que le da el contexto necesario al lenguaje. SQL es un modelo mental tan poderoso para resolver problemas de organización, administración y escritura de datos, que trascendió su tecnología y se convirtió en un estándar de la industria. Hoy, si sabes SQL, puedes programar bases de datos utilizando diferentes tecnologías, como Oracle, MySQL, Access, PostgreSQL, Sybase, Microsoft SQL Server, y más.
Ahí es justamente donde yo dibujaría la línea. Si sabes SQL, un lenguaje que sigue siendo relevante después de 40 años, no significa que no tienes que preocuparte por el contexto en el que vas a usarlo. Ese contexto hoy en día es mucho más amplio y tiene muchos más matices que cuando la tecnología original fue inventada. Y la primera pregunta que cualquier persona experimentada te haría si le pides consejo porque quieres usar SQL para administrar una base de datos es, ¿tienes la certeza de que una base de datos relacional es la solución adecuada?
SQL permanecerá vigente indefinidamente mientras haya necesidad de resolver problemas de bases de datos relacionales. Pero la tecnología fundamental, el contexto en el que el lenguaje realmente brilla, puede cambiar, mejorar, empeorar, y sí, hasta desaparecer.
Saber cómo expresarte en un lenguaje de programación no es una bala de plata. Incluso me atrevería a decir que tener dominio de únicamente un lenguaje puede llegar a ser contraproducente. Porque para ser eficiente y efectivo programando, no solamente tienes que saber expresar la solución a un problema — también debes poder determinar si la solución que quieres expresar es la adecuada para el contexto de tu problema.
Es decir, tienes que saber si estás intentando usar Mandarín para explicarle a un Chino que ayer está a la izquierda.
References
| ↑1 | L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22 |
|---|
La diferencia entre trabajar en producto vs. consultoría
Toda la diferencia entre el trabajo de producto vs. el de consultoría está en los incentivos que determinan el cómo se trabaja.
Hacer consultoría se trata de completar proyectos para un cliente. El objetivo es entregar a tiempo y cumplir con un contrato.
Si trabajas en consultoría, lo que importa es entregar en tiempo y forma, lo que significa que la calidad y exactitud técnica del desarrollo no es prioridad. Después de todo, hay una gran posibilidad de que una vez que se llegue a la meta, y el cliente esté satisfecho, no será necesario revisarlo ni mantenerlo a largo plazo. Se le resolvió el problema al cliente, se entregó a tiempo y con los requerimientos cumplidos, y ahora puedes pasarte a pensar en el siguiente proyecto sin voltear atrás.
Trabajar en desarrollo de producto se trata de resolver problemas para un usuario. El objetivo es agregar valor.
Al desarrollar un producto, lo que estás buscando es crear tecnología para resolverle un problema a tu usuario. Muy probablemente (si trabajas en un startup, por ejemplo) no habrá una guía para encontrar la forma óptima de agregar valor. Tendrás que experimentar, investigar, innovar. Pero más importante, trabajar en producto tiene la implicación de que el mismo equipo será el responsable de arreglar cualquier cosa que se rompa, y de saldar cualquier deuda técnica que se adquiera.
La fuente de frustración más grande que he experimentado es cuando he intentado desarrollar un producto como si trabajara en consultoría, y viceversa. Pero dejo esa historia para otra publicación.
No todas las empresas que dicen querer contratar Seniors lo dicen en serio
Un verdadero Senior no va a caer en la trampa de simplemente ir a implementar cosas sin pensar en sus posibles consecuencias e implicaciones a largo plazo. Un Senior no va a aceptar mediocridades, y va a presionar para mejorar procesos — no solamente dentro de su área.
Pocas organizaciones están preparadas para lidiar con el pushback que esto representa.
Muchos que dicen querer contratar Seniors, en realidad lo que quieren son desarrolladores “nivel Mid” con muchos años de experiencia resolviendo cierto tipo de problemas. Pero no quieren Seniors.
Cómo programar una base de datos realmente útil
Un sistema operativo es más que una interfaz gráfica y un conjunto de API: es una manera de ver el mundo. La forma en que está diseñado e implementado modela la forma en que sus usuarios interactúan con él.
Las decisiones técnicas de la implementación de un sistema operativo informan, de manera directa o indirecta, como sus usuarios piensan acerca de las capacidades y potencial del sistema con el que están interactuando.
Por ejemplo, Windows y macOS, a nivel técnico, manejan de manera completamente diferente el ciclo de vida de una aplicación. En Windows, el proceso termina al cerrar la ventana. En macOS, un mismo proceso puede tener múltiples ventanas abiertas, y cerrar una ventana no afecta el ciclo de vida de la aplicación que la mantiene. Un usuario relativamente avanzado, como tú, puede estar consciente de las implicaciones de usar cada estrategia de manejo de memoria y emitir un juicio sobre cuál ofrece más ventajas sobre la otra. Pero un usuario normal lo único que sabe es que en Windows cerrar una ventana significa que el progreso que ha hecho en su documento se va a perder, mientras que en macOS no.
Creo que es una buena analogía para entender la importancia de tener cuidado al momento de diseñar, implementar y mantener una base de datos.
Las discusiones sobre qué motor de base de datos deberíamos emplear, si implementar una relacional o una basada en documentos, son bastante comunes. Las que intentan entender si el modelo de datos que estamos construyendo tiene sentido lógico, es semánticamente correcto y qué tipo de valor añade al negocio, no lo son tanto.
Una base de datos es útil en la medida en que los datos que almacena puedan ser manipulados, actualizados e interpretados. Los desarrolladores de software estamos muy acostumbrados a pensar en bases y modelos de datos únicamente como componentes transaccionales de nuestro proceso de desarrollo. “Tengo esta información aquí que necesito preservar de alguna manera”.
Lo que nos falta concientizar, en muchos casos, es que otras personas, como analistas de negocios, científicos de datos y tomadores de decisiones, y otros desarrolladores, dependen de que la data que nosotros manipulamos y almacenamos sea accesible.
Al igual que un sistema operativo influye en la percepción de las capacidades de una computadora, un modelo de datos moldea la forma en que otras personas resuelven problemas. Considera que la persona que va a utilizar tu base de datos está viendo su universo a través de tus decisiones de diseño e implementación. Aunque técnicamente tengas la información guardada, no va a servir de nada si esta no es accesible.
Si el lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día, los datos son la memoria que nos ayuda a generar consciencia sobre las decisiones que hemos tomado. Y para poder tomar mejores decisiones, necesitamos tener mejores datos — no solamente más datos, sino más y mejores datos.
Aquí te dejo algunos consejos puntuales que puedes comenzar a implementar desde hoy para que tus datos sean más accesibles:
Comienza por tener buenas bases técnicas
Date cuenta de que no hay motor de base de datos que sea una bala de plata. Lo que te funciona para resolver cierto tipo de problemas, no necesariamente funcionará para otros. Habiendo dicho esto, es importante que sepas que tienes toda la flexibilidad del mundo para implementar soluciones combinadas. Por ejemplo, para el módulo de contratos puedes usar una base de datos no-relacional, orientada a documentos. Mientras que en tu módulo de analítica puedes utilizar una base de datos distribuida como Cassandra, y en tu módulo de perfiles de usuario una un poco más tradicional como PostgreSQL.
Sigue las mejores prácticas de cada tecnología que implementes. Si tienes bases de datos relacionales, normaliza tus tablas en caso de que esto agregue valor para tu caso de uso (si estás haciendo un sistema de analítica, mientras menos normalización mejor). Si tienes una base de datos basada en documentos, embebe los modelos que tengan relaciones para evitar joins a nivel aplicación.
Recuerda que una buena base técnica es únicamente el primer paso para tener modelos de datos accesibles.
Identifica tus datos y tus metadatados
Recuerda que hay dos tipos de datos:
- Datos de primer grado (el contenido de un correo electrónico)
- Y datos que describen los datos de primer grado, también conocidos como metadatos (quién le mandó el correo a quien, a qué hora, a través de qué cliente de correo electrónico, etc.).
La forma en que razono sobre estos tipos de datos es la siguiente: los datos de primer grado me permiten operar el día a día de mi negocio. Los metadatos me dan una visión de más alto nivel para detectar patrones de comportamiento de mis usuarios — incluso problemas potenciales que cuando se comiencen a ver reflejados en los datos de primer grado, será mucho más difícil corregir.
Aprende a identificar estos dos tipos de datos, y pregúntate si deberías de mantenerlos de manera integrada, o los metadatos deberían vivir en su propio repositorio de información. Toma tu decisión, y procura que este mismo patrón se siga en el resto de tu organización.
Procura la precisión semántica
“Precisión semántica” es solamente una manera rebuscada de decir que es primordial que todos los involucrados estén hablando de la misma idea en un momento dado.
Por ejemplo, ¿tienes claro qué es un “usuario activo” para tu negocio? En tu base de datos, este concepto pudiera estar simplemente representado por una tabla Users con una columna is_active, pero probablemente para el negocio un usuario activo es la relación intermedia entre la tabla de usuarios y la tabla donde están almacenados los contratos de servicio.
Una discrepancia así de sencilla en el significado de un factor tan básico del negocio, puede ocasionar muchísimos problemas. ¿Cómo podrás refactorizar el código de la aplicación que interactúa con usuarios sin causar efectos secundarios imprevistos? ¿Cómo podrá el negocio estar seguro de que los datos que reporta a los inversionistas son realistas?
Es importante que la forma en que diseñas tu base de datos esté informada por las necesidades del negocio. Después de todos, van a ser el negocio mismo el que se va a beneficiar o perjudicar como resultado de las decisiones técnicas que tomes. Ignorar esto es una receta para causar fricciones innecesarias y malentendidos entre equipos, además de que inherentemente estarás contaminando los datos que estás recabando.
Por eso recalco que se necesita precisión semántica — tanta como sea posible.
Aunque trabajes en un equipo de ingeniería, si tu trabajo es diseñar o mantener una base de datos, déjame decirte que tu rol está más cercano al negocio de lo que crees. De hecho, hasta cierto punto, la persona que diseña o mantiene una base de datos funge un punto de conexión entre el negocio y el equipo de desarrollo, pues está influenciando a través de sus decisiones técnicas a ambas partes sobre cómo razonar sobre los problemas que tienen enfrente.
Procura que tu base de datos sea un reflejo semánticamente preciso con respecto a lo que tu negocio necesita.
Haz que la data esté disponible par quien la necesite
Apóyate de herramientas como Panoply, Metabase o Tableau para habilitar la interpretación de los datos que mantienes.
Dependiendo de tu organización, es probable que no todo mundo necesite (o tenga permiso para) ver toda la información cruda. Procura tener una gobernanza de datos bien establecida para que haya forma de identificar si cierto dato en particular necesita ser visto por un stakeholder en particular.
Como parte del protocolo de manejo de datos con los equipos con los que trabajo, usamos réplicas de nuestras bases de datos para cuando otras unidades del negocio necesitan acceso a los datos crudos. Pero nunca les damos acceso a las instancias de producción. Esto puede variar de organización a organización.
Si sigues estos consejos, estarás haciendo algo porque tu trabajo no solamente sea correcto técnicamente, sino que además harás que sea útil y agregue valor a la organización. Toma en cuenta que esto es únicamente una parte de la ecuación, porque en mi mundo ideal, la gente de negocio sabría más de desarrollo de software. Y los desarrolladores de software se interesarían más por el negocio para el que trabajan.
Pero vamos paso a paso.
Gracias a Xavier Carrera por su feedback y ediciones en este artículo.
Fomenta una cultura de privacidad, no de secretos
El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”
Adam Thomas escribió brillantemente al respecto (traducido por mí):
La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.
En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.
Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.
A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.
Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación de secresía. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.
Durante los más de 12 años en la industria del software, he aprendido a identificar que si sientes que necesitan comunicar algo en secreto (por DM, en una llamada, o por medios fuera de la compañía), significa que inconscientemente no confías en tu compañía. La cultura está rota.
Legislatura en Washington obliga a que las vacantes incluyan información de salario completa
El Proyecto de Ley 5761-S, en la legislatura de Washington, dicta que las descripciones de vacantes deberán incluir detalles completos de la compensación que recibirá la persona contratada.
Puedes leer el documento final aquí. A considerar es que esto solamente aplicaría para compañías que tengan 15 o más empleados.
Espero que esto se vuelva práctica estándar eventualmente.
Un lenguaje de programación no es una tecnología
Me encontré este Tweet:
El lenguaje SQL se ha mantenido vigente por más de 40 años.
— The Coder Cave (@CaveCoder) February 18, 2022
¿Qué otro lenguaje crees que estará vigente en 50 años?
Y creo que es una excelente oportunidad para recalcar un punto que a muchas personas se les escapa: un lenguaje de programación no es lo mismo que una tecnología.
Los lenguajes son herramientas que te permiten razonar sobre problemas puntuales de maneras muy particulares.
Por ejemplo, intentemos razonar sobre el concepto del “paso del tiempo”. Para los que hablamos Inglés y Español, vemos el pasado como algo que está a la izquierda, y el futuro como algo que está a la derecha del presente. Los que hablan Árabe, al revés, ponen el pasado a la derecha y el futuro a la izquierda. Y los que hablan Mandarín, ponen el futuro arriba y el pasado abajo.[1]L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22
Un lenguaje no solamente te permite resolver problemas particulares, sino que, además, cambia la manera en que entiendes el problema en primer lugar. Puedes hablar Mandarín perfecto, pero si te sigues refiriendo al pasado como algo que sucede a la izquierda del presente, no te van a entender cuando trates de explicarle el paso del tiempo a alguien en China.
Hay una distinción, sutil, pero importante, sobre lo que queremos expresar, y el contexto en el que lo expresamos.
Cuando el autor del Tweet original dice que “el lenguaje de SQL se ha mantenido vigente por más de 40 años” no se refiere a que no ha habido avances en la tecnología que le da el contexto necesario al lenguaje. SQL es un modelo mental tan poderoso para resolver problemas de organización, administración y escritura de datos, que trascendió su tecnología y se convirtió en un estándar de la industria. Hoy, si sabes SQL, puedes programar bases de datos utilizando diferentes tecnologías, como Oracle, MySQL, Access, PostgreSQL, Sybase, Microsoft SQL Server, y más.
Ahí es justamente donde yo dibujaría la línea. Si sabes SQL, un lenguaje que sigue siendo relevante después de 40 años, no significa que no tienes que preocuparte por el contexto en el que vas a usarlo. Ese contexto hoy en día es mucho más amplio y tiene muchos más matices que cuando la tecnología original fue inventada. Y la primera pregunta que cualquier persona experimentada te haría si le pides consejo porque quieres usar SQL para administrar una base de datos es, ¿tienes la certeza de que una base de datos relacional es la solución adecuada?
SQL permanecerá vigente indefinidamente mientras haya necesidad de resolver problemas de bases de datos relacionales. Pero la tecnología fundamental, el contexto en el que el lenguaje realmente brilla, puede cambiar, mejorar, empeorar, y sí, hasta desaparecer.
Saber cómo expresarte en un lenguaje de programación no es una bala de plata. Incluso me atrevería a decir que tener dominio de únicamente un lenguaje puede llegar a ser contraproducente. Porque para ser eficiente y efectivo programando, no solamente tienes que saber expresar la solución a un problema — también debes poder determinar si la solución que quieres expresar es la adecuada para el contexto de tu problema.
Es decir, tienes que saber si estás intentando usar Mandarín para explicarle a un Chino que ayer está a la izquierda.
References
| ↑1 | L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22 |
|---|
La diferencia entre trabajar en producto vs. consultoría
Toda la diferencia entre el trabajo de producto vs. el de consultoría está en los incentivos que determinan el cómo se trabaja.
Hacer consultoría se trata de completar proyectos para un cliente. El objetivo es entregar a tiempo y cumplir con un contrato.
Si trabajas en consultoría, lo que importa es entregar en tiempo y forma, lo que significa que la calidad y exactitud técnica del desarrollo no es prioridad. Después de todo, hay una gran posibilidad de que una vez que se llegue a la meta, y el cliente esté satisfecho, no será necesario revisarlo ni mantenerlo a largo plazo. Se le resolvió el problema al cliente, se entregó a tiempo y con los requerimientos cumplidos, y ahora puedes pasarte a pensar en el siguiente proyecto sin voltear atrás.
Trabajar en desarrollo de producto se trata de resolver problemas para un usuario. El objetivo es agregar valor.
Al desarrollar un producto, lo que estás buscando es crear tecnología para resolverle un problema a tu usuario. Muy probablemente (si trabajas en un startup, por ejemplo) no habrá una guía para encontrar la forma óptima de agregar valor. Tendrás que experimentar, investigar, innovar. Pero más importante, trabajar en producto tiene la implicación de que el mismo equipo será el responsable de arreglar cualquier cosa que se rompa, y de saldar cualquier deuda técnica que se adquiera.
La fuente de frustración más grande que he experimentado es cuando he intentado desarrollar un producto como si trabajara en consultoría, y viceversa. Pero dejo esa historia para otra publicación.
No todas las empresas que dicen querer contratar Seniors lo dicen en serio
Un verdadero Senior no va a caer en la trampa de simplemente ir a implementar cosas sin pensar en sus posibles consecuencias e implicaciones a largo plazo. Un Senior no va a aceptar mediocridades, y va a presionar para mejorar procesos — no solamente dentro de su área.
Pocas organizaciones están preparadas para lidiar con el pushback que esto representa.
Muchos que dicen querer contratar Seniors, en realidad lo que quieren son desarrolladores “nivel Mid” con muchos años de experiencia resolviendo cierto tipo de problemas. Pero no quieren Seniors.
Cómo programar una base de datos realmente útil
Un sistema operativo es más que una interfaz gráfica y un conjunto de API: es una manera de ver el mundo. La forma en que está diseñado e implementado modela la forma en que sus usuarios interactúan con él.
Las decisiones técnicas de la implementación de un sistema operativo informan, de manera directa o indirecta, como sus usuarios piensan acerca de las capacidades y potencial del sistema con el que están interactuando.
Por ejemplo, Windows y macOS, a nivel técnico, manejan de manera completamente diferente el ciclo de vida de una aplicación. En Windows, el proceso termina al cerrar la ventana. En macOS, un mismo proceso puede tener múltiples ventanas abiertas, y cerrar una ventana no afecta el ciclo de vida de la aplicación que la mantiene. Un usuario relativamente avanzado, como tú, puede estar consciente de las implicaciones de usar cada estrategia de manejo de memoria y emitir un juicio sobre cuál ofrece más ventajas sobre la otra. Pero un usuario normal lo único que sabe es que en Windows cerrar una ventana significa que el progreso que ha hecho en su documento se va a perder, mientras que en macOS no.
Creo que es una buena analogía para entender la importancia de tener cuidado al momento de diseñar, implementar y mantener una base de datos.
Las discusiones sobre qué motor de base de datos deberíamos emplear, si implementar una relacional o una basada en documentos, son bastante comunes. Las que intentan entender si el modelo de datos que estamos construyendo tiene sentido lógico, es semánticamente correcto y qué tipo de valor añade al negocio, no lo son tanto.
Una base de datos es útil en la medida en que los datos que almacena puedan ser manipulados, actualizados e interpretados. Los desarrolladores de software estamos muy acostumbrados a pensar en bases y modelos de datos únicamente como componentes transaccionales de nuestro proceso de desarrollo. “Tengo esta información aquí que necesito preservar de alguna manera”.
Lo que nos falta concientizar, en muchos casos, es que otras personas, como analistas de negocios, científicos de datos y tomadores de decisiones, y otros desarrolladores, dependen de que la data que nosotros manipulamos y almacenamos sea accesible.
Al igual que un sistema operativo influye en la percepción de las capacidades de una computadora, un modelo de datos moldea la forma en que otras personas resuelven problemas. Considera que la persona que va a utilizar tu base de datos está viendo su universo a través de tus decisiones de diseño e implementación. Aunque técnicamente tengas la información guardada, no va a servir de nada si esta no es accesible.
Si el lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día, los datos son la memoria que nos ayuda a generar consciencia sobre las decisiones que hemos tomado. Y para poder tomar mejores decisiones, necesitamos tener mejores datos — no solamente más datos, sino más y mejores datos.
Aquí te dejo algunos consejos puntuales que puedes comenzar a implementar desde hoy para que tus datos sean más accesibles:
Comienza por tener buenas bases técnicas
Date cuenta de que no hay motor de base de datos que sea una bala de plata. Lo que te funciona para resolver cierto tipo de problemas, no necesariamente funcionará para otros. Habiendo dicho esto, es importante que sepas que tienes toda la flexibilidad del mundo para implementar soluciones combinadas. Por ejemplo, para el módulo de contratos puedes usar una base de datos no-relacional, orientada a documentos. Mientras que en tu módulo de analítica puedes utilizar una base de datos distribuida como Cassandra, y en tu módulo de perfiles de usuario una un poco más tradicional como PostgreSQL.
Sigue las mejores prácticas de cada tecnología que implementes. Si tienes bases de datos relacionales, normaliza tus tablas en caso de que esto agregue valor para tu caso de uso (si estás haciendo un sistema de analítica, mientras menos normalización mejor). Si tienes una base de datos basada en documentos, embebe los modelos que tengan relaciones para evitar joins a nivel aplicación.
Recuerda que una buena base técnica es únicamente el primer paso para tener modelos de datos accesibles.
Identifica tus datos y tus metadatados
Recuerda que hay dos tipos de datos:
- Datos de primer grado (el contenido de un correo electrónico)
- Y datos que describen los datos de primer grado, también conocidos como metadatos (quién le mandó el correo a quien, a qué hora, a través de qué cliente de correo electrónico, etc.).
La forma en que razono sobre estos tipos de datos es la siguiente: los datos de primer grado me permiten operar el día a día de mi negocio. Los metadatos me dan una visión de más alto nivel para detectar patrones de comportamiento de mis usuarios — incluso problemas potenciales que cuando se comiencen a ver reflejados en los datos de primer grado, será mucho más difícil corregir.
Aprende a identificar estos dos tipos de datos, y pregúntate si deberías de mantenerlos de manera integrada, o los metadatos deberían vivir en su propio repositorio de información. Toma tu decisión, y procura que este mismo patrón se siga en el resto de tu organización.
Procura la precisión semántica
“Precisión semántica” es solamente una manera rebuscada de decir que es primordial que todos los involucrados estén hablando de la misma idea en un momento dado.
Por ejemplo, ¿tienes claro qué es un “usuario activo” para tu negocio? En tu base de datos, este concepto pudiera estar simplemente representado por una tabla Users con una columna is_active, pero probablemente para el negocio un usuario activo es la relación intermedia entre la tabla de usuarios y la tabla donde están almacenados los contratos de servicio.
Una discrepancia así de sencilla en el significado de un factor tan básico del negocio, puede ocasionar muchísimos problemas. ¿Cómo podrás refactorizar el código de la aplicación que interactúa con usuarios sin causar efectos secundarios imprevistos? ¿Cómo podrá el negocio estar seguro de que los datos que reporta a los inversionistas son realistas?
Es importante que la forma en que diseñas tu base de datos esté informada por las necesidades del negocio. Después de todos, van a ser el negocio mismo el que se va a beneficiar o perjudicar como resultado de las decisiones técnicas que tomes. Ignorar esto es una receta para causar fricciones innecesarias y malentendidos entre equipos, además de que inherentemente estarás contaminando los datos que estás recabando.
Por eso recalco que se necesita precisión semántica — tanta como sea posible.
Aunque trabajes en un equipo de ingeniería, si tu trabajo es diseñar o mantener una base de datos, déjame decirte que tu rol está más cercano al negocio de lo que crees. De hecho, hasta cierto punto, la persona que diseña o mantiene una base de datos funge un punto de conexión entre el negocio y el equipo de desarrollo, pues está influenciando a través de sus decisiones técnicas a ambas partes sobre cómo razonar sobre los problemas que tienen enfrente.
Procura que tu base de datos sea un reflejo semánticamente preciso con respecto a lo que tu negocio necesita.
Haz que la data esté disponible par quien la necesite
Apóyate de herramientas como Panoply, Metabase o Tableau para habilitar la interpretación de los datos que mantienes.
Dependiendo de tu organización, es probable que no todo mundo necesite (o tenga permiso para) ver toda la información cruda. Procura tener una gobernanza de datos bien establecida para que haya forma de identificar si cierto dato en particular necesita ser visto por un stakeholder en particular.
Como parte del protocolo de manejo de datos con los equipos con los que trabajo, usamos réplicas de nuestras bases de datos para cuando otras unidades del negocio necesitan acceso a los datos crudos. Pero nunca les damos acceso a las instancias de producción. Esto puede variar de organización a organización.
Si sigues estos consejos, estarás haciendo algo porque tu trabajo no solamente sea correcto técnicamente, sino que además harás que sea útil y agregue valor a la organización. Toma en cuenta que esto es únicamente una parte de la ecuación, porque en mi mundo ideal, la gente de negocio sabría más de desarrollo de software. Y los desarrolladores de software se interesarían más por el negocio para el que trabajan.
Pero vamos paso a paso.
Gracias a Xavier Carrera por su feedback y ediciones en este artículo.