Archivo de la etiqueta: programación

Saber venderte como desarrollador no es echar mentiras

¿Alguna vez has intentado venderte, hablar sobre tus logros y habilidades, y te sientes inadecuado o incómodo? Si tu respuesta es que no, déjame entonces preguntarte: en tu currículum, ¿compartes ejemplos de cómo le ayudaste al negocio con tus habilidades de desarrollo, o simplemente tienes una lista de tecnologías como JavaScript, HTML y CSS?

Ahí está.

Es hora de enfrentar este problema.

Auto-Sabotaje Técnico: por qué no sabes cómo venderte

Muchos ingenieros, programadores y profesionales técnicos están alérgicos a la idea de “venderse”. Preferimos hablar en lenguajes de programación, no en el lenguaje del valor humano o del impacto en el negocio. Desde un punto de vista psicológico, es una forma de auto-sabotaje. Minimizamos nuestro valor al no saber comunicarlo de manera efectiva.

Recuerdo una conversación con uno de mis mentores que cambió mi perspectiva. Me preguntó: “¿Por qué le tienes tanto miedo a venderte bien en la industria?” Mi respuesta fue rápida: “Porque no quiero echar mentiras.” Sin embargo, él me mostró que hablar de mis habilidades técnicas y el valor que agrego a los equipos, en términos que los responsables de presupuestos entienden, no es echar mentiras, sino traducción.

Naturalmente, como yo no estaba acostumbrado a hablar en esos términos, cuando hablaba de “valor agregado” y en vez de “arquitectura de aplicaciones” sentía que estaba echando mentiras. Pero no: estaba hablando de exactamente lo mismo, solamente que desde otra perspectiva.

Aprender a hablar el Lenguaje del Valor

Traduce tu valor. Como desarrolladores de software, tenemos que comenzar a ver que vender nuestras habilidades no es manipulación, sino adaptación. No es cambiar lo que hacemos, sino cómo lo comunicamos. La clave aquí es entender que en una organización se hablan diferentes lenguajes, y que aprender a hablarlos aumenta nuestro valor y nos permite colaborar de manera más efectiva.

Dominar el lenguaje del valor es esencial para tu desarrollo profesional. Esta habilidad no solo te beneficia diariamente como desarrollador de software, sino que se convierte en un factor decisivo al buscar un aumento, un nuevo trabajo o un rol más avanzado. Hablar en términos de valor puede ser la llave que abre la puerta a oportunidades que transformarán tu carrera.

Consejos prácticos para venderte mejor

Aquí hay algunos consejos prácticos para que comiences a perderle el miedo a venderte.

Identifica y lista tus habilidades: Antes de poder traducir tus habilidades a un lenguaje más accesible, primero debes saber exactamente qué estás ofreciendo. Esto va más allá de las habilidades técnicas; piensa también en las habilidades blandas que has desarrollado. Por ejemplo, si eres bueno resolviendo conflictos dentro de tu equipo, eso es algo que también tiene gran valor.

Consejo: usa el método STAR (Situación, Tarea, Acción, Resultado) para describir situaciones específicas donde demostraste tus habilidades, sea de liderazgo, trabajo en equipo o resolución de problemas.

Encuentra un Traductor de Valor: Este puede ser un mentor, un colega de otra área o incluso un amigo que tenga habilidades para comunicar y entender tanto el mundo técnico como el empresarial. Ellos pueden ayudarte a encontrar las palabras y conceptos que transmitan tu valor de una manera comprensible para todos.

Ejemplo: Si eres un experto en optimización de bases de datos, un “Traductor de Valor” podría ayudarte a describir esta habilidad como “mejorar la eficiencia operativa reduciendo los tiempos de espera para los usuarios”.

Practica con Escenarios Reales: No basta con saber cómo traducir tus habilidades; debes practicar. Ya sea en entrevistas de trabajo, conversaciones con stakeholders o incluso en tus interacciones diarias con tu equipo, toma la oportunidad de hablar sobre tu valor. La próxima vez que tengas una revisión de desempeño o una conversación similar, intenta usar este nuevo lenguaje de “valor”. Prepara antemano cómo vas a describir tus contribuciones de manera que resuenen con tu audiencia, y después evalúa cómo fue recibido.

Por ejemplo, la próxima vez que hables con un gerente de proyecto, un cliente o modifiques tu currículum, en lugar de decir que “implementaste un algoritmo de búsqueda eficiente,” podrías explicar que “mejoraste la experiencia del usuario al hacer que la búsqueda de información en la aplicación sea más rápida y precisa.”

Recibe Retroalimentación y Ajusta: Después de cada intento de vender tu valor, busca retroalimentación. ¿Fue efectiva tu comunicación? ¿Hubo algo que pudiste haber dicho de una manera más clara? Utiliza estos aprendizajes para ajustar tu enfoque en el futuro.

Aquí hay una oportunidad de ejercer la Mentalidad de Crecimiento: La habilidad de “venderse” es como cualquier otra habilidad: se puede aprender y mejorar. Mantén una mentalidad de crecimiento y estarás vendiéndote como un profesional en poco tiempo.

Conclusión

En definitiva, aprender a comunicar tu valor es mucho más que una técnica de negociación; es una inversión en tu crecimiento profesional y bienestar emocional. Al dominar el lenguaje del valor, no solo incrementas tus oportunidades para conseguir un mejor salario o avanzar a roles más prominentes. También ganas una nueva capa de autoconfianza, un sentido de propiedad sobre tu carrera que se traduce en un mayor cumplimiento personal y profesional.

