Como foi trabalhar no GitLab
(yorickpeterse.com)- Os 6 anos entre outubro de 2015, quando entrou no GitLab como o 28º funcionário, e dezembro de 2021 foram uma experiência misturada de trabalho totalmente remoto, o caos de uma startup em crescimento acelerado, problemas de desempenho, implantação e cultura organizacional, além de burnout
- No início, a maior reclamação dos usuários sobre o GitLab era a queda de desempenho e as falhas frequentes, mas faltava infraestrutura de monitoramento de performance, e ainda era preciso criar ferramentas que também pudessem ser usadas por clientes self-hosted
- Em 2017–2018, no time de Database, foi criado um balanceador de carga de banco de dados; no mesmo período, a exclusão do banco de produção e falhas de backup aconteceram ao mesmo tempo, causando cerca de 6 horas de perda de dados e aproximadamente 24 horas de recuperação
- Entre 2019 e 2021, o time de Delivery unificou a estrutura de repositórios separados do Community Edition e do Enterprise Edition, reduzindo o fluxo que podia levar até 3 semanas após um commit para chegar ao GitLab.com para algumas horas a um dia
- As lições tiradas do GitLab foram que escalabilidade precisa virar cultura, julgamentos de “minimum viable” sem dados são arriscados, operar SaaS e self-hosting ao mesmo tempo cria conflitos de requisitos, e que implantações rápidas e remuneração baseada em função são importantes
Antes de entrar no GitLab e o papel inicial
- Antes de entrar no GitLab, trabalhava em uma pequena startup em Amsterdã, e a empresa estava em situação difícil por falta de recursos, a ponto de alugar parte do escritório
- No tempo livre, trabalhava no Rubinius e queria estabilizá-lo o suficiente para uso em produção, então começou a procurar um emprego onde pudesse trabalhar com isso
- Conheceu Sytse em um meetup de Ruby e em workshops do Rails Girls, passou a se interessar pelo GitLab e, depois de mandar um e-mail no verão de 2015, entrou em outubro de 2015 como o funcionário #28
- Sua função era melhorar a performance do GitLab, e podia usar 20% do tempo de trabalho no Rubinius
- Ao longo de 6 anos, passou por vários times com grande autonomia, reportou para 10 gerentes diferentes e viveu o crescimento do GitLab de cerca de 30 pessoas para aproximadamente 2.000
2015–2017: trabalho remoto e construção de ferramentas de performance
- Começou no GitLab no dia seguinte ao último dia no emprego anterior, trocando uma rotina de 5 dias por semana no escritório por 5 dias por semana de trabalho remoto
- O GitLab nessa fase era uma empresa totalmente remota, mas com um clima bastante sociável, com encontros e eventos frequentes em lugares como Amsterdã e Austin
- Nesse período, o GitLab passou pelo primeiro ciclo de crescimento, contratando cerca de 100 pessoas; a empresa foi de pouco mais de 30 para mais de 130, depois caiu para a faixa dos 80 antes de voltar a crescer
- Ao mesmo tempo, também enfrentou problemas típicos de startups em crescimento acelerado, como graves problemas de performance, incidentes quase semanais e gestão imatura
- “GitLab is slow” era a principal reclamação dos usuários
- No Hacker News também apareciam com frequência reclamações sobre a lentidão do GitLab
- Melhorar a performance era ainda mais difícil por falta de ferramentas
- Na época, o monitoramento de performance se limitava a uma conta trial do New Relic, e só 1 ou 2 dos 15 a 20 servidores podiam ser monitorados
- Os dados recebidos não representavam com precisão o quadro geral
- O GitLab exigia que as ferramentas usadas também fossem oferecidas a clientes self-hosted e, quando possível, fossem open source
- Para melhorar a performance, primeiro foi preciso criar as ferramentas, o que acabou levando ao recurso oficial GitLab Performance Monitoring
- Também foi criado nesse período o profiler pesado para ambientes de desenvolvimento, Sherlock
- O GitLab percebeu que problemas de performance não podiam ser resolvidos por uma única pessoa e criou o time de Performance, com um gerente dedicado e orçamento pequeno para contratações
- Tentaram fazer o Rubinius rodar no GitLab, mas sem sucesso; com questões de manutenção e controvérsias dentro da comunidade Ruby, o trabalho acabou sendo encerrado
2017–2018: time de Database, balanceador de carga e incidente no banco de produção
- Depois do caos dos primeiros 18 meses, a performance melhorou bastante, e o GitLab passou a tratar o tema com mais seriedade
- O time de Performance mudou o foco de melhorias gerais de performance para performance de banco de dados, tornando-se o time de Database
- O orçamento de contratação também aumentou, e foi designado um engenheiro de infraestrutura para ajudar com novas configurações de banco
- O recurso principal criado nessa época foi o GitLab database load balancer
- A apresentação relacionada foi publicada em Scaling the GitLab database
- O desenvolvedor escrevia consultas ao banco normalmente, e o balanceador roteava para primary ou replica
- Após uma escrita, aplicava-se sticking, mantendo o uso da primary até que a mudança fosse refletida em todas as replicas
- Isso teve um grande impacto positivo na performance, e o aspecto de que foi introduzido de forma transparente continua sendo a parte mais motivo de orgulho
- Em 31 de janeiro de 2017, ocorreu um incidente em que o banco de dados de produção do GitLab.com foi apagado por engano
- O incidente foi divulgado em GitLab.com database incident
- O sistema de backup não funcionava corretamente havia muito tempo, e o sistema que deveria alertar sobre erros de backup também não funcionava
- A recuperação só foi possível porque dados de produção de cerca de 6 horas antes haviam sido copiados para o ambiente de staging
- A recuperação levou cerca de 24 horas e houve 6 horas de perda de dados
- No mesmo período, o GitLab ainda queria fazer sharding do banco, mas na avaliação dos dados da época e dos engenheiros isso não resolvia o problema certo
- O GitLab tinha cerca de 10:1 de leituras em relação a escritas
- O volume de dados armazenados também não era grande o bastante para justificar a complexidade do sharding
- Um consultor também comentou que, mesmo para clientes com carga e volume de armazenamento muito maiores, sharding seria exagero
2019–2021: time de Delivery e melhora no tempo de implantação
- Por volta de 2018–2019, cansado do trabalho com performance e confiabilidade, mudou para o recém-criado time de Delivery
- O objetivo do time de Delivery era melhorar o processo e as ferramentas de release do GitLab, e a situação na época era caótica
- Depois que um commit entrava na branch main, levava em média vários dias para chegar ao GitLab.com, e no pior caso podia demorar até 3 semanas
- O maior gargalo era que o GitLab Community Edition e o GitLab Enterprise Edition existiam como repositórios Git separados
- Eram necessários merge manual e resolução de conflitos com frequência
- Para resolver isso, houve um trabalho de vários meses para unir os dois projetos em um só
- O trabalho relacionado foi publicado em Merging CE and EE codebases
- O time de Delivery melhorou bastante o processo de release, chegando ao ponto de implantar mudanças em poucas horas
- Cair de um pior caso de 3 semanas para um pior caso de cerca de 1 dia foi uma grande melhora
- Ainda assim, essa velocidade não era idealmente rápida o suficiente
Mudanças na cultura organizacional e o caminho até a saída
- 2018 foi o último ano do GitLab summit voltado aos funcionários; a partir de 2019, o formato mudou para algo mais próximo de uma conferência tradicional voltada a clientes
- Como encontros com mais de 2.000 pessoas têm custo muito alto, a mudança era financeiramente compreensível, mas do ponto de vista social ficou menos divertida do que antes
- A gestão de notebooks também foi uma fonte recorrente de conflito
- O GitLab exigiu ou considerou exigir a instalação de software de gerenciamento remoto em notebooks corporativos Mac ou em hardware pessoal usado para acessar recursos do GitLab
- As ferramentas propostas tinham um caráter invasivo, podendo ser usadas para registrar atividade do usuário, e parecia haver pouca garantia contra abuso
- Muito do feedback dos funcionários às vezes era ignorado até que pessoas-chave pressionassem
- No fim, o GitLab escolheu uma solução de gerenciamento de notebooks baseada em SentinelOne
- Com a mudança cultural e mudanças pessoais acontecendo ao mesmo tempo, a motivação e a produtividade diminuíram, e o estresse aumentou
- Depois que um gerente bem avaliado foi para outra função e um novo gerente assumiu o time, surgiram conflitos, e foi aplicado um performance enablement plan
- O PEP era uma etapa anterior ao PIP, um processo para tentar normalizar novamente a relação e o trabalho
- Inicialmente foi apresentado como um processo de melhoria para ambos os lados, mas na prática pareceu focado apenas nas mudanças exigidas dele
- A previsão inicial era de um mês, mas foi estendido por mais um, e após dois meses o resultado foi considerado satisfatório
- Depois disso, passou a sentir que ele e o GitLab estavam indo em direções diferentes, e começou a pensar em sair
- A abertura de capital do GitLab e o momento de exercer stock options tornaram possível sair em dezembro de 2021
- Na época, na Holanda, era preciso pagar 52% de imposto de renda sobre a diferença entre o preço de exercício e o valor de avaliação das stock options, independentemente de liquidez
- A carga tributária era tão alta que era difícil exercer antes do IPO do GitLab
- Depois a lei mudou, permitindo escolher entre pagar imposto no momento do exercício ou no momento de liquidez das ações
- Em dezembro de 2021, deixou o GitLab para se dedicar em tempo integral ao Inko
Lições tiradas da experiência no GitLab
-
Escalabilidade precisa virar cultura da empresa
- Na visão dele, o GitLab não priorizou escalabilidade o suficiente, e esse problema continuava até o momento da saída
- A principal receita do GitLab não vinha do GitLab.com, mas de clientes que faziam self-hosting do GitLab Enterprise Edition
- O GitLab.com custava muito mais do que gerava de receita, e isso fazia o foco ir para o mercado self-hosted
- Muitos dos problemas de performance do GitLab.com não se aplicavam diretamente a muitos clientes self-hosted
- Muitos desenvolvedores queriam melhorar a performance, mas não recebiam tempo nem recursos para isso
-
Times devem se mover com base em dados e com foco em desenvolvedores
- O GitLab tinha uma dinâmica fortemente liderada por product managers, e as funcionalidades a implementar eram decididas principalmente por product managers e diretores
- Algumas decisões faziam sentido, mas outras pareciam partir da ideia de construir algo apenas porque parecia uma boa ideia no Hacker News
- A visão é que resultados melhores poderiam ter surgido com uma hierarquia mais simples adotada mais cedo, mais autoridade para team leads e mais interação com usuários
- O papel de product manager, nessa visão, deveria contribuir tecnicamente para construir o produto e ao mesmo tempo servir de ponte entre o time e os usuários
-
Sem dados, é difícil julgar o que é “minimum viable”
- Um dos princípios centrais do GitLab era sempre começar com uma minimal viable change
- O problema é que cada pessoa tinha uma definição diferente de “minimal”
- Alguns times viam performance ou boa usabilidade como requisitos de viability, enquanto outros não davam importância a isso
- Como resultado, foram criadas funcionalidades que, na visão dele, não eram úteis para os usuários
- Uma platform serverless que ninguém pediu e que acabou encerrada
- Suporte a gerenciamento de cluster Kubernetes que ficou 3 semanas sem funcionar sem que ninguém percebesse
- Uma solução de chatops construída em cima de CI em vez de usar uma solução existente
- Uma funcionalidade de requirements management em que só era possível criar e consultar, sem editar nem excluir
- O GitLab fazia user surveys trimestrais, e alguns times tinham acesso a dados de engajamento de usuários, mas, pela memória dele e por conversas com ex-colegas, esses dados eram usados de forma intermitente, e não como parte central do fluxo de trabalho dos times
-
SaaS e self-hosting são difíceis de operar juntos
- O GitLab oferecia tanto instalações self-hosted quanto SaaS
- Os dois modelos têm estruturas de receita, requisitos e formas de aplicar atualizações diferentes
- SaaS exige implantações rápidas e capacidade de lidar com grandes volumes de dados e carga de trabalho em infraestrutura centralizada
- A maioria das instâncias self-hosted é muito menor que o SaaS, então os problemas e soluções do SaaS não se aplicam diretamente
- Como resultado, várias partes da plataforma acabavam exigindo consideração de dois caminhos de código, um para SaaS e outro para self-hosting
- Focar em apenas SaaS ou apenas self-hosting permitiria concentrar toda a atenção na experiência adequada a esse modelo operacional
-
Mais pessoas não garantem resultados melhores
- O GitLab contratou muitas pessoas ao longo dos anos e hoje emprega mais de 2.000
- Ele não sabe o número exato de desenvolvedores, mas ao olhar as páginas dos times estima que sejam pelo menos várias centenas
- Adicionar mais gente a um projeto não melhora necessariamente produtividade e resultados, o que também se relaciona com “The Mythical Man-Month”
- Mesmo sem dados, a visão dele é que a maioria das empresas precisa de no máximo 20 desenvolvedores; algumas precisam de 20 a 50, e só pouquíssimas precisariam de 50 a 100
- Se o número de desenvolvedores passa de 100, é preciso pensar se o escopo do produto não está grande demais
- Essa avaliação se refere a desenvolvedores de software; áreas como produção de hardware customizado, sales e support seriam exceções por terem custos de sincronização diferentes
-
A avaliação sobre Ruby on Rails é ambivalente
- O GitLab foi construído com Ruby e Ruby on Rails, e essa combinação contribuiu muito para o sucesso do GitLab
- Ao mesmo tempo, à medida que o projeto cresce e há muitos contribuidores com níveis variados de experiência, Rails facilita a criação de código com performance ruim
- Um problema representativo é o N+1 query problem
- O ActiveRecord do Rails tem recursos para resolver isso, mas eles funcionam em modo opt-in
- Se o desenvolvedor esquecer disso, consultas passam a acontecer linha por linha, causando problemas de performance
- Muitos dos problemas de performance resolvidos nos primeiros anos do GitLab eram N+1 query
- A própria linguagem Ruby também era excelente, mas a característica de usar muito meta programming se torna difícil em projetos grandes
- Go, Rust e Node.js podem ser mais eficientes que Ruby, mas na visão dele não têm um framework tão poderoso quanto Ruby on Rails
- Python e Django também podem ser opções, mas provavelmente enfrentariam parte dos mesmos problemas de Ruby e Rails
-
Tempo de implantação é importante para o sucesso organizacional
- Na visão dele, depois que o código é enviado para a branch ou tag de implantação, ele deveria poder ser implantado em no máximo uma hora
- O GitLab levou cerca de 4 anos para chegar perto disso, e ainda havia caminho pela frente
- Implantações rápidas ajudam na resposta a incidentes
- Se a implantação leva horas, pode ser necessário fazer hot-patch
- Implantações rápidas também afetam a motivação
- Existe satisfação em ver e usar na prática a mudança que você criou
- Trabalhar por semanas em uma mudança que só vai ser implantada duas semanas depois desmotiva
- A organização deve ser muito agressiva na redução do tempo de implantação e do tempo gasto pela test suite no processo de implantação
- O ponto principal não é que todos os testes e implantações precisem ficar abaixo de um tempo específico, mas que implantar o mais rápido possível dentro do que as necessidades do negócio permitirem seja tratado como prioridade
-
Salário baseado em localização é discriminatório
- O salário no GitLab era influenciado por várias variáveis, e uma delas era a localização
- Se uma empresa tem escritório físico e precisa contratar em uma região específica, um ajuste por localização pode fazer sentido, mas em uma empresa totalmente remota não haveria motivo justo para pagar salários diferentes a duas pessoas com a mesma experiência e responsabilidade apenas por morarem em lugares diferentes
- Ao sair, o salário recebido na Holanda era de cerca de €120.000 por ano antes de impostos, ou aproximadamente €8.500 por mês
- Se morasse na Bay Area, acredita que receberia pelo menos o dobro, talvez até mais
- A solução, nessa visão, é basear a remuneração nos requisitos da função, e não na localização do candidato
- A 0xide Computer Company é citada como exemplo de empresa que paga o mesmo valor, sem basear a remuneração em localização
- O tema é abordado em Compensation as a Reflection of Values
Conclusão
- O período no GitLab foi uma mistura de experiências muito positivas e muito negativas
- Há grande orgulho pelas conquistas em vários times e pelas pessoas com quem trabalhou
- É uma pena que o último ano aproximadamente tenha deixado um gosto amargo em toda a experiência
- Não se arrepende de ter trabalhado no GitLab e, se pudesse fazer de novo, faria algumas coisas de forma um pouco diferente com o benefício da retrospectiva
- Apesar dos defeitos, considera o GitLab muito melhor do que muitas outras empresas e ainda o recomenda como um bom lugar para trabalhar
1 comentários
Opiniões no Hacker News
A comparação de que seria um grande problema se uma empresa reduzisse salários com base na cor da pele ou no gênero, mas que reduzir com base no local de residência seria aceitável, precisa ser analisada com mais cuidado
Cor da pele·gênero e local de residência diferem quanto a poderem ser alterados e quanto a terem relação real com o trabalho
O local de residência tem relação com o trabalho, pois a empresa precisa lidar com a criação de uma entidade local, entender os sistemas jurídico e tributário, fusos horários, custos de viagem etc.
Dá para discutir se a remuneração regional é correta, mas compará-la a discriminação racial ou de gênero acaba fazendo o GitLab parecer uma organização racista ou sexista, e a discussão termina rapidamente
A pessoa diz que, se morasse na Bay Area, teria recebido mais que o dobro, e que isso é injusto apenas por morar em outro lugar, mas não parece haver pontos de vítima a ganhar aqui
Parece mais um argumento de alguém que não entende muito bem economia
O salário que recebo hoje nos EUA é mais ou menos o dobro do que eu recebia no Reino Unido, mas o padrão de vida é parecido; em alguns aspectos é pior, em outros é melhor
Se o autor do post original tivesse ido para a Bay Area, é bem possível que, mesmo com uma remuneração maior, seu padrão de vida tivesse caído
É preciso considerar não só a renda, mas também seguridade social, impostos e cultura; eu até consideraria aceitar um grande corte salarial para voltar à Europa e viver com mais conforto
A motivação do GitLab para a remuneração regional aparece em https://handbook.gitlab.com/handbook/total-rewards/compensat... e parece bastante razoável
Se pagassem salários da Bay Area até nas Filipinas ou na Ucrânia, as pessoas poderiam ficar presas a algemas de ouro, incapazes de sair mesmo quando precisassem, e acabar em burnout
Por outro lado, se pagassem a mediana global, não conseguiriam contratar pessoas na Califórnia ou em Londres
A afirmação de que gerentes de produto não são necessários e de que não deveria haver mais de 100 desenvolvedores em um único produto também é controversa
O autor do post original parece um engenheiro excelente e com muita autonomia, alguém que teria sido muito mais feliz e bem-sucedido em uma startup relativamente pequena
Se não precisasse esperar mudanças nas regras tributárias, talvez tivesse saído antes e escrito um bom relato de experiência
Também vale pensar em como teria sido difícil deixar a empresa se, além das ações, ele recebesse US$ 300 mil de remuneração em Amsterdã
Se uma remuneração igual no mundo inteiro fosse obrigatória, é provável que as empresas simplesmente preferissem contratar localmente por causa das vantagens de offsites, mesmo fuso horário e comunicação
Isso vale especialmente em um cenário econômico em que há muitos candidatos interessados também em regiões de alto custo de vida
Isso pode mudar no futuro, mas é útil olhar para a estrutura real de incentivos
Também há riscos que uma empresa assume ao contratar em outro país, e isso tem o efeito de deixar conhecimento e sementes de futuras empresas no local
Ir ao escritório dá ao funcionário poder de negociação salarial graças ao custo de vida daquela região, mas, em uma empresa e cultura totalmente remotas, a empresa pode contratar em qualquer lugar e pagar algo próximo do menor denominador comum
O trabalho remoto transforma todo mundo em algo parecido com contratados independentes competindo com talentos do mundo inteiro, enquanto o trabalho em escritório faz as pessoas competirem principalmente com outras da mesma região
Parece ser a história de alguém que era o 28º funcionário, respondia diretamente ao CEO, depois foi vendo gestores serem inseridos gradualmente acima dele, até que um deles o colocou em um PEP; ele percebeu o sinal e saiu
É um fluxo bastante padrão, e talvez seja um dos motivos pelos quais, em grandes empresas, as pessoas não conseguem fazer grandes coisas direito
Mesmo que você comece um projeto dentro da empresa e o leve ao sucesso, a empresa coloca pessoas acima de você e, no fim, você vira o enésimo funcionário no projeto que você mesmo iniciou e ainda pode ouvir que seu desempenho é insuficiente
Quer fazer só trabalhos divertidos e interessantes, acaba tendo opiniões fortes sobre coisas sem importância, e um colaborador individual próximo do CEO que não aceita as escolhas do gestor vira um pesadelo de gestão
Pode ficar se movendo de um lado para outro e criando problemas sem assumir responsabilidade pelas decisões
Segurança de endpoints e o uso de dispositivos pessoais são uma das pistas
Esse tipo de cultura permissiva não escala, por causa dos custos de conformidade regulatória e de produtividade de desenvolvimento
É difícil tirar um desenvolvedor antigo da distribuição Linux de sua preferência, mas o correto é usar um computador corporativo para o trabalho e deixar a empresa gerenciar as atualizações
A história dos backups do banco de dados é a mesma coisa: se você é a equipe de banco de dados, backups são a prioridade número 1
Não dá para empurrar “não havia backup” para a voz passiva; parece que havia mais interesse em debater arquitetura de sharding do que em manter o site funcionando no dia a dia
A conclusão de que o GitLab não investiu o suficiente no desempenho do produto hospedado também pode ser simples: se esse produto dava grande prejuízo, pode fazer sentido não colocar mais recursos nele
É preciso convencer com justificativa de negócio real — não com engenharia interessante — por que esse trabalho é mais importante e por que gera dinheiro
Um gestor iniciou comigo um projeto bem-sucedido, mas a direção, de forma gananciosa, trouxe política e dilemas sociais para o meio, inseriu camadas de gestão e tentou substituir a mim e a esse gestor
Aprendi por que não se deve se importar de verdade com o trabalho, e por causa disso sinto que o projeto vai ser arruinado e desmontado
Aqui parece haver a suposição de que esse funcionário era de fato de alto desempenho, que não precisava de gestor e que não merecia receber um PEP, mas essa não é uma suposição segura
Já vi funcionários iniciais em startups que não conseguiram, ou não quiseram, crescer no mesmo ritmo em que a empresa e o cargo cresceram
É comum mantê-los por respeito às contribuições passadas, pelo conhecimento histórico difícil de substituir e pelos relacionamentos com fundadores e funcionários iniciais que viraram líderes
Mas o fato de alguém ser um funcionário inicial e ter participado de projetos iniciais importantes não significa que continue sendo a melhor pessoa, ou a pessoa adequada, para tocar aquele trabalho
Mesmo que alguém seja excelente em manter algo rodando com gambiarras, jobs de cron e intervenções manuais, esse modo de operação pode não servir de jeito nenhum em uma empresa grande
Se a pessoa não consegue se adaptar, ou fica insatisfeita por precisar trabalhar no modo de uma empresa grande, ela passa a atrapalhar mais do que ajudar
Toda empresa em estágio inicial tem funcionários antigos que não crescem junto com ela, mas esse não é o único desfecho nem necessariamente o mais comum
O GitLab tem muita gente que trabalha lá há bastante tempo, mas não ouvimos essas pessoas em posts de blog cheios de queixas, então é preciso considerar o viés de seleção
Uso o GitLab há muito tempo, e o produto continua evoluindo, então não concordo com a afirmação de que seja um produto estagnado
Só três anos depois, quando viram que os releases continuavam falhando, aquilo virou um problema; mas pareceu menos influência minha e mais o resultado de alguém ter pesquisado no Google “como evitar falhas de release”
Não sei qual é a solução e, mesmo agora, estou passando pela mesma coisa de novo com outro tema
No início, você simplesmente fazia o que precisava ser feito; depois, cada etapa precisava passar por um novo cargo de gestão inserido no fluxo, sob a justificativa de verificar se você não estava fazendo a coisa errada
Isso acontece independentemente das ideias e contribuições iniciais que permitiram a empresa crescer
Fico me perguntando se isso também tem relação com o fato de ainda existirem issues antigas de anos atrás ligadas ao GitLab CI
Visto de fora, parece que o GitLab perdeu completamente a capacidade de criar coisas excelentes, e dá a impressão de que não tenta corrigir bugs de vários anos que continuam se repetindo
O trecho dizendo que os funcionários podiam usar o computador pessoal chega a ser quase surpreendente
Por menor que a organização seja, ela deveria fornecer equipamentos de propriedade da empresa e exigir que todo o trabalho da empresa seja feito nesses equipamentos
Para a empresa, há uma grande vantagem em termos de controle de propriedade intelectual; para o funcionário, isso também ajuda muito a separar o horário de trabalho do tempo pessoal, e o custo nem é tão alto
Assim, onde quer que você esteja, consegue usar o mesmo conjunto de ferramentas que prefere, e a capacidade de apagar e recriar rapidamente também é boa para depurar problemas do tipo “funciona/não funciona no meu computador”
Em uma ponta está o método de depender da memória; na outra, o de criar builds totalmente reproduzíveis em qualquer lugar com https://nixos.org/
Há muitas opções no meio, e já vi gente mantendo um conjunto de arquivos Ansible que instala o necessário com
host: localhostEu uso a versão mais recente do Ubuntu e mantenho alguns scripts de shell [1] que instalam 80% do que quero em uma instalação nova
Se quiser uma abordagem mais científica, dá para instalar algo como https://atuin.sh/ e gerar estatísticas dos programas que você realmente executa com frequência com base no histórico de shell de longo prazo
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
Não é uma solução perfeita, mas, se ao menos o equipamento for da empresa, um vazamento passa a ser resultado de ação maliciosa ou de incompetência ao mover dados sensíveis por um caminho não autorizado
Se a empresa for processada, o conteúdo de dispositivos pessoais pode acabar sujeito a todo tipo de intimação
Exigir um dispositivo separado não traz necessariamente uma vantagem de equilíbrio entre trabalho e vida para o usuário; é apenas inconveniente
O ato de separar o trabalho do tempo pessoal é determinado principalmente pelos próprios hábitos, capacidades e, no fim, decisões
Antigamente eu sentia que salários por região eram discriminação, mas hoje já superei isso em grande parte
No fim, a pessoa está exigindo salário de SF, e pessoas na Índia passam a exigir salários da Holanda ou de SF
Isso pode muito bem criar uma corrida para o fundo
O fato simples é que cada um ganhava o suficiente para viver bem em sua própria região
Se quiser mais, pode se mudar; se não se muda, provavelmente há uma razão para isso
Todo mundo quer salário de SF com custo de vida de Indiana ou da Índia, mas, por motivos óbvios, isso é difícil de se sustentar
Se você for contratado, recebe salário no nível dos EUA, esteja em San Francisco, na Polônia ou na Indonésia
Essas vagas são extremamente concorridas
É como abrir as portas para o mundo inteiro e dizer “mostre o que você tem”, então dá para avaliar um conjunto muito maior de candidatos e talentos, incluindo pessoas excepcionais de países pobres, muito inteligentes e com muita iniciativa
É assim que oferta e demanda funcionam
Quando se diz que vai pagar mais, em geral acaba-se contratando candidatos de nível mais alto
Conheço um bom número de pessoas que trabalham remotamente em vários estados dos EUA e recebem salários no nível de SF
É perfeitamente possível
SF também não deveria ficar arrogante demais
Detroit também já foi a Motor City e a Music City, além de um centro cultural e tecnológico mundial, mas suas competências centrais foram abaladas por mão de obra de outras regiões mais barata e eficiente
O que se exige é salário igual para trabalho igual
Se os membros da equipe fazem o mesmo trabalho, mas outras pessoas recebem o valor integral e só você recebe uma parte, há algo seriamente errado
A contribuição para a equipe não depende de onde você está no momento
O quanto de tempo você gasta no deslocamento também não muda a expectativa sobre seus resultados
Se a localização do escritório é cara demais, a empresa deveria resolver o problema procurando um lugar mais barato, não fazendo o funcionário subsidiar a má escolha de localização do escritório
Os 100k que o funcionário recebe e o custo para a empresa são coisas diferentes
Cada país tem impostos adicionais, previdência social e benefícios que a empresa precisa arcar, e em muitos casos é preciso ter uma entidade local ou uma forma virtual de operação, além de recursos de apoio para cumprir a legislação local
Eu também estou do lado dos funcionários que recebem salário conforme os padrões locais, trabalhando em uma função global em uma multinacional, mas há muito mais a considerar do que parece à primeira vista
Basicamente, ela ajusta com base no custo de vida, não no custo de contratação, mas mirando salários equivalentes
Gestores péssimos são um problema crônico do setor
Por outro lado, muitas startups surgem justamente porque seus fundadores tiveram gestores péssimos em empregos anteriores
Lembro da história dos traitorous eight e da Fairchild Semiconductors
Pessoalmente, acho que eu não teria tido motivação para começar minha startup se não tivesse encontrado, no emprego anterior, um gestor não técnico, político e retaliador
Olhando para trás, até penso que teria sido bom ter encontrado um gestor tão ruim mais cedo na carreira
Também seria bom poder encontrar empresas que realmente precisam das minhas habilidades e me mudar com mais facilidade, sem o peso do processo de RH
A afirmação é que todo o modelo de programação do Ruby se baseava na premissa de que, como na maior parte do tempo se está aguardando E/S ou rede, a velocidade da linguagem não importa
Mas hoje há, no Node.js e no lado da JVM, modelos que fazem outras coisas ou processam mais requisições enquanto aguardam E/S/rede
Em 2024, usar Ruby/Rails pode ser um desperdício, mas pode ser uma boa escolha para apps corporativos com número limitado de usuários, casos em que a velocidade de desenvolvimento é absolutamente crucial, ou protótipos rápidos para validação de mercado
Rails é um framework excelente e tem ótima produtividade, mas projetos Rails com 2 ou 3 anos de idade são sempre difíceis de manter
Um projeto Rails não é mais difícil que um projeto Django ou Express
Qualquer base de código precisa de disciplina e jardinagem constante para que o mato não cresça
Se Ruby e Rails têm pontos fracos, eles ainda são o desempenho bruto da linguagem e a maior exigência/uso de memória, o que os torna menos atraentes para tarefas que exigem baixa latência ou uma pegada de memória pequena
Pela minha experiência, ele costuma doer principalmente quando o tráfego oscila muito de repente, ou quando há muitos usuários ativos usando websockets; no caso dos websockets, o anycable resolve a maior parte
Mas pouquíssimos produtos chegam a esses limites e, mesmo quando chegam, eles são solucionáveis
Stripe, GitHub e Shopify são exemplos representativos de Rails escalando sem problemas de várias formas
A grande força que impulsionou o Rails foi a ideia de DHH sobre felicidade do desenvolvedor, que está intimamente ligada à velocidade de desenvolvimento
Há discussões sobre E/S na comunidade Rails porque isso é importante para operar servidores web, não porque seja o foco único ou principal na decisão pela linguagem ou pelo framework
Se o objetivo for maximizar o uso de CPU do servidor web, isso sempre foi possível no Rails rodando vários processos, uma abordagem usada há muito tempo de forma parecida com rodar várias threads na JVM
Pode ser menos conveniente, mas é um modelo usado desde os anos 90 e, como requisições web geralmente são executadas de forma independente, a comunicação entre processos muitas vezes não é um grande problema
Generalizar isso como “desperdício” é exagerado
Escrever um app em Rust também pode ser desperdício dependendo da situação; depende de onde está a pressão
Nas fases iniciais, não conseguir lançar é uma preocupação muito maior e, mesmo nas fases intermediárias e finais, a velocidade dos desenvolvedores é uma das coisas mais difíceis de escalar
Como CTO de uma empresa que usa backend em Rails e frontend em React, a velocidade de desenvolvimento é muito importante, e a velocidade de desenvolvimento em Rails continua sendo uma grande vantagem
Também há problemas de escala, mas 99% deles não são problemas do Rails, e sim de banco de dados
Acho que empresas quererem pagar engenheiros com base na localização é outra forma de discriminação
Deveriam pagar de acordo com a capacidade do funcionário, não de acordo com a localização
As regras governamentais dizem para não discriminar por gênero, religião, orientação sexual etc.; então discriminação salarial por localização é justa?
Vi amigos que se mudaram da Europa para a Ásia na mesma função receberem menos apenas porque a localização mudou, embora fossem a mesma pessoa no mesmo cargo
Se ele se muda para um mercado menos competitivo, onde fica mais difícil conseguir outro emprego, aumenta a chance de aceitar trabalhar por um salário menor
Mesmo que, por ser remoto, pareça que a pessoa não está presa ao mercado local, governos muitas vezes criam grandes barreiras para contratações internacionais, então alguns países podem se tornar mercados menos competitivos
Se alguém se mudou para outro país fazendo o mesmo trabalho na mesma empresa e teve o salário reduzido, é quase certo que aceitou esse corte por esse motivo
Acho que empresas devem pagar com base na capacidade do funcionário de desfrutar de conforto e saúde, não por alguma medida universal de valor
Acredito que esse valor universal seja impossível
O argumento de pagar apenas por capacidade, sem querer, desfaz comunidades e agrava a gentrificação e a destruição da coesão social por meio da desigualdade
Localização importa
O pagamento é feito para oferecer a mesma qualidade de vida, o mesmo tipo de moradia, a mesma oportunidade de sustentar a família e a chance de mandar os filhos para escolas semelhantes
Como o custo dessas coisas varia de país para país, a renda necessária também varia
A empresa precisa de uma capacidade específica e paga apenas o valor que o mercado atribui a essa capacidade, e nada além disso
Como o mercado atribui preços diferentes à mesma capacidade dependendo da localização, os salários também mudam
Religião é uma exceção meio ambígua, mas, seja justo ou não, isso não é discriminação
Se o GitLab.com sempre custou muito mais do que gerava e a empresa ganhava dinheiro principalmente com clientes do GitLab Enterprise Edition self-hosted, fico em dúvida se foi mesmo um erro não investir o suficiente em escalabilidade
Em primeiro lugar, uma empresa deve investir no que dá dinheiro, não no que faz perder dinheiro
Dá para fazer um julgamento mais abstrato de que um gitlab.com com melhor desempenho poderia trazer mais clientes e reputação, mas, se o negócio real é vender software self-hosted, faz sentido concentrar os recursos de desenvolvimento nisso
Quando de fato compramos licenças do GitLab e descobrimos que o custo por assento era o mesmo quer deixássemos a hospedagem com o GitLab, quer fizéssemos nós mesmos, pensamos: por que deveríamos arcar com o custo de infraestrutura?
Se for para fazer o GitLab.com de qualquer jeito, talvez no longo prazo seja melhor fazê-lo direito ou então eliminar o produto e focar apenas em clientes de self-hosting, como o GitLab Enterprise Edition
Mas ninguém na liderança vai querer tomar essa decisão
Então o produto acaba sendo operado de forma meia-boca
Para quem se importa com o produto em si, essa situação pode ser frustrante
A cada novo desenvolvedor que entra, ele diz “precisamos nos preocupar mais com escalabilidade”, e os seniores respondem “sim, sim, eu sei...”
Economicamente, se um desenvolvedor em Amsterdam entrega o mesmo valor que um desenvolvedor da Bay Area, é bem provável que faça sentido pagar o mesmo salário.
O valor de mercado local de um desenvolvedor em Amsterdam é menor, mas estamos construindo uma empresa global e competindo com outras empresas globais.
Mesmo que hoje seja possível contratar um desenvolvedor em Amsterdam com desconto, no fim algum concorrente vai oferecer um valor mais próximo do que ele entrega, ou ele vai sair para fazer o próprio trabalho.
Acho que as empresas mais fortes acabarão pagando talentos com remuneração independente de localização.
No fim, o que importa é o valor entregue.
Se você tem uma grande base de código em Ruby, como o GitLab, e quer vender para grandes empresas que valorizam desempenho e estabilidade, eu imagino que pagaria a essa pessoa mais de €120k por ano.
A maioria dos engenheiros que valorizam desempenho, segurança de tipos e estabilidade não tem interesse em Ruby, então o valor de mercado dessa combinação de habilidades é certamente mais alto.
Não sei se chega ao nível de US$ 500k por ano na Bay Area, mas empresas fortes que querem talentos de ponta vão perdê-los se não vincularem a remuneração ao valor entregue, e não à localização.
Considero que o tempo necessário para fazer deploy de código é um dos indicadores mais importantes — talvez o mais importante — para manter a velocidade dos desenvolvedores quando uma startup escala.
Troca de contexto é uma das atividades mais caras no dia a dia de um desenvolvedor, mas também uma das mais fáceis de ignorar.
Gestores gostam de organizar a agenda da equipe de acordo com a própria agenda, mas isso frequentemente atrapalha a “agenda de maker” dos contribuidores individuais.
Muitas organizações percebem isso e focam no custo da troca de contexto em termos de agenda, mas, para desenvolvedores, o tempo do build ao deploy é igualmente importante — ou até mais.