Cómo fue trabajar en GitLab
(yorickpeterse.com)- Los 6 años que trabajó en GitLab, desde octubre de 2015 como el empleado número 28 hasta diciembre de 2021, fueron una mezcla de trabajo totalmente remoto, el caos de una startup en rápido crecimiento, problemas de rendimiento, despliegue y cultura organizacional, además de burnout
- En el GitLab inicial, la mayor queja de los usuarios era el bajo rendimiento y las caídas frecuentes, pero faltaba infraestructura de monitoreo de rendimiento y además había que crear herramientas que también pudieran usar los clientes self-hosted
- Entre 2017 y 2018, en el equipo de Database, creó un balanceador de carga para base de datos; en ese mismo periodo coincidieron la eliminación de la base de datos de producción y fallas en los respaldos, lo que provocó unas 6 horas de pérdida de datos y una recuperación de unas 24 horas
- Entre 2019 y 2021, el equipo de Delivery unificó la estructura de repositorios separados de Community Edition y Enterprise Edition, reduciendo el flujo desde un commit hasta el despliegue en GitLab.com de un peor caso de 3 semanas a unas horas o un día
- Las lecciones que sacó de GitLab fueron que la escalabilidad debe formar parte de la cultura, que decidir qué es “mínimamente viable” sin datos es riesgoso, que operar SaaS y self-hosted al mismo tiempo genera conflictos de requisitos, y que el despliegue rápido y la compensación basada en el rol son importantes
Antes de unirse a GitLab y su rol inicial
- Antes de entrar a GitLab trabajaba en una pequeña startup de Ámsterdam, y la empresa estaba en una situación difícil, al punto de rentar una parte de la oficina por falta de dinero
- En su tiempo personal trabajaba en Rubinius, y como quería estabilizarlo lo suficiente como para poder usarlo en producción, empezó a buscar un trabajo donde pudiera dedicarse a eso
- Conoció a Sytse en meetups de Ruby y talleres de Rails Girls, se interesó por GitLab, envió un correo en el verano de 2015 y se unió en octubre de 2015 como el empleado #28
- Su trabajo consistía en mejorar el rendimiento de GitLab, y podía usar el 20% de su tiempo laboral en Rubinius
- Durante 6 años pasó por varios equipos con bastante autonomía, reportó a 10 managers distintos y vivió el crecimiento de GitLab de unas 30 personas a cerca de 2000
2015~2017: trabajo remoto y creación de herramientas de rendimiento
- Empezó a trabajar en GitLab al día siguiente de su último día en la empresa anterior, pasando de trabajar 5 días a la semana en oficina a hacerlo 5 días a la semana en remoto
- En ese entonces GitLab ya era una empresa totalmente remota, pero con un ambiente muy sociable, y había reuniones y eventos frecuentes en lugares como Ámsterdam y Austin
- En este periodo GitLab vivió su primera etapa de crecimiento, contrató alrededor de 100 personas nuevas, pasó de poco más de 30 personas a más de 130, luego bajó a más de 80 y después volvió a crecer
- Al mismo tiempo también vivió los problemas típicos de una startup que crece rápido: graves problemas de rendimiento, incidentes casi semanales y una gestión inmadura
- “GitLab is slow” era la mayor queja de los usuarios
- En Hacker News también aparecían seguido quejas sobre la lentitud de GitLab
- Mejorar el rendimiento era todavía más difícil por la falta de herramientas
- En ese momento el monitoreo de rendimiento se limitaba a una cuenta trial de New Relic, y solo se podían monitorear 1 o 2 de los 15 a 20 servidores totales
- Los datos que entraban no representaban con precisión la situación completa
- GitLab exigía que las herramientas que usaba también estuvieran disponibles para clientes self-hosted y, si era posible, fueran open source
- Para mejorar el rendimiento, primero había que construir las herramientas, y de ahí salió la función oficial GitLab Performance Monitoring
- También construyó en este periodo Sherlock, un profiler pesado para entornos de desarrollo
- GitLab reconoció que una sola persona no podía resolver los problemas de rendimiento, así que creó el equipo de Performance y le asignó un manager dedicado y un pequeño presupuesto de contratación
- Intentó hacer que Rubinius funcionara en GitLab, pero no lo logró, y entre los problemas de dirección del mantenimiento y la controversia dentro de la comunidad Ruby, al final dejó ese trabajo
2017~2018: equipo de Database, balanceador de carga e incidente en la base de datos de producción
- Después del caos del primer año y medio, el rendimiento mejoró bastante y GitLab también empezó a tomarse el tema con más seriedad
- El equipo de Performance dejó de enfocarse en mejoras generales de rendimiento y pasó a centrarse en el rendimiento de base de datos, convirtiéndose en el equipo de Database
- También aumentó el presupuesto de contratación y se asignó un ingeniero de infraestructura para ayudar con nuevas configuraciones de base de datos y otros temas
- La función clave que construyó en esta etapa fue el GitLab database load balancer
- La presentación relacionada se publicó como Scaling the GitLab database
- Los desarrolladores escribían queries de base de datos como siempre, y el balanceador las enrutaba al primary o a una replica
- Después de una escritura, aplicaba sticking para seguir usando el primary hasta que los cambios se reflejaran en todas las replicas
- Tuvo un gran impacto positivo en el rendimiento, y lo que más orgullo le da es que se introdujo de forma transparente
- El 31 de enero de 2017 ocurrió el incidente de eliminación accidental de la base de datos de producción de GitLab.com
- El incidente se publicó como GitLab.com database incident
- El sistema de respaldos llevaba mucho tiempo sin funcionar correctamente, y el sistema que debía alertar sobre errores en los respaldos tampoco estaba funcionando
- La recuperación fue posible porque se había copiado en staging la data de producción de unas 6 horas antes
- La recuperación tomó unas 24 horas y se perdieron alrededor de 6 horas de datos
- En ese mismo periodo GitLab seguía queriendo hacer sharding de base de datos, pero según los datos y el criterio de los ingenieros en ese momento, no era una buena solución al problema
- GitLab tenía alrededor de 10:1 más solicitudes de lectura que de escritura
- El volumen de datos almacenados tampoco era tan grande como para justificar la complejidad del sharding
- Incluso un consultor comentó que, para clientes con cargas y volúmenes de almacenamiento mucho mayores, el sharding también era excesivo
2019~2021: equipo de Delivery y mejora en los tiempos de despliegue
- Hacia 2018~2019, cansado del trabajo de rendimiento y confiabilidad, se movió al nuevo equipo de Delivery
- El objetivo del equipo de Delivery era mejorar el proceso y las herramientas de release de GitLab, y el estado en ese momento era caótico
- Desde que un commit entraba a la rama main hasta que se desplegaba en GitLab.com, normalmente pasaban varios días, y en el peor caso hasta 3 semanas
- El mayor cuello de botella era que GitLab Community Edition y GitLab Enterprise Edition existían como repositorios Git separados
- Se necesitaban merges manuales y resolución de conflictos de forma regular
- Para resolver esto se hizo un trabajo de varios meses para unir ambos proyectos en uno solo
- Ese trabajo se publicó como Merging CE and EE codebases
- El equipo de Delivery mejoró mucho el proceso de release y logró llevarlo a un punto en que los cambios podían desplegarse en cuestión de horas
- Pasar de un peor caso de 3 semanas a un peor caso de alrededor de un día fue una gran mejora
- Aun así, esa velocidad seguía sin ser idealmente lo bastante rápida
Cambios en la cultura organizacional y el proceso que llevó a su salida
- 2018 fue el último año del summit de GitLab centrado en los empleados, y desde 2019 pasó a un formato más parecido a una conferencia tradicional orientada a clientes
- Como reunir a más de 2000 personas cuesta muchísimo, el cambio era comprensible desde lo financiero, pero socialmente le pareció menos divertido que antes
- La gestión de laptops también fue una fuente constante de conflicto
- GitLab exigía o evaluaba exigir software de administración remota a empleados que accedían a recursos de GitLab desde una Mac de la empresa o hardware personal
- Las herramientas propuestas tenían un carácter intrusivo y podían usarse para registrar actividad del usuario, y sentía que faltaban garantías contra abusos
- Mucho del feedback de los empleados era ignorado hasta que personas clave dentro de la empresa presionaban
- GitLab finalmente eligió una solución de gestión de laptops basada en SentinelOne
- Con los cambios culturales y los cambios personales, su motivación y productividad bajaron y su estrés aumentó
- Después de que un manager con muy buenas evaluaciones se moviera a otro rol y un nuevo manager tomara el equipo, surgieron conflictos y se le aplicó un performance enablement plan
- El PEP era un paso previo al PIP, un proceso pensado para normalizar de nuevo la relación y el trabajo
- Aunque al principio le dijeron que era un proceso para mejorar en ambos lados, sintió que en la práctica solo se enfocó en los cambios que él debía hacer
- Iba a durar un mes, pero se extendió otro mes, y al cabo de dos meses se consideró que el resultado era satisfactorio
- Después de eso empezó a sentir que GitLab y él iban en direcciones distintas, y comenzó a pensar en irse
- Por la salida a bolsa de GitLab y el momento de ejercer sus stock options, pudo renunciar en diciembre de 2021
- En ese momento, en Países Bajos había que pagar 52% de impuesto sobre la renta por la diferencia entre el precio de ejercicio y el valor estimado de las acciones, incluso si no había liquidez
- La carga fiscal era tan alta que era difícil ejercer antes de la salida a bolsa de GitLab
- Después la ley cambió para permitir elegir entre pagar impuestos al momento de ejercer o cuando las acciones obtuvieran liquidez
- En diciembre de 2021 dejó GitLab y empezó a dedicarse full-time a Inko
Lecciones que sacó de su experiencia en GitLab
-
La escalabilidad debe formar parte de la cultura de la empresa
- Considera que GitLab no priorizó lo suficiente la escalabilidad, y que incluso cuando se fue, ese problema seguía presente
- Los principales ingresos de GitLab no venían de GitLab.com, sino de clientes que self-hosteaban GitLab Enterprise Edition
- GitLab.com costaba mucho más de lo que generaba, y por eso el foco terminaba puesto en el mercado self-hosted
- Muchos de los problemas de rendimiento de GitLab.com no aplicaban directamente a buena parte de los clientes self-hosted
- Muchos desarrolladores sí querían mejorar el rendimiento, pero no recibían el tiempo ni los recursos para hacerlo
-
Los equipos deben moverse con base en datos y con foco en los desarrolladores
- GitLab tenía una dinámica muy guiada por product managers, y las funciones a implementar las definían principalmente product managers y directors
- Algunas decisiones eran razonables, pero otras le daban la impresión de que había que construir algo solo porque en Hacker News parecía una buena idea
- Cree que GitLab podría haber tenido mejores resultados si hubiera adoptado antes una jerarquía más simple, dado más autoridad a los team leads y promovido más interacción con los usuarios
- Para él, el rol del product manager debería ser contribuir técnicamente a construir el producto mientras conecta al equipo con los usuarios
-
Sin datos es difícil decidir qué es “mínimamente viable”
- Uno de los principios centrales de GitLab era empezar siempre con el minimal viable change
- El problema era que cada persona tenía una definición distinta de “minimal”
- Algunos equipos consideraban que el rendimiento o una buena usabilidad eran requisitos de algo viable, pero otros no les daban importancia
- Como resultado, cree que se construyeron funciones que no eran útiles para los usuarios
- Una plataforma serverless que nadie pidió y que al final se cerró
- Soporte para administrar clusters de Kubernetes que no funcionó durante 3 semanas sin que nadie se diera cuenta
- Una solución de chatops construida sobre CI en vez de usar una solución existente
- Una función de requirements management que solo permitía crear y consultar, pero no editar ni eliminar
- GitLab hacía encuestas trimestrales a usuarios y algunos equipos tenían acceso a datos de participación de usuarios, pero según recuerda y por conversaciones con excolegas, esos datos se usaban de forma intermitente más que como parte central del flujo de trabajo del equipo
-
Es difícil operar SaaS y self-hosted al mismo tiempo
- GitLab ofrecía tanto instalaciones self-hosted como SaaS
- Ambos modelos tienen estructuras de ingresos, requisitos y formas de aplicar actualizaciones distintas
- SaaS necesita despliegues rápidos y la capacidad de manejar grandes volúmenes de datos y carga de trabajo en una infraestructura centralizada
- La mayoría de las instancias self-hosted son mucho más pequeñas que el SaaS, así que los problemas y soluciones del SaaS no se trasladan tal cual
- Como resultado, en varias partes de la plataforma había que pensar en dos rutas de código, una para SaaS y otra para self-hosted
- Si una empresa se enfoca en SaaS o en self-hosted, puede concentrar toda su atención en la experiencia adecuada para ese modelo operativo
-
Tener más personas no garantiza mejores resultados
- GitLab contrató a muchísima gente con los años y hoy emplea a más de 2000 personas
- No sabe cuántos desarrolladores hay exactamente, pero al revisar la página de equipos estima que son al menos varios cientos
- Agregar más personas a un proyecto no mejora necesariamente la productividad ni el resultado, y eso conecta con “The Mythical Man-Month”
- Aunque no tiene datos, cree que en la mayoría de las empresas bastan menos de 20 desarrolladores, algunas necesitan entre 20 y 50, y muy pocas realmente requieren entre 50 y 100
- Si se supera la marca de 100 desarrolladores, cree que vale la pena preguntarse si el alcance del producto se volvió excesivo
- Aclara que esta idea aplica a desarrolladores de software; áreas como producción de hardware personalizado, ventas o soporte tienen costos de sincronización distintos
-
Su evaluación de Ruby on Rails es ambivalente
- GitLab está hecho con Ruby y Ruby on Rails, y esa combinación contribuyó mucho a su éxito
- Al mismo tiempo, cuando el proyecto crece y hay muchos contribuidores con distintos niveles de experiencia, Rails hace fácil escribir código con mal rendimiento
- Un problema representativo es el N+1 query problem
- ActiveRecord de Rails tiene funciones para resolverlo, pero son opt-in
- Si el desarrollador lo olvida, terminan generándose queries por fila y aparecen problemas de rendimiento
- Muchos de los problemas de rendimiento que resolvieron en los primeros años de GitLab eran precisamente consultas N+1
- Ruby en sí también le parecía un gran lenguaje, pero su tendencia a usar mucho meta programming complica las cosas en proyectos grandes
- Go, Rust y Node.js pueden ser más eficientes que Ruby, pero no cree que tengan un framework tan potente como Ruby on Rails
- Python y Django también podrían ser opciones, pero cree que probablemente arrastrarían parte de los mismos problemas de Ruby y Rails
-
El tiempo de despliegue es importante para el éxito organizacional
- Cree que, una vez hecho push del código a la rama o tag de despliegue, debería poder desplegarse en un máximo de una hora
- A GitLab le tomó unos 4 años acercarse a eso, y aun así todavía le faltaba camino
- Los despliegues rápidos ayudan a responder a incidentes
- Si desplegar tarda horas, puede hacer falta aplicar hot-patches
- La velocidad de despliegue también afecta la motivación
- Ver y usar en la práctica los cambios que uno hizo genera satisfacción
- Trabajar durante semanas en un cambio y que luego se despliegue otras 2 semanas después desmotiva
- Las organizaciones deberían ser muy agresivas en reducir el tiempo de despliegue y el tiempo que toma el test suite dentro del proceso de despliegue
- La clave no es que todas las pruebas y despliegues deban durar menos de cierto tiempo fijo, sino priorizar desplegar tan rápido como sea posible dentro de lo que permitan las necesidades del negocio
-
El salario basado en ubicación es discriminatorio
- El salario en GitLab estaba afectado por varias variables, y una de ellas era la ubicación
- Si una empresa tiene oficinas físicas y necesita contratar en ciertas regiones, puede entenderse un ajuste por ubicación, pero en una empresa totalmente remota no ve una razón válida para pagar distinto a dos personas con la misma experiencia y responsabilidad solo por vivir en lugares diferentes
- Cuando se fue, su salario en Países Bajos era de aprox. €120,000 brutos al año, unos aprox. €8,500 al mes
- Cree que si hubiera vivido en la Bay Area habría ganado al menos el doble, quizá más
- La solución, según él, es compensar con base en los requisitos del puesto, no en la ubicación del candidato
- Menciona a 0xide Computer Company como ejemplo de una empresa que paga lo mismo sin basarse en la ubicación
- Eso se trata en Compensation as a Reflection of Values
Conclusión
- Su tiempo en GitLab fue una mezcla de experiencias muy positivas y muy negativas
- Siente mucho orgullo por lo que logró en varios equipos y por las personas con las que trabajó
- Le queda como pena que el último año aproximadamente haya dejado un sabor amargo sobre la experiencia completa
- No se arrepiente de haber trabajado en GitLab, y cree que, si pudiera hacerlo de nuevo, haría algunas cosas de manera un poco distinta con la ventaja de la retrospectiva
- A pesar de sus defectos, piensa que GitLab es mucho mejor que muchas otras empresas y que sigue siendo una empresa recomendable para trabajar
1 comentarios
Opiniones en Hacker News
La comparación de que si una empresa baja los sueldos por color de piel o género sería un gran problema, pero hacerlo por lugar de residencia sí está bien, requiere pensarse más
El color de piel y el género difieren del lugar de residencia en si se pueden cambiar y en si realmente tienen relación con el trabajo
El lugar de residencia sí tiene relación con el trabajo porque la empresa debe hacerse cargo de establecer entidades locales, entender los sistemas judiciales y fiscales, zonas horarias, costos de viajes, etc.
Se puede discutir si la compensación regional es correcta, pero compararla con la discriminación racial o de género termina haciendo que GitLab parezca una organización racista o sexista, y la discusión se acaba muy rápido
Dice que si hubiera vivido en el Bay Area habría ganado más del doble, y que eso es injusto solo porque su lugar de residencia era distinto, pero no parece que haya puntos de víctima que ganar aquí
Es más bien un argumento de alguien que no entiende muy bien la economía
El sueldo que recibo ahora en Estados Unidos es más o menos el doble del que tenía en Reino Unido, pero mi nivel de vida es parecido; en algunos aspectos es peor y en otros mejor
Si el autor del texto original se hubiera ido al Bay Area, es muy probable que su nivel de vida hubiera bajado aunque su compensación fuera mayor
Hay que considerar no solo los ingresos, sino también la seguridad social, los impuestos y la cultura, y hasta estoy dispuesto a aceptar una gran reducción salarial para volver a Europa y vivir con más comodidad
La motivación de GitLab para la compensación regional aparece en https://handbook.gitlab.com/handbook/total-rewards/compensat... y parece bastante razonable
Si se pagaran sueldos del Bay Area incluso en Filipinas o Ucrania, la gente quedaría atrapada con esposas de oro y podría no poder irse cuando debería, hasta quemarse
En cambio, si se pagara el salario mediano mundial, no podrían contratar gente en California o Londres
También es discutible la afirmación de que no se necesitan product managers y de que no debería haber más de 100 desarrolladores para un solo producto
El autor del texto original parece ser un ingeniero destacado con mucha autonomía, alguien que probablemente habría sido mucho más feliz y exitoso en una startup relativamente pequeña
Si no hubiera tenido que esperar cambios en las normas fiscales, quizá se habría ido antes y habría escrito una buena experiencia
También vale la pena pensar en lo difícil que habría sido dejar la empresa si, además de acciones, hubiera recibido hasta $300k de compensación en Ámsterdam
Si se obligara a pagar la misma compensación en todo el mundo, es probable que la empresa prefiriera contratar solo localmente por las ventajas de reuniones presenciales, misma zona horaria y comunicación
Esto es especialmente cierto en una situación económica en la que también hay muchos candidatos interesados en regiones de alto costo de vida
Puede cambiar en el futuro, pero es útil ver la estructura real de incentivos
Las empresas que contratan en otros países también asumen riesgos, y eso además deja conocimiento y semillas de futuras empresas en esos lugares
Ir a la oficina le da al empleado poder de negociación salarial gracias al costo de vida de esa zona, pero en una empresa y cultura totalmente remotas, la empresa puede contratar en cualquier lugar y pagar sueldos cercanos al mínimo común denominador
El trabajo remoto hace que todos compitan como contratistas independientes contra talento de todo el mundo, mientras que el trabajo de oficina hace que compitan principalmente con personas de la misma región
Parece ser la historia de alguien que era el empleado número 28, reportaba directamente al CEO, luego cada vez se fueron metiendo más managers por encima, uno de ellos lo puso en un PEP, captó la señal y se fue
Es un flujo bastante estándar, y puede ser una de las razones por las que en las grandes empresas a la gente le cuesta hacer cosas importantes
Aunque inicies un proyecto dentro de la empresa y lo lleves al éxito, la empresa mete gente por encima, y al final puedes terminar siendo el enésimo empleado en el proyecto que tú mismo empezaste, y que te digan que tu desempeño es insuficiente
Solo quiere hacer trabajo divertido e interesante, termina teniendo opiniones fuertes sobre cosas que no son importantes, y si un contribuidor individual cercano al CEO no acepta las decisiones del manager, se vuelve una pesadilla de gestión
Puede moverse de un lado a otro y crear problemas sin asumir responsabilidad por las decisiones
La seguridad de endpoints y el uso de dispositivos personales son una de las pistas
Esa cultura permisiva no escala por los costos de cumplimiento normativo y de productividad de desarrollo
Es difícil desprenderse de un desarrollador veterano que insiste en su distribución de Linux preferida, pero para el trabajo corresponde usar una computadora laboral y que la empresa gestione las actualizaciones
Lo mismo aplica a la historia de los backups de la base de datos: si eres el equipo de base de datos, los backups son la prioridad número uno
No se puede pasar “no había backups” en voz pasiva, y da la impresión de que estaba más interesado en debatir la arquitectura de sharding que en mantener el sitio día a día
La conclusión de que GitLab no invirtió lo suficiente en el rendimiento del producto hospedado también puede ser que, si ese producto generaba grandes pérdidas, era natural no meterle más recursos
Hay que convencer con fundamentos de negocio reales de por qué ese trabajo es más importante y genera dinero, no con ingeniería interesante
Un manager y yo iniciamos juntos un proyecto exitoso, pero la dirección, de forma codiciosa, está metiendo política y dilemas sociales, insertando capas de management e intentando reemplazarnos a mí y a ese manager
Aprendí por qué no hay que preocuparse de verdad por el trabajo, y por eso siento que el proyecto se va a arruinar y desmantelar
Aquí parece asumirse que ese empleado realmente era de alto desempeño, que no necesitaba un manager y que no merecía recibir un PEP, pero no es una suposición segura
He visto empleados tempranos en startups que no podían, o no querían, crecer al ritmo al que crecían la empresa y su rol
Es común que se los mantenga por respeto a sus contribuciones pasadas, por el conocimiento histórico difícil de reemplazar y por sus relaciones con fundadores y empleados tempranos que se volvieron líderes
Pero el hecho de ser un empleado inicial y haber participado en proyectos tempranos importantes no significa que siga siendo la mejor persona, o la adecuada, para encargarse de ese trabajo
Alguien puede ser excelente haciendo que algo funcione con soluciones temporales, tareas cron e intervenciones manuales, pero en una empresa grande esa forma de operar puede no encajar en absoluto
Si no se adapta o se resiente por tener que trabajar al estilo de una empresa grande, termina haciendo más daño que bien
En toda empresa temprana hay empleados iniciales que no crecen junto con la empresa, pero ese no es el único desenlace ni necesariamente el más común
En GitLab también hay muchos empleados de larga trayectoria, pero no los escuchamos en un post de blog cargado de quejas, así que hay que considerar el sesgo de selección
Uso GitLab desde hace mucho tiempo y el producto sigue evolucionando, así que no estoy de acuerdo con la afirmación de que sea un producto estancado
Recién tres años después, cuando vieron que los releases seguían fallando, se volvió un problema, pero más que por mi influencia pareció el resultado de que alguien buscara en Google “cómo evitar fallas en los releases”
No sé cuál es la solución, y ahora estoy volviendo a vivir lo mismo con otro tema
Al principio simplemente hacía lo que hacía falta, pero más adelante cada paso tenía que pasar por un nuevo puesto de manager interpuesto, con la excusa de asegurarse de que no hiciera lo incorrecto
Eso ocurrió sin importar las ideas y contribuciones tempranas que hicieron posible el crecimiento de la empresa
Me pregunto si esto también tiene relación con el hecho de que sigan abiertos issues de hace años relacionados con GitLab CI
Desde afuera, parece que GitLab perdió por completo la capacidad de construir cosas excelentes, y da la impresión de que no quieren corregir bugs de años que se repiten una y otra vez
La parte de que se les permitiera a los empleados usar computadoras personales es casi sorprendente
Por más pequeña que sea una organización, debería proporcionar equipo propiedad de la empresa y exigir que todo el trabajo de la empresa se haga en ese equipo
Para la empresa tiene grandes ventajas en términos de control de propiedad intelectual, para el empleado ayuda mucho a separar el tiempo de trabajo del tiempo personal, y el costo tampoco es tan grande
Así puedes usar el mismo conjunto de herramientas que quieres adonde vayas, y la capacidad de borrar y recrear rápido también sirve para depurar problemas del tipo “en mi computadora funciona/no funciona”
En un extremo está el enfoque basado en la memoria; en el otro, crear builds completamente reproducibles en cualquier lugar con https://nixos.org/
Entre medio hay muchas opciones, y también he visto gente que mantiene un conjunto de archivos de Ansible que instalan lo necesario con
host: localhostYo uso la versión más reciente de Ubuntu y mantengo algunos scripts de shell [1] que instalan el 80% de lo que quiero en una instalación nueva
Si quieres abordarlo de forma científica, puedes instalar algo como https://atuin.sh/ para sacar estadísticas de los programas que realmente ejecutas con frecuencia, basadas en tu historial de shell de largo plazo
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
No es una solución perfecta, pero al menos, si es equipo de la empresa, una filtración pasa a ser una acción maliciosa o el resultado de incompetencia al mover datos sensibles por una vía no autorizada
Si la empresa enfrenta una demanda, el contenido de los dispositivos personales también puede terminar siendo objeto de todo tipo de citaciones
Exigir un dispositivo separado no necesariamente le da al usuario una ventaja de equilibrio entre trabajo y vida; solo resulta incómodo
Las acciones para separar el tiempo laboral del personal dependen sobre todo de los propios hábitos, capacidades y, en última instancia, decisiones
Antes sentía que los salarios por región eran discriminatorios, pero ahora en general ya no lo veo así
Al final, lo que se está pidiendo es un salario de SF, y la gente de India terminaría pidiendo salarios de Países Bajos o de SF
Eso probablemente generaría una carrera hacia el fondo
El hecho simple es que cada quien ganaba lo suficiente para vivir bien en su propia región
Si quieres más, puedes mudarte; y si no te mudas, probablemente tengas tus razones
Todos quieren salarios de SF y costo de vida de Indiana o India, pero por razones obvias eso difícilmente funciona
Si te contratan, estés en San Francisco, Poland o Indonesia, recibes salario de nivel estadounidense
Esos puestos son extremadamente competitivos
Es como abrir la puerta al mundo entero y decir “muestren lo que tienen”, así que puedes evaluar un grupo mucho más grande de postulantes y talento, y dentro de él hay muchas personas excepcionales, muy inteligentes y con mucho empuje, provenientes de países pobres
Así funcionan la oferta y la demanda
Si dices que vas a pagar más, normalmente terminas contratando candidatos de mayor nivel
Conozco a bastantes personas que trabajan remotamente desde varios estados de EE. UU. y reciben salarios de nivel SF
Por supuesto que es posible
SF tampoco debería confiarse demasiado
Detroit alguna vez fue Motor City y Music City, un centro cultural y tecnológico mundial, pero sus competencias centrales fueron sacudidas por mano de obra de otras regiones, más barata y eficiente
Lo que se pide es igual salario por igual trabajo
Si los miembros del equipo hacen el mismo trabajo, pero otros reciben el monto completo y tú solo una parte, algo está seriamente mal
La contribución al equipo no depende de dónde estés en ese momento
El tiempo que pasas viajando a la oficina tampoco cambia las expectativas sobre tus resultados
Si la ubicación de la oficina es excesivamente cara, la empresa debería resolver el problema buscando una ubicación más barata, no hacer que los empleados subsidien la mala ubicación de su oficina
Los 100k que recibe el empleado y el costo para la empresa no son lo mismo
Según el país, cambian los impuestos adicionales, seguridad social y prestaciones que debe asumir la empresa, y en muchos casos se necesita una entidad local o una forma virtual de negocio, además de recursos de apoyo para cumplir con la ley local
Yo también estoy del lado de empleados que reciben salario según el estándar local mientras desempeño un rol global en una multinacional, pero hay más cosas que considerar de las que parece
Básicamente ajusta según el costo de vida, no según el costo de contratación, pero apunta a una remuneración equivalente
Los malos managers son un dolor de cabeza para la industria
Por otro lado, muchas startups nacen precisamente porque sus fundadores tuvieron malos managers en trabajos anteriores
Me viene a la mente la historia de los traitorous eight y Fairchild Semiconductors
Personalmente, si en mi trabajo anterior no hubiera tenido un manager no técnico, político y vengativo, creo que no habría tenido motivación para iniciar mi startup
Mirando hacia atrás, incluso pienso que ojalá me hubiera tocado un manager tan malo antes, al inicio de mi carrera
También sería bueno poder encontrar empresas que realmente necesiten mis habilidades y moverme más fácilmente, sin tanta carga de procesos de RR. HH.
Se afirma que todo el modelo de programación de Ruby se basaba en la premisa de que, como la mayor parte del tiempo se pasa esperando E/S o la red, la velocidad del lenguaje no importa
Pero hoy, del lado de Node.js y la JVM, existen modelos que hacen otras tareas o atienden más solicitudes mientras esperan E/S o la red
En 2024, usar Ruby/Rails puede ser un desperdicio, pero puede ser una buena opción para apps empresariales con una cantidad limitada de usuarios, casos donde la velocidad de desarrollo es absolutamente crítica, o prototipos rápidos para validar el mercado
Rails es un framework excelente y su productividad es sobresaliente, pero un proyecto Rails de 2 o 3 años siempre se vuelve difícil de mantener
Un proyecto Rails no es más difícil que un proyecto Django o Express
Para que no crezcan malezas en cualquier base de código, se necesita disciplina y jardinería constante
Si Ruby y Rails tienen debilidades, siguen siendo el rendimiento bruto del lenguaje y sus mayores requisitos y uso de memoria, lo que los hace menos atractivos para trabajos que requieren baja latencia o una huella de memoria pequeña
Según mi experiencia, duele sobre todo cuando el tráfico fluctúa de golpe y con fuerza, o cuando hay muchísimos usuarios activos usando WebSockets; y lo de WebSockets se resuelve en gran parte con anycable
Pero muy pocos productos llegan a esos límites y, aun si llegan, se pueden resolver
Stripe, GitHub y Shopify son ejemplos representativos de que Rails ha escalado sin problemas de muchas maneras
Una gran fuerza que impulsó Rails fue la idea de DHH sobre la felicidad del desarrollador, y eso está estrechamente ligado a la velocidad de desarrollo
Si en la comunidad Rails hay discusiones sobre E/S es porque son importantes para operar servidores web, no porque sean el único foco, o el principal, al decidir sobre el lenguaje o el framework
Si el objetivo es maximizar el uso de CPU del servidor web, en Rails también se podía lograr levantando varios procesos, un enfoque usado desde hace mucho y similar a levantar varios threads en la JVM
Puede ser menos cómodo, pero es un modelo usado desde los años 90 y, como las solicitudes web suelen ejecutarse de forma independiente, la comunicación entre procesos muchas veces tampoco es un gran problema
Generalizarlo como “desperdicio” es demasiado fuerte
Escribir una app en Rust también puede ser un desperdicio según la situación; depende de dónde esté la presión
En etapas tempranas, no poder lanzar es una preocupación mucho mayor, y aun en etapas medias o tardías, la velocidad de los desarrolladores es uno de los factores más difíciles de escalar
Como CTO de una empresa que usa un backend Rails y un frontend React, la velocidad de desarrollo es muy importante, y la velocidad de desarrollo con Rails sigue siendo una gran ventaja
También hay problemas de escalabilidad, pero el 99% no son problemas de Rails sino de la base de datos
Creo que pagarles a los ingenieros según su ubicación es otra forma de discriminación
Se debería pagar según la capacidad del empleado, no según su ubicación
Las reglas gubernamentales dicen que no se debe discriminar por género, religión, orientación sexual, etc.; ¿es justo discriminar salarios por ubicación?
He visto amigos que se mudaron de Europa a Asia en el mismo rol y, siendo la misma persona y el mismo rol, cobraron menos solo porque cambió su ubicación
Si te mudas a un mercado menos competitivo y se vuelve más difícil conseguir otro empleo, aumenta la probabilidad de que vayas a trabajar por un salario más bajo
Aunque el trabajo remoto parezca no atarte al mercado local, los gobiernos suelen poner grandes barreras a la contratación internacional, por lo que algunos países pueden convertirse en mercados menos competitivos
Si alguien se mudó a otro país dentro de la misma empresa, haciendo el mismo trabajo, y le bajaron el sueldo, casi con certeza aceptó ese recorte por esa razón
Creo que las empresas deberían pagar en función de la capacidad del empleado de vivir con comodidad y salud, no de alguna escala universal de valor
Creo que ese valor universal es imposible
La idea de basarse solo en la capacidad, sin querer, rompe comunidades y, mediante la desigualdad, agrava la gentrificación y la destrucción de la cohesión social
La ubicación importa
Se paga para dar la misma calidad de vida, el mismo tipo de vivienda, la misma oportunidad de mantener a una familia y de enviar a los hijos a escuelas similares
Como el costo de estas cosas varía de un país a otro, el ingreso necesario también cambia
Una empresa necesita cierta capacidad y paga lo que el mercado determine que vale esa capacidad, y no más
Como el mercado asigna precios distintos a la misma capacidad según la ubicación, los salarios también cambian
La religión es una excepción ambigua, pero, sea justo o no, esto no es discriminación
Si GitLab.com siempre costó mucho más de lo que generaba, y la empresa ganaba dinero principalmente con clientes de GitLab Enterprise Edition self-hosted, me pregunto si realmente fue un error no invertir lo suficiente en escalabilidad
En primer lugar, una empresa debería invertir en lo que le hace ganar dinero, no en lo que le hace perderlo
Se puede hacer un juicio más sofisticado de que un gitlab.com con mejor rendimiento podría traer más clientes y mejor reputación, pero si el negocio real es vender software self-hosted, tiene sentido concentrar ahí los recursos de desarrollo
De hecho, cuando compramos licencias de GitLab y nos enteramos de que el costo por asiento era el mismo tanto si GitLab alojaba la solución como si la alojábamos nosotros, nos preguntamos por qué tendríamos que cargar nosotros con los costos de infraestructura
Si van a hacer GitLab.com a medias, a largo plazo podría ser mejor hacerlo bien o eliminar el producto y enfocarse solo en clientes de self-hosting, como GitLab Enterprise Edition
Pero nadie en la dirección querría tomar una decisión así
Por eso terminan operando el producto a medias
Para quienes se preocupan por el producto en sí, esta situación puede ser frustrante
Cada vez que entra un desarrollador nuevo, dice “deberíamos preocuparnos más por la escalabilidad”, y los seniors responden “sí, sí, ya sabemos…”
Desde el punto de vista económico, si un desarrollador de Ámsterdam aporta el mismo valor que uno del Bay Area, probablemente corresponde pagarle el mismo sueldo.
Aunque el precio del mercado local para un desarrollador de Ámsterdam sea más bajo, estás construyendo una empresa global y compites con otras empresas globales.
Aunque hoy puedas conseguir a un desarrollador de Ámsterdam con descuento, tarde o temprano un competidor le ofrecerá una cifra más cercana a su valor, o se irá a hacer lo suyo.
Creo que las empresas más fuertes terminarán pagando a su talento una compensación independiente de la ubicación.
Al final, lo importante es el valor entregado.
Si tienes una gran base de código en Ruby como GitLab y quieres venderle a grandes empresas que valoran el rendimiento y la confiabilidad, probablemente le pagarías a una persona así más de €120k al año.
La mayoría de los ingenieros que valoran el rendimiento, la seguridad de tipos y la confiabilidad no están interesados en Ruby, así que el precio de mercado de esa combinación de habilidades sin duda es más alto.
No sé si llega al nivel de $500k anuales del Bay Area, pero las empresas fuertes que quieran al mejor talento lo perderán si no vinculan la compensación al valor aportado en vez de a la ubicación.
Considero que el tiempo que tarda desplegar código es uno de los indicadores más importantes —quizá el más importante— para mantener la velocidad de los desarrolladores cuando una startup escala.
El cambio de contexto es una de las tareas más caras en el día a día de un desarrollador, pero también una de las más fáciles de ignorar.
A los managers les gusta armar el calendario del equipo según su propia agenda, pero eso a menudo interrumpe el “calendario de creador” de los contribuyentes individuales.
Muchas organizaciones se dan cuenta de esto y se enfocan en el costo del cambio de contexto desde el lado de la agenda, pero para los desarrolladores el tiempo desde la compilación hasta el despliegue es igual de importante, o incluso más.