Archivos de la categoría Libreta de Notas

El Open Source no se trata de ti

Rich Hickey, creador de Clojure, escribiendo en GitHub Gist:

Ser usuario de algo que es Open Source, no te hace merecedor de nada en absoluto. No necesitas contribuir. No tienes por qué exigir nuevas características. No te mereces la atención de otros. No significa que tus quejas tengan un valor para el producto. No te mereces esta explicación.

Si tienes expectativas (de otros) que no están siendo cumplidas, esas expectativas son tu propia responsabilidad. Eres responsable de tus necesidades. Si quieres algo, hazlo.

Hace un tiempo escribía sobre como ser desarrollador Open Source parecía no ser tan buena idea hoy en día. El Gist que publica Rich no es nuevo, tiene por lo menos unos 5 o 6 años, pero demuestra la tendencia hacia el burn-out que muchos administradores de proyectos Open Source hoy están reportando.

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.

¿Qué otro lenguaje crees que estará vigente en 50 años?
— The Coder Cave (@CaveCoder) February 18, 2022

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[+]

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

[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]

Un demo te ahorra o te compra problemas

Para un desarrollador de software es sencillo comprender por qué un proyecto se puede complicar. Entendemos las implicaciones y complejidades de desarrollar soluciones.

En una empresa tradicional, para bien o para mal, las personas que terminan tomando decisiones no siempre tienen el mismo nivel de entendimiento.

Tener el hábito de hacer demostraciones, demos, de tu trabajo ayuda a achicar esta brecha de entendimiento.

Un demo tiene el potencial de comprarte o ahorrarte problemas. Si del demo salen con más preguntas que respuestas, te compraste problemas. Si salen inspirados, con más ideas, te ahorraste problemas.

Es por eso que es importante que tomes los demos con seriedad. Porque a final de cuentas, desde un estricto punto de vista de negocio: si algo no funciona no sirve, y si algo no sirve, ¿para qué lo quiero? Un buen demo es tu oportunidad de evitar que alguien con poder de decisión a nivel negocio se haga esta pregunta.

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?

Analogías, principios básicos y modelos mentales para resolver problemas

Aprende a buscar analogías y modelos mentales que te ayuden a razonar mejor las soluciones que propones.

Regresa a los principios básicos de cómo se resuelven diferentes tipos de problemas, y extrapola sobre eso para tu caso de uso particular. Por ejemplo, si necesitas crear un sistema para que usuarios suban y validen documentos, analiza cómo lo resolvieron en 1989 con el protocolo HTTP. Construye sobre ese principio.

La gran mayoría de problemas que te va a tocar resolver en tu carrera no son nuevos. Y muchas de las dificultades técnicas con las que te vas a enfrentar vendrán de tu propia renuencia a levantar la cabeza para buscar soluciones externas, y de tu tendencia de reinventar la rueda cada vez.

Estás construyendo sobre los hombros de gigantes. Aprovéchalo.

Por qué deberías invertir en features que deleiten a tus usuarios

Si eres uno de los millones de usuarios de Spotify, seguro compartiste tu Wrapped la semana pasada. Si no fue en tus redes sociales, por lo menos lo comparaste con los de tus amigos y conocidos que sí lo hicieron.

Desarrollar productos que no solamente sean útiles para tus usuarios, sino que también los deleiten, no es tarea fácil. Ni es barato. Para Wrapped, muchísimos equipos dentro de Spotify comienzan a trabajar con meses de antelación. Marketing, datos, ingeniería, diseño — todos trabajando en conjunto para poder ofrecer, al fin de año, lo que muchas personas de la industria considerarían como algo sin valor real: una “simple visualización” de datos.

Las compañías que conocen la importancia de agregar valor a sus usuarios, y crean productos que son mucho más que simples utilidades, son las que terminan ganando. Y no solamente en números brutos, sino en la percepción del público y en el lugar que ocupan en nuestras cabezas.

Ah yes, Spotify Wrapped day, or as I like to think of it “punishment for being an Apple Music user while everyone else gets to have fun with their music recaps” day.

— Chaim Gartenberg (@cgartenberg) December 1, 2021

Una empresa que no reconociera la importancia de ofrecer algo más que una simple utilidad, difícilmente invertiría en una iniciativa como Wrapped. Afortunadamente, Spotify no es esa empresa, y cada año cimientan aún más su valía en la mente de sus usuarios, dejándolos ser parte de una conversación global. Además, virtualmente gratis, reciben una campaña de marketing de primera calidad impulsada por sus mismos usuarios.

