Programação é, em grande parte, um processo de pensamento (2014)
(agileotter.blogspot.com)- O resultado visível como código não é todo o trabalho do dia, mas algo mais próximo do resultado puro que resta após leitura, pesquisa, depuração, validação e decisões
- Em uma pergunta informal feita a programadores ao longo de vários anos, a resposta mais comum para quanto tempo levaria redigitar uma alteração de 6 horas olhando apenas o diff foi cerca de 30 minutos
- Essa proporção não vem de um estudo científico, mas se baseia em enquetes e na observação de diffs; ainda assim, serve como referência prática para ver a programação como 1/12 ação e 11/12 pensamento
- O desenvolvimento de software se parece mais com trabalho de design do que com produção fabril, e a replicação após o design inicial é feita por máquinas com custo marginal quase zero
- Quando gestão e processos são otimizados para aumentar o tempo de digitação, o efeito sai pela culatra; são mais importantes o ambiente e as formas de colaboração que elevam a qualidade do pensamento
Quanto tempo leva para redigitar um trabalho de 6 horas
- A premissa é uma situação em que, em um bom dia, com quase nenhuma reunião ou interrupção, um programador fez 6 horas de programação séria
- Antes de ir embora, ele imprimiu o diff, mas durante a noite o sistema de controle de versão quebrou, foi restaurado a partir do backup do dia anterior, e o trabalho do dia desapareceu
- O ponto central da pergunta é quanto tempo levaria para o programador, recebendo o diff, inserir novamente aquelas 6 horas de trabalho na base de código
- Ao longo de vários anos, essa pergunta foi feita em convenções, em clientes, a colegas e a programadores recém-conhecidos, e a resposta mais comum foi cerca de 30 minutos
- Como 30 minutos cabem 12 vezes em 6 horas, essa observação levou à expressão de que programar é 1/12 ação e 11/12 pensamento
A natureza e os limites da proporção
- Esse número não vem de uma pesquisa científica rigorosa, nem de um levantamento formal com bons registros
- O objetivo não era encontrar uma lei estatística ou matemática da atividade de programar, mas obter uma resposta razoável para uma pergunta razoável
- Como nenhuma empresa quis realmente apagar um dia inteiro de trabalho para provar ou refutar o experimento, a base ficou em estimativas e na observação de diffs diários
- Após examinar muitos changelogs e diffs, a quantidade líquida de mudanças em um bom dia pareceu geralmente ficar em torno de 30 minutos ± 10 minutos
Digitação não é o gargalo
- A frase “digitação não é o gargalo” vem sendo repetida há muito tempo em adesivos e nas redes sociais
- Para alguns programadores, a própria digitação pode ser um gargalo, mas o núcleo da produção rápida de código normalmente não é apenas velocidade de digitação ou domínio das ferramentas
- Em um longo texto do Quora intitulado “How do programmers code so quickly?”, um respondente mencionou memória muscular, domínio das ferramentas, habilidade de depuração, capacidade de digitação e habilidade de busca de informações
- Porém, na produção rápida de código, digitação e ferramentas são mais como meios auxiliares, enquanto o tempo para julgar o que deve ser feito pesa mais
A diferença entre fábrica de software e trabalho de design
- Na produção de produtos físicos, a maior parte do trabalho visível é movimento: rolar, estampar, pressionar, fresar, posicionar e montar aço parecem ser o trabalho em si
- Fábricas modernas executam movimentos precisos com base em modelos abstratos, ou seja, dados, como fazem máquinas CNC; humanos gerenciam as máquinas em vez de operá-las manualmente de forma direta
- No software, a fábrica já está pronta, e o usuário obtém uma bit-perfect copy ao clicar em um botão de “copy” ou “download”
- Uma vez que o modelo inicial existe, o custo marginal das cópias posteriores é, na prática, próximo de zero, e software é um bem intelectual
- Uncle Bob Martin vem dizendo que o desenvolvimento de software não é trabalho de fabricação, mas trabalho de design, e que a replicação após o design inicial é realizada por máquinas a custo quase zero
- Programadores, testadores, PO, Scrum Master e gestores de software projetam o modelo de dados que servirá de base para as cópias usadas por clientes e pela comunidade
Trabalho intelectual é difícil de observar
- O pensamento típico da era industrial tenta enxergar o desenvolvimento de software como uma fábrica, e desenvolvedores sofrem pressão para parecerem trabalhadores físicos, mesmo que isso prejudique o processo real
- Atividades intelectuais são difíceis de observar e medir, e uma ideia 80% concluída não tem forma física
- Pode haver experimentos, código de proof-of-concept e anotações, mas eles não mostram uma porcentagem de conclusão exata como em um trabalho físico
- Uma cadeira em fabricação, no ponto de 50%, parece aproximadamente 50% concluída, e, quando fica pronta, parece um produto acabado
- O design de uma cadeira pode nem existir no papel até estar mais de 70% avançado e, antes do design terminar, é difícil saber se ele está de fato 70% concluído
Por que uma alteração de 30 minutos representa 6 horas de trabalho
- Os 30 minutos são o tempo para reproduzir o resultado puro do código escrito, apagado, editado e refeito ao longo do dia, não todo o esforço investido
- O programador avalia e formula hipóteses continuamente enquanto escreve código para evitar defeitos e vulnerabilidades de segurança
- O texto do código contém apenas o que o programa deve fazer em tempo de execução; em geral, não registra por que aquele caminho foi escolhido, que impacto ele tem em outras partes do sistema, ou quais erros foram introduzidos e depois removidos
- A maior parte do trabalho real não está na mudança em si, mas em decidir como mudar; como é preciso entender o código existente, código bagunçado ou fontes nas quais o design não está claro exigem mais tempo
- O resultado do programador é integrado a uma base de código compartilhada, portanto tem contexto social; ajudar outros programadores, testadores e operadores a entender o trabalho também gera custos e benefícios que não aparecem no código
Número de linhas de código não mede progresso
- 6 horas de trabalho intelectual podem se transformar, após leitura, pesquisa, decisão, conferência, validação e revisão, em 30 minutos de mudanças líquidas na base de código
- Isso não significa número de linhas adicionadas; há casos em que, mesmo corrigindo bugs e adicionando funcionalidades, o número de linhas de código no fim de semana fica menor do que no começo da semana
- Houve um caso problemático em que, por várias semanas, foram registradas linhas de código negativas, sem que a equipe soubesse que a alta gestão estava reportando SLOC como se fosse indicador de progresso
- O que o programador realmente fez está mais próximo de ler, aprender, compreender, inferir, pesquisar, depurar, testar, compilar, executar, formular hipóteses e refutá-las
- Muito do trabalho acaba sendo pensar e decidir
Escrever menos pode ser desenvolvimento mais rápido
- Uma das respostas no Quora dizia que é possível ver os dedos se movendo sobre o teclado, mas não o tempo gasto conversando com usuários, discutindo problemas com colegas, pesquisando e pensando
- Outro respondente disse que ajudar o cliente a eliminar ideias desnecessárias que ele chama de “requisitos” ou “must have” é o que mais acelera a entrega de uma solução
- Ainda outro respondente afirmou que um excelente desenvolvedor realiza mais de 90% do trabalho antes de tocar no teclado, entendendo os requisitos e concebendo uma solução adequada
- “Saber o que não escrever”, “fazer menos”, “trabalhar em etapas menores” e “descobrir primeiro o que fazer” são respostas que aparecem repetidamente
- Quem digita mais ou copia e cola mais pode estar com falta de pensamento e compreensão, e o resultado pode ser mais erros e maior carga para outros programadores entenderem e corrigirem
O processo deve ser desenhado para o pensamento
- Se programação é 1/12 ação e 11/12 pensamento, não se deve pressionar as pessoas a digitar durante 11/12 do tempo
- O que é necessário são materiais, ambiente e processos que aumentem a qualidade do pensamento
- Fazer o contrário otimiza o sistema para os efeitos errados
- A produtividade pode aumentar quando o sistema é criado intencionalmente para pensar sobre software em conjunto e facilitar decisões
- É preciso experimentar o aprendizado durante o trabalho e pensar em como criar sistemas em que o pensamento seja otimizado
1 comentários
Comentários do Hacker News
A frase do artigo, “desenvolvedores realmente excepcionais concluem mais de 90% do trabalho antes de tocar no teclado”, às vezes é verdadeira, mas ignora o fato de que as pessoas não conseguem manter muitas restrições e conceitos ao mesmo tempo na cabeça
O alcance do que dá para fazer sem escrever nada, só pensando de forma pura, é bem limitado, então, assim que surge pelo menos uma abordagem possível, costumo ir quase imediatamente para o teclado antes de refiná-la até virar um projeto completamente especificado
Ao testar várias abordagens escrevendo código de verdade, muitas vezes descobri que a solução que parecia a melhor no começo era muito pior do que outra que parecia menos promissora, e nada expõe tão bem um problema quanto código concreto em execução
No fim, programar é o processo de materializar ideias em código para validá-las, e, como na visão de prototipagem de jogar fora a primeira iteração, escrever código também deve ser visto como parte do processo de pensamento
Existe aquela lenda de que ele pensou no Git por mais ou menos um mês, depois o concluiu em 6 dias e descansou no 7º, mas para a maioria das pessoas, e especialmente no meu caso, isso é mais uma interação entre pensar no que escrever, escrever, testar, pensar de novo e corrigir partes
No fim, o processo de chegar à versão final funcionando é, em certa medida, mais próximo de uma arte
Depois de ter uma ideia geral, começo a escrever código pelas partes mais “pegajosas”, onde o risco de dar problema parece maior
Não dá para prever todos os problemas de antemão, então é preciso trombar com eles na prática, e esse método muitas vezes leva a descartar bastante trabalho
Quase não escrevo documentação até ter confiança de que estou no caminho certo[0], porque isso ajuda a reduzir o estado que eu chamo de Concrete Galoshes[1]
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
A única forma de adquirir isso é com muita prática de programação no mundo real e aprendizado ativo, o que também significa continuar usando repetidamente a mesma stack tecnológica
Eu prefiro ficar na mesma stack e me concentrar no problema em si, mas o “ótimo desenvolvedor” de que se fala aqui provavelmente acaba sendo bem unidimensional na escolha de ferramentas
Quanto mais velho fico, mais óbvio se torna que a arquitetura é mais importante do que decisões micro
O que é micro dá para otimizar, mas decisões macro em geral são permanentes
Muitas vezes projeto o código dentro dos testes e deixo que eles conduzam parcialmente a implementação
Imagino o resultado final na cabeça, depois escrevo testes na forma do que considero uma boa API para o sistema, e parto daí
Como resultado, o código acaba sendo basicamente testável, e fico girando várias vezes em Red → Green → Refactor até chegar a um estado satisfatório
Fico curioso se outras pessoas também trabalham assim
A melhor explicação que já vi estava no livro “The Secret Life of Programs”, de Jonathan E. Steinhart
A ideia é que programação de computadores tem duas etapas: 1. entender o universo 2. explicar para uma criança de três anos
Você não consegue escrever um programa que faça algo que você mesmo não entende, não consegue criar um corretor ortográfico se não conhece as regras de ortografia, e é difícil fazer um bom jogo de ação em vídeo se não entende física
Para se tornar um bom programador, é preciso aprender o máximo possível sobre todas as outras coisas, e, como a solução de um problema muitas vezes surge de lugares inesperados, não se deve ignorar algo só porque parece não ter relação imediata
A segunda etapa é explicar o que você sabe para uma máquina que vê o mundo de forma muito rígida, como uma criança de três anos
Se você perguntar a uma criança “onde estão os sapatos?”, ela pode responder “ali”; ela respondeu à pergunta, mas não inferiu a intenção de fato, que era calçar os sapatos e sair
As crianças crescem e aprendem flexibilidade e capacidade de inferência, mas os computadores, como Peter Pan, nunca crescem
Cada pessoa e cada problema combinam com um tipo diferente de raciocínio, e aprender a pensar e programar de várias maneiras aumenta o conjunto de ferramentas que você pode escolher
Por isso, não gosto da ideia de que programação necessariamente precise acontecer de um único jeito correto
A afirmação de que “você não pode programar algo que não entende” também não é realmente verdadeira, porque muitas vezes escrevemos software justamente para entender como algo realmente funciona
Modelagem física também muitas vezes não busca fidelidade completa à realidade, mas sim explorar um equilíbrio entre a experiência do usuário e a dificuldade de um jogo
Programação pode ser uma ferramenta cognitiva exploratória, e isso não significa que a maior parte do pensamento sempre precise vir antes
Eu gosto de generalistas e autodidatas, mas isso não é a primeira etapa obrigatória para se tornar um bom programador
Não é bem que crianças tenham uma “visão de mundo rígida”, e sim que elas nem sempre inferem implicações sociais; e computadores também podem ser programados para derivar conclusões lógicas a partir de fatos conhecidos
Já expliquei coisas para crianças de várias idades, inclusive de três anos, mas essa experiência não se pareceu em nada com programar computadores
Tenho bastante confiança de que esse número está basicamente correto, mas até hoje nenhuma empresa topou provar ou refutar esse experimento apagando um dia inteiro de trabalho
Antigamente, quando eu tinha muito mais paciência, tive um chefe que revisava todas as mudanças de código toda noite e apagava o que não gostava
Esse chefe achava controle de versão complicado demais e queria adotar como padrão da empresa acessar remotamente um drive de rede na casa dele
Então às vezes eu chegava no trabalho no dia seguinte e o trabalho do dia anterior tinha sumido; no fim, fiquei muito bom em refazer o trabalho do dia anterior até instalar SVN escondido
Mesmo incluindo testes de casos de borda, raramente era algo que levava mais de uma hora
O primeiro emprego me traumatizou um pouco, então no segundo já perguntei logo se havia um repositório Git, e o chefe respondeu que não queria tornar o código público porque achava que Git era a mesma coisa que GitHub
Mais tarde, fomos adquiridos por uma empresa maior e passei a ter acesso à intranet; lá encontrei uma instância de GitLab, coloquei meu código, no qual eu trabalhava quase sempre sozinho, sob controle de versão e ainda documentei tudo, além de instalar até o GitLab Runner
Também documentei passo a passo como executar o código, e quando me demitiram e pediram para eu passar o código adiante, mostrei tudo e ensinei como reproduzir, e meu chefe ficou bastante impressionado e agradecido
Talvez eu tenha deixado um pequeno impacto positivo por ter insistido em fazer do jeito que eu achava certo num emprego horrível
Antes de encontrar aquele GitLab, eu tinha criado um repositório Git puro no compartilhamento de rede e fazia push para lá
Mesmo com boas intenções, quando um gerente se envolve com código ou revisão, quase sempre isso é perda líquida para a equipe
É um bom texto para mandar para não programadores
Assim como programadores precisam de conhecimento de domínio, quem quer extrair algo de programadores também precisa entender um pouco de programação
Mesmo um diff minúsculo pode levar horas por causa de depuração, design e aprendizado
É fácil não se impressionar olhando só para a quantidade de entregas, mas ouvir alguém explicar algo e descobrir por conta própria depois de passar horas batendo a cabeça na parede são coisas completamente diferentes
Encontrar um commit de uma linha que melhora o desempenho em 100x pode levar dias, e ao mesmo tempo você precisa explicar nas reuniões de sincronização por que o ticket não está andando
Por isso, conhecimento de domínio é o essencial
Trabalhando em finanças, eu me sentava na mesa de operações observando várias bolsas e escrevia código para implementar diferentes estratégias
Se você não sabe o que o negócio precisa fazer, também não consegue pensar no que o computador precisa fazer
Nessa perspectiva, faz sentido treinar codificadores como se fossem tradutores
Uma amiga minha tradutora conhece bem a gramática e os idiomatismos de várias línguas e aprende línguas novas do mesmo jeito que nós aprendemos uma nova linguagem de programação, mas também dedicou bastante tempo a estudar a indústria farmacêutica e hoje traduz documentos médicos
Advogados e contadores também são profissões com barreiras linguísticas
Quando você vira especialista, aprende a linguagem do direito, da contabilidade ou do software, mas um bom especialista responde na linguagem do negócio, não na linguagem técnica
Um advogado menos bom vai listar todos os resultados possíveis em juridiquês e deixar a decisão com você, mas um bom advogado vai dizer que, embora existam muitas possibilidades pequenas, na prática clientes na mesma posição fazem todos X por causa deste objetivo de negócio
No meu primeiro emprego em trading, um trader tinha criado um módulo em Excel VBA para varrer ativos e rodar um procedimento que encontrava o que negociar
Só existia o arquivo salvo no disco, sem controle de versão, e um recém-chegado, em poucas semanas, salvou por cima apagando o módulo inteiro de VBA; não havia backup nem ajuda de TI
O trader ficou vermelho, depois se acalmou, aceitou a realidade de que deveria haver backup e de que talvez não devesse estar fazendo aquilo em VBA, sentou e redigitou tudo inteiro como se fosse uma tela de terminal dos anos 80 imprimindo um caractere de cada vez
Minha convicção é que, para criar uma boa solução, primeiro é preciso ter experiência naquele domínio
Hoje passo a maior parte do tempo adquirindo experiência em um domínio novo e me sento ao lado de especialistas no domínio para acumular rapidamente o conhecimento necessário
Elas preferem um engenheiro de software que passou 15 anos fazendo software de contabilidade a alguém com uma formação como a minha, e escolhem colocar essa pessoa para conversar 30 minutos com um contador
Vive aparecendo prescrição dizendo que programação deve necessariamente funcionar de um certo jeito, mas os tipos de trabalho variam muito entre os subcampos
Em vez de tentar aprender ou ensinar uma metodologia única e perfeita que sirva para todas as áreas, acho melhor ter uma caixa de ferramentas com várias abordagens e metodologias e entender em quais situações cada uma se encaixa melhor
Por isso, você acaba focando em habilidades gerais de programação que sejam transferíveis entre diferentes setores
Algo parecido aparece no começo do livro PPP[0] do Bjarne
A ideia é algo como: “Mesmo os melhores programadores, especialmente os melhores programadores, passam a maior parte do tempo não escrevendo código, mas entendendo o problema. Entender o problema exige tempo sério e muitas vezes um esforço intelectual considerável. Esse é o desafio intelectual a que muitos programadores se referem quando dizem que programar é interessante”
Também comprei a nova edição[1], que apareceu recentemente na primeira página[2]
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
[1]: https://www.stroustrup.com/programming.html
[2]: https://news.ycombinator.com/item?id=40086779
Coisas como qual banco de dados usar, qual linguagem é a melhor, se devemos permitir null no código e no banco de dados, formato de API, formato de logs
Não é algo especialmente interessante e às vezes precisa ser revisto, mas o tempo gasto com isso nas últimas três empresas onde trabalhei parece, na maior parte, ter sido com problemas que já deveriam estar resolvidos
Na verdade, se uma empresa tiver uma linha de pensamento forte, ela pode ser muito mais produtiva mesmo que essa linha seja questionável
Se estivesse decidido de antemão que usaríamos Perl, MongoDB e CGI, acho que ainda assim eu teria sido mais produtivo do que tenho sido recentemente, apesar dessa stack
“Programação é majoritariamente pensamento” é uma daquelas frases que a gente diz para si mesmo como se fosse uma verdade profunda, mas como observação ela não é muito produtiva
O fato de programação ser pensamento tem exatamente o mesmo sentido em que todo trabalho do conhecimento é pensamento
Design também é majoritariamente pensamento, contabilidade também é majoritariamente pensamento, e gestão também é em grande parte pensamento
A diferença significativa não é o pensamento em si, mas sobre o que se está pensando
Gestores precisam depurar problemas com pessoas, então precisam passar muito tempo com pessoas, ou seja, em reuniões
Desenvolvedores depuram problemas com computadores, então precisam passar muito tempo com computadores
Existe uma tensão evidente aí, e nenhum dos extremos funciona, então é preciso encontrar um equilíbrio para atrapalharmos menos o trabalho uns dos outros
Não estou falando de código obscuro no estilo code golf, mas do fato de que tudo o que você produz terá de ser mantido
Isso claramente a diferencia de um romancista, que pode se importar pouco com manutenção e muito mais com a emoção produzida pelo texto
A melhor otimização para “como criar um sistema em que o aprendizado no trabalho otimize o pensamento?” é reduzir interrupções
Pesquisas mostram que interrupções têm um efeito devastador sobre a programação
Leva de 10 a 15 minutos para retomar o trabalho depois de uma interrupção, é provável que um programador só consiga uma única sessão ininterrupta de 2 horas por dia, e o pior momento possível para interromper é quando ele está editando, pesquisando ou tentando entender algo
Fico pensando se existe alguma forma de rastrear e mostrar essas interrupções
[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/
No entanto, espera-se que desenvolvedores consigam concluir tarefas de codificação de várias horas no meio de reuniões intermináveis, pings curtos no Slack/Zoom e sincronizações
Nas vezes em que precisei trabalhar em casa no fim de semana, percebi que a qualidade do trabalho em um fim de semana sem interrupções era muito melhor do que em um dia útil caótico
Não serve para todo mundo nem para todos os casos, e os outros 20% consistem em coordenação com pessoas que trabalham de dia, mas a produtividade que vem de boas sessões sem interrupção de várias horas não tem comparação
De novo, isso não serve para todo mundo, provavelmente nem para a maioria
Em casa ninguém me interrompe e, mesmo quando há uma interrupção, eu mesmo posso decidir quando reagir
Especialmente ao lidar com problemas difíceis, se houver interrupções a cada 10 ou 20 minutos, é melhor simplesmente parar; caso contrário, você provavelmente acabará produzindo um código bagunçado que vai virar dor de cabeça depois
Foi projetado para respeitar a privacidade: registrava o fato de que a pessoa tinha usado o navegador, mas não URLs específicas, como se era a intranet da empresa ou fb.com
De vez em quando aparecia um pop-up para o próprio usuário avaliar sua produtividade e deixar comentários em texto livre, e isso não era vinculado ao ID do usuário para evitar que as pessoas mentissem para parecer super-humanas
Fizemos um frontend em Windows e um backend em Scala e distribuímos para um grupo de voluntários incluindo desenvolvedores, advogados e pessoal de finanças, mas, quando a coisa estava começando a ficar interessante depois da primeira análise de dados, acabou o tempo e o orçamento, então não conseguimos publicar como artigo
Também vimos ferramentas existentes como o Rescue Time( https://www.rescuetime.com/
), mas concluímos que armazenar dados internos de produtividade em uma nuvem externa era inaceitável
Às vezes, boa programação é majoritariamente pensamento, mas a frase “nenhum plano sobrevive ao primeiro contato com o inimigo” continua valendo
Programação prática é uma combinação cuidadosa entre planejar e colocar código no IDE para ver o que acontece, e esse equilíbrio precisa variar conforme o caso de uso
Se você passa dias sem escrever código, então ou já conhece completamente a superfície do problema, ou está apenas chutando
Se for a segunda opção, não há assim tanta coisa em que pensar
Na segunda vez, fica mais rápido
Concordo que podemos expandir a ideia de pensamento para “pensamento com ajuda de ferramentas”
É uma reformulação repetida de Programming as Theory Building, de Peter Naur, e foi decisiva para eu compreender a essência da programação
Programar não é o trabalho de criar o programa em si, mas o de formar uma percepção específica sobre os acontecimentos do mundo, e o código produzido ao final é apenas uma simples expressão da teoria que se construiu