E você acha que é programador?

Escrever software implica comunicar a uma máquina as intenções de um ser humano. Para qualquer comunicação é necessário um conjunto de símbolos que ambas as partes reconhecem e entendem. O problema com as máquinas de hoje é que elas entendem um número limitado de símbolos, muito menor que o dos humanos.

Para resolver isso, vários paradigmas foram criados buscando transmitir à máquina as intenções do ser humano. O mais vantajoso até hoje é o paradigma da linguagem de programação.

Programar significa utilizar uma certa linguagem para transmitir uma série de instruções ao computador. O ser humano escreve com símbolos que ele entende – palavras e símbolos textuais – e isso é transformado para o símbolos que a máquina entende através de um programa chamado compilador. Sim, você pensou certo. Se o compilador é um software, e um software é criado com um compilador, como se criou o primeiro compilador?

Parece uma charada mas não é. Acontece que existem diferentes níveis de linguagem. Linguagens de alto nível e de nível máquina ( “baixo nível” não se diz porque é feio). Os primeiros compiladores eram escritos em linguagens de nível máquina com os quais se criaram compiladores de nível mais alto e assim sucessivamente até linguagens de alto nivel como Java, C++ ou C#. O paradigma orientado a objetos é atualmente o paradigma das linguagens mais flexível e difundido, já que nele é possivel montar linguagens com outros paradigmas (procedural, funcional, etc) sem perda de generalidade.

Bom, temos uma linguagem. Toda a linguagem escrita tem um semântica e uma sintaxe. As de programação também têm. E toda a escrita é redigida por alguém.  No mundo editorial quem escreve é redator, mas no mundo do software, quem escreve para máquinas é programador. O texto que o programador escreve é chamado “código” (alguns chamam de código fonte, do inglês “source code“) para transmitir a ideia que é meio críptico e muito “secreto”.

Mas então qualquer um que escreve código é um programador? Tecnicamente sim, mas na realidade isso não diz muito sobre o que a pessoa faz ou sabe fazer. É como dizer que todos os autores de best sellers sabem escrever. Isso é verdade, mas não significa nada de útil. É uma tautologia se pensarmos bem.

O que é interessante para o mundo do software não é que a pessoa saiba escreve código,  o interessante é que a pessoa escreva bom código. Da mesma forma que autores escrevem bons livros. Para isso é preciso uma capacidade técnica maior que simplesmente escrever palavras. O programador é para o código o que um autor é para um livro e não apenas um redator. Bom, pelo menos um (bom) programador aspira a ser um autor e não um redator.

Da mesma forma que na língua portuguesa também nas linguagens de programação uma instrução pode ser escrita de várias formas. Umas mais claras que outras. E enquanto qualquer frase minimamente representativa da ideia basta para a pessoa comum, não basta para o autor que quer tirar o maior partido das palavras que pode usar para escrever em menos espaço o maior número de ideias. Mas também existe um limite. Ser conciso demais pode levar à confusão do leitor médio. Um autor não escreve para si, escreve para  os demais, para ser lido, já que o objetivo ultimo é vender livros difundir as suas ideias.

O programador sofre do mesmo problema. A linguagem até pode permitir que ele escreva mais em menos palavras, mas nem sempre isso é a melhor forma para quem lê. A variedade C de linguagens é conhecida por permitir uma ampla gama de formas de escrita – bastante crípticas, por sinal. E Java permite que tudo seja escrito usando códigos Unicode como \u0002 … Lá porque você escreve dessa forma, não significa que o deva. Essa é a diferença entre um autor e um redator. Essa é a diferença entre um escritor de código e um programador.

Mas saber escrever não é apenas colocar palavras juntas. Existe mais. Existe conhecer as palavras em si mesmas, as regras da linguagem (como escrever corretamente) e  conhecer a semântica da linguagem (o que as palavras significam). Para programadores isso significa saber o que cada palavra reservada faz, assim como as bibliotecas padrão que acompanham a linguagem.  Estas bibliotecas são como dicionários de palavras novas que podem ser (re)utilizadas a cada momento para enriquecer o texto.

Muitas linguagens, poucas palavras

Quando você aprende a falar e a escrever, normalmente, você aprende a língua de seus educadores, que por extensão é a língua do seu país. A sua língua natural. Também quando você programa você começa por aprender uma linguagem. A diferença é que essa, ainda não é, a sua linguagem natural.

