Não fazer nada no trabalho

• O desempenho de um engenheiro de software depende menos de mais tempo ou mais código e mais de trabalho de alto impacto no momento certo; no dia a dia, uma utilização de 80%, passando cerca de 20% do expediente longe do computador, pode ser eficaz
• Em grandes organizações de engenharia, oportunidades dependentes do tempo como apoiar um grande contrato, mitigar um incidente ou lançar um recurso importante podem gerar muito valor, e é fácil perder essas oportunidades quando você já está ocupado
• Se você continua resolvendo tickets de baixa prioridade, acaba não vendo a situação de outras equipes, atualizações do time ou incidentes em andamento, e o gerente também tem mais dificuldade de perceber que você tem folga
• O tempo de não fazer nada permite recuperação do estresse, calma durante resposta a incidentes, novas ideias e foco em trabalhos importantes
• Deixar margem de propósito no dia a dia e só mergulhar com intensidade de 100% em períodos de recompensa muito alta cria condições melhores para se tornar um engenheiro de alta performance

---

Oportunidades de alto impacto

• Muitos engenheiros deveriam trabalhar menos; isso não significa escrever menos código ou fazer menos mudanças, mas sim reduzir o tempo efetivamente trabalhado ao longo do dia e trabalhar num ritmo mais lento quando estiver trabalhando
• No estado padrão, o objetivo é 80% de utilização e, quando não há projetos de alta pressão, passar 20% do horário de trabalho longe do computador
• O desempenho de empresas de tecnologia é muito influenciado por eventos fora do comum, e muitas das mudanças de maior impacto podem ser feitas com uma quantidade surpreendentemente pequena de trabalho
• Em desenvolvimento de software, esforço por si só não vale pontos; o importante é resolver o problema certo no momento certo

• Três exemplos possíveis em grandes organizações

  • Dar suporte a uma funcionalidade ou correção de bug no momento em que a empresa tenta fechar um grande contrato enterprise pode ajudar a fechar o negócio
  • A funcionalidade nem precisa ser excelente; em alguns casos, basta demonstrar disposição e capacidade de fazer uma mudança específica
  • Prevenir ou mitigar um incidente logo no início pode reduzir a perda imediata de receita durante o incidente e também a perda de receita posterior por churn de clientes ou recusa de contratos
  • Só saber que é preciso desligar a feature flag correta já pode economizar muito dinheiro
  • Quando a empresa está tentando lançar uma funcionalidade importante, o sucesso ou fracasso pode depender de uma mudança pequena, mas difícil de encontrar
  • Exemplos incluem adicionar rapidamente um novo campo nas configurações do usuário ou corrigir uma função antiga de exportação de dados enterprise que ninguém mexe há anos
  • Familiaridade com o sistema pode ser a diferença entre uma mudança que leva algumas horas e outra que leva uma semana

• Dependência do tempo

  • Todas essas oportunidades são dependentes do tempo; você não pode entrar de manhã, fazer login e aleatoriamente destravar um grande contrato, mitigar um incidente ou criar rapidamente uma funcionalidade importante
  • Não basta estar no lugar certo e no momento certo; você também precisa não estar ocupado demais

Manter folga

• Se você continua resolvendo tarefas de baixa prioridade e se mantém em 100% de utilização, perde oportunidades de trabalho de alto impacto de duas maneiras
• Primeiro, se estiver ocupado demais, pode nem perceber que a oportunidade existe
  • Você passa a ter menos tempo para conversar com quem está trabalhando em outras coisas, ler atualizações da equipe ou observar incidentes em andamento
  • A melhor maneira de participar de trabalho de alto impacto é se oferecer com base na sua especialidade
• Segundo, se você parece sempre ocupado, fica mais difícil para o gerente colocar você nessas oportunidades
  • A segunda melhor forma de entrar nesse tipo de trabalho é quando um gerente ou product manager percebe que “há espaço para ajudar” e faz a ponte
  • Gerentes e product managers entram em reuniões das quais os engenheiros não participam, então muitas vezes têm uma visão melhor do que está acontecendo em trabalhos de alto impacto

Não fazer nada

• Se você precisa deixar tempo livre para trabalhos de alto impacto e não pode apenas continuar processando tickets, então, minuto a minuto, você pode de fato não fazer nada
• Engenharia de software pode ser uma profissão estressante, mas normalmente não é uma profissão continuamente estressante
  • O estresse aparece em situações como incidentes ocasionais, trabalho urgente de alta pressão ou demissões recentes
