Todos os dias, ou quase todos, no suporte à comunidade vemos um estereótipo: Muita informação para absorver, muitos assuntos para estudar, pouco conhecimento e a busca pela “a solução ideal” em busca de um atalho para o sucesso. Essa ideia se pauta na esperança de que se fizer a escolha certa, a respeito de tecnologia, o stack perfeito, a arquitetura perfeita, o design perfeito conseguirá ter sucesso ou conseguirá ter mais sucesso que os demais. Essa é a narrativa que vamos desconstruir hoje.

Então você se vê perdido em busca de uma solução para seu problema. Da mesma forma que você, milhares de outros jovens possuem os mesmos problemas e a maioria busca pelas mesmas soluções: Balas de prata.

É muito intuitivo buscar uma bala de prata, aquela solução matadora que você vai conseguir encaixar em qualquer lugar. Aquele framework, aquele design, aquela arquitetura, aquele pattern. Aquilo que você sabe que sem sombra de dúvidas, se usar, pode até não estar muito certo, mas errado, definitivamente não estaria. Você já pensou assim? Pois bem, eu também!

Natural buscarmos uma bala de prata para tudo. O desconforto de não saber se está certo ou não, se aquilo que você está propondo faz sentido ou não. E vou te contar. Quanto mais velho você fica, mais tem medo do julgamento alheio. Talvez nesses momentos até se julgue um impostor em pleno exercício da síndrome do impostor.

Calma! Não é porque tem medo que você passa a ser uma pessoa pior, ou um profissional pior.

O que vai determinar se você é melhor ou pior é sua capacidade de lidar com esse medo. E é aqui que vem a primeira lição sobre o tema:

Transforme seu medo em ação

Seu medo te deixa parado, travado, sem ação? Definitivamente não é isso que o universo espera de você. Universo? Ok, pode chamar de Murphy se preferir, vou passar a me referir como Murphy a partir de agora!

Mas então, parar não pode ser uma opção. Mas correr também não é!

A melhor forma de lidar com um medo, quando estamos parados, é dar o primeiro passo. E te digo, tem assuntos técnicos que são tão indigestos que precisamos de 2, 3, 5, 10 visitas ao mesmo assunto, antes de fazer sentido. Outros assuntos, que estão mais próximos, mais conscientes, são tão fluidos que com meia dúzia de palavras, conseguimos compreender aquilo ou pelo menos ter uma visão mais clara sobre o assunto. Outros assuntos são densos, amargos.

A boa notícia é que isso acontece com todos. Cada um tem seus assuntos que consideram complexos demais para seu próprio universo.

E o que eu faço quando encontro algo assim é:

Forçar Imersões

Eu forço o estudo sobre o tema, mesmo que seja indigesto, complexo ou fora do meu ramo de atuação.

Sair de cada sessão sabendo mais do que entrei

Meu único objetivo é sair desse estudo com alguma compreensão(zinha) a mais. Preciso sair mais consciente do que entrei.

E as vezes a única coisa que descobri é que em vez de minha jornada precisar de 3 premissas, ao final de uma sessão de estudo, descubro novas 3 premissas.

Isso não importa. O que importa é que o tempo não foi perdido.

Repetição

Seja insistente. É muito mais fácil não conhecer. É muito mais fácil buscar uma bala de prata.

Mas é a insistência em conhecer o inusitado que o fará um profissional melhor. Com maior capacidade de tomar decisões adequadas. O medo só existe porque o desafio é diferente daquilo que você já fez. Porque se já tivesse feito, saberia dos impactos e provavelmente saberia resolver a questão.

Lembre-se: Pelo simples prazer de poupar energia, você vai tentar se sabotar. Seja com o netflix, seja com um assunto mais divertido. Um filme na TV ou mais um vídeo no TikTok.

Cuidado com suas predileções

Até hoje o que mais me motiva em projetos complexos é a tomada de decisão. É a briga interna, mental, para entender possibilidades, entender comportamentos e vícios de decisão e compreender como algo se encaixa melhor ou pior em algum cenário de uso.

Entenda, eu preciso, quando estou tomando decisões sérias, levar em conta que posso ter uma predileção para tecnologias A, B ou C, simplesmente pela familiaridade e domínio dessas tecnologias. Esse é o caso do RabbitMQ vs Kafka que rolou recentemente. Eu particularmente não sou dos mais fãs de kafka, mas isso não pode, de forma alguma, ser critério de descarte da tecnologia. Portanto, sabendo como meu próprio cérebro tenta encurtar algumas decisões com base em predileções e pouco sustentado nas rasão, eu lido com a predileção como um problema. Preferir uma tecnologia faz com que ela ganha 1 ponto negativo na tomada de decisão. É um puta esforço mental, mas ajuda.

Se você me perguntar o que Kafka tem de ruim, eu vou dizer: Vou repetir resultados de experiências que não são minhas, então é mais ético dizer: Não sei, existem coisas que sinto falta nele em relação ao RabbitMQ.

