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?

De Sênior a Gerente

Se você é desenvolvedor a algum tempo com certeza já se deparou com a questão da promoção de sênior a gerente. Por algumas razões que iremos analisar as pessoas não só aceitam este fato como esperam por ele.

Não é incomum durante uma entrevista perguntar para o candidato a uma vaga de desenvolvedor onde ele se vê daqui a 5 – 10 anos, e a resposta costuma ser “como gerente”. A razão para isso é simples: dinheiro. Historicamente a pessoa na posição de Gerente ganha mais que a pessoa na posição de desenvolvedor, seja qual for a sua classificação ou maturidade. Mas esse, espante-se, não é o único fator. A chamada da sereia do poder é prazerosa.

As empresas acham que promover a pessoa de desenvolvedor sênior para gerente é uma coisa boa. Não é. E as pessoas na sua extrema visão curta só enxergam essa opção.  Não é segredo que todos queremos ganhar mais, então quando a pessoa diz que quer ser gerente o que ele está dizendo, na verdade, é que quer mais dinheiro. Nesse ponto eu desclassifico o candidato já que ele ainda não deixou de ser júnior e já quer ficar mandando nos outros.

Por razões que o tempo conhece as empresas se habituaram a pensar que criar software é dificil e que a probabilidade do projeto de software dar errado é grande. Portanto, os diretores que não querem ver o seu na reta adotam a política de: 1) por um lado criar bodes expiatórios na pessoa do gerente. Se o projeto der errado eles serão culpabilizados e o diretor manterá o seu emprego; 2) é preciso microcontrolar tudo o que os desenvolvedores fazem para que assim não existam imprevistos e não existam atrasos.

O curioso é que são exatamente essas medidas de “contingência” que fazem o projeto atrasar.

O resultado é que em uma hierarquia de um diretor de produção de software é comum existirem vários “gerentes”, os quais tentam microcontrolar a equipe de desenvolvimento. A pessoa no papel de gerente  rapidamente  sacrifica os membros  da equipe para manter um salário um pouco melhor que eles sendo que ele seria incapaz de realizar o mesmo trabalho. A imagem do feitor de escravos me vem à mente.  O pior de tudo nem sequer é isso. O pior de tudo é que, normalmente, a pessoa na posição de gerente não tem capacidade técnica nem política para desempenhar esse papel. Sim, a pessoa foi desenvolvedor sênior 20 anos atrás. Isso não lhe dá conhecimento nenhum sobre como o software é feito hoje.  Não apenas a linguagem e o paradigma utilizado hoje são diferentes, como também as técnicas e ferramentas em volta (uso de repositório de código, por exemplo). Quanto mais cedo a pessoa passou de sênior a gerente mais óbvio é este fato, no limite absurdo de comparar, por exemplo, a plataforma Java com linguagens como Clipper, Delphi ou VisualBasic. Você já reparou como o seu gerente reduz tudo a operações no banco de dados e desconhece o conceito de “Servidor de Aplicação” ou o confunde com “servidor web” ?

Quanto à parte política, a pessoa na posição de gerente não tem qualquer escruplo ou vergonha em pedir ao desenvolvedor para trabalhar extra para manter o (famoso) cronograma. Mas  peraí! Não é o gerente que criou o cronograma? Se houver atraso não é responsabilidade dele? Infelizmente no mundo atual não. Nada nunca é responsabilidade do gerente e ele faz de tudo para que assim não seja. O clássico é pedir que os desenvolvedores estimem o cronograma. Ele pede que “estimem” mas o que ele quer dizer é “assinem com sangue um chute de quanto tempo vai ser necessário”. Depois o gerente faz a seguinte conta: se a “estimativa” é X então como temos N desenvolvedores vai demorar X/N tempo. A estimativa … quer dizer, a corda no pescoço da equipe de escra… desenvolvedores ficou ainda mais apertada. Nestas condições totalmente indecentes a equipa tem zero motivação , zero ajuda, zero autoridade, total responsabilidade e lá para quando faltarem dois meses para o final do prazo do cronograma fajuto a equipa ainda passa a ser chicoteada diariamente com a pergunta “Quantos porcento falta para estar pronto?”. O que revela que a pessoa no lugar de gerente não sabe o estado das coisas, ou seja, ela esteve fazendo o quê enquanto os desenvolvedores criavam o software? Esperaria-se que estivesse exatamente calculando quanto tempo falta. Certo ?

O diretor (a pessoa hierarquicamente acima do gerente e que o contratou como bode expiatório profissional) não se preocupa com a performance do gerente. Apenas com a da equipe. Afinal todos os males advém da equipe de desenvolvedores. Esses seres abjetos que o diretor é obrigado a tolerar para poder vender alguma coisa a alguém. Ao diretor tanto lhe faz se o gerente explora os desenvolvedores da mesma forma que o senhor lhe importa um pepino que o feitor chicoteie os seus escravos. Não só isso, como o diretor espera que o gerente aja assim.  Tanto isso é verdade que em empresas maiores (leia-se “com mais níveis de isolamento dos seres abjetos da equipe”) existem uma camada de gerentes. O diretor delega para N gerentes, cada um deles delega para M outros gerentes, que delegam a outros … em um cadeia até que se chega no gerente que controla a equipe. Vejam bem o estado da coisa. O gerente não serve para gerenciar o projeto. Não. Isso é fácil, qualquer excel ou project pode fazer isso. O gerente serve para controlar a equipe em uma mistura de babysiter com capataz e a empresa é tanto maior quanto mais gerentes forem controlados por outros gerentes.

Quantos “gerentes” estão acima de si na sua empresa? Dito de outra forma, quantas pessoas podem vir chateá-lo na sua mesa com exigências para ontem ?

Parece então óbvio porque um desenvolvedor quer virar gerente: 1) mais dinheiro no fim do mês; 2) menor ou nenhuma responsabilidade sobre o projeto ou o software; 3) direitos de fustigar a equipe como e quanto quiser; 4) receber todos os louros dos superiores quando o projeto dá certo; e 5) nunca ser “castigado” por nada.

Parece muito melhor que a vida de um desenvolvedor que 1) ganha pouco para aquilo que faz e a responsabilidade que tem; 2) tem toda a responsabilidade sobre o resultado mas nenhum autoridade para guiar o processo; 3) é interrompido a todo o momento com perguntas idiotas que não são da sua responsabilidade responder como “Quantos porcento do projeto já está completo?” 4) nunca recebe o agradecimento real de ninguém nem o reconhecimento real do esforço (eu disse real e não aquele tapinha nas costas ou aquele e-mail de agradecimento modelo B) e 5) é sempre “castigado” por tudo no limite de ser despedido por justa causa por erros cometidos pelo gerente, pelo diretor ou até pelo erro estratégico da empresa como um todo.

Se você teve estômago para ler até aqui, parabéns. Vejamos agora um pouco do outro lado. Afinal, nem todo o mundo é mentecapto e alguma pessoas querem realmente ganhar dinheiro a sério e não apenas para pagar as contas. Qualquer economista, por muito ruim que seja, sabe que uma forma de ganhar mais é gastar menos. É fácil gastar menos com desenvolvimento de software.

Primeiro, foque no que dá dinheiro. No caso do software o que dá dinheiro é o software, funcional e entregue. Muito importante o entregue. Segundo, desenvolvedores são pessoas com educação superior e qualificadas a resolver problemas lógicos e matemáticos complexos. Não os trate como animais de curral. Converse com eles e ouça o que eles dizem. Melhor que ninguém eles sabem quais são os problemas com o software. E ninguém melhor que ele sabe como traduzir o que é esperado pelo mercado em código. Eles podem ajudá-lo não apenas a resolver problemas técnicos mas até problemas que impactaram na venda do software ou na aceitação pelo público. O seu foco é fazer software, então dê recursos aos desenvolvedores para o fazerem. O foco da empresa é o software e todos devem ajudar a conseguir que ele seja feito nas melhores condições de mercado possíveis.  Simplifique os processos. Coloque no lixo a hierarquia militar de passar ordens entre níveis.  Muita informação se perde dessa forma quando o assunto é complexo como um software. Pode até funcionar para a guerra onde as ordens são simples, mas não numa empresa de software.  Uma muito boa forma de conseguir isto com facilidade, sem gastar dinheiro e com um retorno imediato é substituir todos os que se dizem gerentes por desenvolvedores sênior (realmente sênior e não apenas júniors disfarçados). Implementar Scrum também não é má ideia, mas se você tem um outro processo que realmente funciona para a sua empresa (eu disse, realmente - o que significa que todo o mundo na empresa acha que funciona) então mantenha esse.

Implemente um mecanismo de carreira. Não separe os desenvolvedores por anos de trabalho  e sim preveja que todos têm mais do que uma habilidade. Não é desmérito para ninguém só saber programar bem. Saber escrever código limpo, bem estruturado, que aproveita ao máximo as funcionalidades da linguagem não é pecado. Nem todos têm  de ser arquitetos. Não é desmérito para ninguém ser um bom tester que sabe escrever testes automáticos com boa cobertura.

A vida de um desenvolvedor têm várias partes e não são: júnior , sênior, gerente. São: programador, engenheiro,  tester, designer, analista e arquiteto. E isto não é uma sequência. Cada um pode ser mais do que uma coisa. Aliás tem que ser mais do que uma. Existe o básico que é ser programador (saber programar não é suficiente) e existe o complexo: analise é uma tarefa ao mesmo tempo técnica, interpessoal e até política onde poucos engenheiros e arquitetos se sentem bem. Moral da história, monte uma equipe multidisciplinar sem gerentes fustigadores mas com pessoas que ajudem a resolver os problemas políticos, burocráticos e administrativos e deixe o desenvolvimento com quem entende.

A próxima década não terá pena de quem não se ajustar à nova ordem. Quem ainda quiser ficar fuçando no código como se fazia à 20 ou 30 anos atrás não vai chegar a lado nenhum diferente da falência. A concorrência é maior que nunca e o mercado de tecnologia é maior do que nunca. Quem não primar pela qualidade não vai vingar.

A escravatura das fábricas de software tem que acabar. O primeiro passo é que você, desenvolvedor,  não aceite esses termos.  Aspire a ter capacidades de análise, conhecimento de arquitetura, design ou teste, e não a ser um gerente mentecapto e escravocrata.  Afinal, você gostaria que pensassem de si o que você pensa do seu gerente?

De Júnior a Sênior

Vivemos uma época transformadora no desenvolvimento de software . A partir da segunda década do século XXI só vai sobreviver quem fizer software barato (leia-se: sem “gordura”),  recheado de valor, feito com responsabilidade e entregue no prazo. É a hora de separar o trigo do joio.

Os sufixos júnior e sênior me aborrecem enormemente desde sempre. Especialmente quando utilizados fora de contexto ou como sinônimos de “tempo de serviço”. Mas o que realmente faz de você um júnior ou um sênior?

A resposta a esta pergunta pode não ser o que você esperava ouvir. Mas se quiser trabalhar com software nos próximos decênios é bom que a aceite.

A diferença entre júnior e sênior não está na idade, nem no tempo de serviço. Está na maturidade técnica e na maturidade profissional.

Para um júnior, trabalhar muito é sinônimo de “bom”. Trabalhar até altas horas e acumular um monte de horas extra é um sinal de dignidade. Para um sênior só de isso ser sugerido, é um insulto. O sênior sabe que se algo der errado não é com horas a mais ou fins de semana longe da família que o problema se resolve. Bem pelo contrário. Se agrava. Então a posição do sênior é não ter problemas. Para isso ele usa todos os seus skills técnicos para que problemas não aconteçam ou sejam facilmente mitigados. Um bom design, uma bateria de testes automatizados e muito refactoring são ferramentas básicas do sênior para não deixar “a vaca ir p’ro brejo”.

Para um júnior, boas práticas são subjetivas e discutíveis e gambiarra é um martelinho de ouro que resolve todos os problemas com uma pancada só. Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoniaco intolerável que tem ser exorcizado a qualquer custo de todo aquele de quem se apodera. O sênior sabe que seguir bons princípios e boas práticas fazem as coisas fluirem mais facilmente e responder mais eficazmente a imprevistos enquanto o júnior ignora que as suas gambiarras são aquilo que está fazendo seus fins de semana serem perdidos na empresa ao invés de poder estar em casa ou em passeio com os amigos ou a namorada.

O júnior acha que o objetivo de construir um software é fazer o programa funcionar. O sênior sabe que o objetivo de criar um software é fazer uma aplicação de fácil manutenção. Pois é na manutenção que está o custo e não na criação.

O júnior acha que com 3 anos de serviço pode ser um pleno. Um pleno tapado será se pensa que o tempo traz experiencia. O trabalho é que traz experiencia. O sênior sabe que desenvolver software é uma arte e uma arte não se aprende com o tempo e sim com a prática.

O júnior tende a usar pouco a cabeça, tentando seguir ao máximo “receitas de bolo”, sem se ater ao contexto. O sênior racionaliza o problema e encontra a solução mais flexível até à solução. Normalmente esta solução só é possível com o uso de alguma técnica avançada de desenvolvimento de software como o uso de  objetos  em vez de rotinas. Como para o júnior boas práticas são piadas que se contam aos amigos este tipo de técnica passa longe.

O júnior fica feliz quando o dinheiro entra na conta todo o mês, o sênior dorme tranquilo quando sabe que o código que a sua equipe fez tem qualidade e pode ser mostrado a qualquer um.  Bom, nisso o junior é muito semelhante. Ele também não tem nenhuma vergonha do código que escreve. Acontece apenas que ele não a tem porque não enxerga as tremendas burrices que o seu código exclama.

Maturidade profissional não se ganha com o tempo. É preciso que a pessoa tenha orgulho no que faz e prime pela qualidade do que faz. Só isso a fará se aprefeiçoar.

Se você acha que ainda é júnior, não se desespere, aprimore-se. Acredite que as boas práticas são realmente boas e apreenda-as. Use-as. Tenha orgulho do que faz e vergonha dos seus erros. Procure qualidade e não quantidade. Procure terminar antes do prazo e com mais funcionalidades e não se faça de preguiçoso para poder arrecadar algumas horas extra. Seja profissional. Desconfie de qualquer um que o tentar levar pelo mau caminho.

Se você conhece alguém nas condições descritas aqui como júnior que ocupa um cargo sênior não tenha medo nem vergonha em o desafiar. Tanto tecnica como profissionalmente. Teste-o. Ele pode estar enganando você. E se você é diretor de gerentes de TI, a probabilidade de estar sendo enganado por um júnior se passando por gerente é quadriplicada. Cuidado, abra os olhos.