Durante a vida do programador ele aprende muitas linguagens da mesma forma que aprendemos muita línguas. Afinal, traduções são limitadas, em si mesmas, na riqueza de transmitir o pensamento (as instruções) do autor, e ler o original, na lingua originalmente pensada para transmitir a mensagem, é sempre uma experiência mais rica. O programador passa por um tempo de busca da sua linguagem natural. Aquela que ele entende e é proficiente sem esforço. Imagine um prêmio nobel da literatura escrevendo em outra língua que não a sua.  Não é simples atingir o mesmo nível de intimidade com todas a linguagens. O programador descobre isso com o tempo.

Pensemos que você decide aprender todas as línguas faladas na Europa. Parece simples. Você até é capaz de agradecer e perguntar as horas em todas elas, mas você consegue manter uma conversa longa em todas elas. sem parecer um idiota?

Parecer um nativo é impossível. Você tem que ser um nativo para falar e escrever nativamente.  É um erro a pessoa pensar que pode aprender uma lingua/gem por tradução daquela que já conhece. Isso dá para o básico, não para o avançado, muito menos para o extraordinário.

Assim, quantas mais linguagens, menos palavras. Em termos de software, você pode conhecer muitas linguagens e fazer o básico em todas elas, mas só será proficiente em algumas e só será intimo com uma ou duas. É uma regra natural, seu cérebro não aguenta saber tudo todo o tempo.

O programador tem então três caminhos. Ser um autor memorável em uma linguagem, ser um “zé-ninguém” em todas ou ser um “meia-boca” em meia dúzia.

Profissionalmente você não ganhará bom dinheiro sendo autor memorável em uma linguagem nem “zé-ninguém” em todas. Você ganhará dinheiro sendo proeficiente em uma ou duas e se desenvolver com uma ou duas (o que é desenvolver é assunto para outro post). Ou seja, você acaba deixando de ser autor no meio do caminho para passar a ser editor, revisor,  professor ou dono de uma editora. É uma mudança de carreira, mas uma necessária nos dias de hoje (um pequeno segredo: ninguém quer realmente pagar para alguém escrever código bem. O mercado, hoje, está preocupado em escrever depressa. Não bem.)

O programador pode evoluir em amplitude ou em profundidade, mas não em ambos. É demasiado extenuante. O “problema” é que para evoluir ele precisa aprender pelo menos uma linguagem em profundidade.

Bom, então se o caminho profissional natural do programador é deixar de ser programador,  se ele se dispersa em várias linguagens, nunca será ninguem no mundo do software ?  Sim. Se você ficar perseguindo linguagens novas todos os dias acabará acordando – tarde – para o fato que não está em lugar algum. Como o andarilho que percorre e conhece todos os caminhos, mas  não onde voltar depois da caminhada. Pelo contrário, se você seguir uma ou duas linguagens, você atingirá o nível necessário para passar ao próximo nivel: desenvolvedor.

Não há vergonha nenhuma em você ser um bom programador em duas linguagens e excelente em uma delas.  Aliás, deveria se sentir dignificado com isso, já que é raro.  Mas é como o cara que saber fazer contas de cabeça com 1000 algarismos e de trás para frente: assombroso, mas ninguém pagará você para fazer isso. (Bom, quase ninguém. Se você for louco talentoso o suficiente para fazer isso, alguem pagará.)

Quando uma pessoa é inciada no mundo do software espera-se que saiba programar. O famoso “programador júnior”. O que ele sabe é escrever código. Não programar. Porque normalmente ele não entende o que escreve e não escreve coisa intelegível. Mesmo que funcione, ele não sabe por onde começar na hora de alterar ou re-escrever em outro lugar. É natural. Afinal todos tivemos que saber o alfabeto antes de saber escrever o nosso nome. O problema é que com tantas linguagens por aí é fácil a pessoa se frustrar e constantemente mudar de rumo. Saberá muitas linguagens, mas saberá dizer pouco.

Se você se apresenta como programador,  pergunte-se: eu sei realmente escrever bem? Os outros entendem meu código sem eu explicar? Estou seguindo as regras? Sei escolher as instruções e API certas ?

Sem saber , você pode ser um “zé-ninguém” em todas as linguagens ou um “meia-boca” na meia duzia com que se cruzou até hoje. E você, ainda, acha que é programador?

