Hoje vou voltar num tema que não tenho abordado ultimamente: carreira. As coisas mudaram muito nos últimos anos. Onde existiam carreiras orientadas a servidor e a uma única linguagem, em que todo o conteúdo, inclusive o front, era produzido no servidor estão agora carreiras separadas e – ao olho não treinado – desconexas. Hoje temos carreiras nos chamados “back end” , “front end” e “full stack” mas temos também coisas “novas” como devops, secdevops além de clássicos como analista e tester. Antes todas estas carreiras eram uma só. Hoje temos uma explosão de especialidades. O que trás a especialidade ? um aprofundamento naquela área de atuação. Qual é o problema disso ? Desconhecimento sobre as outras áreas.
No meio desta Torre de Babel as pessoas não se comunicam corretamente. Formam-se nichos e bolhas, tanto de conhecimento, como de ideologia. Quem perde com tudo isto é a profissão.
Criou-se essa falsa ideia de que não há o certo, que tudo vale e que tudo é justificável, ou pior, que nada precisa ser justificado pois todas as decisões são igualmente equivalentes e boas. Nada poderia ser mais longe da verdade. Talvez não haja uma decisão certas em todos os cenários, mas com certeza há decisões erradas na maior parte dos cenários. Saber distinguir as decisões sempre erradas já é uma ajuda a nos aproximarmos de uma que seja certa para aquele cenário.
A meu ver, o primeiro entrave a compreender a carreira da pessoa que faz software é não conhecer e distinguir a nuances entre as várias disciplinas que a compõem. Então, hoje, vou falar um pouco sobre essas disciplinas tentando esmiuçar dos seus vários estágios e concluir em como isso é importante para a sua Carreira.
Comecemos pelo principio. Tudo o que um artífice de software (Software craftsperson) faz, têm como base saber programar. Podemos ser tentados a dizer que QA não precisa saber programar, só clicar nas telas do sistema. Ou que os scritps de devops não podem ser chamados de “programação”, mas isso tudo são asneiras. Programar implica entender que instruções estão sendo dadas ao computador e existe uma ordem lógica das coisas.
Pensar que uma pessoa pode ter uma carreira em qualquer área de software sem saber programar é como pensar que a pessoa pode ser médico sem saber ler ou escrever. Pode ser possível, mas é muito mais difícil. Tão difícil que não permite um grau de excelência que seria possível se a pessoa soubesse ler e escrever.
Mas, existem alguns movimentos que parecem contradizer esta necessidade. Hoje em dia vemos pessoas que não sabem programar e que apenas colam bibliotecas que encontram na internet para formar novos programas. E embora pareça haver uma vantagem aqui de velocidade, é um inferno de dependências e problemas. A pessoa sabe que funciona, mas não por quê. E quando há problemas, é um problema entender onde está causa, e um inferno tentar resolvê-la no código dos outros. Contudo, mesmo nestes casos. para manter esta quimera de bibliotecas funcionando a longo prazo, é necessário saber programar para manter todas estas dependências integradas corretamente, então mesmo quando se evita programar, tem que se saber programar, e poderia até argumentar que apenas que é um exímio programador sabe transformar estas quimeras em ecossistemas sustentáveis.
Bom, então o que é programação ? Em termos simples é instruir o computador a realizar tarefas através de instruções escritas no que chamamos de código. Código são palavra em arquivos que são usadas de uma forma estruturada para instruir o computador. As palavras, sua ordem e significado é ditado pela Linguagem de Programação sendo usada. E há muitas. Muitas mesmo. Neste artigo vou me resumir a sistemas mais virados para o mundo corporativo, mas há linguagens para todo o tipo de computadores.
Saber programar não implica apenas instruir o computador, mas escrever o código de forma que seja inteligível a outras pessoas.
Ser exímio em programação é como ser um exímio escritor de livros. Não basta saber escrever palavras em ordem e formar frases. As frases têm que ter sentido e ser entendíveis por quem lê – tanto o computador como os humanos. As palavras têm que ser escolhidas para transmitir nuances e conhecimento se forma sucinta, mas não tão resumida que torne a mensagem obscura e ininteligível.
Podemos classificar uma pessoa pela sua competência em programação pela forma como escreve o código e tem sucesso em instruir o computador.
0 – A pessoa não consegue entender código, nem escrever código e nem instruir o computador a fazer o que ela quer. Uma boa fatia da população está neste nível.
1- A pessoa consegue entender código, mas não escrevê-lo ou instruir o computador.
2 – A pessoa consegue entender código, e compor excertos de código pré-feitos, para formar um código maior, mas tem dificuldade em entender exatamente como aquele código instrui o computador. Este estágio é comumente chamado de “copy-paste programming”.
3 – A pessoa consegue entender o código e escrever código de forma a instruir o computador a realizar o que quer, mas não de uma forma otimizada, nem em número de instruções, performance ou organização do código escrito. Este é um nível em que os programas funcionam, mas são mal organizados. É o nível característico de pessoas juniores em programação.
4 – A pessoa consegue entender e escrever o código de forma que instrui computador e de uma forma sucinta e organizada, mas não necessariamente performática ou com baixa complexidade.
5 – A pessoa consegue entender e escrever o código de forma sucinta e organizada e de forma que performática usando corretamente o SDK disponível e utilizar de forma simples conceitos avançados como Threads e análise complexidade. A pessoa utiliza alguns Design Patterns para organizar seu código, documentar responsabilidades de cada parte do código e transmitir informação a quem lê o código
6 – A pessoa consegue entender, escreve e organizar código de forma a ser compreensível tanto ao computador quanto a outras pessoas, tirando partido do SDK e de conceitos avançados. A pessoa utiliza Princípios e Design Patterns para guiar a organização do código, documentar responsabilidades de cada parte do código e transmitir informação a quem lê o código.
7 – A pessoa consegue, de forma exímia, entender, escreve e organizar código de forma a ser compreensível tanto ao computador quanto a outras pessoas, tirando partido do SDK e de conceitos avançados. A pessoa sempre utiliza Princípios e Design Patterns para guiar a organização do código, documentar responsabilidades de cada parte do código e transmitir informação a quem lê o código.
Programar, significa escrever. E todas as regras que se aplicam a escrita em geral, se aplicação à programação. Coisas como formatar textos, usar a pontuação correta, saber a diferença entre substantivos, verbos , adjetivos e advérbios, entender o que é linguagem técnica e o que é linguagem não-técnica são traços comuns a programadores e escritores.
Mas saber escrever é diferente de saber o quê escrever. Uma coisa é instruir o computador, outra é instruir o computador a fazer coisas úteis a alguém. Escrever o código não é o mesmo que escrever o software. O software implica essa noção de propósito das instruções, não para a máquina, mas para a pessoa que usa a máquina. Aqui entramos no reino do Desenvolvimento
Desenvolvimento tem que ver com olhar o mundo real, o que as pessoas fazem, que conceitos usam, como eles se relacionam e transportar tudo isso para o computador. Este processo é chamado Análise.
Desenvolvimento implica conhecer os conceitos que o programador conhecer, como orientação a objetos, classe, função, herança, polimorfismo, mas não necessariamente saber programá-los. Na prática é comum que um programador se torne um desenvolvedor pois da mesma forma que um escritor se torna um autor. Ele escreve as histórias que ele cria. Da mesma forma é possível que o desenvolvedor se distancie da programação e se dedique mais à análise e menos à programação. É também comum que o desenvolvedor consiga pensar o modelo do programa em abstrato e sem depender de uma linguagem de programação especifica e cabe ao programador explicitar o programa em código, naquela linguagem. Eis os estágios de um desenvolvedor
0 – A pessoas não consegue entender o mundo real, nem formar um modelo conceitual do seu funcionamento, nem criar um modelo computacional que o imite. Este é o estágio da maior parte da população.
1 – A pessoa consegue entender o mundo real, às vezes até com bastante pormenor, mas não consegue formar um modelo conceitual do seu funcionamento nem um modelo computacional que o imite. Este é o estágio do que chama em DDD, Especialistas de Domínio (Domain Experts)
2 – A pessoa consegue entender o mundo real, ou a explicação que lhe é dada e traduzir isso num modelo conceitual do seu funcionamento e das relações entre os conceitos, mas não consegue traduzir isso para um modelo computacional. Ele consegue colar alguns modelos computacionais pré-existentes e aproximar o modelo conceitual em causa. Este estágio é chamado de “Design por comparação”.
3 – A pessoa consegue entender o mundo real, ou a explicação que lhe é dada, e traduzir isso num modelo conceitual do seu funcionamento e das relações entre os conceitos, e consegue traduzir isso para um modelo computacional. Contudo ele não é suficiente abrangente. Ou seja, o modelo computacional imita o modelo conceitual e o mundo real mas não em todos os cenários de interesse.
4 – A pessoa consegue entender o mundo real, ou a explicação que lhe é dada, e traduzir isso num modelo conceitual do seu funcionamento e das relações entre os conceitos, e consegue traduzir isso para um modelo computacional que abrange todos os cenários de interesse, mas os modelos ainda não são o mais simples e eficientes possível. Alguns conceitos ainda não foram encontrados ou modelados, ou o foram de uma forma mais complexa do que necessário
5 -A pessoa consegue entender o mundo real, ou a explicação que lhe é dada, e traduzir isso num modelo conceitual do seu funcionamento e das relações entre os conceitos, e consegue traduzir isso para um modelo computacional que abrange todos os cenários de interesse. A pessoa consegue entender conceitos de modelagem mais avançados e usa alguns Design Patterns para ajudar a modelagem.
6 – A pessoa consegue obter o modelo conceitual do que lhe é explicado, traduzi-lo para um modelo computacional, descobrindo padrões nas relações e nos conceitos e aplicar Design Patterns para simplificar e documentar a modelagem. Não apenas o modelo é abrangente mas é compreensível por outros.
7 – A pessoa consegue, de forma exímia, entender o mundo real, ou a explicação que lhe é dada, e traduzir isso num modelo conceitual e computacional tirando partido de nuances e padrões existentes na própria realidade ou na forma de traduzir essa realidade em código. A pessoa se utiliza de Princípios de Modelagem e Design Patterns para organizar os seus modelos
Estes estágios referem conceitos de Orientação a Objetos (OO) porque estou me referindo a Modelagem e Programação Orientada a Objetos. Isto por que, considero, que é a forma de modelagem e programação que permite uma melhor mapeamento do mundo real. É muito mais simples modelar relações usando objetos do que funções puras. Contudo, fora do mundo OO, os estágios não são muito diferentes, salvo os ajustes necessários.
A pessoa que programa se preocupa em escrever o código da forma mais organizada e eficiente. A pessoa que desenvolve se preocupa em o quê escrever e que relação as ações do programa se relacionam com o mundo real. Se preocupa com que serviços o software oferece a quem o utiliza. Contudo, nenhum deles está realmente limitado em tempo ou outros recursos para realizar o seu trabalho. Em teoria, para o programador e o desenvolvedor todos os programas e todos os modelos são equivalentes e igualmente corretos e eficientes desde que cumpram seu objetivo face ao utilizador do programa. Ser consciente das limitações é o que forma a Engenharia.
Engenharia tem que ver com criar algo que seja ao mesmo tempo vantajoso para o utilizador e para quem está pagando pela criação. Veja que não se trata de ser vantajosos ao desenvolvedor ou ao programador, mas a quem lhes paga. Não apenas existem questões de tempo e custo, mas de qualidade de manutenção. Um modelo pode ser excelente e abrangente nos casos de interesse, mas se não pode ser evoluído, levará à extinção da empresa empregadora.
Engenharia está relacionada às propriedades da solução (modelo + código). Coisas como Reprodutibilidade, Manutenabilidade, Rapidez, Segurança, Robustez, e muitas outras. Aqui a Legibilidade do código com que o programador deve se preocupar e ser exímio ganha uma dimensão de custo. A abrangência do modelo, com que o desenvolvedor deve se preocupar e ser exímio, ganha uma dimensão de custo.
Ser engenheiro é entender que tudo tem um custo e um risco. O que é o mesmo que ter um custo agora e um custo futuro e que nem sempre podemos saber ou prever o custo futuro, mas podemos mitigar o seu impacto (custo x probabilidade de acontecer). Um modelo que abrange poucos casos de interesse e um código que executas tais casos de forma simples pode ter um custo baixo agora, mas se não forem extensíveis e manuteníveis, a evolução está cerceada e portanto o custo futuro de evolução por ser tão alto que será proibitivo e o modelo e/ou o código precisarão ser refeitos o que só irá acontecer com recursos suficientes que o primeiro modelo e código podem não ter sido capazes de gerar exatamente por serem limitados.
Então em engenharia o que procuramos não é o ponto ótimo de esforço vs benefício, mas a forma de não solidificarmos as decisões de formas que elas passem a ser constrangimentos e limitações elas mesmas. Procuramos o equilíbrio de o beneficio de agora, com o custo e o risco do futuro. Se trata de deixar a porta aberta a evoluções, com o mínimo custo possível. Eis os estágio de uma pessoa que trabalha com engenharia de software.
0 – A pessoa não é consciente ou não reconhece que toda a decisão tomada ao construir um software tem um custo presente e um custo futuro, aos quais estão associados riscos; e que toda a decisão é realizada dentro de um conjunto de limitações impostas exteriormente. Esta é a maioria da população, que também inclui muitos programadores e desenvolvedores.
1 – A pessoa consegue entender e reconhecer que existem custos, mas não consegue enumerá-los nem compará-los em grandeza. Este estágio é perigoso, porque a pessoa pode ser levada a tomar decisões erradas por não conseguir enumerar/comparar todos os custos e limitações, otimizando a solução para aqueles que ela reconhece e entende, mas não para os outros – que podem acabar sendo mais relevantes.
2 – A pessoa consegue entender e reconhecer que existem custos, riscos e limitações, mas não é capaz de comparar a sua grandeza. Este é um estágio menos perigosos que o anterior, mas ainda susceptível de falhas por motivos de não conseguir comparar os custos, riscos e limitações.
3 – A pessoa consegue entender e reconhecer que existem custos, riscos e limitações, e é capaz de comparar a sua grandeza, sem os quantificar. A pessoa tem noção de maior e menor, mas não um número exato.
4- A pessoa consegue entender e reconhecer que existem custos, riscos e limitações, e é capaz de os comparar e até quantificar, mas não aplica estes conceitos ao nível da empresa, apenas ao nível do software ou do projeto.
5 – A pessoa consegue entender e reconhecer que existem custos, riscos e limitações, e é capaz de os comparar e até quantificar e tem noção de estes custos, riscos e limitações são interconectados com outros custos, riscos e limitações fora do seu projeto e até relacionado a fatores externos ao projeto.
6 -A pessoa consegue entender e reconhecer que existem custos, riscos e limitações, e é capaz de os comparar e até quantificar com noção de fatores externos ao projeto que envolvem a empresa e os parceiros e clientes. A pessoa tem uma visão global, e consegue operar com base nisso, seguindo uma outra metodologia ou conceito de gerenciamento de custo, risco ou limitações.
7 – A pessoa é exímia a entender, reconhecer, classifica e quantificar custos, riscos e limitações provenientes de fontes internas e externas e a aplicar conceitos de metodologias para os gerenciar.
Compara a grandeza de custos , riscos e limitações não necessariamente implica em medir. às vezes basta saber estimar. Sabemos que um sistema sem controle de usuários e senha é menos seguro que um que tem esse controle. Sabemos que um sistema com encriptação de senha é mais seguro que um que não tem encriptação. Sabemos que um site usando HTTPS é mais seguro que um usando HTTP. Contudo não conseguimos colocar números para estas afirmações nem saber “quantas vezes é mais seguro”. Muitas vezes a comparação de maior e menor é suficiente sem a necessidade de saber quantas vezes maior ou menor.
Ao calcular o impacto de uma decisão – que é o custo multiplicado pela probabilidade – não temos exatamente os números mas apenas ordens de grandeza ou conceitos de maior e menor. Ter os números reais é claramente melhor, mas nem sempre é possível e tentar obtê-los pode levar a fenômeno chamado Paralise por Análise.
Aqui vou distinguir entre Teste e Experiências. Experiências são ações – simples ou complexas – que visam entender se uma solução é possível, viável ou sustentável, ou em que cenários ela é possível, viável ou sustentável. Experiências podem ser simples como rodar o sistema e ver se aparece o resultado esperado na tela ou mais complexas como realizar várias ações que têm que ser feitas em sequencia e com valores diferentes. Experiências podem evoluir para coisas mais completas e complexas como PoCs ( Provas de Conceito – Prove of Concept). Experiências são exploratórias do modelo. Testes não são isto. Testes são comprovativos do modelo.
Testes, neste conceito, significa por à prova – forma manual ou automatizada – como as premissas e caminhos escolhidos levam às conclusões desejadas. Preferivelmente de forma automatizada. O objetivo de realizar e conduzir testes pode ser variado. Com frequência pensamos em testes como forma de garantir que o software faz o que é suposto fazer em vários cenários e em condições comuns e incomuns (corner cases). Os testes podem também servir para saber se o software ainda continua fazendo o que é suposto depois de uma modificação. Este são os chamados Testes de Regressão.
A automatização de testes é uma forma de produzir resultados mais rápida e abrangente simplificado e diminuindo o tempo necessário para, por exemplo, realizar testes de regressão. A automatização não é uma necessidade em si mesma. Todos os testes podem ser manuais, mas considerando fatores de engenharia isso não seria proveitoso em termos de custo e riscos. Eis os estágio de uma pessoa que realiza testes. É preciso notar que “automatizar” não necessariamente significa “programar”. Existem pessoas que realizam testes e automação sem saberem programar – usando ferramentas – contudo, saber programar ajuda bastante a pessoa a chegar nos estágios mais avançados.
0 – A pessoa não reconhece ou entende como por à prova certa premissa, caminho ou conclusão do modelo. Este é o estágio da maioria da população.
1- A pessoa consegue reconhecer que existem necessidades de testes, mas não é capaz de os desenhar.
2- A pessoa consegue reconhecer e desenhar testes embora não com a abrangência necessária. Ou seja, alguns casos de interesse não são cobertos pelos testes desenhados. A pessoa não consegue automatizar os testes desenhados
3 – A pessoa consegue reconhecer e desenhar testes embora não com a abrangência necessária. Ou seja, alguns casos de interesse não são cobertos pelos testes desenhados. A pessoa consegue automatizar alguns dos testes desenhados.
4 – A pessoa consegue reconhece, desenhar testes com a abrangência necessária. A pessoa consegue automatizar alguns destes testes.
5 – A pessoa consegue reconhecer, desenhar e automatizas os testes com a abrangência necessária, mas a bateria de testes não é eficiente, consumindo muito tempo ou muitos recursos além do necessário. A pessoa pode ainda criar cenários de testes mais complexos do que necessário.
6 – A pessoa consegue reconhecer, desenhar e automatizas os testes com a abrangência necessária e que são conceitualmente simples e eficientes, mesmo se a bateria de testes não é eficiente, consumindo muito tempo ou muitos recursos além do necessário.
7 – A pessoa consegue reconhecer, desenhar e automatizas os testes com a abrangência necessária e que são conceitualmente simples e eficientes, de forma que a bateria de testes é eficiente, consumindo apenas o tempo e os recursos necessários.
Um programador pode começar a fazer algumas automações para fazer verificações simples do seu código, com testes unitários, mas isso não representa que ele está preocupado ou conhece o conceito de abrangência. Normalmente o programador está interessado em saber se todo o código que escrever faz o que deveria – cobertura. Mas isso é diferente de saber que ele faz o que deveriam em todos os casos possíveis – abrangência.
Uma função de multiplica dois números é muitos simples de programar e necessita apenas de uma operação
int multiplica(int a, int b) {
return a * b;
}Se rodarmos um teste em que multiplicamos 2 por 3 e verificarmos que é 6, teremos cobertura 100%. Contudo não teremos abrangência suficiente. Não testamos números negativos,uns, zeros, números muito perto dos limites inferiores e superiores de um inteiro, etc. Há inúmeros cenários. Há pelo menos 2^64 casos e não será possível abrange todos em tempo hábil. Teremos que lançar mão de técnicas como testes por amostragem ou usar propriedades como indução. A pessoa que realiza testes tem que levar tudo isto em conta num caso aparentemente muito simples. O programador não irá ter tanta preocupação.
Falei de Programação, Desenvolvimento, Engenharia e Teste e haveria muitas outras disciplinas a abordar. De forma resumida podemos pensar em Programação como a arte de usar ferramentas que instruam o computador a realizar tarefas ao mesmo tempo que essas instruções são inteligíveis a outros Programadores. Podemos pensar em Desenvolvimento como arte de capturar os modelos do mundo real e criar modelos computacionais que simular esses modelos e para os quais pode ser criado um código – pelo programador – que instrui o computador. Podemos pensar em Engenharia como arte de entender os constrangimentos físicos e econômicos relacionados às decisões que são tomadas ao criar um software. Podemos pensar em Testes como a arte de demonstrar que o software faz realmente o que o modelo dita, dentro dos constrangimentos, para um vasto número de cenários.
Uma pessoa que quer ter uma carreira como artífice de software ela irá ter características de todas estas disciplinas em diferentes graus. São capacidades que a pessoa adquire e não cargos ou posições em empresas. Ao longo da carreiras a pessoa pode ter acumulado muitas destas capacidades ou pulado algumas. É possível ter uma pessoa com alto grau de engenharia, mas que não sabe programar, mas isso é – na prática- improvável pois a pessoa tem que ter uma noção dos impactos e da origem dos custos, riscos e limitações que pretende medir e gerenciar. Por exemplo, uma pessoa pode falar de Qualidade e tentar medir e gerenciá-las, mas o trabalho será em larga medida mais complexo e difícil se não entender que a origem da falta de qualidade vem de fatores externos como a educação acadêmica dos programadores, seus valores e como eles se alinha com os conceitos de normalização a compliance que são a base de aferições de Qualidade. Se pessoa confunde Qualidade com a existência de mais ou menos bugs, ou cobertura com abrangência ela não sabe realmente o que Qualidade significa. Exemplos semelhantes podem ser dados para as outras “ilidades”.
Por outro lado, um programador não será exímio a usar Threads ou outro tipo de conceitos que permite diminuir o tempo de processamento se não entender que a Rapidez é uma propriedade necessária ao software e não apenas o serviço que o software realiza pelo utilizador. Contudo há limites. Seria extraordinário se o serviço fosse instantâneo, mas às vezes, simplesmente não é possível e o programador deve levar isso em conta em vez de continuamente tentar ser cada vez mais rápido. É preciso entender que há limites para o quão rápido algo pode ser e que esses limites mudam com o avanço tecnológico. Da mesma forma um desenvolvedor pode desenhar um modelo conceitual excelente que resolve todos os casos de interesses para o utilizador do software, mas que é muito caro ou exige tecnologia muito avançada que ainda não existe, não foi comprovada ou é cara. O desenvolvedor tem que embutir no seu modelo considerações de rapidez de acesso aos dados e algoritmos que permitam ao modelo computacional funcionar em um tempo hábil ou modelar de uma forma que o utilizador não espera resultados imediatos. Ao mesmo tempo ele tem que levar em conta como o modelo – conceitual e computacional – será testado. Um modelo que não pode ser testado não se alinha com as necessidade de custo e mitigação de risco de engenharia.
Enfim, um artífice de software tem que ter capacidades em todas as áreas e tem que pelo menos entender o básico de cada uma, digamos o estágio 2 ou 3 de cada disciplina. Antes disso a pessoa não é um artífice de software; é um aprendiz.
Todas estas disciplinas se aplicam em todos os “cortes” de atividade de hoje em dia porque são o coração da profissão. As mesmas características são necessárias se a pessoa trabalha no front ou no back, como dba , devops, ou full stack … As características serão usadas de formas diferentes, mas se não existirem não será possível realizar o trabalho com maestria. A pessoa pode executar um trabalho e até conseguir resultados, mas não irá avançar na carreira.
Ser mestre – alcançar o nível 6 ou 7 – em todas as disciplinas não é nada fácil. Não direi que é impossível, mas é altamente improvável. Cada artífice de software terá talento inato para algumas dessas disciplinas mais que outras. E não refiro apenas a estas que abordei mais de perto, mas a todas. A pessoa saberá o que gosta e o que a faz feliz. Alguns são felizes imaginando casos de teste, alguns são felizes diminuindo custo e mitigando riscos. O caminho que cada um de nós traça no conhecimento e uso destas disciplinas é a nossa Carreira. Em cada momento da carreira teremos diferentes capacidades nestas disciplinas e estaremos nos aperfeiçoando em uma, ou outra, que gostamos ou sentimos necessidade de entender. Contudo, ao colocar essas capacidades ao serviço dos utilizadores do software por meio de uma empresa empregadora teremos uma oportunidade de usar nossas capacidades já existentes e trabalhar nas menos usadas. Seremos condicionados pelas circunstâncias de cada oportunidade a aplica umas disciplinas mais que as outras. Quando mais disciplinas e maior estágio em cada uma, mais volantes nos tornamos sendo capazes de ajudar a empresa em diferentes oportunidades para diferentes fins.
Há, hoje em dia, um sentimento de insatisfação e as pessoas querem sempre pular para próxima coisa nova mais brilhante, mas isso advém de não passar tempo suficiente se aprofundando no que tem hoje antes de entender a fundo o que está fazendo agora. Nada há de errado em ser um exímio programador ou tester. Isso são capacidades suas, sempre válidas e úteis. A oportunidade que seu empregador lhe dá é diretamente proporcional às capacidades que demonstra. Um testes pode ser bom a desenvolver, um desenvolvedor bom a programar, etc. Há manobras possíveis e é possível atender diversas oportunidades, às vezes, até simultaneamente. Por outro lado, se você é feliz sendo testes e a empresa não lhe permite usar essa habilidade, ou exige que use habilidades que você não quer usar, é hora de seguir em frente.
Descubra as várias disciplinas que compõem a paleta do artesanato de software, tente um pouco de cada, se aprofunde nas que gosta mais e depois vá expandindo para as que gosta menos, mas que necessita. No fim são todas úteis. Encare aquilo que os seus empregadores oferecem apenas como oportunidades para exercitar estas capacidades. Esta é uma forma de ter uma Carreira satisfatória como Artífice de Software.