Se você é um sênior, tal como descrito aqui, meus parabéns. Agora é hora de elevar a qualidade exigindo mais dos que estão à sua volta. Ou dobra ou parte. Não há meio termo. O seculo XXI não terá pena de quem for conivente com a mediocridade.

Sistema pequeno. Mente pequena ?

Existe uma moda de falar em sistema pequenos. “Posso fazer xxxxx ? é para um sistema pequeno.” , ” se eu fizer xxxxx tudo bem, certo? é apenas um sistema pequeno” – todos já ouvimos isto e até alguns já podem ter dito. Normalmente xxxxx é alguma gambiarra.Do tipo, posso fazer meu sistema apenas com métodos estáticos ? é um sistema pequeno.

Para mim isto é uma falácia do pensamento. Não existe sistema pequeno. O sistema pode nascer pequeno – modesto em funcionalidades – mas ele tende a evoluir. Mais cedo ou mais tarde esse sistema irá precisa de manutenção (leia-se corrigir algum problema ou aumentar as suas funcionalidades). Com a manutenção o sistema irá crescer.

Esta lógica leva-me a crer que quando alguem diz “sistema pequeno” está pensando em “sistema fast-food para enganar trouxa”, ou seja, “vou fazer esta porcaria, vender por uma nota e ganhar uma nota. Se o cara me processar depois, eu não vou estar mais aqui”. Este tipo de pensamento é triste. Mostra que ha muitos mercenários por ai que não têm qualquer honra no trabalho que fazem e tudo o que querem é dinheiro. Software, infelizmente, não dá dinheiro. Boas ideias dão dinheiro. Boas execuções dão dinheiro.

Será então que quem pensa em sistemas pequenos tem a vista curta ? Que não pensa a longo prazo ?  Este tipo pensamento pode-nos levar por um longo caminho de asneiras. Por exemplo, se o sistema é “pequeno” porquê construir camadas ? porque isolar componentes ? porquê escolher frameworks e tecnologias que trabalham bem juntas? porquê seguir boas práticas ? aliás, porquê aprender boas práticas ? porque investir aprendendo Orientação a Objetos ? porquê levantar requisitos ? porquê sequer fazer direito quando pode fazer rápido ?

Uma outra face desta moeda furada é o comum “vamos fazer só assim, e depois a gente vê como faz o resto”. Basicamente, traduzindo, significa “vamos fazer um sistema ‘pequeno’ e depois o aumentaremos”. Mas o que é pequeno aqui é a visão. Visão curta. Pensar grande corta tempo e custos porque se pensa em todas a partes. Não ha imprevisto nem surpresas. Podemos componentizar as coisas e deixar alguns componentes com implementações mais simples do que gostaríamos – mais simples, não mais “pequena”.

Aliado ao tamanho “pequeno” temos o intervalo de tempo “pequeno”. Frases como “vamos fazer um sistema pequeno para vender logo” ; leia-se : “vamos produzir um porcaria qualquer só para por no mercado sem pensar como isso afeta a nossa imagem , aumenta o risco e produz custos não estimados e altos”.

Os Romanos pensaram grande quando disseram “vamos conquistar o mundo”. E para isso criaram um estrutura social completa, infraestrutura. Infraestrutura sem a qual não seria possível conquistar nada nem ninguém. Criaram estratégias pontuais para alcançarem o objetivo maior.

Não pense pequeno. Aprenda a pensar grande. Aprenda a dividir para conquistar. Para isso nunca abra mão da qualidade do software que produz. É o seu nome, a sua dignidade, a sua honra que está nisso. Eleve a qualidade do código/software que lhe chega em mãos. Não tenha medo se defender a bandeira da qualidade. Se alguem não gostar, tenha a certeza que são eles que estão errados.

E sei que temos que comer e para isso precisamos trabalhar. E para trabalhar precisamos engolir alguns sapos de vez em quando. Mas existe um limite moral até onde você pode ir. A partir daí é trabalho intelectual forçado, é escravatura intelectual, é prostituição intelectual.

Mercenários pensam pequeno e ganham dinheiro, mas são infelizes e mal vistos pela sua falta de moral. Ninguém confia neles.  Artistas pensam grande e são normalmente felizes e as pessoas tendem a confiar neles.  Tudo bem que ha artistas que nada ganham e outros que ganham muito. Isso depende do talento de cada um. Não apenas do talento artístico como do comercial, interpessoal, etc..

Embora possa parecer que pensar pequeno pode ser uma vantagem a curto prazo, nunca é uma vantagem a longo prazo. E sendo que sistemas sempre duram além da sua vida útil, o longo prazo mal planejado tende a ser um problema.

Você pode pensar grande e dar passos simples , um de cada vez e chegar no que pensou. Mas ao pensar pequeno por muito que corra nunca vai chegar onde deveria. Isso porque você não sabe onde deveria chegar. Porque não pensou nisso antes ?

Gâmbito do Peão

Gâmbito é uma palavra utilizada no Xadrez para designar um sacrifício de uma peça em troca de vantagem no tabuleiro.  Normalmente é uma armadilha porque quando o adversário toma a peça é quando ele perde vantagem. Então, normalmente o Gâmbito ou é disfarçado ou muito óbvio. Ambas as formas tentam tomar o adversário desprevenido e forçá-lo a tomar uma decisão “a quente”.

O peão é a peça menos valiosa no tabuleiro (em termos de pontos) e com movimentação limitada, mas são muito uteis para atrapalhar a movimentação das outras peças.  Por outro lado, os peões podem ser promovidos. A Promoção acontece quando um peão chega na extremidade do tabuleiro  oposta àquele em que começou a partida. Nesse caso o peão é substituído por uma outra peça à escolha do jogador. Normalmente a Rainha – a peça mais poderosa do tabuleiro, mas qualquer uma é possível. É por isso que o jogador faz alguns gâmbitos no inicio da partida: para abrir caminho à promoção do máximo de peões. Por causa da promoção,  o adversário normalmente morde a isca e toma o peão sempre que tem oportunidade para evitar ficar em desvantagem mais perto do fim do jogo. Essa é armadinha, ele vai ficar mais vulnerável quando interessa: agora!

“Peão” é também o nome dado às pessoas que trabalham no chão de fábrica. Talvez por analogia  com o peão do Xadrez, já que ambos gozam de certas propriedades semelhantes, como o valor a movimentação o “atrapalhamento” que causam e a “promoção”.

Ao contrário do jogador de xadrez que valoriza seus peões, o dono de fábrica  normalmente não. À semelhança do jogador de Xadrez ambos acham que o peão é dispensável; que não há vantagem em tê-lo por perto e muitas vezes é vantajoso livrar-se dele. O Gâmbito do Peão acaba sendo uma estratégia de donos de fábrica. O que eles esquecem é que o jogador de Xadrez oferece o gâmbito em troca da possibilidade de promover outros peões. Normalmente o dono da fábrica não sabe o que significa “promover”, como um jogador iniciante.

Mas ao contrário dos peões de Xadrez que são peças de madeira sem alma, o peão de fábrica é um ser humano.  Certo que talvez um ser humano com pouca educação e oportunidades, mas normalmente uma pessoa honesta e de caráter que não se importa de sacrificar a sua força física e a sua força emocional e intelectual para o bem da empresa, em troca de salário fixo e constante.

