De um lado as guerras dos frameworks e tecnologias, de outro as guerras de skills e culturas. Cultura DevOps, Agile. Então serverless ou containers? Fullstack é um pato que não corre bem, não nada bem, e não voa bem?

Aproveitei essa noite para reler as pesquisas que eu faço anualmente, onde coleto opiniões, críticas e sugestões e resolvi pegar um tópico recorrente para falar: Carreira. Vocês pediram e eu vou trabalhar em cima desse assunto hoje.

Sobre carreira há muito a dizer, há inúmeras considerações a serem feitas, mas vou usar minha história como fio condutor desse texto, mostrando o que eu fiz, o que eu faço. Assim eu vou narrando o que eu fiz e o conceito ao redor do que eu fiz, com os exemplos que uso.

Indecisão técnica

Pra começar, deixa eu te contar uma coisa: Eu era extremamente indeciso.

Qual tecnologia? Qual framework? Qual blablabla?

Mas, diferente da maioria dos meus colegas de trabalho, eu não aceitava opiniões. Na verdade bem no início eu aceitava e ficava cada vez mais perdido.

Então desde cedo eu senti a necessidade de chegar às minhas próprias conclusões. E há bons argumentos sobre isso que queria compartilhar com você.

Arrogância? Não. Eu simplesmente sempre fui crítico. Não aceito um “Porque não”, preciso entender o motivo para entender como posso chegar à mesma conclusão.

E isso se dá pela cu-ri-o-si-da-de!

Eu sempre quis entender como as pessoas tomavam decisões, como chegavam às conclusões. Eu não queria cair no ridículo de ter uma opinião “ruim”, “frágil”, “descabida”. Eu precisava filtrar meus pensamentos e pra isso precisava julgar minha própria opinião como válida e/ou pelo menos pertinente.

Dessa forma, verdades enlatadas nunca me satisfizeram. Eu precisava sujar a mão para ter a minha opinião. Eu passei toda a minha vida profissional comprometido com isso!

E quando eu falo em comprometimento… ahhhh você não imagina quanto código eu já produzi, quanto cliente, projetinho, poc e mais o que eu fiz para chegar às minhas conclusões.

Fato que decision makers me chamam a atenção desde sempre.

Como aquela pessoa conseguia entender com tanta profundidade algo, ao ponto de descartar ou não.

Como era o processo de tomada de decisão?

Como aquelas pessoas que decidiam, decidiam?

Um ponto curioso do início da carreira é que eu sempre chegava a conclusões diferentes das dos meus colegas. Eu sempre fui curioso, simultaneamente esforçado (odeio esse termo), mas a soma desses 2 elementos me faz uma máquina de testar coisas.

Me peguei essa semana percorrendo exatamente o mesmo processo ao analisar uma reunião de marketing, material que tenho estudado.

Como elas julgavam?

Onde encontrar esse nível de consciência ao ponto de definir se uma simples ideia maluca é maluquice ou algo fantástico?

No final, toda decisão é um julgamento. Há um juízo de valor.

Sempre esteve claro para mim que o contexto é fundamental para se tomar decisões, e assim, decisões nunca são absolutas. Isso quer dizer que, na minha opinião, se você tomou uma decisão com serenidade e sabedoria, você levou em conta o contexto e foi influenciado por ele para chegar a uma conclusão.

Eu percebia que quando eu tentava percorrer os mesmos caminhos, eu chegava a conclusões diferentes, por mais que estivesse sob o mesmo contexto.

Não era difícil chegar à conclusões antagônicas.

Assim percebi que é necessário conhecer melhor as pessoas e o que as motivam na hora de decidir entre uma tecnologia ou outra.

E minha perspectiva sobre isso também não é das melhores:

A maioria de nós decide em função do esforço e não da qualidade. Essas decisões são sobre quem está estudando a tecnologia e não sobre a tecnologia em si. Assim é fácil concluir que sempre haverá flame exatamente porque as pessoas querem olhar pela sua própria perspectiva. Ninguém está disposto a olhar pela perspectiva do projeto, da empresa, do cliente. Decisões pessoais influenciando decisões técnicas.

O processo de decisão

Eu criei meu framework mental para tomada de decisão técnica. Serve desde decisões grandes até decisões pequenas.

Consiste em listar os pontos de interesse de uma decisão e realizar uma sabatina.

O que é importante, quais pontos são relevantes a serem avaliados. Abaixo segue um esboço.

Nem adianta se basear nesses itens pois o que temos aqui é uma lista feita no freestyle.

Em geral perco mais tempo definindo precedência e prioridade dessa lista do que das tecnologias em si.

• UI
  • Flexibilidade
  • Capacidade de representar design complexo
  • Semântica