Mas por outro lado, se olharmos em profundidade quem está usando e como estão usando no mercado, será fácil entendermos que esse argumento é mera birra. Sacou? Entender como seu gosto afeta suas decisões é fundamental. E por isso abrir a cabeça para entender premissas e fundamentos de cada tecnologia ajuda na compreensão do que pode ser feito e aumenta a assertividade na hora de solucionar problemas e tomar decisões.

Tomar decisão é fazer juízo de valor. Quanto mais racional, quanto mais pautado em premissas e quanto mais embasada é sua decisão, maior a proximidade do sucesso.

O processo de tomada de decisão é um processo que exige autoconhecimento e maturidade, fazer juízo de valor tentando eximir predileções/afinidade/gostos é possível, porém complexo.

Eu já falei desse processo no post Como definir a Arquitetura de um Software, muitas vezes a arquitetura é resultante de uma série de premissas, muitas delas sequer são técnicas.

A bala de prata

É muito comum ver essa busca por uma bala de prata. Embora seja natural, é notório que quanto maior a maturidade, mais vezes você vai responder com um “Depende!”.

Vamos testar seu nível de maturidade?

• São 3 afirmações
• Você precisa dar uma nota de 1 a 5.
  • Sendo 1 para discorda totalmente
  • 5 para concorda totalmente
  • Some as 3 notas

Vamos supor que o ápice em arquitetura seja microsserviços, muitos consideram isso. Mas seu problema é um CRUD. Algumas telas de cadastro apenas. Ou ainda, seu projeto é usando estritamente em horário comercial. Com nenhum ou eventual uso fora do horário comercial. Ou você tem algumas dezenas, talvez centenas de clientes com perspectiva de utilização do teu produto.

Consistentemente buscamos soluções definitivas, balas de prata para as coisas, em detrimento de uma análise mais profunda. Isso é natural pois para nosso cérebro é mais racional aprender apenas 1 tecnologia (matadora) de cada assunto pois assim sobra tempo para conhecer mais assuntos. De fato faz sentido.

Por outro lado, quando falamos no perfil “Arquiteto”, ou em “Arquitetura” principalmente em 2019, muita gente pensa que basta tomar decisões óbvias. Como se bastasse pegar um livro de DDD, um livro de Microsserviços, entrar com os 2 em uma centrífuga, e após 30 minutos temos um arquiteto ou alguém pronto para definir uma arquitetura.

Definir uma arquitetura exige prática, prática que você ganha definindo partes de uma arquitetura.

E a melhor forma de validar uma ideia, antes de errar, é defendendo essa ideia com profissionais mais experientes naquele assunto.

Esse tipo de bala de prata, uma solução ou um estilo único que expressa uma forma universalmente certa, não existe. Sempre há um contexto em que essa solução fracassa.

Arquitetura é estratégia técnica, e para conseguir entender como definir uma arquitetura é preciso ter repertório. Pois esses desenhos são padrões, e padrão de [projeto/design/arquitetura] é um estereótipo de [projeto/design/arquitetura] catalogado, mostrando como diversas pessoas usaram uma mesma ideia para resolver um mesmo problema. Padrões não são criados, padrões emergem, emergem de soluções desenhadas por pessoas influenciadas por sua própria história, seu próprio ciclo de leitura e compreensão de arquitetura e outros padrões. Se você repetidamente resolve um problema, você não tem um padrão ainda. Se diversas pessoas usam a mesma estratégia, assim começa a parecer um padrão. E curiosamente, o primeiro a catalogar isso como um padrão, tende a ser o “pai” da coisa.

O que quero dizer é que é preciso conhecer, estudar, ler código, entender soluções de terceiros, para que seja possível entender como tomar suas próprias decisões técnicas. Aliás, sem um leque de possibilidades você não consegue endereçar as premissas e não consegue contornar questões como equipe e contexto, elementos que detalhei em Como definir a Arquitetura de um Software, ou não conseguirá entender como tirar proveito do MongoDB quando estivermos falando de integrações com XML como apresentei em Integrações, XML`s e NoSQL, ainda correrá o risco de chamar de gambiarra.

Cada dia, devemos aprender algo novo, ou pelo menos nos aproximar daquilo que nos predispusemos a aprender.

Tem outros 2 textos sob o mesmo contexto onde apresento algumas dificuldades e minhas decisões fique com Roadmap de Arquitetura – Um exemplo real ou em Por onde andei, andei frustrado.

Aliás, eu continuo usando editor de BPM para fazer meus diagramas de Ação e Reação!

Eu já escrevi bastante, agora é tua vez!

E você, o que lhe causa medo?

Quais são suas dificuldades na hora de definir uma arquitetura?

Quais os desafios que tem tirado seu sono?

O que tem estudado que está te travando?

Grande abraço e até a próxima!

A propósito, sobre o seu número: