Rádio Frequência e UVAS!

Essa é uma das minhas histórias preferidas sobre minha carreira como engenheiro de software, e aconteceu na minha primeira experiência profissional. Nunca esperaria que fosse a melhor, e que seria um dos momentos de carreira mais felizes da minha vida em termos de realização profissional. Acredito que um fator que beneficia essa condição são os começos, eles são sempre encantadores, pois oferece exploração e descoberta, e um outro fator é quando você encontra pessoas com sinergia e propósitos semelhantes. Com isso é possível criar boa cultura e amizades, interações humanas reais que trazem alegria.

Mas, acredito que você clicou aqui querendo saber qual é a relação entre Rádio Frequência e uvas não é mesmo? A história é longa, mas é interessante.

Era uma vez...

O ano era 2012, eu estava na faculdade, cursando o terceiro semestre do curso de Sistemas de Informação. Estava altamente realizado com um universo novo da engenharia de software que eu descobrira, usava um par de All Stars bem surrados no estilo hard rock anos 80/90 e achava que ficaria milionário com a criação de uma rede social como o Zuckerberg tinha feito com o Facebook. (spoiler, não fiquei).

Naquele momento, eu já sabia lógica básica de programação e algorítimos usando Pascal , e também tinha acabado de aprender a programar em linguagem C usando o velho Code Blocks. Eu tinha um empréstimo eterno na biblioteca da faculdade (pagando multa por atraso toda semana) do livro "C Completo e Total" do Herbert Schildt, andava com esse livro na mochila o tempo todo, e foi minha base para entrar nesse mundo.

O Estágio

Naquela época, conseguir um estágio de engenharia de software, não era uma tarefa nada fácil, pois os sites de emprego/estágio não eram tão evoluidos como são hoje, a maioria das empresas não divulgavam vagas através desses canais. O mais comum para mim, era toda semana ir pessoalmente em um prédio perto da faculdade, no centrão do Recife. Era um instituto que visava juntar as empresas e alunos, e lá, lembro que subíamos num elevador velho com porta de madeira e outra semi porta de ferro toda vazada. Nos elevadores, ainda existia uma pessoa que ficava dentro do elevador num banquinho sentado, seu papel era dar informações, apertar os botões e levar você para o andar correto, como um piloto de elevador. A automação do elevador fechava a porta com tanta força que era um estouro (BAHHHHHHHHHHHH). E daí o elevador tomava destino ao 7 andar, balançando como se tivesse numa turbulência severa de avião. Chegando lá, abria mais uma vez a porta (BAHHHHH) e você saía feliz da vida por ter sobrevivido.

Dentro da sala existia uma parede com papéis físicos pregados, onde havia as oportunidades de estágio, como essa foto de exemplo abaixo:

Se bem me lembro, cada papel tinha um número ou algum identificador. E se você se interessasse e tivesse os requesitos da vaga, você ia para a próxima sala, levando o identificador do papel.

'Felizmente', nunca consegui um estágio por aqui. Era uma prática, também, pesquisar no Google, sobre as empresas da cidade, e foi então que encontrei uma empresa chamada: IFICOMM Tecnologia, e sem muita esperança, enviei meu currículo para o email que continha no formulário de contato. E para minha surpresa, poucos dias depois, recebo uma ligação, à respeito de uma vaga em outra de estágio, só que em outra empresa, com nome parecido, era a NIXCOMM.

Na ligação do telefone, era o Agenor Mota ou mais conhecido como: Mota. Ele foi meu primeiro mentor no mundo da tecnologia. Era dono da Ificomm, mas estava recrutando para a Nixcomm, na qual tinha uma parceria. A Nixcomm era uma empresa até então focada em telecomunicações, servidores, VOIP e cabeamento estruturado, nada de software!. O fundador da empresa é um dos caras mais loucos e inteligentes que já conheci, era um engenheiro elétrico que curtia Pink Floyd e tinha uma visão além do alcance para inovação e negócios. Ali era o começo da minha história como engenheiro de software.