Y es así como, un diciembre más, contemplo seriamente la idea de dejar de usar Apple Music para volver a Spotify.

Agregando una opción de ”ninguna de las anteriores” a formularios

El Gobierno de Reino Unido publicó una guía de diseño para agregar “ninguna de las anteriores” como opción a las formas que usen checkboxes en sitios oficiales.

Frankie Roberto explica por qué en el blog de diseño:

A veces, está bien contestar uan pregunta dejando todas los checkboxes vacíos. Sin embargo, algunos equipos en el gobierno han encontrado algunos problemas con esto.

Observaron que:

los usuarios podrían estar inseguros si pueden hacer esto — lo cual puede resolverse usando elementos de guía, pero no todos los usuarios los van a ver

algunas veces, los usuarios quieren dar una respuesta concreta, especialmente si les preocupa contestar las preguntas con confianza y con la verdad

dejar los checkboxes desmarcados significa que los usuarios podrían pasar la pregunta por accidente, tal vez pensando que podrían regresar a ella después

Tengo varios comentarios respecto a esto.

Primero, el hecho de que el Gobierno de Reino Unido tenga un blog dedicado a compartir notas de diseño para sus sistemas internos me voló la cabeza.

Segundo, todos podemos aprender de su razonamiento para resolver este tipo de problemas. Cuando se trata de sistemas internos, o en este caso, de gobierno, los que los producimos debemos de tener en cuenta que el 90 % de las veces, las personas que los van a utilizar quisieran no tener que hacerlo. ¿Cuándo fue la última vez que te dio gusto emplear un sistema de gobierno? Aquí, claramente están poniendo como prioridad crear soluciones que realmente le ayuden a su usuario a reducir su carga cognitiva y, por ende, ayudarles a hacer lo que quieren hacer de una manera más confiable.

Un programador podría argumentar, lógicamente, que la ausencia de un valor podría considerarse como una opción válida. Después de todo, no contestar es, en sí mismo, una respuesta. Por otro lado, el usuario argumenta que un no es en sí también una respuesta explícita, y debería de poder usarla.

Qué bueno que ganó la empatía por el usuario, y no los tecnicismos.

Google Summer of Code no estará limitado a estudiantes en 2022

Stephanie Taylor, escribiendo en el el blog de Summer of Code:

Durante los 17 años de GSoC, el ecosistema del código abierto ha crecido y evolucionado, y nos dimos cuenta de que el programa necesita evolucionar también. Con eso en mente, tenemos algunos cambio smayores para la edición de 2022, diseñados para poder servir mejor a la comunidad de las comunidades de código abierto, y dar un poco más de flexibidilidad a los proyectos y contribuidores, para que cualquier presona puede unirse y contribuir a grandes comunidades de código abierto.

Acá están los cambios resumidos:

La participación ya no está limitada a estudiantes. Cualquier persona mayor de 18 años puede participar.
Los proyectos ya no están limitados en cuanto a su tamaño. Ahora puedes parcipar con proyectos medianos (~175 horas) y proyectos grandes (~350 horas).
Mayor flexibilidad en el tiempo que le dedicas al proyecto. Ahora puedes expandir tu GSoC hasta 22 semanas.

Tip: Si quieres un crash course de cómo trabajar con personas con diferentes perspectivas, pariticpar en proyectos de código abierto es tu solución.

SQLite no usa Git: ¿por qué?

Interesante página en el sitio de SQLite, explicando por qué no usan Git para administrar el código del proyecto:

SQLite no usa el sistema de control de versiones Git. En su lugar, usa Fossil, que es un sistema de control de versiones específicamente diseñado y escrito para soportar SQLite.

Personalmente no sabía de la existencia de Fossil, pero su propuesta de valor se ve bastante atractiva. Especialmente si tomamos en cuenta las razones que motivaron a que los administradores del código de SQLite decidieran que Git no era una opción para ellos:

Git no ofrece visibilidad granular del contexto en el cual se hizo alguna contribución
Hace demasiado difícil encontrar los sucesores de algún commit en particular
El modelo mental de Git es innecesariamente complejo
Git no lleva el recuento histórico de los nombres de las ramas
Requiere soporte administrativo
Es una experiencia de usuario pobre

