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

  • Por qué hacer over-engineering

    Luis Lira, escribiendo en su nuevo blog:

    Over Engineering es cuando nos gusta complicarnos la vida, algo como ser masoquistas, pero programando. Cuando estamos creando un proyecto y queremos sufrir por voluntad propia porque para un problema sencillo usamos una solución compleja. De hecho, este sitio es una muestra de eso.

    En mi pueblo hay un dicho: salió más caro el caldo que las albóndigas.

    Continúa:

    Este Portafolio/Blog que hice aproximadamente en 10 días — aunque aún le falten cosas — pude haberlo hecho en unas horas y solo con unos cuantos clics, comandos en una consola o simplemente pagando una suscripción en algún sitio que me diera todo esto listo.

    En vez de irse por la solución “integrada”, Luis decidió experimentar ensamblando su blog manualmente.

    Se dice que algo está over-engineered (o diseñado de más) cuando la solución tiene cuesta más (tiempo, recursos, esfuerzo) que el problema mismo. Pero existe una distinción importante que me gustaría recalcar: construir algo desde cero cuando existe ya un paquete que resuelve el problema no es hacer over-engineering.

    El término over-engineering es inherentemente negativo. Expresa que el diseño de tu solución está over, o de más. Es inútil, extra. Te lo pudiste haber ahorrado.

    Lo que está haciendo Luis es algo sumamente positivo: tomar un problema que pudo haber resuelto con unos cuantos clics, desmenuzarlo y explorar creando una solución que se adapte exactamente a lo que él quería. Eso no es over-engineering, eso es engineering. 

    A través de este ejercicio, Luis no solamente está aprendiendo y explorando nuevas herramientas de desarrollo, sino que está razonando un dominio de problema al que no estaba expuesto anteriormente. Este razonamiento seguramente le ayudará a comprender mucho mejor 1) la complejidad real del problema, y 2) la toma de decisiones que juegan un papel importante en hacer que WordPress, Ghost, Tumblr, etc., sean exitosos.

    Eso es verdadero aprendizaje.

    La cultura de desarrollo de software actual empuja a las personas a creer que entender las premisas básicas de los problemas que resuelven es algo negativo. ¿Para qué invertir tiempo en eso, si ya hay un paquete de JavaScript que lo resuelve? Sin embargo, es refrescante ver que aún hay personas que intentan comprender el problema antes de obviar el entendimiento del mismo y correr a implementar soluciones sin fundamentos.

  • Cómo saber si deberías dejar ir a un miembro de tu equipo

    Un Engineering Manager en una posición no tan ideal me envió la siguiente pregunta:

    ¿Cómo lidias con la banda que no comunica (ausentes en chat, no confirman llamadas, etc) PERO que sí da resultados?

    El que uses la palabra “lidiar” me dice que, muy dentro de ti, sabes que no te está dando buenos resultados, y es momento de hacer algo al respecto.

    Desde el punto de vista de un Engineering Manager, si alguien es un buen ejecutor, pero tienes que estar invirtiendo tiempo y recursos para asegurarte de que lo está haciendo de una manera que no afecte negativamente al resto del equipo, esa persona no funciona. Aunque esa persona cumpla con sus responsabilidades a nivel técnico.

    Tu rol es establecer procesos y generar estrategias para que se cumplan las expectativas del equipo.

    Como Engineering Manager, una de tus preocupaciones principales debería de ser evitar cuellos de botella y silos de información. Tener a un miembro del equipo que no comunica eficientemente, ni trabaja en equipo, es la antítesis lo anterior. Sobre todo si esta persona sabe que sus habilidades técnicas de alguna manera justifican sus deficiencias en comunicación y colaboración. Esta es una receta para que eventualmente tengas a alguien que sabe mucho del proyecto y del negocio, que sea una carga negativa para el equipo, y que no podrás correr porque con él se iría todo el conocimiento de los proyectos en los que trabajó. Bus factor al millón.

    Un estándar de calidad es lo que se tolera, no lo que se promueve. Puedes invertir tiempo y esfuerzo en promover buenas prácticas de comunicación y trabajo en equipo, pero mientras no tomes decisiones administrativas en pro de defender los procesos y estrategias que promueves, estarás trabajando en vano.

    El mejor momento para remover a ese elemento del equipo era antes de que te pusiera en esta situación.

    El segundo mejor momento es ahora, que estás buscando hacer malabares por alguien que no te está haciendo, ni a ti ni a tu equipo, el trabajo más sencillo.

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

  • Razones comunes para que los desarrolladores busquen nuevos empleos

    StackOverflow compartió en su blog los resultados de una encuesta que aplicaron a 500 desarrolladores de software. La idea era encontrar los factores que  actualmente están jugando un papel importante en el mercado laboral de desarrolladores.

    Las respuestas podrían parecer obvias para cualquier persona que trabaje en el medio. Sin embargo, creo que es buena idea analizarlas un poco más allá simplemente compartir el número de personas que prefieren tal cosa en lugar de otra.

    Los resultados

    Why are you looking for, or open to, a new job? 65% Better salary/pa, 39% wanting to work with new technologies, 36% Better work /life balance, 35% Growth or leadership opportunities

    Para buscar nuevas oportunidades, 65 % lo hacen por un incremento de salario. Esto no debería de sorprenderle a nadie. En los últimos meses, sobre todo, se ha visto un incremento sustancial en la inflación de los salarios para personas que trabajamos en software. Hay varios factores que podrían estar influyendo en esto: la pandemia, la devaluación de la moneda, que cada vez hay empresas con más recursos para “quemar”.

    Al momento de considerar empresas para unirse, el 56 % quieren que la empresa le ponga atención al developer experienceEste dato sí me sorprendió, pero tiene sentido. Conforme los retos se van haciendo más complejos y los equipos se van haciendo más distribuidos, lo que quieren los desarrolladores es que las empresas realmente inviertan en la infraestructura para soportar sus esfuerzos.

    Hace unos años, la discusión sobre el developer experience era relativamente sencilla, porque había un alto grado de probabilidades de que los problemas se mitigaran simplemente eligiendo el cliente de git adecuado para el equipo. Hoy en día, los desarrolladores esperan que haya una infraestructura para colaborar, empujar código a producción, resolver conflictos, recabar datos, y más. Y no solo eso, sino que esperan que haya un equipo encargado de soportar dicha infraestructura.

    Aquellas empresas que reparen en invertir en mejorar y facilitar el trabajo de los desarrolladores la van a tener muy difícil contratando reteniendo talento.

    Lo que hace que una empresa sea poco atractiva tiene que ver con el nivel de micromanagement de la organización. Me sorprendió conocer que hay algunas organizaciones prohíben a sus desarrolladores usar Stack Overflow. Fuera de eso, la mayoría de los desarrolladores están de acuerdo en que lo que quieren es que la cultura de la empresa no esté basada en el control y la desconfianza.

    También me sorprendió la tercera razón más popular que hace que una empresa no sea atractiva para un desarrollador: que no tengan los recursos para darle confianza en su trabajo. ¿A qué se refiere esto? Algunas ideas:

    • Que no haya un proceso de retroalimentación establecido
    • Opacidad en el proceso de toma de decisiones
    • Una estructura organizacional demasiado plana
    • Y, retomando el punto anterior, indiferencia por el developer experience

    La reputación de la empresa es primordial para el descubrimiento inicial de oportunidades. De acuerdo con los resultados de la encuesta, 47 % de los desarrolladores toman más en serio las recomendaciones de oportunidades que vienen de su red personal (familiares y amigos) que cualquier otro medio. Hace poco escribí sobre este fenómeno:

    Es mucho más importante, para tu desarrollo profesional y tu superación personal, estar con las personas correctas, que en la compañía con el nombre más conocido.

    Bien dicen que la publicidad de boca en boca es la más efectiva.

    Conclusiones

    El mercado laboral está más “caliente” que nunca. Y veo que muchas de las conversaciones al rededor del tema se enfocan en cómo se puede hacer para contratar más personas, pero lo que leo entre líneas de estas respuestas es que deberíamos estar hablando mucho, mucho más de cómo retener el talento que ya tenemos en nuestras compañías.

    Si pudiera hacer sugerencias accionables para 1) retener al talento que tienes y 2) hacer tu compañía más atractiva para otros desarrolladores, te diría, en orden de importancia:

    • Invierte en facilitar el trabajo de tu equipo. Desarrolla infraestructura que ayude a que tus desarrolladores se puedan enfocar más en el qué, y no el cómo de hacer su trabajo. Pule los procesos de desarrollo, despliegue y revisión de código. Establece procesos claros par resolver conflictos.
    • Mejora tu cultura de colaboración. Promueve el dar y recibir feedback de manera orgánica y constante. Asegúrate de que los desarrolladores tienen la visibilidad necesaria para tomar decisiones y hacerse responsables de sus acciones. Empodera a tu equipo.
    • Hazlos sentir orgullosos de trabajar en tu compañía. 
    • Súbeles el sueldo. Índice de inflación anual, multiplicado por 2. Al menos.
  • 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.

    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.

  • ¿Cuándo es hora de renunciar a tu trabajo?

    Las cosas en la empresa no pintan bien. Estás al borde del burnout, y pareciera que la situación, en vez de mejorar, se va a poner más complicada.

    Se siente una desconexión entre el ánimo con el que se presentaron los nuevos proyectos y la realidad al momento de ejecutarlos. Sí, vienen grandes retos, proyectos que tienen el potencial de generar un gran impacto en la industria. Sin embargo, algo no está bien. Los compromisos, exigencias y variables siguen creciendo, pero no así el respaldo que sientes por parte de la empresa para lograr tus metas.

    A pesar de todo esto, cada vez que hablas con tu líder y le haces saber cómo te sientes, por alguna razón, sales aliviado. Lograste desahogarte, y probablemente hasta sentiste algo de empatía por él o ella. Te hizo saber entre líneas que realmente está haciendo todo lo que puede para que cambien las cosas.

    No obstante, la pregunta no deja de rondar en tu cabeza: ¿debería renunciar ya, o le doy otra oportunidad? Esta vez seguro será diferente.

    Incentivos

    En algunos lugares, se gana siendo el que más vende. En otros, resolviendo la mayor cantidad de tickets. Desafortunadamente, en algunas organizaciones se gana siendo el favorito del jefe.

    ¿Cómo se “gana” en la cultura de tu empresa? Esta es la pregunta más importante que deberías de contestar.

    Si te das cuenta de que en tu organización se gana siendo el que más vende en números brutos, pero tú trabajas como desarrollador de productos internos, y no como vendedor, tienes un problema. Porque tu usuario hará lo necesario por vender más, independientemente de lo que tú y tu equipo estén haciendo o quieran hacer. Tomarán atajos, desarrollarán sus procesos por fuera, y tu trabajo será cada vez más difícil: crear un producto para personas que no quieren ni tienen que usarlo. Es posible contrarrestar esta situación, sí, sin embargo, requiere que la persona al frente de tu equipo tenga bastante capital político dentro de la organización para poder influenciar el comportamiento de otras áreas.

    Si en tu empresa se “gana” siendo el que más vende, ¿qué significa eso para ti, que no vendes nada? ¿Cuál es realmente la probabilidad de que tu tarea sea factible? ¿Tiene tu líder el suficiente capital político para poder influenciar otras áreas de la organización y alinear sus incentivos con los suyos?

    Charlie Munger dijo, “muéstrame los incentivos y te mostraré el resultado.”

    Eres lo que haces

    Para este punto te habrás dado cuenta de que estás en una situación poco ideal, pues los incentivos de tu empresa no están alineados para que tú también puedas ganar. Pero tu líder insiste en que las cosas van a cambiar pronto.

    Analiza su historial de liderazgo.

    Eres lo que haces, no lo que dices que quieres hacer. Esto es especialmente verdad en roles de liderazgo.

    Esta es una conversación delicada, porque estamos hablando de una persona en particular. Vale la pena hacer zoom out: también es miembro de la organización, y tiene un rol que debe de cumplir. El hecho de que sus incentivos no estén alineados con los tuyos no es un juicio de su persona. Algunas veces lo que tú quieres no tiene nada que ver con lo que tu jefe/líder necesita de ti como miembro de una organización, y esto no significa que no sea una buena persona, o que quiera hacer las cosas mal a propósito.

    Habiendo mencionado esto, es completamente válido hacerte las siguientes preguntas sobre tu líder: ¿Cuál es el incentivo de su puesto? ¿Qué significa “ganar” para él/ella? ¿Cuántas veces te prometió algo y no llegó? ¿En cuántas ocasiones las cosas han estado a punto de cambiar, pero nunca lo hicieron?

    Renuncia

    Mucho se habla en la cultura latinoamericana de “ponerse la camiseta”, y una de las cosas que más me gustaría cambiar de la cultura laboral en México y LATAM es la idea de que los empleos se deben “aguantar”.

    Creo fielmente en que un empleo o un trabajo debería de ser algo vigorizador, no agobiador. Sé, por experiencia, que una de las maneras más sencillas de lograr llegar a ello es desarrollar conciencia de qué es lo que queremos y necesitamos para crecer. Y luego hacer algo al respecto.

    La respuesta es simple: si los incentivos de tu empresa no están alineados de manera homogénea, y tu jefe o líder no tiene un buen historial de entregas a nivel liderazgo, es momento de que salgas de ahí.

    Somos afortunados de trabajar en una industria que nos permite trabajar desde casa y con aire acondicionado, por decir los menores de los beneficios. Con ese privilegio vienen ciertas responsabilidades, y una de ellas es hacer algo con las respuestas a preguntas que no todos se pueden hacer.

    Renuncia.

  • Presentación: Cómo mis Soft Skills me volvieron mejor desarrollador

    Tuve el honor de ser invitado a participar en el meetup de Perú .NET Development. Hablé sobre cómo los Soft Skills me ayudaron a convertirme en un mejor developer, y aquí está la grabación de mi participación.

    Mil gracias a Julissa por la invitación.

  • Los mejores Product Managers tienen las peores ideas

    Lane Wagner, en qvault.io:

    De acuerdo con failory, la razón #1 por la que fallan los startups es porque nunca encontraron product-market fit. 34 % de los emprendimientos fallidos son un resultado de no haber identificardo el problema correcto a resolver. Las segunda y tercera razón, marketing y problemas de administración del personal, representan el 22 % y 18 %, respectivamente.

    En otras palabras, en 34 % de los startups que fallan, los Product Managers fallaron en

    • identificar un problema crítico de sus usuarios
    • y diseñar un producto que lo arregle

    Si bien el rol de Product Manager existe porque no se puede esperar que todo mundo tenga visión de producto, eso no significa que ellos son los únicos que pueden aportar a la evolución y dirección del mismo. Y es ahí donde todos tenemos que poner de nuestra parte: los contribuidores individuales (diseñadores, programadores, etc.) aportando sus ideas basadas en la construcción del día a día del producto, y los Product Managers tomando esas ideas y convirtiéndolas en hipótesis comprobables.

    Lane menciona:

    En mi experiencia, las ideas basadas en asunciones que vienen de gente de producto, rara vez son mucho mejores que las que vienen de ingenieros. La diferencia es que un buen Product Manager tiene una necesidad imparable de validar o recahzar cada idea que llega a su cabeza.

    De acuerdo.

    Creo que el rol del Product Manager no es dictar hacia donde debería de ir el producto, sino funcionar como un catalizador de ideas — moldearlas en hipótesis y validarlas en función de la misión y visión que guían la construcción del producto.

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