O Hermes Aguiar, Pink Floydiano, queria criar um novo setor dentro da empresa. Estava montando um pequeno time de 3 pessoas com Mota no comando, para criar produtos de software baseados na tecnologia RFID (Radio Frequency Identification). Eu nunca tinha escutado falar nisso antes, e isso deixava tudo fascinante. Era pura adrenalina!

Uma curiosidade é que sempre fui uma pessoa da noite, e passava minhas noites estudando, e dormia muito durante o dia. Quando Mota me ligou, era meio dia, e eu tinha acabado de acordar, com voz de sono, atendi o telefone bocejando... e ao final, ainda assim, fui escolhido! Obrigado Mota!

A Nixcomm, minha segunda casa, onde tudo começou.

Uma semana depois, lá estava eu no escritório, e iria conhecer a terceira pessoa dessa história, o meu parceiro de código: André Andrade (O segundo estagiário escolhido). A empresa tinha organizado um ambiente para desenvolvimento de software em uma das salas da empresa, junto com o time de projeto (a galera que usava Autocad para desenhar as plantas), e lá no canto estava todo o hardware novinho em folha!

Antenas, controladoras, leitores de mão, leitores de mesa, cabos coaxiais, rolos de fio, totens, computadores, monitores, placa de vídeo, CDs de instalação de Drivers (Sim! CDs!) tudo novo! Foi como uma criança na manhã de natal, abrindo tudo e plugando cada cabo, cada conector, minha nossa, era mágico! O ano era 2012... ainda era normal existir monitores quadrados (4:3), estávamos no lançamento do Ivy Bridge da Intel, Geração 3. Tinha um servidor gigante do lado da minha mesa, com várias luzes piscando e uma tonelada de cabos bem organizados como manda as certificações de cabeamento estruturado. Era um encanto para um profissional de TI começando a carreira na época.

Foi aqui, que sem querer, mergulhei no mundo do Hardware também, criando software embarcado na minha primeira experiência profissional, isso foi um divisor de águas poderoso em minha vida.

Como éramos um time pequeno, tínhamos uma experiência completa do negócio, conseguíamos atuar do início ao fim da cadeia, não só fazendo código, mas afundados em documentação de hardware, ligando para fornecedores de equipamentos RFID, fazendo compras de equipamentos e etiquetas RFID em seus mais diversos tipos (existem vários, cada um para uma situação específica), interagindo com o time de projeto para entender onde ficariam os equipamentos e cabos nas plantas, interagindo com o time operacional para entender as métricas de quantidades de itens que precisaríamos para implantar a solução em locais diversos com requisitos diversos. Eu gostava tanto desse trabalho que as vezes pensava ( Eu ainda sou pago por isso? ).

Com o passar do tempo, conseguimos ganhar experiência com programação e RFID, e então criamos várias soluções com a tecnologia RFID (que contarei em outros posts). Eu dava uma de designer também, nessa época, eu desenhava os layouts dos produtos de software, as marcas e identidade visual dos produtos, nos quais registramos patente de vários, e até as camisas comemorativas, e esses projetos eram como filhos, pois eles saíam do campo imaterial de nossos esbolços na mesa central, discussões técnicas, até chegar nos códigos que davam vida aos equipamentos e ao ambiente. Depois de 1 ano de estágio, fomos contratados e ganhamos uma sala novinha e dedicada ao projeto de Software da Nixcomm.

Tínhamos a nossa própria versao do Kanban, em um quadro físico na parede da sala, onde construíamos tudo da maneira que mais funcionava para o time, e trazia resultados no final das contas.

Fazíamos muita prototipagem, colávamos as telas e ideias na parede, organizando por fluxo e encaixe de ideias, e fícavamas sentados por minutos em frente dessa parede discutindo e verificando cada detalhe, com a mão no queixo como pensadores da grécia antiga.

