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

Ayudo a personas que trabajan con software a mejorar sus carreras profesionales.

Los miembros tienen acceso a Pathways, pueden comentar en las publicaciones, interactuar con la comunidad, y muchos otros beneficios. Conoce más.

Agrégame a tu lector RSS, o suscríbete a mi newsletter para recibir los nuevos artículos que publique.