Así que no lo postergues; empieza hoy a traducir tus habilidades técnicas en términos de valor.

No es solo un cambio de vocabulario; es una transformación completa que puede elevar tu carrera a nuevas alturas.

Cómo programar una base de datos realmente útil

[fusion_builder_container type=”flex” hundred_percent=”no” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” overlay_color=”” video_preview_image=”” border_color=”” border_style=”solid” padding_top=”” padding_bottom=”” padding_left=”” padding_right=””][fusion_builder_row][fusion_builder_column type=”1_1″ layout=”1_1″ background_position=”left top” background_color=”” border_color=”” border_style=”solid” border_position=”all” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” center_content=”no” last=”true” min_height=”” hover_type=”none” link=”” border_sizes_top=”” border_sizes_bottom=”” border_sizes_left=”” border_sizes_right=”” first=”true”][fusion_text]

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.

 

[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Software Libre: ¿Vale la pena involucrarse?

El mundo del desarrollo de software libre ha estado en las noticias últimamente. Desde la vulnerabilidad de Log4j que mandó a todo mundo a actualizar sus servidores, hasta las controversias por grandes compañías construyendo servicios y productos encima de productos de código libre sin honrar la naturaleza del mismo.

Con iniciativas como GitHub Sponsors, las compañías que dependen del software libre buscan incentivar que las personas que mantienen los proyectos sigan trabajando en ellos. Sin embargo, el panorama no se ve tan alentador para aquellos que tienen que lidiar con las implicaciones de mantener proyectos que son usados por millones de personas.

Gavin Howard, escribiendo en su blog:

Esto es deprimente, por decir lo menos. Es deprimente porque no veo otra alternativa más qu dejar de escribir software. Después de todo, no puedo encontrar trabajo, no puedo hacer dinero trabajando en software libre, y el código que escriba puede terminar dañando a más personas de las que ayuda.

Mi interpretación del problema es que el propósito del software open source se ha pervertido a lo largo de los años. Inicialmente, la idea era poder colaborar para crear mejores soluciones. Durante un tiempo, cuando se construían las bases de la industria de la tecnología, eso era una realidad. Hoy en día, el que una solución sea de código abierto se utiliza como excusa para no dedicar tiempo a entender sus fundamentos.

¿Cuándo fue la última vez que realmente te dedicaste a entender la solución que un paquete de NPM implementaba? No importa, porque es de código abierto, y seguramente alguien más encontrará lo que está mal en ella — si es que hay algo mal, en primer lugar.

La comunidad de código abierto aporta muchísimo beneficio a la industria. ¿Cómo se logrará hacer que reconozca estos beneficios y corresponda de igual manera a la comunidad que habilitó su creación en primera instancia?

Aquí una idea de cómo puedes comenzar a influenciar un cambio positivo: si el producto en el que trabajas depende de una pieza en particular de código open source, pídele a los líderes de tu organización que asignen una parte del presupuesto para contribuir económicamente al mantenimiento de ese proyecto. Si la persona encargada no tiene habilitado un perfil de GitHub Sponsor, estoy seguro de que estará más que contenta de recibir un wire transfer mensualmente con la contribución de tu empresa.

El nombre que le pones a las cosas sí importa

“En las ciencias de la computación, hay únicamente dos problemas difíciles de responder: la invalidación de un caché, y cómo nombrar cosas.” — Phil Karlton

La cultura del Internet después modificó este refrán para incluir errores de enumeración de índices, pero esa es otra historia.

La realidad es que Phil tenía mucha razón: decidir cómo nombrar las entidades que manipulamos al programar es una de las tareas más difíciles de nuestra profesión. No por nada es tan común ver variables, métodos, clases, funciones, o cualquier otro elemento de programas, con nombres genéricos, como x, builder o manager.

Algunos argumentan que invertir tiempo en nombrar los componentes de un programa de manera coherente es una pérdida de tiempo. Las veces que he participado en discusiones donde se intenta impulsar la idea de que alguien debería poder diferenciar una variable X de otra simplemente por el nivel de sangría del código son demasiadas. Creo que desafortunadamente esto es otra muestra de lo inusual que es el sentido de compasión en la industria de la tecnología.

Al igual que agregar documentación completa a tus proyectos, usar nombres descriptivos y semánticamente correctos es un acto de compasión.

El lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día. Al compilador no le importa el nombre de tu variable, pero a la persona que va a leer y contribuir a tu código sí. Y como siempre, es importante recalcar que esa persona puedes ser tú mismo, años después.

Utilizar nombres descriptivos y semánticamente correctos para los componentes de tu programa no solamente hace más accesible la lectura de tu código. También te ayuda a razonar mejor sobre la solución que estás implementando. En algunos casos, hasta te podría salvar, potencialmente, de introducir vulnerabilidades de seguridad críticas.

Conforme he ganado experiencia colaborando en esta industria, he encontrado una relación, casi directa, entre el nivel de atención a la nomenclatura y semántica de los componentes de un programa y su fiabilidad.

Después de todo, me pregunto: si no te tomaste el tiempo de nombrar algo de una manera correcta y con sentido, ¿realmente habrás entendido el problema que estás intentando resolver?