Mota, um dia nos trouxe um super quadro para colocarmos na parede da sala, com os tipos e namespaces mais utilizados no .NET Framework 3.5. Era animal!

Tínhamos muitos eventos durante o ano, e era tradição termos uma camisa para cada um destes. Festas internas, festas para nossos clientes, eventos beneficentes, copa do mundo e etc! Aqui segue a camisa da copa do Brasil, tenho até hoje.

E tinha se desenvolvido uma bela amizade e uma cultura maravilhosa naquele time! Carinhosamente conhecido como: Equipe Cão!

O mais engraçado é que tanto o Hermes quanto o Mota tinham uma cabeça muito aberta para modelo de trabalho naquele tempo (2012). Ninguém queria saber que horas nós chegamos no escritório, nem que horas saímos, nem se a gente ia desenvolver algum módulo de software de casa e não iria para o escritório em alguns dias. Tínhamos a chave do escritório e podíamos simplesmente ir e vir a hora que quisesse. Embora tivesse essa liberdade, a cultura e o trabalho eram tão prazerosos, que por muitas vezes trabalhávamos por muitas horas após expediente, sem nem ver o tempo passar, era como um laboratório de um ciêntista maluco, onde podíamos mexer nos raios lasers e programar o monstro!

Quando ganhamos nossa nova sala, colocamos as mesas em frente de uma super janela, que no por do sol era lindo!

Aqui uma foto minha e de André integrando módulos Desktop Windows Forms .NET Framework 3.5 com ASP e Windows CE para dispositivos móveis, pocket PC. (Velha Guarda).

Era um time de sucesso e alta performance! Nenhuma solução era impossível. E essa parceria gerou uma grande amizade que perdura até nos dias de hoje quando lembramos dos momentos e morremos de rir da equipe cão!

Ok Marcos! Legal Legal... E as Uvas?

Agora vamos para o projeto que dá título a esse texto. Fechamos um contrato para desenvolver uma solução para uma uma fazenda de uvas. O projeto visava medir a eficiência e produtividade de suas equipes em suas linhas de produção. Utilizaríamos tags RFID e antenas acopladas nas esteiras da fazenda, para ler cada tag que estaria presente em cada pack de uva passando em cada fase do processo e criando um timestamp do momento da leitura, quase que um SLA (Service Level Agreement) de uva.

O projeto era altamente desafiador, o nível técnico da solução era altíssimo, pois mesclava vários conhecimentos que tínhamos desenvolvido até então, e também coisas que não tínhamos feito ainda, pois no mundo das solucões de engenharia sob medida, sempre é uma surpresa, não existe cases onde se inpsirar ou exemplos de código para ver e etc, era realmente criar tudo do zero, com muita criatividade para resolver problemas complexos com soluções inusitadas.

O desafio do ambiente industrial

A dificuldade aumentava principalmente por conta do ambiente industrial, o local que a solução seria implementada era cheio de esteiras, máquinas, transformadores e diversas fontes de energia que poderiam causar interferência na rádio frequência, além de pessoas andando de lá para cá. A rede era apenas local e intermitente, então já prevíamos o desafio de sincronia de dados entre os equipamentos que ficavam no local A e o servidor de banco de dados que ficaria no local B, distante, mas ainda dentro da fazenda.

Precisaríamos implementar:

• Uma solução embarcada em hardware RFID que rodasse sozinha sem precisar de ninguém operando.
• Precisaria ser leve o suficiente para rodar em um PC Windows, daqueles com gabinetes pequenos, empresariais, que ocupam pouco espaço e tem um hardware mais inferior.
• Teríamos que gerenciar os dados offline com sincronização para o servidor quando houvesse rede, devido a conexão intermitente.
• Além disso, criar estruturas de backup automático dos dados em caso de falhas, falta de energia ou quando o ambiente ficar sem rede por muitos dias.
• E nosso time de projeto teria que bolar a passagem de cabos de energia e rede na planta do galpão, junto com o time de campo que faria a instalação elétrica e fixação dos equipamentos nos locais estratégicos.

