O código é executado mais vezes do que lido

• O princípio de que “o código é lido mais vezes do que escrito” parte da ideia de priorizar quem faz manutenção em vez de quem escreveu, e se expande para um modelo de decisão que também considera usuários, operações e negócio
• O valor do código não está em sua sofisticação em si, mas em atender ao objetivo do usuário; por isso, é importante mostrar o produto cedo e com frequência aos usuários e incorporar o feedback
• “Executar” código em produção inclui implantação, upgrade, observação, auditoria, monitoramento, correção e descarte; o custo operacional de longo prazo pode ser muito maior do que os incômodos durante o desenvolvimento
• O KISS vai além de simplificar código e se amplia como um princípio operacional de reduzir partes móveis e entender os modos de falha, para que o sistema continue funcionando mesmo quando algo falha
• Orçamento, marketing, prazos, stakeholders, investidores e interesses políticos entram nas decisões, então é preciso reconhecer que agradar o usuário e gerar receita nem sempre são a mesma coisa

---

Expansão do modelo de prioridades

• A frase “o código é lido mais vezes do que escrito” significa que quem escreve o código pela primeira vez não deve ignorar o custo imposto a quem vai lê-lo e modificá-lo no futuro
• Esse princípio fundamenta investimentos em manutenibilidade, como simplicidade, testes e documentação
• Em forma condensada, isso pode ser visto como o modelo maintainer > author

O usuário vem antes do desenvolvedor

• Código é um meio para um fim, e software deve prestar serviço a algum usuário
• Por melhor que seja o código ou por mais sofisticada que seja a tecnologia, se não cumprir seu propósito e não oferecer uma boa experiência ao usuário, seu valor diminui
• A prioridade se expande para user > maintainer > author e, se não distinguirmos os papéis dentro do desenvolvimento, vira user > dev
• Em vez de apenas adivinhar ou perguntar o que os usuários querem, é melhor colocar o programa cedo e com frequência diante deles e incorporar o que for aprendido com o feedback

Executar inclui a operação em produção

• “Executar” não é apenas ligar o programa, mas inclui todo o processo de operá-lo em produção
  • implantação
  • upgrade
  • observação
  • auditoria
  • monitoramento
  • correção
  • descarte
• Em Choose Boring Technology, Dan McKinley argumenta que o custo de longo prazo para manter um sistema funcionando de forma estável quase sempre é muito maior do que o desconforto de construí-lo
• Com essa perspectiva, o modelo passa a ser user > ops > dev
• Muito software nunca chega a uma escala significativa em produção e é construído sobre suposições não validadas
• Quando o código é operado em produção, o KISS deixa de ser apenas uma questão de código e passa a ser uma questão de reduzir partes móveis e entender modos de falha
• O importante é implantar algo e garantir que continue funcionando mesmo quando falhar

O negócio é um eixo separado

• Desenvolver pensando no usuário pode levar longe, mas a suposição de que “software valioso para o usuário também é valioso para a organização” é uma abstração simplificada
• Do ponto de vista do desenvolvedor, é fácil separar entre criar um bom software e o negócio transformá-lo em dinheiro, mas em algum momento é preciso incluir a perspectiva de negócio no processo de trabalho
• Essa distinção costuma funcionar em software de consumo e software corporativo
• O modelo se expande para biz > user > ops > dev
• O orçamento é o exemplo mais claro: como os recursos para atender às demandas dos usuários não são infinitos, é preciso medir custo e benefício
• Marketing, prazos, stakeholders, investidores, interesses pessoais e política também afetam a tomada de decisão
• Uma decisão que parece correta ao considerar apenas software, equipe e usuários pode deixar de ser correta quando se considera a organização como um todo
• Às vezes, é preciso fazer o que gera receita em vez do que agrada o usuário

Cheiros de organizações de desenvolvimento vistos pelo modelo