Em épocas de crise (ou pseudo-crise) as fábricas despedem os peões que contrataram a mais anos atrás quando as coisas “iam bem”. A mídia interpreta isso como “corte de custos” e automaticamente como “crise na empresa”. Quando muitas empresas fazem o mesmo a mídia fala em “crise do mercado”, cega ao fato do problema ser da empresa que faz isso, nunca do mercado. Isto nada mais é do que o Gâmbito do Peão sendo executado em massa.

Agora, você que trabalha com desenvolvimento de software em uma empresa que se auto-denomina “fábrica de software” deve estar pensando se você é um peão ou se seus superiores teriam escrúpulos em oferecê-lo em gâmbito.  Está?

Se está, então deixe-me lhe dizer o que já é sabido há muito tempo:  sem peões não há jogo.
Por muito descartáveis que sejam não é possivel ter um jogo sem eles. Durante a partida, você pode até sacrificar alguns, mas se você deixar alguns até ao fim, normalmente acontece alguma promoção que lhe dá a vitória do jogo.

Donos de fábrica inteligentes tentam promover seus peões da mesma forma que o jogador de Xadrez. Isso envolve treinamento e custo, mas principalmente envolve respeito e profissionalismo.

Então, não é porque você trabalha em uma “fábrica de software” que automaticamente você está no páreo para o sacrifício.

Se você não quer sacrificado seja aquele peão que tem mais chance de ser promovido. Mas  se os donos da fábrica não tiverem uma política de promoção (ou pelo menos reconhecimento), então é hora de procurar outro emprego. É o processo de seleção natural. Quem sabe fazer software vai trabalhar para empresas que respeitam esse talento. Quem não respeita, acaba com meia duzia de autômatos que escrevem código (que é algo diferente de desenvolver software). A longo prazo essas empresas morrem.

Essas empreas que estão voltadas a morrer são simples de identificar. Normalmente têm muita gente  pouco qualificada programando (quer dizer, escrevendo código) e essas pessoas são encaradas como dispensáveis. Aliás, alguns tipos de contratação já meio que signfiicam isso (aka estagiário).  Têm sempre algum tipo de hierarquia como no exército. Isto é necessário quando a força ativa do grupo precisa cumprir ordens sem pensar, ou quando os superiores acham que a força ativa não pensa ou não pode ter esse direito. Além disso a hierarquia é essencial para ordenar o sacrifício e ter certeza que será cumprido. Em uma real empresa de software não há hierarquia, ha responsabilidades e colaboração.  Finalmente, empresas voltadas a definhar não fazem nenhum investimento na educação ou re-educação da força ativa (já que eles não pensam, como iriam aprender ?). Quando qualquer novidade é encarada com desdem e até como sacrilégio é porque a empresa não preza pela capacitação de seus membros. Esse é o sinal para você dar o fora. Você aprendeu a ser profissional em um nível superior ao que a empresa onde trabalha admite. Se você não for embora por sua conta, acabará sendo enviado para fora mais tarde já que a sua necessidade de evolução e a mentalidade mentecapta da empresa nunca poderão funcionar juntas. Encare isso como um processo natural em que você seleciona parceiros mais aptos e não como um castigo.

Quebra de Tradição

Em posts anteriores já falei de como acho importante dar importância ao valor do software, como é ruim cotar o desenvolvimento em horas e como o cliente quer tudo de uma vez só.

A questão para mim era: como?

Os métodos atuais utilizados na maioria das empresas partem de princípios construídos durante a era Ford de fazer automóveis.  Mas para quem não sabe a Ford não está funcionando tão bem assim e as suas concorrentes que não utilizam esses princípios tradicionais (leia-se velhos e obsoletos) têm muitos mais lucro (ex.:  qualquer companhia asiática). Se isso ainda não o convenceu, pense nos problemas que enfrenta projeto após projeto e em quantos projetos não vingaram…

O outro problema é a tradicional (leia-se velha) cobrança por hora. Isto é um tiro no pé por muito que lhe digam o contrário. Afinal o objetivo das empresas é ter lucro (certo?) se eu cobro por hora significa que o único jeito de ganhar mais é trabalhar mais. Certo? Errado. Qualquer pessoa com noção de economia vai-lhe dizer que o ganho não advém do preço que o cliente paga mas sim da margem que você tem. Ou seja, da diferença entre o que ele paga e o que custa a você. O objetivo é portanto ter uma margem maior.  Trabalhar por hora significa que a margem é fixa. Você não pode aumentar a margem porque não pode haver disparidades entre o esforço e o tempo. E esse é o real problema.

Se a margem é fixa não ha como trabalhar as funcionalidades de maior valor de forma diferente que as de menor. Às vezes uma funcionalidade sem valor demora muito mais do que uma de menor.  Se eu cobrar por hora estarei cobrando muito por algo inútil e pouco por algo imprescindível.  Isto não faz nenhum sentido, mas atualmente tanto empresas como clientes caem nesta falácia.

Existem duas formas de reverter isto: a) as empresas aprendem a fazer certo e os clientes tem que seguir a onda ou; b) os clientes exigem o que é certo e as empresas têm que seguir a onda.

Portanto o objetivo é evangelizar tanto empresas quanto clientes. (bom, às vezes é necessário evangelizar os desenvolvedores também)

Clientes querem sempre tudo e estão acostumados a receber tudo. Mas estão satisfeitos? Não. Ninguém pode estar, em perfeita sanidade, satisfeito por pagar mais por algo inútil. Então a forma de trabalhar o cliente é não aceitar tudo o que ele pede. Mas claro, de um jeito educado.

A forma de fazer isto é óbvia. Cria-se um pacote  fixo. Este pacote pode ser de tempo , custo, esforço, valor, etc… o que importa é que seja fixo. Claro que alguns serão mais fáceis de estimar e controlar, normalmente  esforço ou custo. Deixe o cliente pedir o que ele quiser. Estima o tamanho de acordo com o critério fixo (tempo, esforço ou custo). Até aqui tudo bem. O problema é quando você converter esse tamanho em dinheiro. Ai o cliente vai dizer que ” ‘tá muito caro” e que você precisa fazer um desconto e blá, blá , blá … Como norma não dê desconto! Principalmente se é um cliente novo.

Dar desconto para ganhar o cliente é uma outra prática tradicional (leia-se velha) que está errada. É que ao fazer isso você passa a idéia de que: a) o valor que você está falando não é honesto e b) você não sabe o real valor do que está fazendo (valor, não custo). Isso significa que cada vez que você falar um valor daqui para a frente o cliente vai interpretar como não sendo verdadeiro. Isso detona a confiança que ele tem em si. Quando o cliente quiser um preço menor você simplesmente diz: “Tudo bem, corte algumas funcionalidades”. Isso diz duas coisas ao cliente: que você sabe o esforço de cada funcionalidade e que o seu preço é honesto. O valor da funcionalidade cabe ao cliente decidir não a você. Ao ser forçado a retirar algo da lista ele vai repensar nas funcionalidades com mais atenção (coisa que ele nunca faz da primeira vez) e priorizar umas em realção às outras. Durante esse processo ele vai pensar em outras funcionalidades ou descobrir que afinal não precisa daquilo tudo.  Repare que você não está proibindo o cliente de fazer o que ele quer, você está impedindo que ele tire vantagem de si ou que pense que o seu trabalho não tem valor para ele (já que o dele não tem valor para você).