Sem dúvida, era um mega desafio de engenharia. Acredito que foi um dos maiores que já enfrentei. Um problema como esse não se resolve com snippets de código que se encontra na internet hoje em dia. Naquele tempo, não existia chatGPT e nem se falava de IA ainda, não existia projetos boilerplates para se basear, pois era tudo único para aquela situação, daquela empresa, daquele projeto.

Equipamentos e Recursos

Após entender os objetivos da solução e resultados esperados, começava a fase imaterial do projeto: pensar, pensar e pensar.

Surgiam os questionamentos:

• Quais os equipamentos seriam mais eficientes para a solução? Que tipo de antenas, quais leitores? E a frequência?
• Que tipo de tags seria mais coerente usar em um ambiente industrial, que fosse capaz de suportar umidade, poeira, manuseio humano e etc.
• Qual banco de dados podemos usar para uma solução in loco, com escrita constante, relacional ou não relacional?
• Como faremos a arquitetura do projeto de software? Quais camadas? Que padrões utilizar?

Eram muitos questionamentos, e em minha opinião, é o momento mais importante na carreira de um engenheiro, seja de qual área for. É preciso desenvolver a habilidade de imaginar coisas no mundo das ideias primeiro, e conseguir traze-las à matéria. Isso é ser um pontífice, cabeça nos céus e pés na terra, ligar os dois mundos.

Para os leitores, decidimos utilizar modelos da Motorola, pela sua qualidade e também porque já tínhamos muita experiência com esses modelos e alguns projetos executados com eles.

FX500 e RD11320

Antenas, tínhamos 2 modelos em mente também, para situações diferentes em locais diferentes do processo.

AN400 e AN480

As Tags RFID eram inúmeras. E precisávamos escolher uma que fosse adequada para todos os problemas que pensamos mais acima, como: umidade, poeira, mauseio humano, frequência, quantidade de memória disponível para gravar os dados...

Para quem não sabe como uma tag RFID funciona, aqui vai uma breve explicação:

A maioria das soluções que trabalhamos eram resolvidas com tags passivas, que é o tipo que você vê acima, essa tag possui um chip muito pequeno internamente, que guarda as informações de identidade da tag e mais alguns slots que podemos gravar informaçoes.

Uma tag RFID passiva não possui bateria própria e é ativada pela energia do sinal de rádio emitido pelo leitor. Quando recebe esse sinal, a tag reflete uma resposta codificada com seus dados de identificação.

E os tipos de tags são diversos em: tipo, material, potência de sinal, tamanho da antena, quantidade de memoria...

Quando fazíamos o pedido dos rolos de etiqueta para alguma solução, podíamos pedir ao fabricante que colocasse uma pré gravação de IDs em um range específico, ou gravar algum campo específico que podíamos utilizar como alguma flag para identificar algum grupo de tag, projeto, fase e etc. A maioria das tags tinham campos de memória protegidos por senha, entao não era apenas ter um leitor e apontar para tags e conseguir ler os dados, eles ficavam criptografados.

Podíamos escolher também a arte da etiqueta...

Em futuro próximo após esse projeto, compramos uma impressora/gravadora, que era possível comprar os rolos de etiqueta (virgem) e gravar os dados e layout nós mesmos, eliminando uma etapa do processo, era mais ou menos assim...

Não lembro muito bem se era esse o modelo, mas isso é história para outra postagem...

Para o banco de dados, tínhamos uma mescla de SQL Server para a aplicação com replicação em um MYSQL IN LOCO para leitura via PowerBI interno da empresa contratante.

As leitoras ao capturar os dados das tags, faziam a gravação em um banco de dados SQL Server local na máquina onde rodava a solução de software e sincronizava para um Mysql em outro local da fazenda.

