• 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.

    The ‘Register your trailer to take it abroad’ service on GOV.UK on a laptop

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

    A veces, está bien contestar una 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.

  • La barra de progreso de Gmail no es real: ¿por qué?

    En smitop:

    Un poco de investigación revela que la barra de carga de Gmail no es una barra de carga en absoluto! De hecho, el progreso que se muestra es controlado por una animación de CSS que hace que inicie lento, y luego se quede quieta hasta que Gmail termina de cargar. Esto vence el propósito de una barra de carga: dar un estimado del progreso, no llenarse de manera arbitraria.

    Este tipo de problemas es donde muchos programadores pueden “meter el pie”. El impulso inicial de las personas técnicas es hacer las cosas técnicamente correctas, aunque no agreguen tanto valor al producto final o aporten a mejorar la experiencia del usuario.

    Tomando en cuenta el caso de uso más obvio de una barra de progreso, comunicar progreso, ¿qué debería hacer Gmail para ofrecer información técnicamente correcta? Sin lujo de detalle, y vagamente en el orden adecuado:

    1. Analizar la velocidad de conexión actual
    2. Analizar el tamaño del bundle de JavaScript que hay que cargar desde el servidor
    3. Hacer un cálculo de la transferencia de los datos de manera continua, tomando en cuenta fluctuaciones en la velocidad de la conexión.

    Suena relativamente sencillo; son pocos pasos. Pero toma en cuenta a) la escala a la que opera Gmail, y b) el objetivo real de presentar una barra de navegación, que es darle seguridad a tu usuario de que estás haciendo algo. Considera las implicaciones de hacer un cambio “sencillo” a la escala de Google. Además, la idea de que realmente lo que importa es la experiencia de usuario, y no necesariamente la exactitud de la barra del progreso. Te das cuenta de que implementar una barra de progreso que muestre información técnicamente correcta, realmente no vale la pena.

    Por si no te habías dado cuenta, muchas de las barras de carga que encuentras en tu día a día son completamente falsas. Hoy en día, los sistemas son tan complejos, impredecibles y con tanta entropía, que hacer una barra de carga que muestre progreso requeriría una inversión de tiempo que muy pronto deja de ser rentable para el producto.

  • 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:

    1. La participación ya no está limitada a estudiantes. Cualquier persona mayor de 18 años puede participar.
    2. 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).
    3. 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.

  • Cómo usar Google Calendar para evitar distraerte

    En los equipos de ingeniería con los que trabajo, les pido a mis colaboradores que por favor bloqueen su calendario — que lo segmenten y organicen para poder saber cuándo es apropiado invitarlos a una llamada con la confianza de que no estaré interrumpiendo una racha de productividad.

    Por alguna razón se me había pasado que se había agregado una nueva opción a Google Calendar. Un nuevo tipo de evento, que en español se llama “Enfocar horario” que te permite rechazar automáticamente eventos a los que te inviten durante ese periodo de tiempo.

    Antes de que Google Calendar activara esta opción, crear un evento para segmentar tu tiempo productivo no era tan efectivo porque hay algunas personas que aún no están acostumbradas a la realidad del trabajo remoto y la comunicación asíncrona. La cantidad de veces que alguien me invita a una llamada sin verificar primero que ese espacio esté libre en mi calendario es impresionante. Esto lleva a un espiral de tener que contestar manualmente, buscar otro horario, etc.

    Previo a este cambio, la única manera de proteger tu tiempo en el calendario de manera automática (y real), era crear un evento de “fuera de la oficina”. Pero es claramente el mensaje equivocado. Ahora, con un evento de “Enfocar horario”, el mensaje es mucho más certero y claro: este tiempo lo estoy reservando para algo importante que necesita de mi completa atención, por favor respétalo.

    Poco a poco nos estamos haciendo más conscientes de que no todos funcionamos en el mismo horario, que no todos tenemos las mismas horas productivas. Pero aún hay mucho por hacer — sobre todo en organizaciones grandes. Este es un paso en la dirección correcta, creo.

    La documentación de este nuevo tipo de evento está disponible aquí.

  • YouTube esconde el botón de “no me gusta”

    Meaghan, escribiendo en el sitio de soporte de YouTube:

    Basados en lo que descubrimos de nuestro experimento, hemos tomado la decisión de ocultar el número de “dislikes” en YouTube. Esto significa que el botón seguirá existiendo, pero el número de “dislikes” únicamente será visible en el Studio y no será visible para el público en la página del video.

    Encontraron que había algunos miembros de la comunidad de creadores que recibían ataques de ”dislikes”. Pero es lo único que Meaghan comparte en su publicación.

    Creo que es interesante, y en la superficie parece una jugada en la dirección correcta. Me pregunto cómo afectará esto el comportamiento de aquellas personas que usaban el número de “dislikes” como indicador de la veracidad de la información en el video.

  • Portugal hace ilegal que tu jefe te contacte fuera de horario laboral

    Tom Bateman, reportando para euronews.com:

    Bajo las nuevas reglas, los empleadores podrían enfrentar penalizaciones legales si contactan a sus trabajadores fuera de horarios de oficina. Las compañías también deberán de ayudar a pagar gastos originados por le trabajo remoto, como facturas eléctricas y de servicio de agua.

    Pero las reglas tienen límites: no aplicarán a compañías de menos de diez empleados.

    Progreso es progreso.

    Las nuevas leyes dictan multas para quienes contacten a sus empleados fuera de horarios laborales. Además de que se prohíbe que se monitoreen las actividades de las personas mientras trabajan desde casa.

    Si el bienestar de sus empleados, y la división sana entre vida y trabajo no es tan importante como para que algunos empleadores se organicen mejor, tal vez consecuencias legales les haga cambiar de opinió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:

    1. Git no ofrece visibilidad granular del contexto en el cual se hizo alguna contribución
    2. Hace demasiado difícil encontrar los sucesores de algún commit en particular
    3. El modelo mental de Git es innecesariamente complejo
    4. Git no lleva el recuento histórico de los nombres de las ramas
    5. Requiere soporte administrativo
    6. 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:

    1. Confirmación de que estaba resolviendo un problema real.
    2. Hacía algo mejor que la competencia.
    3. Tenía una idea del caso de uso ideal de su herramienta.
    4. 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.

  • Los desarrolladores de software se casan entre ellos

    Nathan Yau, en FlowingData.com:

    Cuando se tratal de matrimonio, los empleos que cada miembro de la pareja tiene juegan un papel importante para determinar si funciona o no. Tal vez sean los horarios ismilares. Tal vez son las reglas intrínsecas de la relación. Tal vez los empleos son un indicador de los tipos de personas que hacen buena pareja.

    Busqué “Software Developer”, y este fue el resultado:

  • WhatsApp creció 1,000 millones de usuarios con un equipo de 50 personas: ¿cómo le hicieron?

    Excelente análisis de cómo una de los servicios de mensajería más populares del mundo logró escalar para soportar 1,000 millones de usuarios con un equipo de tan solo 50 personas.

    No me es ninguna sorpresa que el primer punto es la cultura de ingeniería de la empresa. Algunas claves que definieron la cultura de ingeniería de WhatsApp y que le permitieron crecer a esos números tan grandes:

    • Hacer las cosas pequeñas
    • Hacer las cosas simples
    • Estar enfocados en la misión, una cosa a la vez

    La tecnología, claramente, tuvo muchísimo que ver en esta proeza. Pero recuerda, que una cultura de ingeniería bien establecida, con principios y valores claros y alineados a una meta concreta, es mucho más importante que una tecnología en particular.

    Si tienes una buena cultura de ingeniería, la tecnología se vuelve únicamente un detalle de implementación.

    Enlace.

  • 5.8% de los usuarios de un videojuego reportaron el 38% de los bugs: usaban Linux

    Un desarrollador de videojuegos comparte algunos números y reflexiones interesantes. Hasta la fecha, ha vendido un poco más de 12 mil copias de su videojuego, de las cuales 700 (5.8%) fueron comprados por usuarios de Linux. En total ha recibido 1,040 reportes de errores (bugs), de los cuales 400 fueron reportados por usuarios de Linux.

    Esto significa que, en promedio, el jugador que usa Linux reporta 650% más errores que los jugadores de otras plataformas.

    El detalle más interesante que comparte el autor es que de todos los errores reportados por usuarios de Linux, únicamente 3 tenían que ver específicamente con el sistema operativo. 5.8% de los jugadores encontraron el 38% de los errores que afectaban a todos los usuarios del juego.

    En palabras del autor, “es como tener un equipo de QA de 700 personas, esencialmente gratis. La comunidad de Linux está excepcionalmente bien entrenada para reportar errores. Así es como funciona el código abierto.”

    Enlace.