Mas…com certeza que o cliente vai querer mudar de opinião (vai dizer que isso nunca lhe aconteceu?) e querer mudar as funcionalidades   no meio do projeto. Tradicionalmente (leia-se “da forma antiquada”) isso é mau. É mau porque se partiu do princípio errôneo que o cliente sabe o que quer antes do projeto começar. Ele sabe o que quer, mas o que ele quer muda com o tempo. Então, para satisfazê-lo você aceita mudar as funcionalidades. O ponto é que do jeito antigo isso é uma exceção, com o jeito certo isso tem que ser a regra. Então, basta que o cliente possa modificar a lista de funcionalidades que criou no início do projeto. Sempre tendo em atenção o tamanho fixo. Isto inevitavelmente obriga a um trade-off por parte do cliente. Esse trade-off nem sempre pode ser feito pelo seu interlocutor e obriga a um processo interno no cliente para que haja uma decisão. Isso é bom porque: a) deixa o cliente consciente do que está pedindo e pelo que está pagando; b) deixa o resto da empresa-cliente consciente das mudanças que irão acontecer quando o software for introduzido.

Isto é suficiente para mudar a atitude do cliente sem mudar muito aquilo que você pode fazer por ele.Tanto antes como agora você irá fazer um levantamento das funcionalidades. Tanto antes como agora, você vai deixar que ele mexa na lista de funcionalidades. A diferença é que agora fazer essa alteração tem um efeito muito bem delimitado e visível. Clientes adoram visibilidade e adoram que você se preocupe com as necessidades deles. É exatamente isso que está fazendo. Você está conversando com o cliente e aprendendo o que ele quer. A diferença é que você não está partindo do princípio que pode aprender tudo num certo momento do projeto. Isso não é real. Isso não é possível.  Pensar o contrário é ingenuidade e persistir nesse pensamento, quando você  já passou, por isso é imbecilidade.

Bom, temos agora de tratar a empresa. Empresas de software adoram cotar as coisas em horas. Pior, em horas-relógio (por oposição a horas-homem). Adoram pedir que você dê estimativas de quanto demora a fazer. Tudo um desperdício de tempo, paciência e capacidade mental, em suma, de recursos. E o pior é que : nunca dá certo.

O primeiro conceito a aceitar é que é impossível adivinhar quanto vai demorar a fazer algo, ou quanto vai custar algo com certeza absoluta (i.e. sem erro). Tem que se aceitar que para cada estimativa há uma margem de erro associada. O erro depende de muitas coisas, mas o ponto é que ele existe. Isto é desconhecido de muitos gerentes. Quando se fala que vai demorar “3 horas”, eles sequer cogitam que você quis dizer de “2 a 4 horas”. E o pior é que você quis , realmente, dizer 3 horas exatamente.

Ok, precisamos estimar, mas precisamos que a estimativa seja útil. A única forma dela ser útil é conter a informação do erro. Descobrir esse erro não é simples. A forma de o encontrar é fazer muitas estimativas, comparar com os resultados reais e ver quanto erro, em média, existe. O bom é que alguém já fez isto e chegou ha conclusão que existe um padrão de desvios. Ele é chamado: cone de incerteza (incerteza é a palavra oficial e técnica para o conceito de erro).
É claro que o cone típico é genérico, você pode criar o seu se tiver dados para isso.

Tudo muito bom, mas então como estimar o tamanho das funcionalidades se não podemos usar horas?
Para responder a isso, precisa-se de saber exatamente o que se está tentando fazer e o que os números que encontrar representam. Eles representam “tamanho”, mas em que unidade? Será que importa unidade? Digamos que você tem uma funcionalidade “A” que estima em 3 horas de trabalho. E uma “B” que estima em 1 hora. O que 1 e 3 significam além de “A”" é 3 vezes mais demorado que “B”?  Nada mais. Repare que não significam que você irá demorar exatamente 1 ou 3 horas, e sim que se para “B” você demora “X” para “A” você demora 3 vezes mais (o problema das empresas é assumir que 1 hora e 3 horas são realmente isso na realidade). Use-se, então, um conjunto de números sem unidade (adimencionais), afinal o que interessa é a relação de proporção entre eles e não o que o número realmente significa.  São simplesmente pontos em um jogo de proporção.

E o que eu faço com isso? Eu pego a lista de funcionalidades e estimo todas elas com base em proporções. Quando a proporção for muito díspar, parto a funcionalidade em mais funcionalidades de maneira a ter uma boa granularidade. Qual é a melhor granularidade? Tipicamente uma tal que o número da menor seja menos de 10 vezes o da maior. Isto porque os seres humanos tem uma pré-disposição a entender intuitivamente números de uma ordem de grandeza (de 1 a 10). Além disso eles entendem apenas matematicamente e não têm um felling do significado real (você sabe quanta área ocupam 50550 pessoas colocadas ombro a ombro? E 3 pessoas?)

Ótimo, agora tenho um tamanho para a lista de funcionalidades. Mas como isso me ajuda a cobrar o preço certo pelo projeto como um todo? E pior, como fazer essa estimativa antes do projeto começar?

A idéia é que o projeto estará pronto quando todas as funcionalidades da lista estiverem prontas. E prontas significa terminadas mesmo, implementadas, testadas e implantadas (deployed). Isto é óbvio. Mas quanto isso demora? A pergunta neste ponto é: importa quanto demora?

Certos projetos têm datas limite para o cliente. A data em que o projeto tem que estar pronto é fixada e imutável. Outras vezes o cliente não está nem aí, ele quer é o projeto pronto. Certo?

Errado. O Cliente sempre quer o projeto na data que você lhe disser que vai estar pronto. Acontece que às vezes se essa data não for antes de uma data pré-determinada pelo cliente, ele não vai sequer tentar fazer o projeto. Então, você sempre tem que saber a data em que vai terminar, mas às vezes isso é um constrangimento, outras não. Ou seja, à vezes pode-se ultrapassar a data, outras não.  Quando é um problema, a data acaba limitando o tamanho da lista de funcionalidades em vez do custo ou do esforço.

Bom, então, precisamos de uma data. A conta é simples. Se o projeto tem “N” pontos de tamanho e  consigo fazer “D” pontos por dia, eu morarei N/D dias. Acontece apenas que em um dia é pouco provável que eu consiga terminar alguma funcionalidade. O bom senso aconselha a ter um tempo maior. Bom, então se eu fizer “P” pontos por período, demorei N/P períodos. Claro que isto tem um erro associado porque “P” não é “P” é P±p, portanto demorarei entre N/(P+p) e N/(P-p). (Sim, o “N” também não é “N”, é N±n)

E qual período escolho?

Você tem que escolher um período que lhe permita um certa flexibilidade. Já sabe-se que o cliente vai querer alterações e você quer lhe mostrar progresso. Isso implica reuniões. O período tem que ser tal que ambas as coisas sejam possíveis sem que se tornem empecilhos. Por outro lado o período depende da equipe. Nem todas as equipes fazem os mesmos pontos por período. Além disto você quer criar um sentimento de pressa na equipe sem que ter que estar todo o momento pedindo para “dar um gás”.

Tudo isto somado leva a um tempo de entre 2 a 4 semanas. Sendo possível ser mais ou menos em casos particulares. É claro que a primeira vez que fizer isto você não vai sequer ter noção de quantos pontos a sua equipe pode fazer por período, mas você pode fazer algumas tarefas durante um ou (preferencialmente) dois ou três períodos para ter uma noção e em cima disso fazer uma estimativa. (Claro que se fizer 10 ou mais periodos você pode fazer uma estatística melhor, mas ai já terá, provavelmente, acabado o projeto).