• Se você aborda até períodos relativamente tranquilos com intensidade de urgência, chegará aos momentos de alta pressão já cansado e irritadiço
• Mesmo em períodos de trabalho sob alta pressão, a postura de não fazer nada pode ajudar
  • Engenheiros sem muita experiência em on-call não deveriam se apressar; é melhor respirar algumas vezes antes de entrar na chamada ou antes de falar
  • Em resposta a incidentes, de modo geral, é preciso “pensar com clareza em câmera lenta”
• A maioria dos incidentes se resolve sozinha, e mudanças apressadas feitas durante o incidente “que talvez ajudem” muitas vezes pioram a situação em vez de melhorar
• Em geral, só de evitar pânico você já estará lidando melhor com incidentes do que a maioria dos engenheiros
• O tempo de não fazer nada vira um espaço onde as coisas podem acontecer
  • Quando o cérebro tem chance de descansar, aumenta a probabilidade de surgirem ideias novas
  • Quando um trabalho importante chega, você pode se concentrar por completo nele, sem tocar ao mesmo tempo três outras coisas em segundo plano
  • Quando você não está ocupado, sobra tempo para simplesmente olhar as coisas e absorver novos dados

Escolher deliberadamente não fazer certas coisas

• Muitos engenheiros se sentem desconfortáveis numa situação em que veem algo a ser feito, mas não fazem
• Essa tendência é uma característica psicológica compartilhada por muitos engenheiros de software e, até certo ponto, é justamente algo que os torna adequados para a função
• Para criar tempo de não fazer nada, às vezes é preciso se forçar deliberadamente a não se meter

• Evitar trabalho de cola

  • Em geral, engenheiros deveriam evitar trabalho de cola
  • Trabalho de cola inclui fazer as pessoas conversarem entre si, atualizar documentação de trabalhos que você não lidera e conseguir recursos para resolver dívida técnica
  • A maior parte do trabalho de cola reflete o fato de que a organização não priorizou explicitamente aquilo
  • Se a organização realmente prioriza aquilo, não é preciso que uma pessoa se voluntarie
  • Se a organização não prioriza e tudo bem que seja assim, assumir esse trabalho é perda de tempo e pode irritar o gerente
  • Mesmo que seja um grande erro a organização não priorizar aquilo, se uma pessoa resolver o problema sozinha, a empresa deixa de sofrer as consequências do próprio erro e a carreira e a saúde mental dessa pessoa passam a pagar a conta
  • É um mau negócio para a própria pessoa, um mau exemplo para colegas juniores e um precedente ruim em que, após o burnout, outra pessoa acaba entrando no mesmo lugar
  • Se o resultado for realmente sério, talvez seja melhor deixar a consequência acontecer para que a organização sinta a dor e mude a política

• Ajudar demais cria vulnerabilidade

  • Uma postura excessivamente prestativa torna você vulnerável a trabalho não recompensado
  • Em empresas de tecnologia, há muita gente tentando extrair dos engenheiros de software trabalho pelo qual eles não serão recompensados
  • Isso é diferente do trabalho que entra pelo caminho normal e é recompensado com promoção, bônus ou salário regular
  • O trabalho problemático vem por vias informais e parte de pessoas que não têm capacidade ou disposição de registrar oficialmente aquele trabalho em seu nome
  • Um exemplo é um product manager de outra organização pedir certos números porque você é bom em consultas de dados
  • Outro exemplo é um engenheiro de outro time pedir pair programming, mas na prática fazer você escrever todo o código enquanto a mudança é enviada no nome dele
  • Fazer esse tipo de coisa às vezes é ok, e você pode ajudar as pessoas quando der
  • Mas você precisa conseguir aplicar pressão contrária, recusando ou respondendo só horas ou dias depois

• Não investir demais em coisas com grande chance de desaparecer

  • É melhor não investir demais em coisas que têm grande chance de desaparecer
  • Quando um product designer está refinando o que quer em tempo real, você não deveria reescrever a página inteira a cada hora
  • Um exemplo é querer o cabeçalho da página de um jeito às 9h, mudar às 10h e mudar de novo às 11h
  • Nesses casos, é melhor não fazer nada — por exemplo, sair para caminhar — e depois reescrever uma vez à tarde com base no design mais recente
  • Outra situação comum é a grande ideia de um gerente sem força política suficiente
  • Muitas vezes dá para deixar o tempo passar até o projeto ser cancelado
  • Mas, se você avaliar mal o nível de apoio político do projeto, pode parecer preguiçoso e acabar tendo de entregar tudo às pressas