Observa cómo ninguna de las razones que SQLite expone para no usar Git tienen que ver con la validez de la tecnología, sino con el impacto que esta tiene en las personas que tendrán que interactuar con ella.

Tip: Recuerda que tu software existe para resolverle un problema a tu usuario. Independientemente de la excelencia técnica de tu solución, si esta no le ayuda a tu usuario a resolver su problema, no estás cumpliendo tu cometido.

Repite lo que dices, múltiples veces

Tomasz Tunguz, escribiendo en su blog:

Los grandes líderes entregan sus mensajes con palabras memorables que repiten constantemente.

Muchas personas creen que liderar significa dar órdenes. Pero no es así. Liderar significa lograr que un grupo de personas le pongan esfuerzo, atención y empeño a resolver un problema en particular. Y una de las mejores formas de hacer eso es tener un mensaje claro.

Tip para ser mejor líder: ponle nombre a tus iniciativas, y repítelas como si no conocieras otra palabra.

Un CV falso lleno de buzzwords es mucho más efectivo que uno real

u/AngelinaTheDev, en Reddit:

Después de ser rechazada en múltiples ocasiones, decidí conducir un experimento para ver si los reclutadores realmente leen los currículums (no lo hacen),

Originalmente, mi CV era bastante normal, y solo agregué algunos puntos de mentira que sonaran reales. Poco sustanciados y muchos buzzwords. Lo único extraño es que todos los enlaces te hacen rick-roll.

Con este currículum, me llamaron el 90% de las compañías a las que apliqué, incluyendo Notion, ApartmentList, Quizlet, Outschool, LiveRamp, Airbnb y Blend.

Excelente recordatorio de que un CV no debería estar diseñado para que te contraten, sino para iniciar una conversación. Engánchalos con lo que quieren escuchar, y luego apantállalos con lo que tienes que ofrecer.

Por qué las metodologías ágiles no sirven para construir software

Lucas Majerowicz, en Medium:

Con metodologías ágiles, no vas a construir un avión si lo que necesita tu cliente es un auto. Pero si ya sabes que tu cliente necesita un auto, las metodologías ágiles no te van a ayudar a construir un auto de confianza de manera efectiva.

Recuerdo la primera vez que me topé con las metodologías ágiles, y todas sus ceremonias. Algo no hacía sentido. Desde entonces, cada vez que he estado involucrado en un proyecto donde se usen metodologías ágiles, he comprobado que para las personas que promueven estas metodologías lo importante no es construir software y agregar valor al usuario — sino seguir el manifiesto al pie de la letra.

Es 66 % más probable que te contesten un correo si lo terminas con un “gracias”

Interesante análisis por parte del equipo de Boomerang. Usaron esta librería de código libre para analizar más de mil hilos de correo electrónico para intentar encontrar patrones en la efectividad de tener una respuesta a un mensaje.

De acuerdo a su estudio, encontraron que es 65.7 % más probable que alguien te conteste un correo si lo terminas con una variación de “gracias”. La frase que más respuestas genera es “gracias de antemano”.

Recuerda: correlación no implica causalidad.

Obtener una respuesta favorable a cualquier mensaje es mucho más complejo que usar una cierta frase al terminar. Mi intuición me dice que no es necesariamente que sea la frase mágica, “gracias”, la que haga que alguien responda a tu mensaje.

Yo apostaría a que las personas que usan esta frase, en general, tienen un toque más humano al momento de comunicarse. Y es por eso que sus mensajes son más efectivos. El “gracias de antemano” al final es la cereza del pastel, solamente.

Los éxitos de la noche a la mañana tardan 10 años en construirse

Una inspiradora historia por Jonathan Berger, en dateful.com. Relata cómo su proyecto alterno, un convertidor de zonas horarias, se convirtió en una vía sostenible de ingreso extra para su casa. También comparte los principios que determinaron el éxito de su pequeño proyecto:

Confirmación de que estaba resolviendo un problema real.
Hacía algo mejor que la competencia.
Tenía una idea del caso de uso ideal de su herramienta.
Tenía expectativas bajas del éxito de su proyecto.

Recuerda: los éxitos de la noche a la mañana tardan 10 años en construirse.

Soft Skills para Devs

Saber programar te da un empleo. Tus Soft Skills, una carrera.