• Código impossível de manter: author > maintainer

  • Código esperto, mas preguiçoso, vira espaguete e uma “floresta assombrada”
  • Inclui problemas como otimização prematura e módulos que só uma pessoa específica consegue mexer

• Software impossível de usar: dev > user

  • Surge em equipes que não aprendem com os usuários ou priorizam tecnologia
  • Exemplos: programas superprojetados, “modernizações” que pioram a experiência do usuário e web apps que quebram recursos do navegador

• “Na minha máquina funciona”: dev > ops

  • É software que não foi projetado com a operação em mente
  • Inclui complexidade excessiva, como usar um banco de dados extravagante para pouca carga de dados ou operar um ecossistema de microsserviços com uma equipe minúscula
  • Também entra aqui o software em que quem é acordado de madrugada por causa de incidentes não é a mesma pessoa que o projetou

• “A coisa certa”: dev > biz

  • É quando o código é tratado como se fosse um fim em si mesmo
  • Exemplos: artesãos vaidosos, os músicos do Titanic e Lisp Hackers

• Desenvolvimento guiado por currículo: dev > *

  • É o software criado quando não há nada em jogo e o desenvolvedor pode fazer o que quiser

• Software imaginário: biz > user > ops > dev

  • É software que foi criado, mas quase nunca ou nunca chega à produção
  • Charity Majors chama isso de living a lie
  • Software sem usuários também entra como software imaginário: não resolve problema nenhum, resolve o problema errado ou resolve um problema que ninguém jamais teve
  • Também inclui o caso de sair martelando tudo com tecnologia exagerada até que algo passe a parecer um caso de uso vago

• “Capitalismo tardio”

  • É quando software financiado por venture capital não tem modelo de negócio ou só passa a tê-lo depois de crescer até virar monopólio e então explorar os usuários

A tensão entre usuário e negócio

• biz > user tem efeitos difíceis de aceitar
• A forma como se aprendia software era resolver problemas de usuários finais, e uma das últimas dicas de The Pragmatic Programmer se resume ao objetivo de não apenas entregar código, mas encantar o usuário
• À medida que o software se torna ubíquo, fica cada vez mais difícil sustentar essa suposição
• Muito software não se importa com o usuário, manipula o usuário ou transforma o usuário em produto
• Esse problema não se limita às redes sociais
  • Pop-ups tentando capturar a atenção do usuário aparecem ao reservar hospedagem, pedir comida ou até clicar no botão Iniciar do Windows
  • Diz-se que a busca do Google entrega resultados que parecem um monte de lixo
• A discrepância entre acreditar que se está fazendo algo bom e o que grande parte da indústria considera lucrativo explica o desconforto de muitos profissionais de software
• Não dá para voltar a um passado que ignorava a realidade econômica, mas é necessária uma postura ética mais forte para não causar dano aos usuários
• O usuário nem sempre pode vir antes do negócio, mas o negócio também não deve vir sempre em primeiro lugar
  • user > ops > dev
  • biz > ops > dev
  • biz ≹ user

[GN⁺]

Comentários do Hacker News