Conclusão

• Conselhos e ferramentas de engenharia de software muitas vezes são voltados para ampliar a capacidade técnica de fazer mais coisas ao mesmo tempo, assumir projetos maiores e escrever mais código
• O sucesso em engenharia de software não é determinado por esses fatores
• O sucesso é determinado pela capacidade de fazer a coisa certa na hora certa, e para isso é preciso deixar deliberadamente uma parte do esforço reservada no trabalho cotidiano
• É possível ser um engenheiro de alta performance com 80% de esforço; na verdade, isso reduz erros bobos causados por estresse e facilita entrar em trabalhos de alto impacto que geram grande retorno
• Também existem momentos em que é preciso mergulhar com 100% de esforço; duas ou três vezes por ano, pode fazer sentido trabalhar por longas horas, com foco intenso e pensando no problema o dia inteiro
• Vale a pena guardar esse modo de trabalho para quando a recompensa for realmente grande e, no resto do tempo, trabalhar com relativa folga

[GN⁺]

Comentários do Hacker News

• É um bom texto, mas no fim das contas o problema volta a ser incentivos
  Faz sentido dizer que evitar ou mitigar problemas cedo pode economizar muito dinheiro, mas o que vi repetidamente em várias empresas é que prevenção de problemas não recebe reconhecimento, enquanto empilhar um monte de material inflamável e depois apagar o incêndio inevitável rende reconhecimento em dobro. Isso acontecia até em organizações “boas”
  Nunca consegui me envolver de verdade nesse tipo de política em estilo teoria dos jogos de lançar código lixo de propósito e depois colher o mérito. Eu tinha orgulho demais do meu trabalho
  Mantive e expandi por mais de 5 anos um framework para eliminar uma classe de problemas que atormentava a versão anterior do produto, mas a equipe parceira que colocou código lixo em produção, causou incidentes e depois consertou foi elogiada publicamente, enquanto a nossa equipe não recebeu nenhum mérito porque não houve incidentes desse tipo. Era prevenção impossível de medir

  • Em teoria dos jogos, uma equipe que repetidamente causa problemas e perde clientes deveria ser punida de acordo. Se não for, talvez os problemas gerados por releases rápidos não afetem a retenção de clientes tanto quanto se imagina
  • É só espalhar Thread.sleep(100000) por todo lado e esperar até quebrar. Aí você vira a pessoa que fez um longo e heroico combate a incêndio até meia-noite de sexta depois do release
    Não pergunte por que isso é recompensado e, claro, às vezes a organização muda os critérios de recompensa para outra coisa
  • Sobre “não dá para receber crédito por não ter havido incidentes porque isso não é mensurável”, filosoficamente eu diria que até o peso do nada pode ser medido
  • Infelizmente isso está totalmente correto, mas não é o único caminho
    Uma abordagem honesta é criar algumas ferramentas complexas, mas essenciais, que façam outros engenheiros continuarem vindo até você. Você passa a identificar muito bem o uso incorreto de uma ferramenta específica e, quando aponta bugs no código dos outros em segundos, parece muito mais inteligente do que realmente é
    Idealmente, a ferramenta deve ser confiável, útil e complexa. Quando outros desenvolvedores a usam e encontram bugs, continuam vindo até você, e você pode apontar os erros deles. Para essa estratégia funcionar, os erros quase sempre precisam estar do lado deles, e seu código precisa ser robusto
    Se um bug real aparecer no seu código, de preferência um caso pequeno de borda, você deve ser muito humilde e pedir desculpas, além de elogiar na reunião da equipe o desenvolvedor que encontrou aquele bug complexo
    É melhor do que ganhar crédito corrigindo o próprio código com bug. Isso pode funcionar com gerentes ou juniores, mas outros engenheiros seniores acabam não gostando disso
    A estratégia de criar ferramentas complexas, mas estáveis, faz você ser reconhecido repetidamente, muitas vezes bem mais do que duas vezes, e o reconhecimento de outros desenvolvedores acaba chegando aos ouvidos da gerência. Líderes inteligentes sabem que esse sinal é melhor do que demos chamativas
    Líderes que distribuem elogios só porque um certo desenvolvedor faz protótipos rápido acabam aprendendo com os próprios erros. Fundadores jovens parecem frequentemente passar por essa fase de elogiar o que é superficial
  • Concordo se a oposição for colocada nesses termos, mas é preciso um pouco de nuance
    Parte de construir um produto ou um conjunto de funcionalidades está mais próxima de exploração do que de excelente engenharia. Às vezes, é melhor criar duas funcionalidades boas o suficiente para descobrir o que tem valor para o usuário do que construir uma única funcionalidade sólida
    Eu sempre fui do tipo “vamos fazer e descobrir”. Dito isso, sou grato que alguém com uma atitude diferente da minha tenha criado o git
    Existe um equilíbrio aqui, e isso depende de quanto o problema que você está tratando é um problema de exploração. Aqui, “solidez” significa disponibilidade, manutenibilidade e possibilidade de vazar fotos sensíveis de usuários, do ponto de vista puramente de engenharia

