Sendo um engenheiro de software profissional

Introdução

Quer dizer então que você quer ser um profissional e entregar melhores resultados? Quer subir no alto do Empire Estates e declarar para o mundo: "Eu sou um programador foda!"?

Certo, não tem problemas, mas... Cuidado com o que você almeja, pode ser que isso signifique muito mais do que você pensa!

Não seja "O Herói"

Desenvolvimento de software é uma tarefa colaborativa realizada em equipe, a dependência exclusiva de um único profissional pode ser prejudicial para o projeto.

Além disso, promover a ideia de super programadores individuais acaba diminuindo o valor do trabalho em equipe.

Particularmente falando, acredito que todo dev que quer ser herói, na verdade quer aumentar sua própria reputação achando que isso o torna "especial" ou que vai receber louros por ser herói, mas não vai! O que provavelmente vai ocorrer é um bournout, sempre que tiver problema vão chamar quem? O Herói! Sempre que der B.O., vão chamar quem? O Herói! E se der algum problema? O culpado será o herói!

Além disso, na tentativa de aumentar a própria reputação, os heróis acabam negligenciando suas responsabilidades, podendo assim se tornar herói no desenvolvimento e vilão na produção.

Imagine que uma das responsabilidades seria realizar testes, na ânsia de se tornar especial, você não vai querer testar, fará isso para entregar em menos tempo, no futuro essa economia de tempo será traduzida em transtorno e dor de cabeça!

Teste, teste e teste

Sabemos que é praticamente impossível criar um software isento de bugs, mas isso não significa que você deva deixar de se preocupar com eles.

Na verdade, é justamente devido a eles existirem que cabe ao profissional o dever de assumir a auto-responsabilidade de escrever o melhor algoritmo possível!

Profissionais devem testar suas aplicações antes de enviarem ao QA, a função dele pode até ser ficar relatando os bugs que foram encontrados, mas a falta de profissionalismo dos desenvolvedores pode acarretar em atrasos em cronogramas e a diminuição na confiabilidade do código, lembre-se que um QA faz diversos testes (por exemplo: usabilidade, sobrecarga) e ao final é escrito um relatório, isso pode gerar demissões devido a falta de profissionalismo dos programadores.

Ressalto que os testes ainda são necessários para saber se o trabalho realizado cumpre com os requisitos, isto é, precisam saber se está funcionando conforme o esperado.

É extremamente benéfico uma equipe ter 100% de coverage com testes automatizados de unidade e integração, eles podem ser executada de forma rápida, o que garante segurança para mudanças e refatorações futuras.

Seu dever (e obrigação pessoal)

Pense comigo: se a carreira é sua, de quem é a responsabilidade? Bem, com certeza não é do seu chefe, não é ele quem tem que qualificar você... Empregadores não tem nenhuma obrigação de ficar bancando conferências, livros e cursos (na pandemia tinha muito disso pois tinha muita grana rolando, agora, de volta a realidade). Essas coisas agregam a sua carreira e devem ser sua responsabilidade.

É ótimo existirem empresas que fazem isso por nós, mas isso é muito mais um favor do que dever deles.

Também não faz parte da responsabilidade do seu empregador fornecer o tempo que você precisa para aprender, você já tem que entrar sabendo ou aprender fora do horário de expediente.

Mas você aí vai dizer: não tenho tempo! Então, vamos fazer algumas contas - uma semana tem 168 horas, se você dormir 56 horas e trabalhar 40 horas na semana, ainda sobram 72 horas, considerando que você tem família, acho que você poderia pegar pelo menos 10 horas na semana e se aperfeiçoar (se puder mais, pegue mais), essas 10 ou mais horas não são para seu chefe, é para sua carreira, para sua profissionalização.

Conheça sua área

Você sabe POO? Sabe DSA? É capaz de implementar uma DS Priority Queue sem colar? Domina DDD? É capaz de realizar uma consulta SQL? Conhece as implicações da lei de Moore?

Se não sabe a resposta para as perguntas, não sabe por quê?

Nossa área existe a mais de 100 anos, existe uma riqueza de conhecimento técnico/científico que poderia te agregar muito profissionalmente.

Como Bob disse: "Se quiser ser um profissional, deve saber uma fatia considerável de sua área e aumentar constantemente o tamanho dessa fatia.".

Minha lista pessoal de requisitos mínimos que todo engenheiro de software deve ser proficiente:

• Programação: Data Structures and Algorithms (DSA), POO, Test Development Drive;
• Metodologias: Scrum, XP, Lean e Kanban.
• Artefatos: UML, MER DER.

Vale a pena ler a lista do Uncle Bob no livro "The Clean Coder".

Aprendizado guiado pela prática

Um lema que eu sigo é o LLL (Longest life learning) significa algo como "Uma vida de aprendizados" ou "Uma vida aprendendo". Sigo esse lema devido à nossa indústria passar por mudanças de uma forma constante, e sério, se você ficar 6 meses sem estudar, quando voltar muita coisa pode ter mudado, além disso, uma pessoa que decida parar de estudar com toda certeza vai ser atropelada pelo mercado.

Além de estudar muito, você precisa praticar o que está sendo estudado, precisa ficar afiando suas habilidades para quando precisar utilizá-las elas já estarem "prontas".

Conclusão

Essa é a primeira parte do que eu acho que é essencial um programador ter em mente se quiser ser um profissional, pode ser que você não veja da mesma forma e está tudo bem, mas depois não reclame de ser uma pessoa fácilmente substituível dentro da organização que você trabalha.

Vale eu fazer uma sugestão de leitura aqui, recomendo o livro "The Clean Coder" do Uncle Bob, vale a pena pois ele mostra a visão dele do que é necessário e eu me basiei um pouco no livro para escrever essa publicação com minhas próprias palavras!

Referências

The Clean Coder