Para o desenvolvimento de Software estávamos munidos do SDK da Motorola, que era em C# .NET Framework 3.5, e interfaces gráficas com o velho Windows Forms e ASP, na IDE mais pesada que já vi: Visual Studio(não existia o VS Code ainda), e era quase tarefa impossível rodar o C# em outro canto que não fosse a IDE da Microsoft. Ao abrir o projeto, meu laptop quase voava devido a intensidade do trabalho do cooler 😄, mesmo portando um i7 da última geração.

Tudo era mais complicado, só para montar o ambiente, tínhamos um manual que desenvolvemos, com quais DLLs precisam estar em quais pastas, qual versão disso, versão daquilo outro... docker naquela época ainda tava engatinhando e não era realidade nas empresas locais. Então o ambiente era montado na raça, seguindo nosso manual, era uma verdadeira novela!

E muitas definições continuavam a ser executadas. Esbolços, negociacões com fornecedores, interação com time de projeto, logística... tudo isso, nós 3 que fazíamos, o código era a ultima parte. Poucos dias depois, estávamos prototipando, e criamos tags de teste para simular o ambiente dentro do escritório, onde o processo era as tags passando na esteira e sendo lidas e processadas. E levaríamos essas tags para o projeto piloto, até receber as tags definitivas que tínhamos encomendado para o projeto oficial.

Fizemos as tags de teste à mão, adicionamos um invólucro de plástico para proteger a etiqueta do suor das mãos e outros líquidos. Estilete, impressora, corta papel, cola etiqueta... e lá vai história! Tudo isso dentro do escritório, pois o próximo passo era arrumar as malas de roupa e de hardware e pegar a estrada para o projeto piloto.

Pegando a estrada

Com o protótipo pronto, alugamos um carro e caímos na estrada. Fomos na frente, conhecer o ambiente, e depois chegaria o time operacional para instalação dos equipamentos e conexões elétricas.

Foram mais de 10 horas de viagem, com muito Jelly Bean na jogada! Uma verdadeira road trip da tecnologia.

Chegamos no hotel exaustos naquele dia, mas lembro que "arrumamos" os equipamentos em cima de uma bancada que tinha no hotel, conectamos as coisas e fomos fazer alguns últimos testes antes de iniciar a semana de implantação. Seria vários dias, para entender os locais mais adequados para posicionar as antenas, testar o software, conexões, integrações e teste em ambiente real.

Em pouco tempo o quarto do hotel parecia um cenário de guerra, com tudo espalhado, cheio de fio, equipamento e etiquetas!

No dia seguinte, acordamos cedo e fomos direto para o local, mais 50km de carro em estradas de barro com muitos seixos, que faziam o carro parecer que estava andando em cima de uma chuva de bolas de gude, deslizando a toda hora.

Chegamos, ambiente Industrial.

Ambiente industrial, com todos os desafios para os quais nos planejamos e chegamos preparados.

Agora era hora de tirar tudo de dentro do carro, parecia uma mudança. Fomos até o galpão onde faríamos o projeto piloto. Estávamos conhecendo o processo pessoalmente, observando por quais esteiras as uvas passavam. E, nesse local, precisávamos usar um traje especial.

E aos poucos, juntamente com o time operacional, fomos fixando as leitoras e antenas, nos locais apropriados para uma boa leitura das uvas que iriam passar pelas esteiras em diferentres fases do processo, cada uma com a sua etiqueta RFID.

A FX500 ficou em um quadro, com os cabos das antenas saindo pela passagem lateral, para que fossem posicionadas na esteira.

Já a RD11320 ficou em uma configuração fixada abaixo da AN400.

Tudo fixado e ligado, agora era a hora de distribuir as tags de controle nas uvas teste.

Ok! Depois de muito trabalho e análise, as coisas estão no lugar. Elétrica ok, agora precisamos testar o software no ambiente real, e é claro que "na prática a teoria é diferente".

O BUG! 🐞

Quando abrimos o software principal que controlava as leitoras juntamente com as antenas. Percebemos um comportamento inesperado, e é daquele tipo de problema que você só consegue identificar em ambiente real.