• Backend
  • Mensageria
    • Resiliência
    • Facilidade
    • Curva de aprendizado
    • Confiabilidade
  • Web Framework
    • Flexibilidade
    • Extensibilidade
    • Praticidade
    • Portabilidade
    • Monitoramento
    • Segurança

Essa lista deve contemplar o que eu desejo como resultado de uma decisão técnica.

Tudo que eu coloco na minha arquitetura, ou me aproxima ou me distancia de algum desses elementos.

Dica para a vida: Não existe nada que seja adicionado que seja indiferente. Ou é positivo, ou negativo, neutro: Não existe!

Isso faz com que você tome partido de todas as possíveis escolhas.

E tomando decisões e mais decisões, eu adotei o ataque, desqualificação e descarte.

Sim, eu transformo minhas decisões técnicas em rinhas mentais. 

É quase um processo esquizofrênico onde eu encaro 2 realidades: Defensores e Detratores.

1° Round

A primeira fase, é uma peneira. Ela é pouco propositiva e visa reduzir o esforço da segunda fase.

Ataque: Ataque a tecnologia com seus problemas que você tem a resolver.

Defesa: Defenda a tecnologia, validando se o argumento de fato é um argumento pertinente ou se está fora de contexto.

Desqualificação: Desqualifique a tecnologia com base nas suas premissas, Ache aquilo que é incompatível com teu contexto.

Descarte:..

O que estamos fazendo aqui é peneirando diversas tecnologias. Um ponto importante é que desse pipe, não sai apenas 1 vencedor, saem 2, ou 3 vencedores.

2° Round

Agora tudo que vimos no primeiro pipe não funciona com a tecnologia, funciona com detalhes de cada tecnologia.

Em vez de comparar o contexto, comparamos as tecnologias, concorrentes sob o prisma dos requisitos.

É uma comparação do que cada uma das tecnologias traz com maior fit para endereçar um problema que você tem a resolver.

Ataque: Ataque uma feature com sua similar

Defesa: Defenda o ponto de vista do problema, quem resolve melhor o problema?

Desqualificação: Ache argumentos que inviabilizam o uso. Seja o mais contundente possível.

Descarte…

Isso gera…

Essa forma de lidar com decisões é traumática.

Ela exige que você estude mais do que provavelmente está habituado a estudar. 

Não te faz expert, mas te faz no mínimo conhecedor, muito, mas muito além do overview. Mas para teu conforto, você não precisa percorrer esse caminho sempre. Esse tipo de profundidade faz com que você reaproveite muito seus estudos.

Então, sempre que me deparo com algo novo, eu faço isso.

E para entender com essa profundidade, eu muitas vezes preciso recorrer ao fundamento.

Como foi com Docker. Precisei parar para entender, mesmo que superficialmente, o kernel e como os pontos se conectam. Precisava saber o papel de cada coisa para que pudesse, no momento seguinte fazer sentido. E mais tarde servir de alicerce para entender a tecnologia em si. Que por sua vez serviu de alicerce para ensinar a tecnologia.

Quando eu comecei a ensinar docker, eu estava fascinado, e produção com Docker era meu servidor pessoal.

Mas note: Eu falava sobre o assunto, testava, implantava, via rodando e usava aquilo que eu estava falando.

É graças a esse tipo de abordagem que consigo falar com propriedade sobre diversos assuntos e tecnologias.

Essa forma de pensar, que leva em conta “sujar a mão de lama” abdicando do mi-mi-mi me permite discutir decisões com profissionais de outras áreas, me permite fazer coisas típicas de profissionais de outras áreas. Me faz entender o ponto de vista da outra pessoa, me faz entender o que ela quer dizer com o que está dizendo.

Essa “boa vontade” tem uma pitada de busca por autonomia. Busca por ser autossuficiente, se assim precisar. Só SE PRECISAR!!!!!!!!!!!!!!!

Outro ponto relevante que lembrei agora enquanto estava revisando esse post, é que por sorte, em situações normais de temperatura e pressão (SNTP), você tem poucos problemas por vez. Ou pelo menos pode revisá-los para ter poucos por vez.

A habilidade do futuro

E assim eu concluo dizendo que a habilidade do futuro não é sua linguagem, framework, navegador ou console favorito.

A habilidade do futuro é a capacidade de se reinventar. De aprender coisas novas, é a capacidade de não parar, de não ser um dinossauro.

Hard skill a gente aprende, compra.

Cognição para aprender, desaprender e reaprender não! Essa a gente desenvolve!

Desenvolva sua habilidade de aprender.

Eu ainda tenho outros posts sobre aprendizado, que estão engavetados aqui no rascunho.

Me diga o que achou desse aqui.

Deixo aqui um vídeo do TEDxFAAP com Michelle Schneider.

 

Essa palestra merecia um prêmio.