Tudo isto para concluir que é possível sim – existem pessoas fazendo isso , sim! – propor  sistemas, vende-los e construí-los: a) sem fazer todas as vontades ao cliente; b) sem cobrar e/ou estimar por hora de trabalho e; c) sem desprezar o valor que o software tem para o cliente.

A minha surpresa é que estas idéias simples e óbvias são o coração de todas as metodologias ditas “ágeis”. Elas não estão propondo nada que não seja intuitivo ou que seja inconcebível. O período de tempo é chamado Iteração, o número de pontos por período é chamado Velocidade. Os pontos usados são chamados de Story Points e a lista de funcionalidades (features) é chamada de Backlog. Os conceitos importantes têm nomes próprios.

Alguns  chamam a este processo Scrum, mas  Scrum é um pouco mais que isto. Outros chamam XP, mas XP é um processo de desenvolvimento e não de “gerência”, mas todos concordam que é o jeito ágil.

“Ágil” é portanto uma palavra que se opõe à “Tradicional”, sendo que a palavra “ágil” advém exatamente de usar o princípio contrário ao tradicional que parte da idéia de que tudo pode ser conhecido com antecedência e portanto é possível fazer um plano sem imprevistos. A idéia ágil é que se parte do princípio que nada será imutável durante o processo. O tamanho do backlog tende a ser fixo (porque é o rumo do projeto) mas mesmo ele pode ser alterado. Basta que o contrato seja revisto.
Falamos então em freqüência de mudança e não se a mudança vai existir ou não.

Falta apenas uma coisa: se o backlog está cotado em pontos como saber quanto cobrar? Obviamente chegaremos em algum fator de moeda/ponto mas como?
Se você não tiver nenhuma idÉia,  e está habituado a cotar por hora, pode converter o backlog em perÍodos, contar os dias dos períodos e converter em horas. Mais ou menos assim:

Custo = N/V * I * 6* H

“N” significando o total de pontos do backlog, “V” a velocidade  da equipe por iteração, “I” é o número de dias por iteração, “H” é o custo por hora  e 6 são as horas por dia.  Repare que não é 8 horas por dia, porque um dia de trabalho tem 8 horas, mas não todas são horas úteis. Na média de 5 a 6 horas são úteis.

Digamos que o projeto tem 200 pontos, a 20 pontos por iteração de três semanas (15 dias) e a 100 reais por hora teríamos : 200/20 * 15 * 6 * 100 = 90.000

Pensemos que este é um valor médio. O ponto aqui é que o valor do custo depende da equipe. Logo o preço depende da estimativa  da equipe e da velocidade da equipe: depende da equipe. E a margem?  Digamos que colocamos 10.000 de margem e chegamos no valor de 100.000 de preço final.

Equipes mais produtivas serão mais rápidas, certo? Certo.  Pensemos que a equipe é duas vezes mais rápida: Teremos o valor do custo cortado pela metada. Se o preço é o mesmo a nossa margem que era de 10.000 é agora de 55.000 tivemos um ganho de 550 % porque a velocidade da equipe aumentou para o dobro. E tivesse aumentado para o triplo? o resultado seria uma margem de 90.000 (900%) . Disto se aprende que uma pequena mudança na velocidade melhora a margem de lucro.  Você consegue mais lucro se não vincular o preço ao esforço de forma tão rígida como o preço por hora. Isto é óbvio. Sempre que você compra um serviço, deve-se perguntar um preço e um prazo, e não só um deles para calcular o outro. É pela flexibilidade entre os dois parâmetros que há lugar a margens maiores.

Nesta apresentação do Jeff  Sutherland você entende realmente que compensa e que é assim que empresas grandes ganham dinheiro.  Você quer ganhar dinheiro? Tenha equipes produtivas, seja ágil.

Categorias de Desenvolvedor

Hoje em dia existe uma deficiência em entender as atividades de um programador e no que elas se distinguem das de um desenvolvedor, de um arquiteto ou de um analista. O mesmo é válido para cada uma destas em relação às outras.

A confusão aparece no universo java por dois motivos:

1) A Sun – que certifica os profissionais – estabelece 3 tipos principais de certificado: Programador, Desenvolvedor e Arquiteto. Para a Sun o papel de cada um é muito bem definido (existem objetivos concretos a serem alcançados) e, por isso, ela pode certificar que alguém chegou nesse patamar. Sob este ponto de vista, o processo é evolutivo sendo que apenas uma pessoa certificada como programador pode se habilitar a ser certificada em qualquer outra coisa. Os nomes explicitam o que a pessoa é potencialmente capaz de fazer, independentemente se tem ou não experiência.

2)Os Departamentos de Recursos Humanos, ou empresas terceirizáveis de Recursos Humanos – a que carinhosamente chamarei de RH – precisam ter parâmetros para avaliar tanto as competências necessárias mas principalmente as faixas de salário “de mercado”. Veja, o RH é avarento por natureza e não gastará um centavo a mais do que for necessário. Por outro lado, ele tem dificuldade em definir o que “precisa”, o  que leva a processos de seleção mais ou menos aleatórios.

Um profissional java também quer saber a faixa de salário em que se encaixa para saber como negociar com o RH e vice-versa. Contudo, é difícil ambos concordarem no que marca cada patamar da faixa salarial.

Os RH, de modo simplista, dividem as coisas em: júnior, pleno e sênior; chegando ao cúmulo destes três sufixos passarem a ser mais importantes que as atribuições do cargo em si.

Por exemplo, “Programador Sênior” singifica o quê ?
Em tese significa que a pessoa é um excelente programador. Nada mais que isso. Mas para os RH significa principalmente que: a) a pessoa tem mais de 5 anos na área; b) que já gerenciou equipes de programadores.
Ora, é óbvio a qualquer um que trabalhe com programação que : a) tempo não é equivalente à experiência nem a qualidade; b) gerenciar equipes não é trabalho de programador e sim de desenvolvedor, ou quiçá de arquiteto. Ou melhor dizendo, gerenciar equipes é uma qualidade completamente ortogonal à de programador.

Dois mundos separados que são “unidos” por expressões vazias como “Programador Sênior”, que  não têm um significado próprio pois significam coisas diferentes para cada um. Entenda que o erro do RH é entender o prefixo (junior/sênior) como equivalente a idade ao invés de a experiência. Uma pessoa com 15 anos no ramo de desenvolvimento pode ser programador sênior de uma linguagem que aparecem há 3 anos? Sim, porque o RH exige apenas 5 anos de experiência na área de programação e não na linguagem/tecnologia/plataforma em si. Isso leva ao absurdo do RH pedir por alguém mais experiente do que é matematicamente possível. Isso talvez não seja totalmente despropositado considerando o ponto de vista do RH que nada tem a ver com as qualidades técnicas da pessoa. Estamos frente a um paradoxo.

Bom, temos então duas áreas importantes para entender as atividades de um programador: a pessoal e a técnica. A pessoal é uma combinação de personalidade, histórico e esforço enquanto que a técnica é uma questão de experiência – experiência real, não apenas anos de trabalho na área. Por exemplo à pergunta:  “Qual a sua experiência com Java?” a resposta “Trabalho com java há 10 anos” diz muito pouco, mas “Já utilizei java em 5 projetos: um Desktop com SWT, três para Web e um embarcado em automóveis” diz muito mais. É que o cara pode passar 10 anos mexendo apenas com, digamos HTML+JSP e nem saber o que é um Servlet ou TagLib ou , pior, um List<T>. Tempo não é experiência é exposição.