Era oficial, tínhamos um bug!

No SDK da Motorola para leitores RFID, existia um loop principal que era a estrutura central responsável por monitorar continuamente o ambiente e capturar as tags RFID detectadas pelas antenas. Esse loop operava de forma intermitente, o que significa que ele ficava em execução constante, realizando leituras sucessivas das tags dentro do alcance do leitor.

O software primeiro inicializava o leitor e configurava os parâmetros de leitura, como frequência, potência da antena e protocolos suportados.

O loop principal rodava indefinidamente, chamando funções da API para realizar leituras de forma recorrente. A cada iteração:

• O leitor enviava sinais de rádio para estimular as tags RFID dentro de sua área de cobertura.
• As tags respondiam com suas identificações únicas (EPC – Electronic Product Code).
• O software capturava essas respostas e armazenava os dados em uma estrutura de controle.

A API fornecia mecanismos para notificar eventos também, como: nova tag detectada, erro de leitura, e outros.

O bug estava nessa estrutura, que, além de tudo, tornava a personalização do comportamento bastante complexa. O código interno do SDK era rigidamente fechado para extensões, contrariando o princípio Open/Closed (OCP) do SOLID. Por isso, precisávamos utilizar a estrutura exatamente como foi criada, sem muita flexibilidade, o que tornava a resolução do problema ainda mais desafiador.

Esse erro ocorria ocasionalmente, em situações específicas, como quando uma uva permanecia por muito tempo sob a antena e o leitor também capturava uma uva na esteira ao lado, ou quando duas ou mais uvas passavam simultaneamente sob a leitora e outras duas ou mais estavam na esteira vizinha. Era um problema desafiador. Embora soubéssemos que, sendo um projeto piloto criado do zero para uma necessidade exclusiva, alguns erros seriam inevitáveis, ainda assim era frustrante vê-los acontecer. Esses momentos exigiam inteligência emocional.

O bug fazia com que o loop principal ficasse travado, o código ficava em um estado onde não processava corretamente novas leituras.

Também causava:

Sobrecarga de eventos: O sistema gerava eventos repetidos devido a leituras sucessivas sem um controle adequado.

Problemas de concorrência: Se múltiplas threads estivessem tentando acessar os dados ao mesmo tempo, podia ocorrer um comportamento inesperado.

Timeouts ou buffers cheios: Se muitas tags fossem detectadas simultaneamente, o leitor poderia sobrecarregar e não processar corretamente os eventos.

E aqui tínhamos o nosso ponto de virada!

Uma experiência que estava sendo incrívelmente satisfatória, começava a se tornar incrivelmente frustrante. Naquele dia coletamos todos os dados que podíamos e ao final do expediente da industria, fomos direto para o hotel encontrar uma forma de resolver o problema. Lembro que naquela noite, dormimos em cima dos computadores, acordamos pela manhã com os primeiros raios de sol entrando na varanda do quarto de hotel. Um banho quente e pé na estrada, pois o dia na industria começa cedo. Mais um dia de testes, debug, alterações no código, volta para o hotel, vira a noite, tira um cochilo e tudo novamente.

A semana tinha chegado ao fim, seria a hora de voltarmos, mas a missão ainda não estava cumprida, e o clima de frustração no ar era estonteante. Lembro que Mota ofereceu que eu e André voltássemos de avião, e ele ficaria por lá para resolver sozinho. Foi muita cortesia da parte dele, mas nós não aceitaríamos, chegamos lá todos juntos e voltaríamos todos juntos.

Era a primeira vez que eu viajava a trabalho, e a sensação de estar longe de casa, longe da minha namorada (que hoje é minha esposa), somada à frustração de ver um projeto dando errado, era horrível. Até então, não havia existido um projeto que esse time não conseguisse resolver, nem um problema que não pudesse ser superado.

