Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Um taco e uma bola custam, no total, US$ 1,10. O taco custa US$ 1 a mais que a bola! Quanto custa a bola?
10 centavos? Parabéns, você acabou de cair na armadilha cognitiva que Daniel Kahneman explorou em seu livro “Pensar, rápido e devagar”. Antes de continuarmos, a resposta correta é 5 centavos. Mas, é claro, a maioria das pessoas não faz os cálculos; elas simplesmente confiam na intuição. Isso nada mais é do que um reflexo mental que Kahneman chama de Sistema Um.
Segundo Kahneman, o Sistema Um é o modo de pensamento automático e intuitivo do cérebro, que muitas vezes leva a respostas rápidas. Esse sistema do nosso cérebro está sempre pronto para responder e analisa continuamente padrões que pode resolver com pouco esforço. Mas a triste realidade é que esse sistema frequentemente se engana.
Por outro lado, temos o Sistema Dois, um processo mais lento e ponderado, que exige esforço. Ele começa a funcionar quando nos impedimos de gritar “10 centavos”. No entanto, esse sistema consome energia, e é por isso que não é a opção preferida do nosso cérebro. Esses dois sistemas não aparecem apenas em quebra-cabeças lógicos.
Para os desenvolvedores, eles determinam como o código é escrito, como os problemas são depurados, se você espera pela compilação ou dá uma olhada rápida no Slack, e muito mais. Se esses dois sistemas estiverem funcionando sempre que você abrir seu IDE, a questão é: qual deles você usa com mais frequência e como pode utilizar um ou outro para aprimorar as práticas de desenvolvimento? Vamos descobrir!
Kahneman 101 – Pensar rápido, pensar devagar
Antes de abordarmos como esses dois sistemas podem ser utilizados para aumentar a eficiência no desenvolvimento, vamos ver o que eles realmente são. Kahneman, um psicólogo que ganhou o Prêmio Nobel de Economia e propôs esses sistemas, não foi premiado por previsões financeiras ou projeções de mercado.
Na verdade, ele foi premiado por uma realidade que os economistas há muito ignoravam. A realidade de que os seres humanos não tomam decisões de forma racional. Kahneman dedicou 50 anos de sua vida a estudar como os seres humanos tomam decisões diante da incerteza. Os resultados de seu trabalho mudaram completamente a suposição de que os seres humanos escolhem com base na lógica e na razão.
Em seu livro *Pensamento Rápido e Lento*, Kahneman apresentou um modelo do cérebro humano, afirmando que ele se divide em dois sistemas:
| Características | Funcionalidade | |
| Sistema 1 | Rápido
Emocional Barato Intuitivo |
Esse sistema tira conclusões precipitadas com base em padrões, mesmo quando esses padrões são enganosos. É o sistema que instintivamente grita “10 centavos” no quebra-cabeça do taco e da bola. Para os desenvolvedores, é isso que faz vocês dizerem “Pra mim parece certo” quando veem o código, mas não pensam muito sobre ele. |
| Sistema 2 | Caro
Lento Lógico Controlado |
Esse sistema é o que você aciona quando se controla antes de dar a resposta errada, ou quando analisa um determinado padrão de projeto para determinar se ele é adequado com base na arquitetura do seu projeto. No entanto, esse sistema só entra em ação se você o forçar a isso. |
Então, o que tudo isso significa para os desenvolvedores? A resposta é que seu cérebro está constantemente escolhendo entre uma “rápido, mas errado” ou um “lento, mas correto” . Mas eis o problema: quando você está cansado e exausto, seu cérebro passa automaticamente a usar o Sistema Um, e isso pode afetar gravemente a qualidade do seu código.
Sistema Um x Sistema Dois – Qual deles os desenvolvedores usam mais?
Quando você pergunta a qualquer desenvolvedor em qual sistema ele mais confia, a resposta certamente será o Sistema Dois. Ele é lento, lógico e exige esforço. Tudo isso se alinha perfeitamente à programação. De fato, em uma enquete ao vivo, quase 90% levantaram a mão a favor do Sistema Dois. Eles não estão errados. Por quê? A maioria dos desenvolvedores precisa de um pensamento profundo e concentrado.
Mas eis o problema. O Sistema Dois é bastante dispendioso, pois consome um recurso cognitivo limitado ao qual costumamos nos referir como “combustível mental”. Quando esse combustível se esgota, o cérebro humano recorre automaticamente ao Sistema Um e, se a tarefa ainda exigir precisão, paciência.
É um conceito e tanto, não é? Bem, não se trata apenas de teoria. Cientistas do comportamento encontraram evidências reais e mensuráveis de que nossa energia mental funciona de maneira semelhante à bateria de um celular. Assim, toda vez que você escreve código, depura ou evita se distrair, a bateria se esgota. A Dra. Gloria Mark, que passou 15 anos estudando a atenção humana, afirma que:
- Uma pessoa comum verifica seu e-mail 77 vezes por dia.
- O tempo gasto diante da tela antes de mudar de atividade é de apenas 3 minutos e 47 segundos.
- Leva 25 minutos para se concentrar totalmente na tarefa original depois de ter sido distraído.
Então, esses três minutos de espera por uma compilação que você aproveitou para checar seus e-mails estão, na verdade, custando 25 minutos na realidade. Mas essa não é a pior parte. Toda vez que você muda de contexto, seu cérebro volta automaticamente para o Sistema Um, mesmo que você estivesse trabalhando no Sistema Dois. É por isso que ocorrem erros, a qualidade cai e você acaba escrevendo “código mediano”.
É “código aceitável” pior do que código ruim?
Nem todo código ruim representa uma ameaça real. Há momentos em que um “código mais ou menos” pode ser tão perigoso quanto, se não mais. Qual é a razão por trás disso? Ele compila, passa nos testes e, muitas vezes, passa despercebido nas solicitações de pull.
Então, em essência, o código escrito no modo “System One” tende a ser apenas bom o suficiente para passar despercebido. A cereja do bolo são os revisores de código que estão com a energia mental esgotada. Eles dão uma olhada rápida nesse tipo de código e dizem: “Para mim, parece estar tudo certo.”
Esses fluxos de trabalho, por definição, funcionam como modelos do Sistema Um, e o resultado é que um código medíocre se transforma em um produto medíocre. Kahneman observa que a repetição e os ciclos de feedback podem transferir habilidades do Sistema Dois para o Sistema Um; então, seria possível treinar desenvolvedores para escreverem um código melhor de forma instintiva?
Técnicas para proteger o Sistema Dois
Quando se trata de aproveitar tudo isso para aumentar a eficiência do desenvolvedor, comece por entender que o Sistema Dois é sua ferramenta mais poderosa como desenvolvedor, mas também é a mais frágil. Por isso, ele precisa ser protegido contra distrações constantes, e há muitas maneiras de fazer isso.
A gestão do tempo é fundamental nesse caso. É possível que métodos como a técnica Pomodoro, em que você se concentra por 25 minutos e depois faz uma pausa de 5 minutos, sejam eficazes, mas podem sair pela culatra se sua sessão de trabalho profundo for interrompida justamente quando você estiver prestes a entrar no fluxo. Portanto, você deve considerar os 25 minutos como um tempo mínimo e continuar se estiver no ritmo.
Além disso, o agrupamento de tarefas também é uma ótima técnica que pode proteger os mecanismos do Sistema Dois, pois ajuda a evitar a alternância de contexto. Os desenvolvedores podem até mesmo usar diferentes ferramentas baseadas em IA para incluir sessões de concentração em suas agendas, mantendo espaço para reuniões — uma situação em que todos saem ganhando. O próximo item da lista é proteger o “combustível mental”.
Para isso, dormir é a única opção de reinicialização completa. No entanto, existem algumas outras técnicas que podem ser úteis. Por exemplo, tomar café e deitar-se por alguns minutos até que o efeito do café comece a fazer efeito pode ajudar. Além disso, há práticas como a atenção plena e a meditação. Elas podem parecer coisas de hippie, mas a ciência as endossa.
Os desenvolvedores devem fazer isso para aprimorar suas práticas e aumentar a eficiência
Em primeiro lugar, o princípio fundamental por trás de tudo isso é que resultados de qualidade provêm do Sistema Dois, ou seja, esse é o estado em que os desenvolvedores devem estar se quiserem obter melhores resultados. Diante disso, algumas coisas importantes a se tentar incluem:
- Sistema de Proteção Dupla, utilizando ferramentas que programam intervalos de concentração profunda e se ajustam automaticamente com base na disponibilidade, juntamente com métodos de bloqueio de tempo para manter o fluxo de trabalho por períodos mais longos.
- Utilizar automação e IA para reduzir a carga cognitiva, delegando tarefas repetitivas a ferramentas de automação e IA, pois isso economiza tempo e ajuda a evitar a alternância de contexto.
- Agrupar tarefas semelhantes também pode ajudar a evitar a alternância de contexto, o que poupa energia mental e ajuda a manter o foco.
- Recarregue suas energias por meio de técnicas de sono e atenção plena, pois elas podem ajudar a proteger seus recursos cognitivos, permitindo que você permaneça no Sistema Dois por mais tempo.
- Se algo não for da sua área de especialização e estiver tomando muito tempo, delegue essa tarefa para que especialistas possam criar soluções melhores e mais seguras para você, enquanto você se concentra nas atividades essenciais que impulsionam o crescimento dos negócios.
Considerações finais
Embora Daniel Kahneman talvez não tenha escrito *Pensar, Rápido e Devagar* para desenvolvedores, as ideias contidas no livro são exatamente o que as equipes de software mais precisam. A dura realidade é que, quando você programa no piloto automático, obtém resultados funcionais. Mas acaba perdendo soluções mais limpas e escaláveis que estão ocultas sob a superfície.
No fim das contas, escrever um código excelente não tem muito a ver com talento ou habilidade. Trata-se de ter a mentalidade certa, a mentalidade do Sistema Dois. Hoje, identificar quando você está caindo no Sistema Um e organizar seu fluxo de trabalho para permanecer no Sistema Dois por mais tempo é que constitui a vantagem competitiva.
Então, da próxima vez que você for programar, pare um pouco e pergunte a si mesmo se está programando rápido ou de forma inteligente!
