Você não é pago para programar!

Você, que desenvolve software e programa todos os dias em que vai ao trabalho, recebe o salário no final do mês por quê? Bem, o título estraga a surpresa, mas é isso mesmo. Você não é pago para programar.

O código fonte que você gera todos os dias é, na verdade, um subproduto do que é realmente o seu trabalho. Mas por que então você foi contratado? Generalizando:

O seu trabalho é resolver problemas de negócio da sua empresa.

Entregar resultados, através de tecnologia. Isso não significa necessariamente escrever linhas de código o tempo todo, nem exclui tal tarefa. O código é uma das formas de resolver os problemas da sua empresa, do seu usuário. Mas há outras formas que não envolvem commits, não envolvem um framework novo, nem uma linguagem de programação pouco conhecida.

Colocar um novo site no ar com wordpress, usar um SAAS que resolva 90% do seu problema, contratar um sistema de helpdesk em vez de escrever seu crm e até mesmo usar o bom e velho excel/spreadsheets são muitas vezes ideias mais rápidas, baratas e que vão criar menos código legado e manutenção. O seu MVP pode envolver bem menos programação do que você imagina.

Repare que isso já está no nosso inconsciente: detestamos quando nos medem a produtividade através de métricas como linhas de código e número de commits.

Linhas de código são um compromisso a longo prazo. Você vai ficar com elas no seu repositório por muito, muito tempo, e precisa garantir que elas funcionem enquanto estão em produção. Isso não quer dizer que você não precisa ter um conhecimento profundo de programação. Pelo contrário. Para poder julgar melhor quando usar e quando não usar determinada ferramenta e linguagem, apenas uma grande experiência vai poder te ajudar a decidir e a encontrar alternativas.

Certamente não sou o primeiro a fazer essas observações. Krzysztof Zabłocki diz em um artigo incrível sobre soft skills:

As pessoas te contratam porque elas precisam resolver problemas específicos do business delas, seja numa app ou outra coisa, não para escrever código somente pelo código. Entregar resultados importa.

E também há o artigo de quem eu copiei o título descaradamente:

Nós não somos pagos para escrever código, nós somos pagos para adicionar valor (ou reduzir custos) do negócio.

A sua tarefa de hoje então é essa: você é pago para fazer o quê? Qual é o valor que você pode entregar para a sua empresa, para a sua comunidade open source, para suas amigas e amigos programadores? Sim, pode ser que haja bastante código envolvido, mas também pode existir uma maneira mais fácil e simples de chegar a esses mesmos resultados.

Programe para resolver problemas e entregar resultados, não apenas por programar. Novamente: isso não impede de você almejar ser um exímio programador, continua necessário.

