O Codificador limpo — O que aprendi — Parte 1
Uma tentativa de expressar o que aprendi em minha carreira e em livros como o codificador limpo
A idéia dessa sequência de 3 partes é passar algumas experiências e conhecimentos adquiridos em minha carreira .
Profissionalismo
Já se perguntou se é um(a) profissional? É uma tarefa pesada e cansativa fisicamente e mentalmente, já que para atingir esse status, você deve ser responsável por aquilo que faz. Parece simples, mas pense com calma, e reflita se realmente sente a dor da empresa ou produto em que trabalha, de forma a se sentir responsável quando o mesmo vai mal. Não entenda errado, ninguém precisa ficar triste porque a empresa em que trabalha não está com bons resultados, mas sim sentir o peso que suas ações tem na empresa e entender que o resultado do seu trabalho pode ter um desempenho negativo. Se o resultado do seu trabalho não lhe importa, tenho péssimas notícias a lhe dar.
Ser profissional é ser responsável pelas suas ações e resultados, e estar disposto a limpar a própria bagunça se necessário. O ideal é que não haja bagunça para se limpar, mas sejamos realistas, é um cenário pouco provável.
Isso nos leva a outro ponto:
Não quebre nada
Não cause problemas a sua estrutura de trabalho, como pessoa desenvolvedora, espera-se que faça seu trabalho com consistência e qualidade, portanto nosso objetivo principal poderia ser:
“Não cause bugs”.
Nossa! Parece um mundo ilusório, afinal, como podemos mensurar algo tão obstinado quanto não errar? A questão é simples, erros acontecem, mas isso não justifica nosso erro e responsabilidade, portanto, erros irão acontecer, e é parte do seu trabalho evitar e se responsabilizar por eles.
Comprometimento
Já se perguntou se é um(a) profissional comprometido(a)? Te convido para alguns exemplos do cotidiano:
Na empresa, você percebe que estão com falta de equipamentos e ao solicitar novos para a pessoa responsável, recebe como resposta:
“Realmente, estamos precisando de novos equipamentos”
Ao perceber que o prazo para a entrega de uma funcionalidade está próximo, nos dirigimos ao desenvolvedor responsável para saber se é possível que a entrega aconteça nessa semana e como resposta, ouvimos:
“Espero ter entregado tudo até la”
É preciso aprender a detectar a linguagem que não condiz com comprometimento, e muitas vezes ela é simples de se detectar, usando até mesmo um dos exemplos acima, mas de outra forma
Em vez de usar a frase “Espero ter entregado tudo até la”, podemos usar:
“Vou entregar tudo até la”.
Estranho, não? Como uma palavra pode mudar todo o contexto da frase, afinal, de um lado estamos colocando uma possibilidade e da outra definimos basicamente um resultado binário, que seria de entregar ou não o que foi combinado. Dessa forma, assumimos uma responsabilidade, e se for perceber, tendemos a evitar isso, afinal não queremos ter a possibilidade de falharmos somente por nossa culpa. A grande questão do comprometimento é assumir responsabilidades e papeis com autoridade e confiança, utilizando uma linguagem com os mesmos critérios, sem passarmos a sensação de dúvida para outros. Meio assustador, não?
Mas, e se eu depender de alguém para fazer isso, como devo proceder? É fácil, a atitude é importante aqui, já que você não pode responder por outra pessoa, sendo assim, o que de fato você poderia se comprometer? Simples, em vez de esperar a outra parte se virar, por que não se junta a ela para ajudá-la, ou se falta alguma informação para seguir, de que forma você poderia ir atrás dessa informação para tentar acelerar o processo.
Mesmo assim, pode também ocorrer de simplesmente você perceber depois de um tempo que não será capaz de realizar tal tarefa, mesmo tendo se comprometido a realizá-la, nessa situação, é importante sinalizar isso o mais rápido possível, seja de um possível atraso para uma reunião ou para a entrega de alguma funcionalidade.
Também vão existir momentos em que será pressionado(a) ao extremo para dar uma resposta, onde deverá passar um prazo determinado, por exemplo, e embora consiga passar um prazo, lhe pressionarão o máximo possível para reduzir esse prazo. Nesse momento, algumas coisas podem passar pela sua cabeça, como:
“Talvez se eu não seguir a arquitetura a dedo, ou não incluir testes, consiga entregar no prazo”
Pensamentos assim são perigosos, uma vez que esses critérios deveriam ser tão necessários ao projeto quanto qualquer outra coisas.
O importante é entender o que é mais importante naquele contexto: O valor ou a estrutura.
Decidido isso, podem existir casos em que a velocidade será mais valiosa que a qualidade, e nesse caso acaba sobrando para a mão de obra, em tecnologia e produtos novos, tende a cair na mão dos(as) desenvolvedores em forma de horas extras e trabalho em fins de semana e feriados. Aqui é necessário entender seu limite, se trabalhando mais horas e no fim de semana você conseguirá de fato entregar as coisas a tempo, tente negociar de forma que você seja recompensado(a) de acordo.
A conclusão disso tudo é que não se espera que profissionais digam sim para tudo, e sim que encontrem formas criativas e inovadoras de conseguir o sim, de forma que possam se comprometer da melhor forma possível, não deixando espaço para dúvidas.
Muitíssimo obrigado por ler até aqui, caso tenha interesse em continuar com o conteúdo, aqui estão as outras partes.