• Alguns usuários usam um sistema não porque gostam dele, mas porque a empresa comprou
  Nesse tipo de situação, por definição, o negócio vem antes do usuário, e os desenvolvedores acabam atendendo às demandas dos gerentes intermediários da empresa cliente, e não dos usuários reais. Se não fizerem isso, não fecham o contrato. No fim, os usuários ficam presos a funcionalidades entregues de qualquer jeito enquanto a equipe de desenvolvimento está ocupada criando novos recursos que os gerentes intermediários vão gostar
  É um pouco cínico, mas, como engenheiro, é útil saber se você está fundamentalmente nesse tipo de empresa. Por exemplo, varejistas online são muito sensíveis aos usuários e chegam a manter versões diferentes do site por país porque alemães gostam de X e americanos gostam de Y. Pequenas mudanças podem fazer grande diferença na receita
  Já algumas empresas quase não são sensíveis à usabilidade, porque quem compra o produto não é quem de fato o usa

  • Já trabalhei em uma empresa que vendia SaaS para grandes corporações
    Para fechar contratos, precisávamos cumprir a checklist do cliente, mas também nos preocupávamos com a experiência do usuário. Uma boa experiência de usuário quase nunca era uma exigência rígida do cliente
    Como o software dos concorrentes era muito doloroso de usar, queríamos nos diferenciar nesse ponto; graças a isso, o treinamento ficou mais fácil, os usuários ficaram mais satisfeitos e, quando possível, até recomendavam aos próprios gestores que comprassem mais do nosso produto
    No fim, 80% disso vinha do orgulho e da empatia de dizer “nosso software não é horrível”, mas, no longo prazo, também era do nosso interesse porque construía marca
  • Trabalhei em uma empresa de um mercado com uma estrutura de compra parecida, e nós focávamos apenas nos usuários
    Adotamos uma estratégia de crescimento liderado pelo produto, não tínhamos vendedores, e a equipe de produto se concentrava inteiramente na experiência do usuário. O problema era que não vendíamos para os usuários. As pessoas que compravam o software eram outras dentro da organização dos usuários e nem tinham experiência direta usando o produto
    Era uma abordagem fadada ao fracasso. Precisávamos de vendedores que entendessem a cabeça dos compradores, explicassem os benefícios a eles e treinassem os usuários para explicar os benefícios a outras pessoas dentro da organização. Era preciso preencher a lacuna entre usuário e comprador
  • Normalmente, o gerente intermediário também é usuário, mas é minoria dentro da base de usuários e usa funcionalidades diferentes, como relatórios
    Então vira uma questão de quais usuários priorizar, e é preciso encontrar um equilíbrio entre priorizar a experiência da minoria que tem influência sobre os demais usuários e manter o produto utilizável o bastante para que os demais usuários forneçam dados significativos à gerência
  • Passei por isso em uma empresa que vendia software para prefeituras
    O que importava eram apenas as opiniões do prefeito, do administrador municipal e da câmara municipal. Se os relatórios parecessem bons e o preço estivesse certo, renovavam
    Lembro de reuniões presenciais em que as pessoas que usavam aquilo todos os dias diziam na nossa cara o quanto era horrível. Mesmo assim, sem exceção, com a promessa de corrigir alguns bugs específicos e um aumento mínimo de preço, aquele cliente renovava
  • O fato de os desenvolvedores acabarem atendendo às demandas dos gerentes intermediários do cliente, e não dos usuários reais, é o motivo pelo qual todo software empresarial é ruim