25 Comentários

  1. Rafael Rossignol 27/11/2017 at 09:15 #

    Muito boa a reflexão.
    Vejo muita gente entrando no mercado sem entender isso. E muita gente que está no mercado a anos sem entender isso. Do mesmo jeito que um mecânico usa ferramentas pra manter um carro andando. Nós usamos ferramentas (software que nós programamos e que programaram pra nós) pra resolver problemas.

  2. Michael Nascimento Santos 27/11/2017 at 09:32 #

    Ainda faltou uma coisa que fiz muitas vezes e os usuários/clientes agradeceram muito: provar que uma ideia de negócio não funciona ou é até nocivo pro futuro da empresa antes de sequer começar o projeto. Já saí de reunião pra fazer SELECT ou puxar relatório que mostrava que a premissa do projeto estava toda errada e que fazer o que pediram ia só causar mil problemas. A alegria da pessoa no final da reunião era incrível.

  3. Paulo Silveira 27/11/2017 at 09:38 #

    Isso é um ponto ainda mais interessante! Tem vezes que eu mesmo peço um relatório super complicado de ser implementado, mas na verdade só precisava de um numero naquele instante e nunca mais iria usar esse relatório novamente.

  4. Rafael Ponte 27/11/2017 at 09:47 #

    Excelente post, Paulo.

    Acredito de verdade nisso e tento seguir no meu dia a dia!

    Um detalhe importante no seu post é quando você diz: “Linhas de código são um compromisso a longo prazo.”. É aquela velha história do porquê devemos escrever código de qualidade, testes e automatização de processos: o mais caro de um software não é o desenvolvimento, mas sim a manutenção.

  5. Rodolfo Castanho 27/11/2017 at 10:24 #

    Isso só piora em empresas gigantes, onde o dinheiro é abundante. Muitas vezes você é obrigado a desenvolver uma “solução” inútil para agradar ao ego de poucos. É um desrespeito impressionante pelo dinheiro da empresa.

  6. nem tanto 27/11/2017 at 13:56 #

    Considero importante uma ressalva :
    Se você recebe um salário de programador você deve escrever programas.
    Se você recebe um salário de Engenheiro de Software, ai sim você deve resolver problemas, “arquiteto de soluções”, “engenheiro de software” … Essas são skills que custam $$. Salários de programador devem por respeito a nossa área contemplar apenas profissionais capazes de programar, resolver problemas é mais um skill e deve ser remunerado tal qual, caso contrário, é 1 programador e 1 analista.

  7. Paulo Silveira 27/11/2017 at 13:58 #

    Entendo seu ponto, mas o meu realmente é diferente. E acho que o ponto de vista não é tão macro assim. Eu só quero evitar o overengineering. Não estou pedindo que programadores venham com soluções rebuscadas já pensando em cac, ltv, capex ou qualquer outra coisa de business.

    Eu acredito que programadores devem resolver problemas. Muitos deles com código. Muitos outros sem código. Assim como médicos resolvem doenças com remédios e cirurgias. Muitas outras sem remédios nem cirurgias.

  8. Pires elis 27/11/2017 at 22:30 #

    Em alguns momentos as regras de negócios não estão bem definidas, as vezes pela complexidade do negócio, as vezes por falta de conhecimento dos POs, independente desses detalhes, a justifica de compra de horas é a resolução de problemas. Não quero causar polêmica, mas expôr nossas opiniões, as vezes é uma oportunidade de compartilhar ou de aprender com os mais experientes. Com relação a “programadores escrevem programas e engenheiros resolvem problemas”, eu diria que ambos resolvem, sendo que, engenheiros mais focados nos problemas de infraestrutura de aplicação e programadores nos problemas de regras de negócios…..

  9. André Lima Girão 28/11/2017 at 09:08 #

    É Importante ter esta consciência, o grande caos que vejo hoje no nosso mundo é a grande demanda de soluções que devem ser implementadas paralelamente em pouco tempo e mal especificadas, resolvendo uma solução é criando outros problemas.

  10. Daniel 28/11/2017 at 10:00 #

    Bom dia, acho que existe uma interpretação errônea ( proposital ) entre o que a equipe gerencial considera a tarefa do programador e o que o programador experiente faz. A bem da verdade a escolha do termo “arquiteto” para designar a pessoal que “concebe” o sistema não é apropriada: arquitetos cuidam de estética e funcionalidade, engenheiros transportam para o mundo real os devaneios desses sujeitos. Além disso, o simples ato de ter uma ideia e transpor para um documento de especificação gerando uma pletora diagramas UML não faz o projeto vir a realidade mais facilmente por si só. A concepção em termos abstratos não facilita a tarefa do programador ela apenas proporciona um guia ou uma limitação quando mal feita. Um exemplo, faz algum tempo implementei um protocolo de automação comercial que possuía uma especificação comum para todos fabricantes e descrevia o protocolo em si mas não dizia como fazê-lo. E além disso era vaga.
    Partindo de uma versão anterior que implementava um protocolo proprietário reformulei essa implementação, atualizei para uma linguagem moderna ( de C para C++ 11) trazendo orientação a objeto ao projeto e reduzi o uso de heap e stack. Meu cargo era engenheiro de software mas não me iludo: o que fazia era tarefa de um programador, uma pessoa que transporta uma abstração para linhas de código funcionais.
    Uma coisa é dizer “uma queue precisa ser implementada para guardar as transações e ela deve de comportar como x,y,z” outra é se debruçar nos meandros e particularidades da STL ou posix threads para fazer isso se tornar realista. Acho que a grande falácia de engenharia de software é transformar o programador em um mero peão que converte UML em código. Como sempre comparo: o gerente é o Shogun, o arquiteto o monge taoista e o programador é o samurai. O programador trilha esse caminho sem volta do “meifumado”, ele transforma abstrações em funcionalidades otimizadas e de fácil manutenção. Ele realiza o que precisa ser feito utilizando esmero, inteligência, paciência, sagacidade, criatividade e inventividade. E não se vê fora desse caminho.

  11. José Vidal 28/11/2017 at 10:12 #

    Ficou muito genérica sua comparação do programador com médico, já que existem muitos segmentos na medicina, cardiologia, pediatria, ginecologia…
    Um ginecologista não resolve problemas de um cardiologista, assim, como um programador não deve resolver problemas de um analista de suporte, por exemplo.

  12. Luiz Carlos Oliveira 28/11/2017 at 11:17 #

    Muito bom o texto, e expando para outras áreas. Seja um analista de marketing, um designer ou um programador, toda a equipe precisa ser proativa, procurar problemas pra resolver e fazer a sua tarefa na agencia de modo que traga resultados ao todo, só assim se tem uma equipe forte. Parabéns pelo artigo Paulo!

  13. Paulo Silveira 28/11/2017 at 11:20 #

    Vidal, como eu disse no meu texto, é uma generalização. E nenhuma analogia é perfeita mesmo. Mas acho que o recado ficou bem claro. Programar por programar não necessariamente traz resultados. Se não estiver alinhado com os objetivos finais do cliente, do que a historia fala, de economizar recursos, de facilitar trabalho, nào adianta ser o melhor código do mundo.

  14. Leo 28/11/2017 at 12:00 #

    Muito legal seu texto ! Vou começar a ler mais temas do blog e acompanhar mais publicações agora que vou entrar de férias da faculdade, espero poder aprender muito e ler muitas coisas com a mesma qualidade !! Obrigado pelo texto e ideia passadas.

  15. Roberto Marin 28/11/2017 at 12:06 #

    Daquelas coisas “óbvias e naturais” que precisamos relembrar e dizer todo tempo, afinal justamente as coisas óbvias e naturais são as mais subjugadas e esquecidas. Assim como o amor de um filho pela mãe, de um marido pela esposa…

  16. Thiago Marques 28/11/2017 at 13:46 #

    Dps de ter lido alguns comentários, e alguns fizeram comparação de uma área com outra e tals, mas alguns falaram que o programador recebe salário de programador e o engenho recebe o valor de si . Mas o problema msm é que o cara que trabalha com engenheiro de software faz algumas parte do trabalho do programador mas so acontece isso pois o cara não vai falar que não vai fazer aquilo! pq não é da área dele ainda mais no país em crise é logico que o cara vai querer agradar quem paga -lhe o salário então acaba fazendo
    Ex: eu pretendo trabalhar como programador e entrei recentemente ne uma empresa suponhamos que ja sei administrar redes e de algum problema no servidor mas eu sei resolver se meu chefe pedir, é claro que vou fazer apesar de não ser meu trabalho, é melhor fazer um favor e ter crédito com chefe do que ter alguém que ‘não vai mt com minha cara’

  17. marcos 28/11/2017 at 16:26 #

    Ótima reflexão, nos ajuda refletir e contextualizar nossas atividades.

  18. Eliseu Ribeiro 28/11/2017 at 20:52 #

    Acho que tá a dar a entender que o programador é alguém contratado para resolver problemas. Mas se formos por aí, todo o tido de carreira baseia se em resolver problemas. Alguém que desenhe ou produza algo está a fazer isso de uma forma mais complexa ou simples. Contudo concordo que o programador tem de ter uma capacidade diferente de resolver problemas e criar algoritmos na sua cabeça. É uma capacidade essencial de um programador, mas não continua a ser pago para escrever código, como um mecânico é pago para resolver um problema.

  19. Antônio Neto 29/11/2017 at 07:19 #

    Excepcional observação, Paulo.

    Aproveiro para ampliar sua fala – resolver um problema – para além do programador, do time de desenvolvimento, mas para todo o time de tecnologia. Entendo que devido às características de cada área de atuação – desenvolvimento, banco de dados, redes e segurança – a especialidade do profissional faz com que, algumas vezes, a parte mais importante seja negligenciada: o negócio.

    Penso que ainda falta o desenvolvimento ou o aperfeiçoamento de uma visão holística na companhia como um todo, não exclusivamente apenas do time de tecnologia. Muitas vezes decisões são tomadas sem uma profunda investigação, e isso nos remete para várias outras disciplinas. É o velho esteriótipo nosso: não planejar.

    Quem nunca se deparou com a situação que o time de TI precisa fazer uma mudança na infraestrutura mais ou menos assim: “é rapidinho, é só aplicar, derrubar e subir o servidor”.

    E se o negócio afetado é crítico? Quantas cifras serão perdidas em alguns minutinhos, e se houver algum problema na hora da subida? Isso porque não falamos de sistemas que envolvem a vida de pessoas – saúde, segurança pública.

  20. Mateus Queiroz Correia 30/11/2017 at 09:35 #

    Excelente post! É interessante esse foco em resolver problemas… E essa visão é necessária em todos envolvidos. Nem todos tem a sorte de ter líderes ou clientes que sabem disso!

    As vezes o próprio cliente pede “Quero ter meu App” quando a pergunta deveria ser qual a melhor forma de validar minha hipótese ou qual a melhor forma de atender uma jornada de público alvo específico. E cabe ao time de desenvolvimento tentar abrir os olhos do solicitante.

    Gostei muito sobre essa visão que há a preocupação de resolver o problema com a ferramenta correta, para diminuir o custo de manter. Cheguei a escrever um artigo sobre isso, relacionado a app, essa semana no linked in:
    https://www.linkedin.com/pulse/o-que-considerar-para-or%C3%A7ar-seu-app-mateus-queiroz-correia/

  21. Fernando Pires, Jr 30/11/2017 at 15:51 #

    Em contrapartida tem o cara que não quer programar. Só quer saber de marcar reuniões, fazer modelos, cronogramas e achando que o programador só precisa digitar apesar de ele só ter documentário óbvio e deixado um monte de ambiguidades.

  22. Rafael 30/11/2017 at 17:44 #

    Concordo com o Amigo Eliseu, partindo-se deste pressuposto, todas as profissões foram feitas para resolver problemas e utilizam-se de um meio para resolve-los. O nosso é o código.

    Claro que, como programadores, devemos estar bem alinhados com as regras de negocio que permeiam um software para desta maneira evitar com que produzimos código desnecessário. É um requisito básico para nossa profissão.

    “Entregar valor para a comunidade”, me parece um olhar meio vislumbrado ou eu não entendi claramente o que significa isso.

    Sobre o artigo no qual você se baseou, acredito que lá a abordagem foi um pouco diferente, o autor usou essa frase para ilustrar o que eles estão chamando de “Taco Bell Programming”, que a grosso modo diz que com um conjunto básico de ferramentas você pode construir N coisas. Ou seja, o Menos é mais.

  23. Marcio 01/12/2017 at 00:09 #

    Isso mesmo, trabalhamos para resolver o business do cliente, quanto ao código ele pode ser uma inteligência de um legado, como uma solução presente que resolvemos quando programamos, mas a expertise de codificar ela é sempre importante para resolver pequenos ajustes sistemicos !!!!

  24. Paulo Silveira 01/12/2017 at 15:54 #

    tem esse tipo tambem Fernando 🙂

  25. Raphael Lacerda 04/12/2017 at 11:52 #

    fala isso pra minha mulher…. ela acha que esses “programinhas” vem do Japão

Deixe uma resposta