Os modelos mentais são como mapas em nossa mente que nos ajudam a dar sentido às coisas. São a razão pela qual achamos que algumas coisas são mais importantes que outras, e nos ajudam a resolver problemas.
Basicamente, um modelo mental é nossa pequena compreensão ou imagem de como algo funciona. Afinal, não conseguimos lembrar de todos os detalhes minuciosos sobre tudo, né? Então, criamos esses modelos mentais para dividir toda essa informação complexa em partes que conseguimos gerenciar e entender facilmente.
"Você não alcança o nível das suas metas. Você cai ao nível dos seus sistemas."
- James Clear
O que isso significa? Significa que você não consegue mirar alto sem um sistema que dê suporte a isso. Ou, de forma mais simples, significa que o que você alcança é o resultado dos seus sistemas, o resultado de como você segue seus processos internos/externos, e não o resultado de mirar alto.
Por que eles são tão importantes para um desenvolvedor?
Já falamos bastante sobre como você pode ser simplesmente um "Fechador de Tickets" ou pode mirar mais alto e se tornar um "Organizador de Problemas". Se você não lembra, dá uma olhada no nosso artigo "Redefinindo a senioridade: de fechadores de tickets a organizadores de problemas".
Se você quer ser esse "Organizador de problemas", ou até se está começando como um "Fechador de tickets", precisa de um sistema, processos e formas de pensar que deem suporte ao seu trabalho. Você precisa de um jeito de encarar problemas, ler aquele código que precisa manter e fazer isso da forma mais saudável, produtiva e profissional possível. E o mais importante: você precisa fazer isso sem ter que reinventar a roda o tempo todo.
Na minha opinião, os modelos mentais são comparáveis aos padrões de projeto: são soluções gerais e reutilizáveis para problemas encontrados com frequência. Eles não são soluções prontas que podem ser aplicadas diretamente; pelo contrário, funcionam como um conjunto de "boas práticas" que podem ser usadas em diversas situações.
Modelos mentais para desenvolvedores
Existem vários modelos mentais circulando por aí. Aliás, existem catálogos de modelos mentais que você pode encontrar online. Mas, assim como acontece com os padrões de projeto, pode haver casos em que seja difícil aplicar a descrição abstrata do modelo a uma situação prática do dia a dia em que ele seria útil.
Por isso, escolhi estes modelos mentais que, na minha opinião, são os mais úteis para desenvolvedores de software, e adicionei um ou mais exemplos reais de como podem ser aplicados.
Navalha de Occam
No desenvolvimento de software, esse modelo pode ser usado quando você está tentando resolver um bug. Depois de um tempo procurando, você começa a achar que não vai conseguir consertar; depois vem uma crise de confiança (olá, síndrome do impostor!); algumas horas depois, você está questionando sua carreira, e termina o dia questionando a vida toda. Na manhã seguinte, você percebe que era só um ponto e vírgula faltando ou um simples erro de digitação. O verdadeiro problema (e a explicação mais simples) era que você estava enfiado demais no buraco (ou só cansado mesmo).
Se você está procurando outro exemplo desse modelo aplicado a software, lembre-se do princípio de design KISS (Keep It Simple, Stupid).
Círculo de competência
Se refere à ideia de que cada um de nós, individualmente ou como organização, tem um alcance de habilidades ou compreensão em certas áreas. O conceito reforça a importância de nos mantermos dentro das nossas áreas de experiência na hora de tomar decisões e direcionar esforços. Conhecer nossos limites nos permite entender quando temos vantagem em determinada situação, e quando temos uma "aresta bruta" que nos deixa vulneráveis.
Conhecer nossos limites nos permite melhorar a tomada de decisões sem deixar o nosso ego nos cegar. Você já discutiu sobre um assunto fora da sua área só para evitar admitir que não faz a menor ideia? Não é uma posição confortável, especialmente na hora de tomar decisões.
Inversão
Inversão é um modelo mental simples, mas muito poderoso, no qual você aborda uma situação a partir do extremo oposto ao ponto de partida normal. Em vez de pensar em como ter sucesso, você pensa em como fracassar. Isso ajuda a entender quais erros evitar.
Vamos supor que você e sua equipe de desenvolvimento prometeram a um cliente que vão produzir um código sustentável. O que isso realmente significa? Se você perguntar, vão te responder "código limpo", como se isso fosse suficiente para garantir a manutenibilidade do código. Em vez disso, você pode perguntar à sua equipe o que ela pode fazer para tornar o código-fonte insustentável. Vão te dizer "não adicionar comentários", "usar nomes de variáveis/funções crípticos", "colocar tudo dentro de uma única classe/arquivo", etc. Isso vai te dar uma lista útil do que evitar no seu processo de codificação, garantindo assim mais manutenibilidade.
A inversão, como método, pode ser desafiadora para nós por três razões científicas principais:
- Quebra nossos padrões de pensamento convencionais.
- Nos obriga a considerar resultados indesejados.
- Mudar nossa abordagem habitual de resolução de problemas para a inversão exige um esforço extra do nosso cérebro.
Ao dominar esse método, temos o potencial de transformar completamente nossa capacidade de resolver problemas.
Pensamento de segunda ordem
O pensamento de segunda ordem é um modelo mental que envolve considerar não só os resultados imediatos das decisões, mas também como esses resultados podem gerar efeitos adicionais no futuro. Essa capacidade de previsão pode ajudar a evitar problemas em potencial que não eram evidentes de imediato, e nos permite tomar decisões mais informadas e estratégicas.
Essa forma de pensar é fundamental no desenvolvimento de software porque tomamos muitas decisões ao longo do dia. Por exemplo: devo atualizar essa ferramenta para a versão mais recente por causa dessa nova funcionalidade? Ou devo optar por esse novo estilo de design? Cada escolha que fazemos tem um efeito instantâneo, e geralmente acertamos nessa parte. Mas se não pensarmos no que pode acontecer depois por causa dessa escolha, podemos acabar prejudicando outras partes do projeto, ou tendo problemas inesperados mais adiante porque a nova versão não é estável.
Esse modelo mental é especialmente importante no começo de um projeto. Nesse momento, tomamos muitas decisões que são difíceis de mudar depois. Pense em decisões de arquitetura, tipo de banco de dados, provedor de nuvem, e uma longa, longa lista de outras. Se quiser se aprofundar no assunto, dá uma lida no conceito de decisões Tipo 1 e Tipo 2 do Jeff Bezos.
Reciprocidade
Este é um princípio bem simples, mas poderoso. Se alguém faz algo com você, é provável que você faça o mesmo de volta (ou pior ainda, com outras pessoas).
Um exemplo disso pode ser quando fazemos a revisão de código de alguém. Se formos gentis, honestos e educados no nosso feedback, é provável que essa pessoa faça o mesmo por nós, e até com outros desenvolvedores, ao fazer uma code review.
Inércia
A inércia é uma regra básica da física que diz que se algo está se movendo em uma determinada direção, vai continuar indo nessa direção a menos que outra coisa o pare ou mude sua direção. Essa ideia também pode ser aplicada a diferentes áreas da nossa vida, incluindo o trabalho.
Em muitas empresas, mesmo à medida que crescem e mudam bastante, as partes técnicas, como bancos de dados e linguagens de programação, não mudam tão rápido. Isso é especialmente verdade para aspectos fundamentais como bancos de dados, linguagens de programação e provedores de nuvem. Embora seja importante continuar fazendo as coisas rápido e de forma eficiente, também precisamos garantir que sejam fáceis de manter.
Acho que essa ideia de inércia também se aplica a projetos de engenharia de software. Você já tentou mudar as coisas logo depois de entrar em um novo projeto? Geralmente não dá muito certo. Costumo usar uma cena do filme "Indiana Jones e os Caçadores da Arca Perdida" para explicar isso. Na cena, tentar parar ou redirecionar uma enorme pedra rolando (assim como tentar mudar um projeto) vai te esmagar!
A falácia do custo irrecuperável
A falácia do custo irrecuperável é como jogar dinheiro bom atrás do ruim. Acontece quando continuamos fazendo algo porque já investimos muito tempo, dinheiro ou esforço nisso, mesmo que talvez não seja mais a melhor opção. O erro está em pensar que, já que investimos tanto, deveríamos continuar, mesmo que não possamos recuperar o que já foi gasto. Basicamente, significa deixar que o que fizemos no passado afete nossas decisões agora, em vez de pensar apenas no que é melhor para o futuro.
Esse último modelo mental é muito comum na nossa área. Quantos de vocês já estiveram envolvidos em um projeto de desenvolvimento de software que deveria ter sido interrompido muito antes? Mesmo assim, a gerência seguiu em frente até o final, o que resultou em insatisfação generalizada, e o produto final agora está esquecido em um servidor sem uso.
Mas não vamos só apontar o dedo para os gerentes. Como desenvolvedores de software, muitas vezes criamos sistemas complexos que podem se expandir de todas as formas possíveis, de acordo com os desejos do cliente. Mas depois percebemos que as necessidades do cliente eram muito mais simples do que imaginávamos no início. Ainda assim, continuamos usando nosso monstrengo porque levamos muito tempo para construí-lo e ele até que fica bonito, em vez de usar uma estrutura simples.
Conclusão
No mundo da programação, ter modelos mentais pode nos ajudar a pensar melhor e tomar decisões mais inteligentes. São como um mapa-guia que nos ajuda a entender situações complicadas, resolver problemas e prever o que pode acontecer a seguir. Mas é importante lembrar que não existe um modelo mental que sirva para tudo. Eles são apenas ferramentas para pensar, não regras rígidas a seguir. O melhor é ter vários no seu arsenal para poder usar diferentes modelos conforme a situação.
No começo, pode exigir um certo esforço se acostumar com esses modelos mentais enquanto os usa no seu trabalho diário. Mas, com o tempo, eles vão se tornar algo natural e influenciar sutilmente como você toma decisões, facilitando o manejo do complexo mundo do desenvolvimento de software. O objetivo não é ter uma resposta para tudo, e sim desenvolver uma forma de pensar que te permita olhar os problemas de diferentes ângulos e encontrar soluções eficazes.
