Oi, eu sou o Edu!
O tema deste post surgiu a partir de um comentário que li sobre o conteúdo da publicação de uma vaga de desenvolvedor nível Sênior, onde - ao contrário do que costumamos ver normalmente - não exigia-se nenhum tempo de experiência para os requisitos apresentados.
Ao invés de declarar algo como "Mínimo de 5 anos atuando com a linguagem XPTO", "Pelo menos 3 anos de experiência com banco de dados relacional XYZ", e outras coisas do tipo, a descrição dos requisitos era mais objetiva, apresentando cada um apenas como "Experiência com a linguagem XPTO", "Experiência com banco de dados relacional (XYZ)", etc.
A descrição dos requisitos - uma lista não tão pequena, porém sucinta - gerou o seguinte comentário: "Achei interessante a diferença [em relação ao nível de desenvolvedor] ser nos requisitos técnicos em vez de tempo de experiência".
De fato, o que vemos com frequência (principalmente em vagas que pedem nível de experiência mais avançado, como Sênior, por exemplo), é a especificação de um "tempo mínimo de experiência requerido" - normalmente em anos. Por isso a surpresa do amigo que fez o comentário no nosso grupo do Whats.
O comentário dele, embora não direcionado a mim, acabou chamando minha atenção, e então achei por bem dar minha opinião sobre o tema. E, como algumas pessoas que leram o que escrevi entenderam que aquilo poderia gerar um bom tema para discussão, resolvi trazer aqui a essência do que escrevi lá - não está escrito exatamente da mesma forma porque aqui tive um pouco mais de tempo para revisar o texto, mas ele dizia basicamente o seguinte:
Normalmente quando escrevem sobre "ter experiência com algo", seja uma linguagem, ferramenta ou tecnologia, entende-se "ter vivência em projetos reais" - então fica meio que implícito o "tempo mínimo de experiência", considerando ser bem incomum encontrarmos um dev com 2, 3 anos de experiência que já tenha atuado em projetos que fizeram uso de todos os recursos detalhados na vaga (que apresentava, entre outros, os seguintes itens: experiência com C# e .NET Core, experiência com banco de dados relacional - SQL Server ou PostgreSQL, experiência com banco de dados não relacional - MongoDB, Cosmos ou Atlas, experiência com Git e Git Flow, experiência na construção de testes unitários automatizados, experiência com design patterns - singleton, factory, strategy, etc, experiência em clean code, conhecimentos de arquitetura básica e seus princípios - SOLID, ACID, conhecimentos em CI/CD, metodologias ágeis e estruturas de dados, e por aí vai...).
E, aproveitando o gancho - do assunto em questão, mas também de alguns memes e comentários que havia visto recentemente, sobre a diferença entre o que era exigido em uma entrevista, e o que o dev teria que lidar no dia-a-dia de trabalho, complementei:
Eu mesmo não tive tanta vivência em projetos que exigiam tal nível de conhecimento (considerando o tempo que estou trabalhando na área - quase 30 anos!), porque a maioria dos projetos onde atuei - em empresas dos mais diversos portes e segmentos - não ia muito além de CRUD's, arquiteturas mais básicas, uma ou outra regra de negócio mais complexa, e a preocupação em gerar relatórios e consultas com grande volume de dados de forma a não impactar no I/O das transações no banco relacional.
De vez em quando acaba aparecendo algo mais diferentão - um ETL aqui, uma Máquina de Estado ali, uma integração com API's e Webservices de Terceiros (que normalmente não têm suporte a JSON, só a XML, e com documentação porca), troca de arquivos TXT via FTP, implementação de cache ou messageria... mas, em geral, não passa muito disso não.
Projetos que fazem uso de Arquitetura Hexagonal, CQRS, e outras coisas mais complexas, como Microsserviços, são bem mais difíceis de aparecer... primeiro, porque na maioria das vezes trazer este nível de complexidade vai significar construir um canhão para matar uma mosca - por que construir algo usando a arquitetura da Netflix, por exemplo, se o consumo da aplicação será equivalente ao volume de um Pluto TV da vida (e olhe lá)? Brincadeiras à parte, esse nível de complexidade dentro de um projeto acarreta em custos bastante altos - Infraestrutura, pessoal especializado, recursos para monitoramento, etc. Segundo, porque na imensa maioria dos casos, seremos alocados em projetos existentes (os famigerados legados) e que não nasceram fazendo uso da tecnologia mais atual ou o hype do momento. Como vocês devem saber, em pleno 2022 ainda tem muita empresa com projetos rodando - e atendendo as necessidades delas - em PHP, ASP Clássico, VB, Delphi... até Java! (hahahahaha, tô brincando, mas não podia perder a piada! rsrsrs)
MAS... isso não quer dizer que devemos ficar apenas no feijão-com-arroz - é bom conhecer coisas novas, o que o mercado está usando, outros tipos de linguagem, arquiteturas que vão além do padrão MVC, boas práticas de programação como Clean Code, os principais Design Patterns, etc... porque quando a oportunidade aparecer, poderemos bater no peito e dizer "eu conheço esse assunto aí, embora nunca tenha trabalhado num projeto que demandasse a implementação dele, mas deixa comigo que eu desenrolo", sem medo de ser feliz!
(É por isso também que tô sempre buscando algo novo para aprender - agora, por exemplo, estou estudando para conhecer mais a fundo tudo o que a Cloud da AWS oferece, além de um pouco de Flutter e K8s...)
Bom, o que eu quis passar naquela resposta (e aqui), e para qualquer dev (principalmente aqueles iniciantes que se sentem inseguros, achando que nunca terão capacidade para aprender tanta coisa) é que o único jeito de adquirir experiência é colocando a mão na massa, atuando em projetos reais, lidando com problemas reais, batendo cabeça (não no sentido literal, por favor), aprendendo que nem tudo o que vemos na teoria se aplica na prática, o que o que usamos pra resolver no projeto X não se aplica no projeto Y... e que isso leva tempo - não é algo que seja possível condensar num sprint, num bootcamp de 12 semanas! E, como dizem, tá tudo bem!
É isso... como sempre, comentários, críticas e sugestões são sempre bem-vindos! Escrevam, será bacana discutir esse assunto com vocês.
Grande abraço, e até a próxima!
Oldest comments (0)