• A parte sobre “pessoas que querem extrair trabalho sem recompensa” merece ser emoldurada
  Especialmente situações como um gerente de produto de outra organização dizendo “já que você manda bem em consultas de dados, pode levantar umas estatísticas sobre X para mim?” ou um engenheiro de outra equipe pedindo para fazer “pair”, mas no fim eu escrevo todo o código e ele submete a mudança discretamente no nome dele

  • Onde eu trabalho, Principal Engineer é um título que todo mundo quer, é bem remunerado, mas raramente alcançado. Todas as pessoas com quem trabalhei que tinham esse título eram muito competentes e também muito boas como gente, e uma vez perguntei a uma delas como tinha conseguido esse título na empresa anterior
    A estratégia dele era ajudar as pessoas e dar o crédito de forma ativa. Em 1:1s ou reuniões com vários níveis de gerência, ele destacava consistentemente o valor do trabalho dos colegas de equipe, e com isso conquistou a boa vontade do time
    Anos depois, quando um projeto com muito dinheiro em jogo saiu do cronograma e vários engenheiros-chave pediram demissão, ele trabalhou até tarde para conduzir o projeto ao sucesso e, na avaliação seguinte, recebeu o título e um aumento salarial
    Aquele projeto acabou sendo o empurrão final, mas ele não foi o único engenheiro fazendo hora extra. Ele atribui a promoção à boa vontade acumulada ao longo do tempo ao dar crédito aos outros
  • Acho que isso depende de quão envolvido o seu chefe é. Um dos tipos de pessoa com quem eu não gosto de trabalhar é a que diz “isso não é meu trabalho”
    Quero trabalhar com pessoas que veem um problema e propõem uma solução, esteja isso ou não na descrição do cargo
    Se meu trabalho não é reconhecido, isso é um problema de liderança. Recusar as coisas de forma seca me parece um caminho para uma cultura organizacional rígida e lenta
  • A frase que merece ser emoldurada é “abre um ticket”
  • Está certo, mas eu não vejo isso de forma tão preto no branco. Além de cuidar diretamente da minha própria compensação, também há incentivo em ajudar a empresa em si a ter sucesso, então pode ser racional ajudar com pequenos pedidos, mesmo sem receber desfile por isso
    Da mesma forma, algum dia eu também posso precisar de algo de um colega, e nesse momento eu agradeceria se a pessoa ajudasse ativamente, em vez de me expulsar com um “venha pelos canais formais”. Os canais formais também podem levar muito mais tempo
  • Empresas boas têm cultura, e as pessoas se ajudam
    Conversas no almoço ajudam as pessoas a entender alguma coisa
    Dito isso, fazer um trabalho de várias horas para alguém pode ser uma questão diferente

• Não é sarcasmo, é mais uma observação: em organizações grandes o bastante ou burocráticas o bastante, é difícil ganhar mérito ou visibilidade por prevenir problemas com antecedência. Esse tipo de resultado entra na categoria de “era o que já deveria estar sendo feito”.
  Por isso, quem é bom em política corporativa às vezes prefere deixar o problema acontecer e então se mover de forma barulhenta nos itens de acompanhamento. O truque é não deixar o incidente virar um desastre, e isso exige bastante delicadeza.

  • Aprendi cedo isso trabalhando em uma organização conservadora. Prevenção é arriscada. É melhor ter pronta uma solução para quando algo der errado, porque só nessa hora vem a aprovação.
  • Todos os exemplos de grande impacto parecem ser de trabalhos difíceis de reconhecer.
    Se eu salvo um contrato de vendas, quem recebe aplausos é o time comercial, e são eles que recebem a comissão. Eu não recebo nem parte disso.
  • Desastres também podem ser um bom sinal para os níveis de cima de que há problemas na organização. Se você apagar heroicamente todos os incêndios, talvez seu chefe saiba, mas o chefe do seu chefe do seu chefe vai achar que a organização está funcionando perfeitamente e que está tudo verde.
    Se você deixar algumas coisas queimarem, o chefe do chefe do chefe vai ver esse fogo, e talvez algo melhore. Talvez seja até a forma mais fácil de se comunicar com eles.
  • O ponto central é se as pessoas percebem. Já ouvi dizer que governos locais às vezes cortam programas populares de propósito para provocar reação e depois levar o crédito por restaurá-los. No meio disso, ainda dá para encaixar outras medidas necessárias, mas impopulares.
  • Muita carreira e muito bônus são construídos em cima de bancar o herói.

