Excelente Programadora vs Boa Programadora com Excelentes Hábitos
Bom, Mau, Excelente, Péssimo, palavras que expressam qualidade ou característica do ser. Quando olho para esses adjetivos, penso que sozinhos eles não dizem muita coisa mas acompanhados de um substantivo, nesse caso “Programadora”, a coisa muda de figura e agora eu passo a sentir necessidade de um referencial. Bom em que? Mau com relação a que? O que isso significa?
Essa é uma pergunta comum, não sei se para todas mas para mim e grande parte das que me cercam. Antes de prosseguir na discussão, eu quero tomar dois minutos de reflexão para que você pense:
- O que te vem à cabeça quando eu digo Programador?
- O que te vem à cabeça quando eu digo Programadora?
Esse artigo não é sobre gênero, mulheres na programação, estereótipos, síndrome da impostora ou papéis de gênero. É sobre autocrítica e experiências, logo, é sempre bom pensar no que trazemos na bagagem. Os termos aqui citados encontram-se no feminino pois refiro-me a pessoas, pessoas programadoras.
Sigamos.
O que é ser uma boa programadora?
No meu último semestre da graduação em Ciência da Computação, poucas semanas antes da apresentação do meu TCC, uma professora que eu tinha acabado de conhecer, me fez a seguinte pergunta: “Você é uma boa programadora?”. Na hora eu não exitei e respondi que sim, de imediato. Apresentei confiança mas isto abriu uma fenda na minha cabeça, eu não sabia ao certo o que ela queria saber, qual era o conceito de bom, quais seriam esses critérios.
Respondi aquele “sim” com base em alguns fatos:
- Atuo profissionalmente como programadora a um tempo considerável
- Sou capaz de resolver problemas e conduzir tarefas no contexto em que estou inserida
- Tenho uma mínima confiança do meu chefe e da minha equipe
- Posso apostar num “talvez” mas não quero deixar que alguém que acabou de me conhecer responda isso por mim
Esse foi o meu ponto de partida para começar a refletir, ler sobre o assunto e desenvolver algumas percepções:
À primeira vista, os fatos que citei podem trazer algum tipo de convencimento mas se ampliarmos o olhar, existem alguns fatores não mencionados que geram ruídos nessa interpretação. Um exemplo disso é que se você puxar pela memória, talvez se lembre de alguém no qual julga como uma programadora “méh”, uma profissional “mais ou menos” e ainda assim elas continuam marcando itens neste checklist.
Para quebrar um pouco a subjetividade desse tópico e ser mais assertiva com essa percepção, quero aplicá-lo em outras áreas. Vamos pensar que houve um vazamento na sua casa e você precisou contratar os serviços de uma encanadora, o que te faz afirmar que aquela é uma boa profissional? No meu caso, o que me convence é a qualidade do seu trabalho. Se o conserto resolveu o meu problema, se eu não vou precisar chamá-la novamente pra remendar naquele mesmo ponto, se o reparo resiste ao uso diário, se foi um reparo que manteve a estética da minha casa, se ela me passa confiança e honestidade. Julgo que o tempo de experiência pode contar pontos e trazer diferenciais para aquele trabalho, mas não é decisivo quando colocado ao lado da qualidade do serviço. A confiança da chefe ou da equipe pode representar um bom indício, desde que elas também prezem por um serviço bem feito.
É com essa analogia que cheguei à conclusão de que na época eu era uma ótima programadora-apagadora-de-incêndios. Eu dava conta do recado mas tinha pouca confiança no meu código, justamente por escrever e replicar códigos complexos, acoplados, difíceis de ler, de manter, pouco testados e consequentemente com alto risco de inserção de bugs. Essa era a característica principal dos códigos produzidos no contexto em que eu estava inserida, eu sentia na pele as consequências dessas práticas, mas eu demorei um tempo pra entender as causas e por onde começar a mudança.
Boa Programadora com excelentes hábitos
Mudar a forma como eu desenvolvia software veio de uma mudança na forma como eu enxergava o meu trabalho, a minha forma de aprender, onde eu buscava as minhas referências, os hábitos que eu nutria. Uma das primeiras coisas que eu fiz foi identificar onde eu queria estar, mapear o que eu de fato sabia e o que eu precisava saber para estar no nível que eu queria estar naquele momento, quais lacunas me separavam daquele nível técnico desejado. Obviamente eu precisei fazer um plano realista, considerando quem eu sou, o tempo que eu tenho, a minha trajetória, o que eu quero e gosto de fazer. Digo isso porque colocar as minhas atenções em acompanhar as tendências do mercado, dos eventos de tecnologia, o que as desenvolvedoras mais influentes têm utilizado, sem me colocar na equação me gerava mais ansiedade do que perspectivas.
Eu tinha muita preocupação por não estar desenvolvendo nas linguagens e frameworks que eram tendência nos eventos de programação que eu frequentava. Mas o que eu não entendia era que as tops linguagens sozinhas não me fariam desenvolver códigos de qualidade. Não era porque eu só sabia Java que isso me fazia não testar meu código, não era a linguagem que me fazia não conhecer e nem utilizar técnicas para escrever códigos fáceis de ler, de manter, menos acoplados. Não era a sintaxe ou o paradigma que me fazia não ter preocupação com segurança, design de código e qualidade. Existiam alguns passos a serem dados antes de me ocupar com saber uma vasta quantidade de linguagens e frameworks específicos, existiam fundamentos, bases sólidas de conhecimento para serem adquiridas e que podiam ser aplicadas na linguagem que eu já sabia.
Me concentrar em fundamentos de programação me faz ter argumentos técnicos, exercitar o senso crítico, querer saber o que motivam as decisões técnicas e me fez também atentar para um hábito que eu não tinha, questionar. Parei para perceber que eu extraí menos das experiências que tive por não perguntar, não querer saber o que motivava as decisões técnicas, de negócio ou de processo e apenas segui-las, muitas vezes em modo automático. Perguntas como: “Qual conjunto de fatores tornou tal sistema de gerenciamento de banco de dados mais viável?”, “Por que adotamos esse caminho para produção?”, “Como chegamos a essa decisão de arquitetura?”. Esses questionamentos não são para ser “do contra”, para discordar sempre ou para confirmar sempre, são para entender, para gerar consciência do que está sendo feito, aprender com os erros e poder tornar essa experiência algo que eu possa fazer uso, referenciar em outras situações.
Coisas que aprendi no caminho
Ao iniciar essa mudança de olhar, fui aprendendo novas coisas ao longo do caminho e agregando novas práticas. Reuni aqui alguns desses hábitos que me ajudam a desempenhar melhor o meu papel, me dando maior confiança nos códigos que escrevo e no trabalho que desempenho.
Seja curiosa. Questione.
Busque saber como as coisas são feitas e por que são feitas dessa maneira. Perceber que as coisas não passam por você em modo automático pode gerar confiança, baseada na sua preocupação com qualidade, no entendimento das coisas que você faz e de onde está inserida.
Tenha iniciativa, inclusive de pedir ajuda.
É massa bater cabeça e encontrar soluções, mas é mais massa ainda saber quando parar e pedir ajuda. Pessoas vieram antes de você e criaram várias coisas, você não precisa reinventar a roda e isso não significa que você também não pode melhorar o que está criado. É possível aprender se permitindo ser ajudada.
O hype não é tudo, tenha referências, fundamente seu conhecimento.
Ferramentas são só ferramentas se você não souber como empregá-las. Entenda os fundamentos do que você está fazendo. Como é perfeitamente dito nesse artigo: “Tenha em mente que aprender a programar é diferente de aprender uma linguagem de programação. Foque em técnicas de programação, resolução de problemas e análise”. Isso não impede que você seja especialista em algo mas também não te coloca refém de tecnologias.
Teste. Durante e depois. Teste sempre.
Entenda testes como parte da criação e desenvolvimento de algo, não uma etapa — principalmente final. Não conclua o seu desenvolvimento dizendo que “está pronto, só falta testar” ou “está praticamente pronto” sem que você tenha escrito uma linha de teste ou realizado um cenário que seja.
Se você cozinha ou já viu alguém cozinhando, pode perceber que ao longo do cozimento o alimento é experimentado, o sal é corrigido, o tempero, a consistência. Provar a comida durante o processo de preparo faz com que seja possível perceber o que está faltando, se tem algo a mais, sem que a sua refeição seja comprometida. Notar que uma comida está salgada demais quando o prato já está na mesa pode custar caro e ser trabalhoso.
Testes fazem parte do nosso dia-a-dia de vida, por que não fazem parte da nossa rotina de desenvolvimento software?
Invista no conhecimento de boas práticas
Encontre formas de desempenhar melhor o seu trabalho através de boas práticas de desenvolvimento de software. Leia sobre o que as pessoas têm utilizado no dia-a-dia, os desafios encontrados. Tente unir o conhecimento teórico adquirido através da literatura, com o que você vivencia e com a vivência de outras desenvolvedoras.
Se preocupe com o caminho para produção
Busque saber o que veio antes e o que virá depois que você “entregar” aquele código, qual caminho é percorrido até lá, principalmente se você está envolvida em uma única parte do processo de desenvolvimento. Isso pode ajudar a entender o seu lugar no processo e também como melhorá-lo.
Faça o seu melhor com o que você tem
Nem sempre o contexto no qual você está inserida é aberto para o uso de novas práticas, melhoria contínua, testes. Talvez a pessoa cliente apresente resistência e seu escopo seja limitado ou a empresa tenha processos engessados, entre outros agravantes. Pense no que você pode fazer de melhor naquele contexto, pode ser que hoje não seja possível incluir testes unitários no processo de desenvolvimento e o melhor que você consegue fazer seja escrever um código menos acoplado. Hoje eu posso nomear métodos e variáveis de forma entendível, amanhã talvez seja possível questionar um processo, aplicar uma pequena mudança, um dia de cada vez.
Pense no seu autodesenvolvimento
Ainda dentro desse escopo de contextos de time ou empresa que acabam limitando a aplicação de novas coisas e às vezes desmotivando o aprendizado, lembre que você é uma desenvolvedora para além desse emprego, desse time. Tenha em mente o que você gostaria de aprender, de praticar e não deixe de se atualizar, lembrando de manter o equilíbrio e fazer isso de forma saudável e leve.
Conclusão
Se eu encontrasse aquela professora novamente, eu perguntaria o que significa para ela ser uma boa programadora e se a pergunta surgisse novamente, provavelmente essa seria a minha resposta atual:
“Eu não sou um excelente programador; eu sou apenas um bom programador com excelentes hábitos.” — Kent Beck
E isso me faz entender que é um processo contínuo. Daquele dia até hoje, muitas coisas mudaram, eu aprendi muitas coisas e continuo aprendendo. Os novos hábitos me fizeram ser mais confiante, extrair mais das experiências que tenho, me empoderar do que eu sei, não ter medo de revelar o que não sei e com ainda mais confiança dizer que posso aprender.
Indicações de leitura
Indico aqui alguns temas que fizeram sentido para mim na obtenção desses hábitos que citei, são conceitos dos quais faço uso e foram a porta de entrada para aprofundar outros conhecimentos.
The S.O.L.I.D Principles in Pictures
Clean code, o que é e por que usar?