Nesse dia, lembro de sentar em um batente de cimento na porta do galpão e dizer: "Não vai dar, não sei como resolver", foi um breve momento de desespero até que André chegou perto e me fez algumas perguntas:

• Quem fez o planejamento desse projeto todo?

E eu respondi:

-- Fomos nós 3

• E quem foi que escolheu os equipamentos, e desenvolveu do zero todo o código?

Mais uma vez eu respondi em alto e bom tom:

-- Fomos nós 3

E a ultima pergunta veio:

• E quem é que pode resolver esse problema se não nós?

Clareza mental! Pronto! Entendi! Talvez pareça óbvio, mas são justamente esses momentos óbvios que nos trazem reflexões profundas. A partir daquele instante, nossa mentalidade mudou completamente. Foi como os antigos tambores de guerra, reacendendo o espírito dos guerreiros. Era final de semana, e continuávamos trabalhando na solução. No hotel, cada um implementava algo e compartilhava sua linha de raciocínio com os outros, até que conseguíssemos chegar a uma síntese.

A boa convivência entre o time foi essencial para solucionar esse problema, todos estavam focados como grupo, não existia competição, só objetivo.

E nos dias seguintes, depois de muito trabalho em equipe, conseguimos!!! É do Brasil!!! O bug tava resolvido!!

A solução envolveu vários fatores, como por exemplo:

• Criar uma fila de processsamento, usar uma estrutura de fila (FIFO) para armazenar eventos de leitura e processá-los sequencialmente, evitando sobrecarga dos eventos e travamento do loop.
• Diminuir a frequência de leitura e o range da potência do leitor para evitar detecção excessiva em cenários onde tags de esteiras paralelas fossem capturadas.
• Criar um cache de leituras ativas, armazenando EPCs detectados recentemente e descartando duplicações dentro de um intervalo de tempo definido.
• Criar logs mais sofisticados para identificar falhas e ajustar os parâmetros do leitor conforme necessário.

Voltamos no dia útil pós final de semana e atualizamos o software das unidades de leitura, a missão estava cumprida!

Aprendizados

O conhecimento que adquiri nessa experiência foi muito além do técnico — foi um aprendizado para a vida e para a carreira.

Poderia citar que:

• Mesmo que você planeje uma situação do zero ao cem, sempre existe a chance de algo dar errado — e tudo bem. Quando temos um perfil controlador e acreditamos estar no comando das situações da vida, tendemos a sofrer mais quando as coisas não saem como esperado. As experiências adversas estão aí para nos trazer aprendizados inesperados, forjando novas habilidades de improviso e pensamento crítico para a resolução de problemas em momentos de crise.
• A amizade é um alicerce poderoso para a conquista de grandes objetivos. Em um bom time, sempre haverá pessoas com habilidades diferentes, mas quando cada um entende seu papel e utiliza suas competências para fortalecer o grupo, o time se torna coeso, sem disputas por destaque individual. Fazendo uma analogia com o corpo humano: todas as células precisam trabalhar juntas para manter a homeostase do organismo. Se uma célula passa a agir de forma descontrolada, pode se tornar um câncer, comprometendo todo o sistema.
• Em momentos de crise, o controle emocional será mais eficiente do que potência mental, porque com isso, você consegue ficar no centro, e trazer todos para o centro, lugar no qual precisamos estar para resolver problemas em momentos de crise.
• Por último, mas não menos importante, é essencial ter devoção ao conhecimento e estar sempre disposto a aprender com os outros. Se você não se mantiver estudando, não terá como contribuir nos momentos necessários. E se não estiver aberto para aprender, perderá a oportunidade de adquirir um conhecimento que só outra pessoa pode te transmitir.

Para ser um profissional experiente, é necessário passar por muitas experiências

Essa experiência com certeza, foi e será sempre uma referência interna, quando eu precisar de inspiração e achar que não consigo resolver algo.

Obrigado pelos bons momentos, onde o trabalho sempre fez sentido, André e Mota!