Opa, eu estou aqui para falar do seu processo de evolução, e sua rede de apoio.
É difícil estar sozinho
Se você planeja começar um projeto .NET do zero, ou evoluir um projeto .NET em 2023, você certamente tem dificuldade tomar boas decisões técnicas.
São novas ferramentas, tecnologias, padrões em que para cada um dos assuntos você se questiona:
Será que faz sentido nesse contexto?
Nesse time?
Nesse projeto?
Com essa demanda?
Em algum momento você esbarrará em algumas dessas restrições:
- Orçamento
- Tempo
- Equipe/Empresa/Recursos
Como se não bastasse essa complexidade, ainda temos de garantir que o produto esteja alinhado com as expectativas da empresa.
Aqui estou falando de qualidade e longevidade.
Afinal, será que estamos tratando de uma PoC que será substituída por um projeto definitivo, ou estamos falando de um projeto que nasceu para evoluir e sua base de código precisa durar?
Nem sempre você encontra o que foi buscar
Se você faz uma pergunta em um grupo, na maior parte das vezes ou te respondem: — Depende!
Mas depende do quê?
Ou te dão um feedback enviesado, sem profundidade, baseado em gostos pessoais e não em critérios lógicos.
Também há a falta de disponibilidade
Aposto que para você, deve ser difícil tomar decisões, comigo não foi diferente, eu vivi a solidão de estar na frente das decisões técnicas, sozinho.
Errar é uma certeza
Errar é uma certeza, então erre pouco. Tome decisões que facilitem a correção. Traga padrões e soluções que ao menos não dificultem a solução.
Já tomei decisões, que com o tempo, se mostraram erradas, mesmo sendo exaustivamente validadas com o time na época em que foram tomadas. Essa validação não foi o suficiente para evitar o fracasso.
Isso aconteceu com uma decisão que tomei lá em 2012. Ponderei muito e cheguei à conclusão de que a melhor ideia era adotar SPA para uma aplicação que nascia lá em 2012.
Era um ERP interno para 3 mil funcionários de uma consultoria de TI carioca.
O time validou e aceitou a ideia de um framework em específico e peso de trabalhar muito javascript, sem nenhuma objeção, mas no dia-a-dia, durante o projeto, não funcionou.
O framework escolhido era lindo, dava para criar coisas incríveis, encaixava como uma luva com o negócio, dava para fazer tudo que o cliente pedia, mas a complexidade cobrava um preço alto demais.
As coisas simples, eram feitas com alguma dificuldade, mas tudo que fugia ao simples era conduzido com enorme dificuldade.
A aplicação exigia muito banco por conta dos tipos de consolidações e tinha limitações em relação às tecnologias que poderiam ser adotadas nela.
Era um típico caso para a adoção de MongoDB em algumas partes, mas fui obrigado a usar SQL Server para tudo. Meu servidor de banco era um servidor compartilhado com outras dezenas de aplicações e era bem complexo extrair mais desempenho.
Redis também daria uma paz para essa aplicação, mas também estava restrito e limitado.
Enfim, trabalhar com essas restrições limitou muito as opções.
Essa era uma das 10 telas que justificavam a complexidade de um SPA.
Essas telas faziam parte do coração do sistema, cada uma atendendo um perfil de usuário diferente, desde o colaborador até todos os níveis de gestão, inclusive a diretoria.
Esses casos de uso eram herdados de soluções desktop, com interfaces ricas e complexas.
Essa tela acima era o ponto central do planejamento financeiro de centro de custo, e cada célula dessa grid era produto de uma lista grande de itens, que precisava ser editável, tanto inline quanto em um popup detalhado.
Fora o controle de acesso, capacidade de delegar parcialmente acessos a um determinado centro de custo.
Enfim, era uma aplicação com um domínio bem complexo.
Ouvir não é uma habilidade desenvolvida…
Aposto que você tem dificuldades de encontrar quem esteja disposto a entrar no seu mundo, fazer as perguntas pertinentes, entender com clareza ao contexto, para daí propor.
Ou mesmo validar as suas soluções.
Ou que ao menos mostre quais variáreis importam e quais variáveis são irrelevantes.
Nossos fantasmas
Somos mestres em criar fantasmas:
É tão comum acharmos que variáveis importantes, não fazem diferença,
e acharmos que variáveis pouco importantes, mudam tudo.
Esses fantasmas nos ocupam com o que é pouco relevante, em detrimento do que é relevante.
Como se não bastasse, o mercado mudou!
De 2002 até hoje a principal diferença é a quantidade de opções. Elas cresceram exponencialmente.
Novos padrões, novos patterns, novas arquiteturas e consigo novos tradeoffs.
Na busca por me manter atualizado, ajudei muita gente. Dediquei o tanto a ajudar outros desenvolvedores, o tanto quando dediquei a programar.
Aqui trago depoimentos de 2005, de outros devs que ajudei na época. Essa pegada de ajudar, sempre esteve comigo, porque a forma como eu tento entender cada assunto, me permite ajudar com mais facilidade.
Assim, sempre que entrava em um novo cliente, um novo time, para recuperar esses projetos, eu percebia as mesmas dificuldades.
Ao fazer isso inúmeras vezes, identifiquei padrões, desenvolvi estratégias, e evoluí com a didática, encontrei formas de digerir a complexidade de assuntos complexos.
Todo tema complexo, tem um jeito fácil de ser explicado!
Além do tempo e espaço
E resolvi trazer essa experiência para a internet.
E eliminar a limitação física, do espaço ao qual eu estava trabalhando:
- o projeto onde eu estava
- o time
- a empresa
- a cidade
- o país
E passar a ajudar em qualquer lugar.
E também eliminar a limitação de tempo, já que eu não precisaria falar as mesmas coisas e tocar nos mesmos assuntos muitas vezes.
A internet possibilitou que ao invés de falar para 5, 10, 15 pessoas por vez, apenas aqueles que trabalhavam comigo.
Pudesse falar para 100, 1.000, 10.000, pessoas, assincronamente.
Mesmo que não fosse ao vivo, mas que ao longo dos meses, anos, décadas, pudesse alcançar mais e mais gente.
Sem precisar repetir as mesmas coisas, me permitiria avançar em novos temas, e falar bem sobre cada um, algumas poucas vezes, para otimizar o tempo.
Mas descobri que não bastava criar posts no meu site, ou vídeos e lives no YouTube. As pessoas ainda tinham dúvidas, por mais detalhado que fosse cada assunto.
Quando projetei o Cloud Native .NET, ainda com outro nome, eu pensei nesse dia-a-dia que vivi, pensei nos meus amigos e colegas de trabalho que ajudei ao longo dos anos. Pensei nos projetos e problemas que corrigi nos últimos anos.
E na dificuldade que é assistir um conteúdo sobre um tema complexo ou novo e criar seus próprios fantasmas sobre um determinado assunto.
É tão comum interpretar coisas que não foram ditas, nem escritas, muito menos, lidas ou escutadas, e ainda assim gerar confusão.
Esse fenômeno é cada vez mais comum.
E a facilidade com que se encontra conteúdos superficiais, que te induzem ao erro, por pura e simples negligência é enorme.
Foi com base nessa história, ajudando times e projetos, com base na minha percepção sobre a produção de conteúdo, com base nessa visão de mercado e arquitetura que resolvi criar esse espaço, que chamo de INSIDE.
Como uma alusão ao lado de dentro, repleta de respostas para inúmeras perguntas, e principalmente para perguntas que ainda estão à frente na jornada, repleta de assuntos e temas que te ajudarão na jornada de amadurecimento e profissionalização das soluções dadas pelo desenvolvedor. Seja ele um desenvolvedor sênior, um líder técnico ou um arquiteto.
Sem conhecer muito bem os formatos disponíveis no mercado, eu optei em 2019 pelo que descobri mais tarde se chamar CURSORIA:
Uma fusão dos formatos Curso e Mentoria.
Isso porque acredito que por melhor que seja a produção, o roteiro, o conteúdo, esses fantasmas aparecem e fazem parecer que seu problema, é igual ao do conteúdo, quando não é. Da mesma forma que faz parecer diferente, quando não é.
E às vezes a compreensão está no detalhe que passou despercebido.
Porque era isso que eu fazia com as os desenvolvedores que precisavam de ajuda, eu ensinava (e agora posso multiplicar meu tempo gravando o que eu ensinaria do teu lado).
Agora eu posso apenas lapidar o entendimento, escolhendo a melhor explicação, a melhor abordagem, sem limite de tempo, para explicar um assunto. E lapidar ao vivo, seja no grupo, seja na mentoria.
Assim consigo validar sua implementação, e te ajudar com seu projeto, com dicas, com melhorias, com pontos de atenção. Tornando esse conhecimento em algo prático.
Foi assim que criei o Cloud Native .NET, para ajudar Desenvolvedores Seniores, Lideres técnicos e Arquitetos do universo Microsoft, principalmente ligados ao .NET que tomam ou precisarão tomar decisões técnicas significativas.
Esse é um espaço para a resolução de problema, compartilhamento de percepções, análises, vagas, trocas de experiência e principalmente: APOIO.
É um espaço onde você tem o meu apoio, o tempo todo em que estou online.
Isso se traduz em mais de 90% das mensagens respondidas em menos de 5 minutos. Mais rápido do que se estivéssemos trabalhando na mesma empresa.
A mentoria do Cloud Native .NET traz consigo como conteúdo de apoio a formação Cloud Native .NET e o Mensageria .NET.
Além disso, alunos de algum dos 2 programas, só pagam a diferença no primeiro ciclo.
A mentoria conta com 2 camadas de Suporte: Reuniões a cada 15 dias no Zoom, e suporte integral no Telegram.
Como Funciona?
Passo 1 – Preenchimento da Aplicação
Ao clicar no botão você será redirecionado para um formulário de aplicação. Tenha em mãos o endereço do seu perfil do LinkedIn e faça o preenchimento da aplicação.
Passo 2 – Avaliação do Perfil
As perguntas realizadas no formulário ajudam a entender em que fase da carreira você está e a aderência ao programa. Se tudo estiver ok, em alguns dias entramos em contato.
Passo 3 – Call
Se tudo estiver ok, marcamos uma ligação de alinhamento, finalizamos o processo de pagamento e liberamos os acesso.
Seu Ingresso na Mentoria – Você está dentro!
Assim que o pagamento for confirmado, seus acessos são liberados imediatamente e você já poderá usar todos os recursos da mentoria. No grupo do telegram, você tem acesso ao mentor. Os acessos aos recursos são liberados em seguida e você agora têm acesso às formações.
0 comentários