Introdução

O trabalho do desenvolvedor não é sobre código, é sobre entregar valor/resolver o problema do cliente.

Essa é uma daquelas frases que qualquer pessoa pode soltar num meio de uma reunião e essa pessoa parecerá inteligente, pois é uma frase que dificilmente pode ser contradita, mas não diz muita coisa.

Algumas vezes as pessoas querem passar a ideia de "seu código não importa, mas sim se a dor do usuário foi solucionada ou não", e outras vezes quem ouve/lê é quem entende a frase dessa forma. Mas como a maioria dessas afirmações pra ganhar engajamento, essa é uma afirmação superficial e não entra no principal (ou seja, não gera valor hehe), que é "o que é entregar valor?".

O que é entregar valor?

Até entendo as pessoas ficarem só na superfície dessa frase feita, porque entregar valor é algo que varia bastante em cada contexto. A resposta pode mudar se levar em consideração pra quem você está gerando valor, o momento da empresa e os seus objetivos, a sua função e etc.

Por exemplo, em uma startup em estágio embrionário, gerar valor seria colocar um produto rápido no mercado e que solucione os problemas do público alvo. Já numa empresa em crescimento rápido, talvez gerar valor seja tornar o produto escalável, ou diminuir custos.

Esses são exemplos clichês e fáceis de dizer que geraram valor porque são métricas facilmente mensuráveis, entregar em 3 meses, aguentar 5000 usuários simultâneos, custos de infraestrutura diminuir em 20.000 reais. Mas tem muita coisa que gera valor e que não é fácil medir o valor gerado, que não temos como afirmar se o impacto causado aconteceu por alguma atitude tomada e consequentemente é mais difícil de vender a ideia para quem toma decisões. Pra exemplificar, vou citar 2 atividades: Escrever código de qualidade e melhorar a developer experience do projeto.

Gerando valor invisível

Escrever código de qualidade já é algo difícil de afirmar se está sendo feito ou não, constatar se isso gerou valor é mais difícil ainda. Pro cliente final não parece ter uma relação entre a maior qualidade do código e maior satisfação com o produto, mas pode ser que tenha, posso afirmar que um código com mais qualidade significa um produto com menos bugs pois é mais fácil de manter, e um produto com novas funcionalidades mais cedo pois o código é fácil de modificar e evoluir.

Melhorar a developer experience também não parece afetar diretamente o cliente final, mas ajuda os desenvolvedores a começar a trabalhar no projeto mais cedo, a solução de problemas é mais rápida por conta de melhores ferramentas pra investigação, menos tempo perdido com reuniões e dúvidas, mais segurança na entrega, mais qualidade de vida, e tudo isso pode afetar também o número de bugs e novas funcionalidades presentes no produto.

Há vários outros hábitos que parecem ser apenas firula ou perda de tempo, mas que ajudam de alguma forma no processo de desenvolvimento e entrega de um valor visível, da mesma forma como decisões equivocadas e ausências de certos hábitos interferem na entrega de valor mas que também não é fácil mostrar que foram a causa dessa improdutividade.

Você é responsável pelo código

É por isso que a afirmação no começo do artigo é superficial. Seu trabalho como desenvolvedor, em muito dos casos, não é saber se o que você está fazendo gera valor diretamente ou não pro cliente, pra isso há diferentes times pra realizar entrevistas com clientes, pra gerenciar projeto, pra analisar métricas, pra definir estratégia, e etc. Se você estiver se preocupando com tudo isso, quem está se preocupando com o código? Ninguém, e é assim sua base de código fica deteriorada, e o trabalho do time de desenvolvimento era não deixar isso acontecer.

Dá pra fazer uma analogia com a engenharia civil, já que uma pessoa dev pode ser considerada uma pedreira do mundo digital =p. O valor que um pedreiro entrega é uma estrutura boa, resistente, durável, alinhada com as definições do projeto. Outros times que irão definir ou já definiram cores, lugar dos móveis, repartição dos cômodos, iluminação, revestimentos, gerenciamento do projeto. Então como desenvolvedor você deve estar comprometido com o código, outros times estarão comprometidos com prazo, outros com o cliente e etc.

Seja um pouco flexível

Mas claro, estar comprometido com o código não é ignorar todo o contexto, você e o time de desenvolvimento não trabalham sozinhos numa ilha, há todo um esforço coletivo na construção de um produto. Então deve haver uma flexibilidade, às vezes é necessário abrir mão de certos processos que seriam "os mais corretos" em prol de um benefício maior.

Uma situação clássica onde isso deveria acontecer: Há um bug em produção que está gerando prejuízo para a empresa ou para o cliente, o ideal é que isso seja resolvido o mais rápido possível. O processo "correto" seria corrigir o problema, abrir pull request, solicitar revisão, aguardar CI passar, realizar testes de QA e daí realizar deploy. Mas talvez para um ganho de todos, esse fluxo pode ser ignorado e a correção ir direto para produção. Não é o correto em condições normais, mas condições anormais acontecem, você pode minimizar isso registrando uma atividade pra revisar, refatorar e testar o que foi feito. Tenha sempre processos para voltar aos trilhos.

Agora se isso se torna algo cotidiano, você estiver sempre tendo que comprometer a qualidade do seu trabalho para apagar incêndios, isso pode ser sintoma de uma falta de organização da empresa, falta de maturidade nos processos, e daí você pode tentar corrigir mas se for algo cultural, é melhor partir pra outra ou dançar conforme a música.

Conclusão

Resumindo, diferente da frase que motivou esse artigo, o seu trabalho como desenvolvedor/a é sobre código sim, você focando na qualidade do seu trabalho, numa empresa organizada, você estará contribuindo para um melhor produto e consequentemente gerando mais valor. Quando as pessoas responsáveis pelo código não ligam para ele ou não tomam as melhores decisões, o produto está condenado a uma estagnação e a uma constante correria pra apagar incêndio.