22 thoughts on “E você acha que é programador?”

  1. Autor , Sergio Taborda
    Se você se apresenta como programador, pergunte-se: eu sei realmente escrever bem? Os outros entendem meu código sem eu explicar? Estou seguindo as regras? Sei escolher as instruções e API certas ?

    Se eu fosse desmenbrar esse seu programador eu dirigia que ele é na verdade um analista de especificação, não é possivel que um programador tome todas as decisões da implementação, essa sua visão de programador é totalmente daquele programador que fazia programas em Pascal em casa ou Clipper para fazer softwares de poucas expressividade e extensibilidade.
    As coisas mudaram continuamos programando mas forma forma de programar não é o que projetamos para o especificio e sim para uma colaboração de tecnologias que devem ser entendidas e entre Use Cases, UML e nisso para o deployment de componentes especializados para compartilhar recursos com varais tecnologias e responsabilidade.
    É necessário abandor esse papel de programador e dar um responsabilidade de amplitude , as regras de negocios devem ser entendidas e tratadas de forma inteligente para a solução de projetos.
    Se agente for procurar o estilo de desenvolvimento para determinados profissionais de dizer que ele é programador e dizer que ser programador e escrever bons livros isso é uma verdadeira catastrofe.
    Veja você precisa de abstração e essa forma de produzir dados é estrutura-los, e nisso decidir pela a melhor tecnologia que sera envolvida.
    Cada cenário deve ser entendido de forma que o recurso tecnologico deve ser bem explorado, mas isso nunca foi tarefa de programador.
    É necessário conhecimento e saber muito bem o ramo que você esta atuando, seja Engenharia Civil, elaboração de software para determinadar calculos e geração de graficos complexos, ERPs entender toda a funcionalidade de Frameworks funcionais e como eles produzem invocações de suas solulções e fazer os redesenhos de objetos ou reuso de suas aplicações, entre outras entidades relacionadas.
    Acho que o assunto vale uma reflexão para o que procuramos hoje em termos de direcionar corretamente o termo profissional de tecnologia da informação, e não rotular qualquer um de programador por dizer que ele sabe as regras de linguagem de programação ou conhece o funcionamento de qualquer API.

    1. Dizer que o programador é um analista é uma contrasenso sem tamanho. É como dizer que o escriba é arquiteto. Não faz sentido você comparar coisas diferentes.
      Analista tem que saber analisar , o que singifica saber entender o que o cliente quer e como o sistema lhe dará isso. Ele tem que conhecer a parte tecnica o suficiente para saber com o que pode comprometer-se ou não, mas ele não programará. OS inputs do analista passarão pelos desenvolvedores e arquitetos antes de chegar nos programadores. Isso abstratamente, por que na realidade, e nos dias de hoje, analista, arquitetos, desenvolvedores, todos têm que saber programar. Mas como disse, Programador é aquele que é muito bom programando. É a sua especialidade. Ele é capaz de o fazer em menos tempo com mais eficiencia e menos bugs.
      Dar responsabilidade de modelador ou analista ao programador é um erro. A menos é claro que seja também desenvolvedor ou arquiteto. Escrever bom código não significa modelar bem , nem muito menos , entender bem o dominio do problema. Pensar isto é um erro comum. O cara contrata um programador pleno e já acha que pode ir pedindo UML e um monte de modelagem e analise sofisticada. Não!

      Programador é bom para qualquer dominio porque ele entende é da linguagem. O resto do modelo vem pronto para ele.
      O que se espera hoje em dia é que cada programador aspire a ser desenvolvedor e a saber modelar. Embora isso sejam utópico é uma necessidade em equipas multidisciplinares em que um programador excelente é caro. As empreas aspiram a ter um programador menos bom e um desenvolvedor um pouco melhor na mesma pessoa.

      Dar responsabilidade sobre modelagem ao desenvolvedor, tudo bem. Ao programador ? grande asneira!

  2. Autor:Sergio Taborda
    O programador é para o código o que um autor é para um livro e não apenas um redator. Bom, pelo menos um (bom) programador aspira a ser um autor e não um redator.
    Resposta:Marcio Duran
    Programar não é saber somente as regras de linguagem de programação , você tem que ter tecnicas aprimorada.
    Se for uma linguagem que atende um conceito procedural, saber ligar com estrutura de dados, se for uma linguagem que é regida por paradigma OO, saber utilizar OOP, image então que você deve decorar todas as sintaxes de Linguagem C, Pascal, Clipper etc.., é claro que existem entre essas regras sintatica diferentes mas não é o alvo que determina o que é programar, e sim ter conhecimento muito em profundidade aos requisitos que esse software vai implementar.
    Autor : Sergio Taborda
    Sem saber , você pode ser um “zé-ninguém” em todas as linguagens ou um “meia-boca” na meia duzia com que se cruzou até hoje. E você, ainda, acha que é programador?
    Resposta: Marcio Duran
    Isso é uma aversão do que é conceituar programador, você codificar algo que já foi modelado você nunca programou coisa alguma, mas lhe garanto se você tiver uma formação em Física(Por exemplo) irá projetar um software poderoso para resolver questões especificas em várias areas , seja para automação(diversas Industrias) , seja para outros setores que dependeram desses riquisitos ao sistema que irão fazer sentido o software existente.

    1. Marcio, você está enganado. Primeiro, eu disse que para ser programador vc precisa saber escrever código. Isso implica em saber escrever a linguagem, mas tb conhecer as API. Modelar não é responsabilidade do programador. É responsabilidade do Desenvolvedor. Colocar tudo no mesmo saco e cahr que um programador com experiencia saber modelar é o erro comum. A probabilidade é que ele não saiba. Se soubesse não se apresentaria como programador.

      1. Tudo bem , Modelar não é responsabilidade do programador, isso também incluiu que ele não deva saber algoritmo, estrutura de dados, ele deve simplesmente seguir o que é sintatico nas regras da linguagem de programação e APIs ?

      2. Quando eu disse modelar me rederia a modelar o dominio. O core da aplicação. É claro que ele tem que saber estruturas de dados e algoritmia já que isso é a essência de programar. Mas isso é apenas o como, e não o “o quê” nem o “por quê”. Essas outras coisas vêm de outros lugares. O programador é programador se souber o como. Se souber mais que isso, é mais que programador.

      3. Autor:Sergio Taborda
        “O programador é programador se souber o como.Se souber mais que isso, é mais que programador.”

        Resposta:Marcio Duran
        Sua argumentação responde o que é contraditório ao consenso do programador, ora se ele “sabe como”, já não é mais programador, já subiu nessa herarquia ou não herquia evolução de sua materia prima programar.

        A forma de se doutrinar programador é algo como esse fosse um ser inerte de questionamento e de pensar, ao adquirir abstração ao que deve ser modelo programatico na produção ao software, esse já sai da condição de sua função senão a mais complexa a interpreção sistemica.Será que estamos falando de programador ainda.

      4. Não. Eu não estou dizendo para tratar o programador como um ser abjeto. Bem pelo contrário. Programar, programar bem mesmo, é difícil! Requer estudo e paciência e acima de tudo talento. O que estou dizendo é exactamente isso. Programar bem é algo que deve ser valorizado e não há mal nenhum em ser apenas uma bom programador.

        Como também já comentei, ser apenas programador não o leva a lado nenhum no mercado de hoje, mas se você não for pelo menos um programador razoável em uma linguagem, nunca será nada mais. O foco de quem se inicia em software é primeiro saber programar bem em uma linguagem. Depois ele parte para o resto.

      5. Isso seria algo como MVC, design patterns certo ?

        acho que isso ja é necessario mesmo em uma linguagem só

  3. Em alguns pontos muito bom o artigo.
    Só discordo de você falar que aprender várias não é o ideal, que o ideal é 1 ou 2.

    Acredito que devemos abrir a mente e pensar que não estamos mais na epoca onde só tinhamos um foco, trabalhar a vida toda em um só lugar. O mundo é mais dinamico, e todos devemos ampliar os conhecimentos, por isso acredito que quando mais conheçemos mesmo que seja um pouco em cada, seremos programadores melhores. Cada nova linguagem que aprendo, melhoro meu estilo de escrever em outra, levo as coisas boas de uma para outra, e isso eu acredito que me torna melhor.

    Excelente post

    []’s

    1. Você pode aprender tanto ou mais usando sempre a mesma linguagem, já que aprender não tem nada a haver com a linguagem mas apenas com o seu espirito de curiosidade. Eu não disse que o ideal é aprender uma ou duas. O que eu disse é que para avançar para o proximo nivel vc só precisa dominar uma ou duas em profundidade. A ideia é assim: 1 ) quanto mais lato o espectro de linguagens que o programador conhece, menor a profundidade em que as conhece. e 2) Para se tornar desenolvedor o programador precisa dominar pelo menos uma linguagem profundamente.
      O resto deriva daqui.

    1. Verdade Sergio !!!!

      Se puder passar o seu Twitter eu gostaria de saber também até msn, todas as formas de midias pra a gente bater papo e ficar antenado em novidades !!!

      Abraçoss !!!!

      1. Já não era sem tempo mesmo ^^, como você mesmo escreveu no seu twitter, só falta agora usar \o/ ativamente na divulgação das suas ideias, de coisas que achar interessante, e quando você fizer a produção de pensamento.

        Sei que existe o RSS, mas não deixe de divulgar pelo twitter também quando sair novos artigos.

        Abraços, Tomaz Lavieri

      2. Sim, design passa por mvc e design patterns. arquitetura passa por decidir tecnologias, api, distribuição, protocolos…

  4. Olá Sergio!

    Hoje estou a ler alguns dos seus posts e por mais que sejam antigos (2009 e hoje estamos em 2012) são muito interessantes e geram boas discussões.

    Parabéns e continue escrevendo!

    Abraços!

Deixe uma Resposta

Please log in using one of these methods to post your comment:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s