Uma outra dimensão do problema é considerar a carreira como um todo. Muita gente pensa que a carreira é mais ou menos assim: Programador Júnior > Programador Pleno > Programador Sênior > Analista de Sistemas > Analista de Negócios. Quanto a mim, isso é bem longe da realidade. O trabalho do analista é levantar os requisitos necessários ao desenvolvimento do projeto. O analista (de negócios, requisitos, como se quiser chamar) tem que entender o pedido do cliente e dos desenvolvedores,  elaborar trade-offs inteligentes de forma a maximizar o valor do software para o cliente sem incorrer em riscos de desenvolvimento. O analista não precisa saber programar, ele precisa saber analisar. Isto é, ter espírito crítico, poder de comunicação e conciliação. Ele tem que ter noção daquilo que os pedidos do cliente implicam mas sempre deve contar com o apoio dos desenvolvedores. O pior  erro que uma analista pode cometer é não colaborar com o resto da equipe sob o falso pretexto que ele é o “chefe” ou o “líder”.

A carreira é uma escolha da pessoa entre as opções possíveis, mas o que interessa, eu acho, é a sua capacitação, isto é, o que a pessoa é capaz de fazer. Vejamos assim:

Programador	J	E
		P	S
Desenvolvedor		J	P	S
Arquiteto			J	P
				E
Analista				J	E

A capacitação de um programador júnior começa em uma área especifica da plataforma ( web,por exemplo) onde ele aprende a mexer com as classes básicas ( String, BigDecimal, File , InputStream, OutputStream, etc.). Ele não está preocupado com a estrutura abstrata do código, em seguir padrões, etc… apenas em escrever código que funcione. Repetindo este processo sempre no mesmo ambiente o programador vai conseguir executar tarefas de forma mais estruturada e tornar-se um especialista em uma certa área da paltaforma (web , desktop, por exemplo). Se ele muda de área, a bagagem do básico vai com ele; e ele começa a acumular conhecimento da plataforma como um todo. Pode até começar a enxergar e implementar um ou outro padrão de projeto. Aqui, ele está capacitado como programador pleno e desenvolvedor júnior, ou seja, ele pode assumir qualquer programação mas não a responsabilidade do design, para isso precisamos de um desenvolvedor pleno, que é normalmente um programador mais experiente que passou por diferentes projetos usando tecnologias diferentes e consegue enxergar o que há de comum entre elas. Por exemplo, entender que o JMS é na realidade uma super implementação do padrão Produtor-Consumidor ou que JMX é uma super implementação de Observer. A este ponto, a pessoa está capacitada a entender diagramas de arquitetura e até a dar algum palpite. Ele deve ser responsável pelo design e levar a equipe a seguir um design. Não pode, contudo,  ser responsabilizado por escolhas de arquitetura. O arquiteto é quem tem essa responsabilidade. Não é necessário que o arquiteto saiba programar na plataforma em causa, já que lhe bastam conceitos genéricos como Orientação a Objeto e Padrão de Projeto. Ele contará com o desenvolvedor para os detalhes, a ele cabem as idéias e as escolhas. Para o arquiteto é importante o conhecimento de tecnologias, plataformas, padrões e frameworks  tanto como para o desenvolvedor sênior é importante um pouco de feeling sobre as expectativas do cliente. O arquiteto pode ser especialista – trabalhar apenas com java, por exemplo – ou não, trabalhando com várias plataformas e/ou linguagens. Ou pode, ainda, se especializar em um tipo de arquitetura: web, desktop, etc. Um arquiteto verdadeiro tem um pouco de analista e, em uma equipe pequena, pode até acumular as duas capacidades, mas um bom arquiteto não necessariamente dá um bom analista e vice-versa. O arquiteto é uma pessoa versada em tecnologia enquanto um analista é uma pessoa versada em pessoas. Nem sempre estas duas vertentes são compatíveis. Normalmente não são. O analista pode também se especializar em uma área de negócio caso em que se transformará em um analista de negócios que pouca, ou nenhuma, relação tem com o mundo da informática. O trabalho do analista é levantar requisitos com o cliente e identificar padrões de requisitos para futuros projetos.

Embora pareça pela descrição, não acho que a pessoa precisa começar como programador para se transformar em analista de negócios, mas com certeza precisa se quiser virar arquiteto. Existem analistas de negócios que entendem a informática como uma ferramenta e tentam entrar nesse mundo como programadores (não como arquitetos) para suprir demandas na área de negócios que conhecem. Viram adeptos por necessidade (ver no fim). São dois mundos. Um pode levar ao outro, mas isso será obra das circunstâncias e não um plano de carreira.

O analista de negócios é um especialista em uma área de negócios. Ele pode simplificar as coisas para o analista não-especialista e/ou para o arquiteto. O analista de negócios tem uma participação esporádica e trabalha normalmente como consultor. O arquiteto, quando considerado que ele não programa e não analisa, também tem uma participação esporádica e trabalha também como consultor. Os outros, têm normalmente uma participação continua no projeto. Por isso ele representam a fatia maior do custo do projeto. Excluindo o analista não-especialista que consideramos trabalhar como consultor esporádico existem 5 categorizações possíveis: Programador Júnior , Programador (sem afixos) , Desenvovledor (sem afixos) , Arquiteto (sem afixos) e Analista (sem afixos).

Hoje me dia fala-se muito no Analista Desenvolvedor que teria capacidade equivalente a um analista junior, arquiteto junior e desenvolvedor senior e que no fundo representa a soobreposição ótima do quadro que apresentei antes. Isso nos deixa com três categorias: Desenvolvedor Junior , Desenvolvedor Programador e Desenvolvedor Analista. Essa nomenclatura faz mais sentido se pensarmos que Programadores, Desenvovledores e Arquitetos (nomenclatura Sun) são todos desenvolvedores (nomenclatura geral) .

As empresas – e portanto os RH – consideram ainda dois outras categorias: estagiário e trainee (treinando). A diferença é legal, um é protegido por ditames da lei diferentes. O treinando é alguém que a empresa assume que vai ensinar a teoria e a prática por seu próprio risco. Numa oficina seria o aprendiz. Ele tem N meses para mostrar que aprendeu. O estagiário é alguém se assume que já sabe alguma teoria e se espera que se encaixe numa certa prática (normalmente é alguém vindo direto da faculdade).

Onde se encaixam estas pessoas? Na categoria de júnior já que as suas capacitações são equivalentes. Na realidade a diferença é apenas administrativa relativa a como a lei enxerga a posição da pessoa na empresa e não relativa ao que ela sabe fazer. Existem estagiários com capacidade maior que junior, é verdade, mas o ambiente – infelizmente – não os deixa expressar as suas qualidades ( isso é assunto para outro post… ). Quando alguém consegue um certificado de programador pela Sun, isso significa, basicamente, que a pessoa é um programador júnior (Desenvolvedor Junior) certificado, já que o resto vem com a experiência.

Existe uma outra categoria que não posso deixar passar que é o Adepto. Este é o cara que começa com 10 anos a programar umas coisas em casa e até se vira bem, mas não tem nenhuma noção teórica do que está fazendo nem tem responsabilidade sobre os erros que comete. Alguns podem ser programadores em potencial, mas nem todos.

Ser programador não é apenas escrever código é responsabilizar-se pelo código que escreveu. Certificações podem ajudar a escrever um código melhor, mas os RH procuram pessoas responsáveis.