• Hoje conheci o símbolo ≹. Dizem que ele “representa uma relação em que, entre dois objetos comparados, nenhum é maior nem menor que o outro, mas também não se pode necessariamente dizer que sejam iguais. É uma distinção sutil importante em domínios onde há formas de comparação que não são estritamente numéricas” (https://www.mathematics-monster.com/symbols/Neither-Greater-...)

  • O exemplo com números complexos z_1, z_2, dizendo que z_1 ≹ z_2, é estranho
    Parece bem mais claro escrever |z_1| = |z_2|, ou seja, que os dois números complexos têm o mesmo valor absoluto
    O texto diz que “em conclusão, o símbolo ≹ desempenha um papel importante ao oferecer um meio-termo entre os operadores relacionais tradicionais”, mas, como doutorando em matemática, nunca vi isso. Acho difícil acreditar que desempenhe um papel importante
  • Esse glifo deveria ser o resultado de combinar o emoji de maçã com o emoji de laranja
  • Isso me lembra o conceito de jogo na teoria dos jogos combinatórios
    Jogos são um superconjunto dos números surreais, e os números surreais são um superconjunto dos números reais; é como afrouxar a definição dos surreais de modo a perder a propriedade de ordem total
    Com isso surgem números estranhos que podem ser “confundidos” com outros números, ou “difusos”. O exemplo mais simples é * (star), que não é maior nem menor que 0 e, portanto, se confunde com 0. É como uma nuvem difusa em torno de 0, e se escreve 0║*
    Switches, que são jogos mais complexos, podem se confundir com intervalos maiores de números e são considerados “quentes”. Ao construir números com switches, dá para criar jogos quentes ainda mais interessantes
  • Acho esse conceito importante para entender a ordem causal em sistemas distribuídos. Por exemplo, no contexto de CRDTs
    Eventos gerados em um único dispositivo sempre têm uma ordem completa. Mas, se eventos são gerados em dois dispositivos offline, não dá para dizer qual veio primeiro, e surge uma relação ≹ entre os dois eventos. Em outras palavras, os eventos são vistos como simultâneos
    Assim, podem surgir ordens como “d > b > a” e “d > c > a”, mas “c ≹ b”
    Definir uma forma determinística de resolver empates nesses casos é uma grande parte do problema que CRDTs resolvem
  • No link, o “Exemplo 1: contexto numérico” diz que, para dois números reais a e b, se a não é maior nem menor que b, mas também não é explicitamente igual a b, então a relação é ≹
    Como isso é possível?

• Para muitos de nós, o custo de executar o código 1 bilhão de vezes pode ser menor do que alguns minutos do tempo de um desenvolvedor
  Se eu gastar US$ 200 por mês em servidores na AWS, consigo executar boa parte do meu código de API web até 100 bilhões de vezes
  Portanto, otimizar para leitores humanos é sempre melhor, e outras otimizações só devem ser feitas quando for comprovado que o código é lento a ponto de ser economicamente inviável

  • O autor também parece pensar assim, mas acho que escolheu um título confuso
    O texto termina com:
    user > ops > dev
    biz > ops > dev
    biz ≹ user
    A conclusão parece estar mais próxima de que o código existe para o usuário final e para o negócio. A última expressão, ≹, expressa de forma elegante que as necessidades do usuário final e do negócio não são iguais, mas que ambos são igualmente importantes para a existência do código
  • O problema do cálculo de “custa menos do que o tempo do desenvolvedor” é que, em geral, quem paga esse custo não é a própria pessoa
    O usuário paga de formas menos óbvias, como uma conta de luz mais alta, vida útil reduzida[0], oportunidades perdidas, maior frustração e upgrades de hardware mais frequentes
    Além disso, a maioria dos usuários não tem o salário nem a qualidade de vida de um desenvolvedor, então o prejuízo pesa várias vezes mais
    [0] Desperdiçar o tempo dos outros é reduzir QALYs
  • No texto, “execução” não é usado simplesmente no sentido de rodar um programa
    Ele diz que inclui operar em produção, ou seja, deploy, upgrade, observabilidade, auditoria, monitoramento, correção, descarte etc.
  • Pela minha experiência, latência é algo com que é preciso se preocupar. Porque afeta a experiência do usuário. É bem difícil comprar latência melhor com dinheiro
  • Eu esperava que a reação fosse essa. Mas este texto é outra coisa. Vale a pena ler

• Se eu devolvesse ao autor a consequência do título, ela estaria mais perto de código ilegível não roda por muito tempo do que de “código é lido mais vezes do que é escrito”
  Dito isso, sou um administrador de sistemas experiente tentando fazer uma transição lateral para desenvolvimento e, nesse sentido, sou um iniciante completo

  • Há muito código fossilizado sobre o qual o negócio depende, mas que as pessoas têm medo de mexer porque não entendem
  • Software proprietário sem código-fonte, por exemplo bibliotecas de terceiros ou praticamente qualquer sistema caixa-preta, é um contraexemplo dessa consequência
  • Acho que todo o setor financeiro discordaria. E você não quer voltar rapidinho da aposentadoria para explicar seu código COBOL a outros desenvolvedores?
  • Acho que ele pode continuar rodando, desde que exista a infraestrutura correta
    Mais precisamente, seria algo como “código ilegível não permanece modificável por muito tempo”
  • Não é um ponto ruim, mas parece mais um tema separado
    A menos que estejamos tratando de ofuscação intencional, a maior parte do código pode ser lida por alguém disposto a se esforçar, e há formatadores de código se necessário

• Há uma consequência a acrescentar aqui. Entre cada uma das etapas a seguir, o número de usos aumenta exponencialmente

  1. Projetistas de linguagens e desenvolvedores da biblioteca padrão
  2. Desenvolvedores de módulos ou bibliotecas compartilhadas
  3. Desenvolvedores em geral
  4. Usuários finais
     Em muitas linguagens, a proporção em cada etapa é aproximadamente da ordem de 1000 vezes, então para cada projetista de linguagem pode haver 1000 pessoas projetando e distribuindo módulos, 1 milhão de desenvolvedores e 1 bilhão de usuários. Os números variam muito conforme o caso concreto, mas a ordem de grandeza está correta para uma discussão qualitativa
     O ponto central é que uma preguiça minúscula na primeira ou na segunda etapa se multiplica de forma dramática rio abaixo. Um hack sujo feito na etapa 1 para economizar 1 minuto “por conveniência própria” pode literalmente desperdiçar milhões de horas da vida preciosa de outras pessoas. Seja fazendo-as esperar por software lento, frustrando-as com crashes, ou atrasando o desenvolvimento de funcionalidades nas etapas 2 e 3 e fazendo-as esperar por isso
     Manter o nível de qualidade necessário nas duas primeiras etapas exige uma enorme autodisciplina e ética pessoal. Por outro lado, fico profundamente triste sempre que ouço alguém defender uma posição injustificável relacionada ao design de linguagens centrais ou bibliotecas padrão
     Ouço com frequência coisas como “se você souber toda a história por trás de como essa aresta afiada surgiu, tudo bem! Se ficar vigilante para sempre, não é um problema. Desde que não use errado, não é inseguro, nem um risco de segurança, nem lento, nem problemático”, porque sei que essas coisas vão continuar derrubando desenvolvedores por décadas e deixando mais lento o software de milhões ou bilhões de pessoas

• Parece que o autor pegou uma regra prática bastante boa e está tentando transformá-la em uma teoria de tudo
  Parece elegante e sensato, mas, tirando as formulações forçadas, está mais para uma mastigação de obviedades amplamente conhecidas

  • theory > /dev/null
  • Você falou em “formulações forçadas”, mas é bom lembrar com frequência que neste setor há muita gente que não é falante nativa de inglês e nem mora em países anglófonos, mas tenta escrever em inglês
    Por isso a expressão pode soar estranha
    E mesmo que sejam “obviedades amplamente conhecidas”, este texto as costura de uma forma especialmente coerente e serve como uma referência útil
  • Acho que também há valor em variar uma regra prática e, por meio dessa variação, revisitar e contextualizar coisas que achávamos que já sabíamos
    Para alguém, tudo isso é novo e, mesmo que para mim tenha sido apenas confirmação dos meus vieses, foi uma perspectiva interessante
  • Para ser mais preciso, é uma teoria de tudo sobre tudo que pode dar errado no desenvolvimento de software. Ainda assim, achei a leitura interessante
  • Você leu até o fim? Todo o resto é contexto

• O enquadramento do autor pode ser mal interpretado de tantas maneiras que dificilmente serve como uma expressão abreviada útil. Não pode haver uma hierarquia absoluta entre esses tokens.
  Antes de tudo, aqui “dev” não é uma pessoa, mas um conjunto de pessoas com diferentes especialidades e níveis de experiência, espalhadas por organizações de produto, engenharia e design em várias organizações.
  “ops” também não é uma coisa só, nem significa apenas operações de engenharia. Pode incluir operações de negócios, suporte ao cliente etc.
  “biz” também não é uma coisa só. Há branding, marketing, vendas, jurídico e a liderança executiva, o conselho, órgãos reguladores, credores, investidores etc.
  Todas essas pessoas influenciam que código é escrito, como ele é escrito e quando e como é entregue aos usuários. Todas precisam resolver o mesmo problema.
  Muitas pessoas dentro de uma organização muitas vezes existem para fazer com que todos entendam e enxerguem o mesmo problema e trabalhem em direção ao mesmo objetivo.
  Mas esse entendimento continua evoluindo, e há um atraso para que ele se propague por toda a organização. Por isso, enquanto o próprio objetivo está mudando, também há atraso para que todos trabalhem em direção ao mesmo objetivo.
  Por fim, “user” também não é uma coisa só, e nenhum grupo de usuários é estático. Existem diversos grupos de usuários, e seus comportamentos podem não ser estáveis no longo prazo.
  Portanto, ajuda entender e reconhecer como todas as variáveis ao redor mudam e, nesse contexto, interpretar um mundo imperfeito e quebrado. Caso contrário, é fácil cair na ideia de que todo mundo é péssimo e tudo está quebrado, então seria melhor refazer tudo do zero.

• Fico contente em ver uma discussão que se aproxima da ética.
  No trecho do texto que diz “acho que há um desalinhamento entre aquilo que pensávamos ser fazer um bom trabalho e o que uma parte significativa do setor considera lucrativo, e que isso explica o desconforto crescente de muitos profissionais de software”, desconforto é uma palavra bem fraca. Muita coisa fica sem ser dita.
  Gostaria de acrescentar algumas perguntas. O que acontece quando o usuário não é o cliente, ou seja, a pessoa que paga? Uma empresa tem obrigações éticas com todos os usuários, inclusive os que não pagam? O que acontece se um cliente pagante quiser usar o seu negócio de uma forma que gere efeitos negativos a jusante para os usuários?
  Por exemplo, e se uma plataforma tornar golpes mais fáceis do que as alternativas existentes, ou facilitar a disseminação de desinformação, ou facilitar o shaping das opiniões dos usuários de uma forma destrutiva no longo prazo, mas atraente e formadora de hábito? Tudo isso já se provou, por certo período, como modelo de negócio bem-sucedido.
  Se essas dinâmicas são reais, uma empresa deveria buscar esses modelos exploratórios? Se buscar, pode fazê-lo de modo mais responsável? Uma versão mais ética do negócio pode mitigar as piores tendências dos concorrentes, ou acaba se tornando parte do problema?
  A conclusão central é clara. Certos tipos de problema são maiores e mais importantes do que o modelo de negócio. Há problemas que podem ser formulados como “que normas e regras são necessárias para fazer as empresas funcionarem dentro de algum grau de bom senso”.
  Por fim, quero deixar claro. Um negócio transmite, por natureza, um conjunto de valores, e isso é inevitável. Mesmo adotar apenas a posição de que “o popular vence” já é, por si só, uma escolha com implicações profundas em termos de valores. Cientistas políticos e historiadores conhecem há muito tempo o problema da tirania da maioria. Seja qual for a sua filosofia política, é algo para se pensar.
  Não sei qual é o “melhor” sistema ético, mas sei que algumas éticas são melhores do que outras. E espero que continuemos refinando nossa ética, em vez de deixá-la sem exame.

  • Vejo isso como um problema diferente daquele de que o texto trata.
    Você pode escolher quais problemas e áreas se alinham à sua própria ética. Este texto fala sobre como construir sistemas e como definir prioridades de trabalho.

• Uma empresa, na prática, não existe; é uma construção imaginária que criamos para organizar recursos e trabalhar em conjunto
  A empresa não é a coisa mais importante acima de tudo. Há muitos usuários, e às vezes seus interesses entram em conflito. Não dá para estar em todos os lugares nem ser tudo para todos, então é preciso priorizar. Buscar usuários mais lucrativos ou usuários alinhados à estratégia de longo prazo pode parecer “bom para o negócio”, mas, na verdade, o objetivo é servir os usuários. Só que passando por algumas etapas a mais
  Quando a política interna fica tão emaranhada que as decisões passam a ser tomadas apenas pelo interesse da empresa, sem considerar como isso leva à felicidade dos usuários, a organização se tornou tóxica. Ela não deveria mais existir. Pode cambalear por um tempo em estado zumbi, mas está em declínio, e todas as pessoas boas irão embora

  • Dizer que uma empresa não existe de verdade é parecido com dizer que emoções não existem
    Dá para dizer que emoções também são apenas construções criadas para explicar reações a situações, mas o fato de não serem feitas de átomos não significa que não sejam “reais”
    Empresas existem na medida em que são um dos principais fatores que determinam a vida da maioria das pessoas. Elas moldam cidades, mídia, leis, política, política externa e exercem grande influência sobre quase tudo que importa. Reais ou não, têm impacto prático ao nosso redor
    Fora do open source, é bem claro que quem paga decide a forma do que é criado. Mesmo que essa decisão seja ruim para essa entidade, ruim para os usuários, ruim para o público em geral ou para o meio ambiente. Claro que há regulações setoriais e governamentais, mas, em geral, a empresa detém o poder de decisão
  • Isso não é verdade. Empresas existem como construções legais, e há muitas coisas que são boas para a empresa, mas ruins para quase todo mundo. Além disso, empresas não existem para servir os usuários
    Infelizmente, empresas existem para servir seus donos. Na maioria dos casos, especialmente em companhias grandes que não sejam microempresas com menos de 5 pessoas, os donos querem dinheiro, então todos na empresa existem para ganhar mais dinheiro para os donos. A felicidade de outras pessoas, até mesmo a felicidade dos usuários, é totalmente irrelevante, exceto quando tem correlação com receita
    Outro incentivo universal dentro de uma empresa é a autopreservação. Portanto, além de ganhar dinheiro, os tomadores de decisão também consideram a segurança do próprio emprego
    Os funcionários não vão embora. A empresa os deixa satisfeitos o bastante. Pagando bem e fazendo-os sentir que fazem parte de uma “comunidade”, é surpreendentemente fácil manter pessoas trabalhando em uma organização maligna ou sem rosto. Basta olhar os escritórios das FAANG para ver uma lista detalhada desses truques de RH
    Concordo que essas empresas são tóxicas e não deveriam existir, mas, na prática, é assim que empresas funcionam. Isso não é sinal de declínio, e sim a forma de um negócio maduro e saudável que pode durar décadas. Executivos, produtos e donos mudam, mas a empresa permanece
  • No começo, eu tive a mesma reação. Quando vejo um texto que pode ser resumido como dinheiro > pessoas, parece errado
    Mas importância é subjetiva. Se for código pessoal para o próprio prazer, o negócio não importa. Se você quiser transformá-lo na sua principal fonte de renda, o negócio passa a ser o mais importante. Porque, se o software não servir a ninguém, por mais que os usuários gostem dele, isso não se transforma em receita real
  • Vamos interpretar aqui “negócio” de forma generosa como um modelo de financiamento sustentável capaz de sustentar manutenção, suporte e desenvolvimento futuro
    Sem um modelo de negócio, até um software excelente, amado pelos usuários, distribuível e fácil de manter, pode acabar desaparecendo

• No começo eu estava cético, mas gostei deste modelo mental
  Claro, não se deve segui-lo cegamente. Há exceções em que dev > biz, como o caso da OpenAI, e também exceções em que dev > ops. Em startups no estágio inicial, é preciso se mover rápido, então especialmente por causa do negócio pode acontecer de dev > ops