Você é o ÚNICO responsável pela qualidade do código que produz!

Publicado originalmente em meu linkedin

Se há algo que aprendi, tanto academicamente quanto empiricamente, é que a motivação é intrínseca ao indivíduo. Ou seja, fatores externos podem, no máximo, criar a condição favorável (ou desfavorável) para que você se sinta (des)motivado.

Como programadores, escrevemos código. Esta é parte significativa do nosso trabalho. Todos deveríamos saber fazer isso. Concorda?

Código de qualidade, limpo e expressivo, é o resultado da produção de um bom programador. Um programador que se importa (motivado) sempre escreve o melhor código (que consegue). Se assume uma dívida técnica, trata de pagar a mesma no menor prazo possível. Afinal, essa é a sua responsabilidade e isso é intransferível.

A qualidade do código de um programador não pode ser, definitivamente, influenciada por fatores externos. Código bom é mérito do programador! Código ruim, TAMBÉM.

As dívidas técnicas que você assume, programando, são suas. Não são do seu gerente, analista, Scrum Master, Product Owner, ou qualquer espécie exótica que podemos encontrar no universo corporativo.

Se você não escreve testes de unidade, é uma decisão SUA! Se o seu código está bagunçado, é uma decisão SUA!  Se o nível de acoplamento está alto, é uma decisão SUA!

Se um ambiente medíocre faz com que seu trabalho fique medíocre. Desculpe informar, mas, você é tão medíocre quanto seu ambiente.

Como categoria, temos que parar de arrumar fracas desculpas para nossos desempenhos fracos. Sempre disse e repito: “Não podemos terceirizar a gestão de nossas carreiras”. Da mesma forma, não podemos “delargar” para os outros a responsabilidade pelo trabalho que realizamos.

Seu código não estar fazendo o que o cliente precisa pode até ser, em alguns casos,  responsabilidade do contexto. Entretanto, a forma como esse código está escrito é responsabilidade intransferivelmente sua.

Não concorda?! Comente e discutimos.

Capa: Jefferson Santos

Compartilhe este insight:

18 respostas

  1. Eu sempre digo às pessoas: “não saia vomitando código por aí. Você precisa ter mais preguiça de programar, e menos preguiça de pensar.”

  2. Discordo completamente. É fato consumado que velocidade e qualidade são inversamente proporcionais. Se você trabalha num lugar onde tudo é pra ontem, tudo tem que ser ultra rápido, nem que o único programador do lugar seja você, seu código será uma lástima. E a culpa, é sua?
    Normalmente programadores são os kras que lutam para escrever um código decente, mas quem paga a conta não deixa. Como colocar a mediocridade do ambiente no mesmo patamar do programador, num cenário desse?
    O texto me remete a professores da faculdade ensinando engenharia de software, onde o mundo é ideal e colorido. Desculpa informar, mas isso não existe.

    1. Obrigado, Flávio, por suas ponderações. Concordamos em discordar, ok?

      Quanto a não existir, este ano completo 25 anos programando profissionalmente. Não venho da academia e meus empregadores são empresas sérias e saudáveis.

      O programador é mesmo o único buscando qualidade? Está certo disso?

      1. Escreve um texto e no final coloca “Não concorda?! Comente e discutimos.”

        Aparece alguém que discorda.

        A resposta é “completo 25 anos programando profissionalmente”.

        Fiquei com preguiça de comentar.

        1. Cara, todos somos frutos de nossas experiências, qual o problema de ele comentar que tem 25 anos de experiência? Pensei que adultos iriam comentar aqui, mas acho que seu pai precisa moderar melhor seus comentários irrelevantes.

        2. Você pegou apenas uma frase de minha resposta e diz que essa foi minha resposta. Não foi bem isso. Certo?

      2. Escreve um texto e no final coloca “Não concorda?! Comente e discutimos.”

        Aparece alguém que discorda.

        A resposta é “completo 25 anos programando profissionalmente”.

        Fiquei com preguiça de comentar.

        * O seu comentário está aguardando moderação. Vamos ver se vai aparecer

        1. Gustavo, eu coloco comentários sobre moderação apenas para garantir que eu não tenha conteúdo inadequado. A partir de agora, você pode publicar sem moderação.

          BTW, considero pouco apropriado postar duas vezes o mesmo comentário.

          Adoraria ouvir mais de seus argumentos e menos ataques pessoais. Combinados?

  3. Por partes:
    A qualidade do código de um programador não pode ser, definitivamente, influenciada por fatores externos. Código bom é mérito do programador! Código ruim, TAMBÉM.
    – Você trabalha sozinho? por conta? code review? Você consome serviços e Apis somente produzidos por você? porque tudo isso influencia na qualidade do código e das entregas. Definição do que é um “código ruim” ou “bom” depende de N fatores e um desses fatores é contexto.

    As dívidas técnicas que você assume, programando, são suas. Não são do seu gerente, analista, Scrum Master, Product Owner, ou qualquer espécie exótica que podemos encontrar no universo corporativo.
    – As dívidas ou débitos técnicos são assumidos pelo time (leia-se em “time” aqui todos que fazem parte do processo da entrega de uma determinada funcionalidade, projeto, etc), de comum acordo com TODOS (deixei de lado X por Y e volto em Z) simples assim, responsabilidade é dividida e não isolada; espírito de time e tal… se as pessoas que trabalham diretamente com você não conseguem dividir as responsabilidades e o “mea culpa”. I have bad news for you… E palavras como “exótico” para definir papéis dos quais você não respeita demonstra falta de conhecimento sobre determinado processo, papel e afins. O papel de um PO ou Scrum master dentro de um determinado time não tem nada de átipico ou anormal, as pessoas estudam, se aprofundam em seus campos de conhecimento tanto quanto, suponho, você estuda para ser um melhor programador/cto/gerente o que for. Chamar de “exótico” o trampo de alguém é no mínimo, desrespeitoso.

    Se você não escreve testes de unidade, é uma decisão SUA! Se o seu código está bagunçado, é uma decisão SUA! Se o nível de acoplamento está alto, é uma decisão SUA!
    – Se você trabalha em uma caverna, sozinho, produzindo pra você mesmo eu concordo com essa responsabilidade da decisão. EM qualquer outro caso esse tipo de decisão/responsabilidade é compartilhada.

    Se um ambiente medíocre faz com que seu trabalho fique medíocre. Desculpe informar, mas, você é tão medíocre quanto seu ambiente.
    – Você pode também, procurar um lugar que seja mais satisfatório, um lugar onde suas qualidades são melhores encaixadas; Talvez fazer um exercício de auto-avaliação, etc. Desculpe informar, mas você não pode julgar a relação de uma pessoa e seu ambiente de trabalho com base na sua definição de mediocridade, não faz sentido algum e só demontra prepotência.

    Como categoria, temos que parar de arrumar fracas desculpas para nossos desempenhos fracos. Sempre disse e repito: “Não podemos terceirizar a gestão de nossas carreiras”. Da mesma forma, não podemos “delargar” para os outros a responsabilidade pelo trabalho que realizamos.
    – Como categoria, devemos fazer em prol da nossa comunidade para melhorar a qualidade dos desenvolvedores em inicio de carreira ou aqueles que por algum motivo estão desmotivados com o “jogo”. Seja contribuindo com palestras em eventos, produzindo/contribuindo mais código open source, etc. No final todo mundo ganha com isso: O empresário, o mercado e o profissional. devemos também como categoria não aceitar mais subempregos, com contratações ilegais, cargas horárias extenuantes, etc, tem um monte de tópicos que “deveríamos” fazer como categoria
    Como indíviduo sim, você pode fazer uma auto-analise sobre o seu desempenho, pedir feedbacks para as pessoas que trabalham diretamente contigo, etc.

    1. Olá Guilherme. Nunca trabalhei em uma caverna, muito menos sozinho. 🙂

      Não queria desrespeitar ninguém com meu texto. Desculpa se lhe ofendi. Concordo que a palavra “exótica” não é uma escolha feliz. Sobre suas sugestões, estou há mais de 15 anos palestrando e participando de eventos.

      Obrigado pelo feedback.

  4. Quais são as implicações dessa “responsabilidade” pra você? Que a única pessoa a ser cobrada pela qualidade de código, decisões técnicas, débitos técnicos, organização de código, é o programador?

    Como membro de um time, vejo responsabilidades importantes de:
    – deixar claro as implicações de negócio que algumas decisões técnicas possuem
    – estar comprometido com o próprio desenvolvimento
    – trazer conhecimento para membros do time

    Mas o que leio do seu texto é uma simplificação de algo bastante complexo. É claro que você deve prezar pela qualidade, mas algo como introduzir testes automatizados é uma decisão que envolve muita gente, que às vezes até envolve política. Então você pode tentar vender o valor de testes automatizados, mas o contexto não pode ser desconsiderado nessa ação.

    Alguns conhecimentos dependem de pessoas sênior da equipe – acoplamento é um problema bastante complexo, e não faz sentido cobrar isso de forma individual; também cabe aos membros mas graduados trazer esse conhecimento pro time, dado que é um problema que exige muito conhecimento para resolver.

    O que o texto passa pra mim é uma cobrança individual de problemas coletivos. E isso é nocivo tanto para pessoas mais júnior, que se sentirão responsáveis por esses problemas, quanto para pessoas mais sênior, que fazem uma avaliação injusta do que é esperado de um integrante do time.

    Imagino que você queria passar uma mensagem da possibilidade de mudar o ambiente onde você está inserido – você é capaz sim de trazer melhorias para o seu time, de trazer novos conceitos. Mas é algo difícil, que demanda muita energia, que exige que você supere muitas barreiras organizacionais, muitas coisas pré estabelecidas. E se era essa a idéia que você queria passar, o texto parece minimizar o desafio que é ser essa pessoa.

    1. Você leu e refletiu sobre o que disse?

      Sobre os testes, você não pode obrigar os membros da sua equipe a fazerem, mas você pode fazer para você. Seu chefe pode até chegar para você e te proibir de fazer isso, a partir desse momento, você tem que escolher se está trabalhando no local certo, e se aceitar, você é cumplice, simples assim. Se você não pode largar seu emprego pq não acha outro melhor, talvez seja por que você não seja suficientemente bom para tal, e nada disso muda o fato que você produz um código ruim, aceite isso.

      Sobre os programadores novatos, leia com atenção: “Código de qualidade, limpo e expressivo, é o resultado da produção de um bom programador”, sendo assim, nenhum programador que chegou agora vai ser bom, e portanto, produzirá código ruim sem uma orientação. Todo programador que evolui com o tempo e fica melhor, acha seu código que fez a um bom tempo atrás ruim.

      Uma boa pessoa que presencia um assassinato e não fala nada, por mais que ela tenha sido ameaçada ou coagida, não a torna inocente, ela é cumplice, isso não a torna uma má pessoa, mas naquele momento em que ela se omitiu, ela fez uma ação ruim, aceite isso.

  5. A se fosse tão simples assim… até eu chegar em uma empresa que aceitasse ouvir um “NÃO” de um programador, imagina o “Zezinho” que saiu agora da faculdade

    1. Talvez esse seja um feedback para o “Zezinho” trabalhar melhor seus argumentos. Mas, geralmente o mais fácil é fazer um trabalho abaixo da média e jogar a culpa no ambiente. Não é?

  6. Ótimo texto Elemar, concordo em gênero numero e grau. É muito difícil digerir isso, mas quando você assim o faz, sua postura muda, e tende a melhorar o código que você deseja produzir.

  7. Também concordo com você Elemar. Como disse o colega Alberto, é uma questão difícil de digerir e a gente só se dá conta disso após uma madura auto análise. O livro “O programador apaixonado” trata diretamente essas questões. Recomendo a todos.

  8. Concordo em gênero, número e grau com o Philippe Hardardt.
    Uma questão complexa foi tratada de forma muito simplista. Traduzindo em miúdos:
    No mundo existem pessoas que matam outras, quer dizer que todo esse problema deve ser resolvido por apenas uma pessoa? Quer dizer que se o mundo for medíocre por esse fato (existir pessoas assassinas), a solução é simplesmente mudar de planeta? De jeito nenhum. Claro que você fazendo a sua parte as coisas ficam melhores, mas não se resolve uma questão complexa de uma forma tão simplista.

  9. Parabéns pelo artigo amigo,
    Sempre bom ler suas palavras, gostei tanto que irei referenciar em meu artigo que estou escrevendo!
    O trecho “Se você não escreve testes de unidade, é uma decisão SUA! Se o seu código está bagunçado, é uma decisão SUA! Se o nível de acoplamento está alto, é uma decisão SUA!” realmente nos da um tapa na cara sobre nosso código, porém tudo realidade, somos responsáveis por todo código que escrevemos e se existe um erro, fomos nós que deixamos ele lá.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

As you probably noted, my old blog posts are gone! It’s sad, but I had to take this way. Main reasons:...
Há tempos sou questionado e “assediado” quanto a possibilidade de ministrar cursos. Entre os temas mais frequentes estão “Arquitetura de...
Quando estamos desenvolvendo aplicações distribuídas, não devemos nos perguntar se teremos problemas de conectividade. No lugar disso, devemos nos perguntar...
Implementing synchronization for multiple threads in .NET is easy. There are a lot of options for doing that – for...
Most of my client’s applications code is for parsing, caching, storing, aggregating, protecting and sharing data! It is not the...
Qual deveria ser o resultado da execução desse código? using System; using System.Threading.Tasks; using static System.Console; using static System.IO.File; class...
× Precisa de ajuda?