• Há tempos eu tinha meio escrito um texto nessa linha, usando uma metáfora de RPG de fantasia. Quando você joga com um personagem que usa mana nesses jogos, aprende rápido que, se gastar toda a mana em cada batalha pequena, vai ficar andando vazio e não terá nada quando realmente precisar.
  A energia mental usada no trabalho não é tão diferente assim. Se você deixar um pouco no tanque, consegue usar isso de forma estratégica quando algo inesperado acontecer, sem colocar sua saúde — ou seja, o burnout — em risco.
  E, nesses jogos, se você forma grupo com alguém que não sabe administrar mana, também aprende que essa pessoa não é exatamente um bom membro de equipe.

  • Senti na prática que, se por um tempo você não for suficientemente desafiado, pode ficar extremamente difícil superar o próximo desafio.
    Em qualquer área, os momentos em que estive no auge foram aqueles em que havia trabalho suficiente à frente para eu processar tudo com constância, quase como uma máquina, e em que eu recebia confiança para trabalhar rumo ao objetivo sem ser interrompido o tempo todo para explicar o que estava fazendo. As habilidades cresciam como fogo em mato seco, e o trabalho terminava mais rápido do que o esperado.
    Infelizmente, são raros os lugares que aproveitam esse tipo de estrutura. Há bloqueios e interrupções demais que impedem entrar em trabalho profundo de verdade.
  • No meu caso, eu terminaria o RPG com 29 ethers sobrando, mesmo que tivesse sido muito menos trabalhoso se eu os tivesse usado no começo.

• Se você quiser derrubar um sistema, basta operá-lo a 100%. Sem folga e sem capacidade para absorver nova demanda, qualquer pequena perturbação coloca o sistema em modo permanente de falha.

  • Eficiência é inimiga da resiliência.
  • Só que o colapso não acontece. Quando os engenheiros entram em burnout ou envelhecem, simplesmente contratam gente nova e o ciclo se repete.
    O problema de textos como este, ou de livros como Peopleware / Slack, é que eles não apresentam métricas reais suficientemente convincentes para levar o pessoal de finanças a tentar outra abordagem.

• A metáfora que mudou minha forma de ver isso foi uma do livro “The Power of Full Engagement”. Era algo como: “Você está agindo como um atleta de resistência de elite mundial sem offseason. Pare com isso.”

• Há muita sabedoria aqui. Além de reservar parte da capacidade para quando surgir algo de valor realmente alto, também acho que engenharia de software não é um tipo de trabalho em que você consegue ser bom ficando ocupado o tempo todo.
  Raramente sai um bom design quando você tenta escrever código o mais rápido possível. O texto também não aborda outro ponto importante: como trabalhar com 80% de capacidade sem levar bronca do gerente.
  Isso exige um pouco de cuidado com comunicação e estimativa de trabalho. Um dos melhores conselhos que ouvi de desenvolvedores mais velhos e experientes no meu primeiro emprego de programação continua comigo até hoje: estime quanto tempo algo vai levar e, antes de dizer ao gerente ou ao usuário, dobre esse número.
  Com experiência, talvez isso caia de 2x para algo como 1,5x, mas o princípio continua valendo.

  • O Kent Beck disse, no Good News Factory ou talvez numa palestra, que o time dele nunca prometia mais do que metade do que achava que conseguiria fazer. É uma boa forma de sustentabilidade.
    O que deveria ser otimizado e usado como referência é a capacidade de entregar de forma consistente no longo prazo, em ritmo sustentável. É um jogo longo, e prometer demais só corrói a confiança. E essa confiança é justamente o principal meio de um desenvolvedor conseguir o espaço de que precisa.
    É preciso prometer menos, construir a confiança de entregar o que foi dito e ganhar espaço para não entrar em burnout.
    Quanto mais sênior você fica — especialmente quando vira líder — mais definir limites, preservar a atenção e evitar burnout passam a fazer parte do trabalho. Porque há muitas formas de se destruir no processo.
  • O conselho de “dobrar a estimativa de tempo antes de falar com gerente ou usuário” faz sentido, mas será que ele levou em conta a lei de Hofstadter?
    Mesmo levando a lei de Hofstadter em conta, as coisas sempre levam mais tempo do que o previsto.
    https://en.wikipedia.org/wiki/Hofstadter%27s_law

