Soft Skills para Devs
Soft Skills para Devs

Artículos en Oscar Swanros.

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

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

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.

Go to Top