10 Passos

Ser uma pessoa que escreve código é relativamente fácil, mas ser um bom desenvolvedor requer talento e esforço. Ser “bom” em alguma coisa , em qualquer área, sempre necessita de trabalho pessoal, empenho.
Eis a minha lista das 10 coisas em que é necessário se empenhar diariamente para ser um bom desenvolvedor.

1.Comunique

Comunicação é essencial em qualquer atividade e desenvolvimento não é diferente. Comunicar é tudo sobre fazer-se entender e ser entendido. Comunicação tem várias vertentes. Na vertente pessoal, significa dar-se bem com as pessoas, ser simpático, honesto e prestativo tanto quanto possível, sem ser chato. Significa também falar corretamente de forma que qualquer um entenda. Na vertente técnica, significa redigir textos simples e claros. Não se esconder por detrás de um jargão técnico.

Inluido aqui está também o trabalho de equipe, que se resume a isso: comunicação.

Aprenda línguas, comece pelo Português e continue até ao Inglês ou mais além.

2. Informe-se

Leia livros, artigos, todo o material que conseguir sobre um assunto. Mude de assunto quando tiver uma visão geral do assunto anterior. Não se preocupe em conhecer os detalhes até que tenha que trabalhar com isso na prática. Preocupe-se em entender os conceitos e em ter uma visão abrangente da utilidade e fundamentos do assunto.

Nem tudo o que você vai ler terá qualidade. Muito do que você vai ler será repetido. Depois de um certo ponto será dificil ler algo novo ou inovador. Isso causa um fenômeno conhecido como “main stream” (corrente principal). Estar dentro dela é dificil e sair fora é periogoso, contudo exigido. Equilibrar as coisas não é fácil. Apele para o básico sempre que tiver dúvidas.

Leia livros, paticipe de convenções, fóruns, assine revistas, etc …mantenha-se atualizado.

3.Pense

Não é possível desenvolver software sem ser lógico ou saber criar algoritmos. Não precisam ser algoritmos sofisticados, apenas precisam ser funcionais. Por lógico me refiro a ter um pensamento que possa ser seguido passo-a-passo, sem hiatos, por qualquer um. A lógica está na abastração com que se lida com o problema. Relacionado com algoritmia estão as estruturas de dados: characteres, listas , tabelas de hash, etc.. conhecer estas estruturas ajudará muito na hora de contruir o seu algoritmo.

Pense antes de agir. Estude o problema e as soluções. Sempre há mais do que uma, mesmo quando não parece existir nenhuma.

Aprenda Matemática , Lógica Booleana e Estrutuas de Dados para o ajudarem a pensar. Seja crítico relativamente à sua opinião.

Lembre-se que você nunca vai pensar em tudo. Pense em equipe para minimizar esse problema.

4. Conheça os Detalhes de Como as Coisas Funcionam

Tente conhecer o funcionamento interno das coisas. O nível de detalhe depende do seu gosto e da sua necessidade. Mas precisa entender como as tecnologias, protocolos e equipamentos funcionam para poder utilizá-los correta e eficientemente. Não acredite em magia. Acredite que há uma lógica real, criadas por humanos, dentro do funcionamento dessas coisas.

Compreendendo como as coisas funcionam pode-lhe fornecer idéias para resolver seus problemas.

Consulte a documentação para obter esclarecimentos ou mais detalhes sobre as escolhas feitas pelos autores daquilo que você está utilizando.

5.Padrões e Melhores Práticas

Existem vários padrões de desenvolvimento em diversas áreas como arquitetura, design, teste , etc… Conhecer os padrões é evoluir a sua forma de pensar e comunicar. Isso o ajudará a ter um nivel de abstração maior e a ver soluções se repetirem. Conhecer padrões ajuda a resolver problemas mais rapidamente e com menor esforço. Isto também o ajudará a entender o código escrito por outros mesmo em uma linguagem que você não domine, ajudará a ter uma melhor visão do software construído ou que vai construir.

Esforce-se para seguir as melhores práticas. Tenha dúvidas sobre o que está fazendo e compare com o que o resto está fazendo. Aprenda a reconhecer o que está fazendo errado e como fazer da melhor forma possível.

Quando em duvida siga padrões. Quanto mais internacionalmente aceites, melhor. Mas cuidado, alguns podem ser limitativos. Aprenda a construir o seu padrão em cima de outros sem violar a utilidade ou incluir coisas demasiados específicas.

6. Solicite Revisões

Seja humilde e saiba aceitar quando o seu trabalho é de má qualidade. Submeta o seu trabalho à opinião dos outros, mas assegure-se que a opinião é imparcial (por exemplo, se mostrar sua aplicação ao seu amigo, não diga que foi você que vez, diga que foi uma outra pessoa da empresa). Saiba evoluir e aprender. Não tente convencer ninguém que o erro não é seu. Mediocridade é inaceitável, mas ninguém nasce ensinado. Aprenda com o seus erros. Seja humilde e honesto consigo e com os outros.

Se alguém lhe diz que algo é errado, aceite naquele momento. Se tiver dúvidas, informe-se melhor, mas não despreze o que lhe disseram. “Quem avisa amigo é”: tenha consideração por quem o avisa dos seus erros, pois não o avisar seria muito pior. Tente ajudar os outros da mesma forma, mas não seja arrogante.

7. Conheca as suas Ferramentas

Utilize ferramentas que o ajudam, não as que o atrapalham. Boas ferramentas diminuem o esforço, não o aumentam. Ferramentas evoluem, troque de ferramenta conforme. Não caia na besteira de querer fazer tudo no braço.

Linguagens de programação, IDE, editores de texto, tudo isso são ferramentas. Use a mais apropriada. Não existe uma ferramenta que resolva tudo. Faça alguns testes se necessário. Saiba como a ferramenta funciona.

Explore novas ferramentas no seu tempo livre antes de as utilizar profissionalmente. Isso lhe dá mais liberdade de experimentar e de as abandonar quando quiser.

8. Conheça o Paradigma

Se você trabalha com linguagens, ferramentas ou metodologias associadas a um certo paradigma de desenvolvimento – orientação a objetos, por exemplo – conheça o paradigma. Todo o resto é inutil se você não entende o mundo em que está inserido.

Discuta com outras pessoas sobre o paradigma que está utilizando e tente explorar todas as capacidades que ele lhe oferece.

Certificações podem ajudá-lo a conhecer melhor o paradigma, mas não devem ser encaradas como títulos de omni-sapiência (informe-se, solicite revisões).

9. Pratique

Na teoria tudo é muito bonito e parece funcionar perfeitamente. É na prática que uma ferramenta, conceito, idéia, dica , etc… realmente funciona ou não. Por isso pratique. Pratique bastante. Tente escrever programas completos, mesmo se começar pelo básico. Se tiver problemas em encontrar um programa completo que fazer, participe de algum projeto open source. É também uma ótima forma de aprender.

Tente colocar em prática tudo o que sabe e aprendeu. Isso irá melhorar o seu entendimento daquilo que sabe e até lhe ensinará formas melhores de fazer as coisas.

10. Desafie-se

Nada é perfeito e ser um bom desenvolvedor é uma tarefa árdua e que requer tempo. Mesmo seguindo orientações as coisas não acontecem do dia para a noite. Portanto, não desista, saiba que é um processo em andamento, contínuo. E quando achar que domina o que sabe, desafie-se a aprender algo novo.