• Como alguém que já fez bastante trabalho voltado ao cliente, a pior armadilha em que caí várias vezes foi me dar bem demais com clientes pagantes. Quando você é contratado como especialista para ajudar, e o cliente é genuinamente uma pessoa muito legal, fica absurdamente difícil dizer não.
  Fica pior ainda quando essa pessoa não é a tomadora de decisão, mas alguém que está sendo pressionado a me empurrar alguma coisa. Como especialista de confiança, é fácil dizer não quando o próprio cliente apresenta uma ideia ruim; mas, quando a ordem vem do chefe dele — alguém com quem eu nunca falo diretamente — eu acabo colocado na posição de parecer um custo inútil ou virar um puxa-saco que deixa um monstro para trás.
  Às vezes invejo quem trabalhou principalmente em funções internas. Pelo menos essas pessoas tinham alguma chance de tentar convencer alguém em algum nível acima.

• A parte sobre trabalho de cola é interessante: quando eu trabalhava em uma grande empresa, isso era uma parte explícita da avaliação anual de desempenho. O Google chamava isso de “citizenship”, e acho que é uma expressão que capta bem a essência. Ou seja: “o que você tornou melhor para o resto das pessoas da empresa”
  Por um lado, era meio estranho. Não estava na descrição do meu cargo, então tecnicamente era trabalho não remunerado, mas ao mesmo tempo fazia parte das expectativas oficiais. Por outro lado, era bom trabalhar em um lugar onde todo mundo gastava um pouco de tempo e esforço para melhorar o ambiente para todos
  Se isso vira uma exigência explícita para todo mundo, também é uma tentativa de contornar a cultura tóxica do tipo “sou um engenheiro rockstar, estou ocupado fazendo coisas importantes, então outra pessoa que faça o trabalho de cola”. E, além disso, essa “outra pessoa” geralmente era uma mulher e, quase com certeza, ganhava menos do que o tal engenheiro rockstar
  O texto original dá a entender que a empresa deveria contratar formalmente alguém para fazer o trabalho de cola, mas na prática ele é formado por pedaços tão variados que é quase impossível contratar uma pessoa para assumir tudo. Por exemplo, qual seria o cargo que abrangeria “escrever documentação, entrevistar candidatos para engenharia de software e organizar eventos offsite da equipe”
  Mas todas essas tarefas eram necessárias, e a exigência de citizenship ajudava a distribuir esse peso de forma mais justa
  Acho que a formulação melhor não é “não faça trabalho de cola”, mas sim “não seja o único otário fazendo trabalho de cola sem compensação”. Ou seja, todo mundo deve assumir uma parte, e é preciso incentivar uma cultura em que isso seja oficialmente reconhecido como trabalho

• Operar com 80% de utilização é um bom hábito, e ajuda quando não há um gerente fiscalizador exigindo 100% o dia inteiro, todos os dias. Esse tipo de pessoa confunde o jeito silencioso e tranquilo com que engenheiros de software pensam com preguiça ou inatividade
  Por isso, o trabalho remoto é a melhor forma de preservar alguma folga de utilização e proteger a saúde mental
  Um pouco de trabalho de cola pode tornar a vida profissional de todo mundo muito melhor e, se ninguém mais souber como fazer isso, pode fazer de mim uma peça indispensável ou um herói dentro da equipe

  • Também acho 80% alto. E isso varia de desenvolvedor para desenvolvedor
    Considerando o quanto eu peno para aprender, pensar e começar, meus 80% não são nem de longe iguais aos 80% de um colega tecnicamente mais forte
    Se levarmos em conta até mesmo um pouco de neurodiversidade, os 80 de uma pessoa podem ser os 120 de outra