Sou Programador!

É comum na universidade voce encontrar gente que não se dá bem com algoritmos e planeja  migrar (sic) para áreas "gerenciais". Isso é típico de quem entrou no curso de computação porque a concorrência de Fisioterapia estava maior na época de seu vestibular.

Mas antes que rotulem esse post de algo, quero deixar claro que existem aqueles que migram para a área gerencial por causa do salário e aqueles que migram por … como direi… não rolar uma "química" entre eles e os algoritmos. É comum voce ouvir: "-me cansei disso, pretendo virar gerente de projetos".

Ano passado uma menina praticamente formanda se perguntava qual a serventia de um banco de dados, esse tipo de gente é mais comum do que se pensa, não tenho estatística nem ninguem tem que eu saiba, mas creio por experiência de ministrar cursos, palestras e participações em eventos sobre programação que se não for maioria, esse pessoal no mínimo é a metade do contigente da área.

Alguns acham que regulamentação da profissão evita esse tipo de profissional, eu afirmo que não, porque se ela consegue cursar 8 semestres sobre integrais e derivadas ou estatistica computacional e consegue se formar, quem garante que um conselho ou guilda qualquer evitará que esse profissional seja um analista ou pior… um CIO?

O nível anda tão baixo que ainda existem dúvidas se um profissional deve conhecer mais de uma linguagem de programação, ora, se o profissional aprende como construir uma linguagem (pelo menos deve aprender já que qualquer curso de Ciência da Computação ensina isso), qual a dificuldade de aprender 5 ou 10 linguagens diferentes?

Eu nem considero linguagens diferentes aquelas que somente modificam a sintaxe de determinados ADTs ou sentenças, mas sim aquelas que são construídas para contextos diferentes. Java e C++ são linguagens diferentes? humm… Java e LISP são!

Isso merece um post a parte, portanto não farei juízo de valores sobre isso nesse post.

Não deixe que a Universidade atrapalhe seus estudos

Em um post passado, evidenciei o fato da burocracia escolar ser um empecilho ao desenvolvimento pessoal, todo estudo é um auto-estudo, ninguem pode ditar o que outro tenha que aprender, é uma escolha pessoal e por mais que isso pareça temeroso e sombrio, voce está sozinho.

Portanto, não deixe que a escola atrapalhe seus estudos, mas nunca abandone a universidade, mesmo depois de formado, se não há tempo, invente um mestrado, pós ou especialização. O contato com o meio acadêmico é de vital importância ao  programador, esse contato oxigena as idéias, afasta um pouco o apelo comercial que tanto o mercado exige.

O academicismo as vezes é benéfico, te desregula da própria não-regra, evita que voce considere padrões como gambiarras e abres os olhos do programador para questões mais profundas.

Sou um programador

Divirto-me com os códigos saídos do meu teclado, se tem uma expressão de mais-valia (da marxista luta de classes) mais precisa, é a programação. Um software nada mais é que uma idéia armazenada na forma de bits, soluções para processos humanos transformados em um emaranhado de fórmulas e algoritmos. Quando voce desenvolve um software ou parte dele, mesmo que terceirizado por outro para tal tarefa, voce está projetando o seu "eu" naquele software. "Os meios de produção" é a sua mente, talves o fator que mais provoca fracasso nos projetos que presenciei esse fracasso foi tentar "desumanizar" o software, tentar por meio de processo ou metodologia de desenvolvimento que qualquer um chegue e altere uma criação de outro artista.

Ninguem chega e altera uma obra de "Michelangelo" (não é a tartaruga ninja, é o … deixa pra lá), talves seja pretensão minha, mas os programas são obras artísticas, não são meros produtos industriais, analogia com prédios da construção civil também não tem refletido muito sucesso nas últimas décadas.

Sou um programador, apenas isso, pode chamar de desenvolvedor, analista, anapropégua! Mas na verdade somos desenvolvedores.

Há quem queira ser analista, ou desenvolvedor ou até Gerente de Projetos, rótulos criados para caberem nas teorias administrativas e distribuir organograma colorido na empresa. Besteira, Bullshit!

Porque programadores recebem menos?

Recentemente travei uma dessas discussões homéricas sobre um fato que as vezes passa despercebido, que um gerente PMBOK genérico não serve para projetos de Engenharia de Software. Uns acham que sim, que qualquer um com teoria sobre gerência de projetos consegue controlar um projeto computacional, eu afirmo categoricamente que não, se o Gerente não foi programador (não vale ter sido estagiário que normalmente é chamado de programador) ele não conseguirá controlar o projeto satisfatoriamente.

Lembro de um projeto recente na SEAD que o suposto "gerente" em meio a uma reunião, apertado por todos os lado, fala: "-háaa! o cronograma não está assim tão atrasado, os riscos estão em dia", sobre um projeto que não tinha uma linha de código funcional, não passava da tela de login, já consumira 3/4 do tempo, centenas de páginas de documentação desnecessária e rodado metade da população do estado no projeto.

O principal fator de uma empresa de software é o programador, é ele o sucesso ou o  fracasso, mas só ganha 1/3 do que ganha um Gerente, isso na mais otimista das hipóteses.

O problema é a hierarquia artificial criada pelo mercado e legitimada pelo meio acadêmico de que o programador é o novato, o inexperiente. O programador veterano que entende de análise é apropriadamente (reconheço) chamado de analista, mas… pera aí! Ele continua sendo um programador. Criou-se o programador (reles servil, geralmente estagiário), o analista, o arquiteto (ui) e o gerente, estou ainda desconsiderando as carreiras intermediárias ou artificiais como engenheiro de especificação, arquiteto de configuração, programador de testes e variantes. Virou uma zona, o Gerente as vezes sequer sabe reconhecer um fluxo condicional, o arquiteto não conhece a arquitetura (ironia?) de determinada plataforma, e o desenvolvedor não sabe desenvolver algoritmos, apenas desenhar no IBM Rational Rose.

O programador de verdade conhece UML, entende como funciona RUP e métodos ágeis, sabe instalar e configurar não só as ferramentas auxiliares no processo de desenvolvimento, mas faz tuning no SO e poderia gerenciar um projeto satisfatoriamente, mas isso é quebrar o Status Quo estabelecido… onde esses revolucionários vão parar mesmo? 

Pague o salário de programador acima do salário de gerente e veja na próxima entrevista o nível dos candidatos, é uma dica! Sei que ninguem vai levar a sério.

Como escolher um programador

Em recente projeto que graças a Odin não participei, consideraram o fator humano um risco de nível intermediário e as ferramentas usadas no projeto de risco alto. Esse é o tipo de projeto que pede de cara para fracassar, nem nasceu e já considera um profissional, o artista, aquele que dará vida, o "faça-se a luz" no sistema como sendo mero insumo em uma cadeia produtiva similar a um chão de fábrica na indústria.

Dois posts recentes falaram sobre como escolher um profissional decente. Um foi esse post do José Oliveira e outro foi esse do Vítor no embalo do Zé que prontamente completou

Não tenho muito a completar sobre as excelentes dicas que deram, mas gostaria de dar somente dois pitacos:

1 – Não terceirizar a escolha do candidato, entrevistar pessoalmente, o olho-no-olho revela todos os segredos;

2 – Não deixar os títulos sobrepujarem a experiência, experiência não tem preço. Claro que não estou confundindo experiência com tempo na área.

3 – Verificar a vida do sujeito, conhecidos, comunidades que frequenta, postura diante dessas comunidades, vê se ele se encaixa realmente na cultura da empresa.

Sei sei, eu disse que eram dois pitacos, mas depois de "cálculo 2" perdi qualquer noção de matemática básica 🙂 

Humilhação

Sentados, reunidos e planejando um software WEB 2.0 da nossa Evil inc, em um dos nossos escritórios (A.K.A casa do Handerson) imaginando como ficaremos ricos depois de concluído o plano maléfico de dominar o mundo com nosso capitalismo selvagem… eis que uma senhora "joga um balde d'agua fria" de realidade sobre nossas cabeças, chega na porta entre-aberta e solta a pérola: "- aqui bate xerox?"

H-U-M-I-L-H-A-Ç-Ã-O! 

Será que estamos regredindo?

No século 18 Adam Smith escreveu:

"It is not from the benevolence of the butcher, the brewer, or the baker, that we expect our dinner, but from their regard to their own interest…"

Transcrito ao português:

"não é da benevolência do padeiro, do açougueiro ou do cervejeiro que eu espero que saia o meu jantar, mas sim do empenho deles em promover seu próprio interesse

No século 19 Mikhail Aleksandrovitch Bakunin escreveu:

"Assim, sob qualquer ângulo que se esteja situado para considerar esta questão, chega-se ao mesmo resultado execrável: o governo da imensa maioria das massas populares se faz por uma minoria privilegiada. Esta minoria, porém, dizem os marxistas, compor-se-á de operários. Sim, com certeza, de antigos operários, mas que, tão logo se tornem governantes ou representantes do povo, cessarão de ser operários e por-se-ão a observar o mundo proletário de cima do Estado; não mais representarão o povo, mas a si mesmos e suas pretensões de governá-lo. Quem duvida disso não conhece a natureza humana.

No século 20 Ludwig Von Mises escreveu:

"Não é porque existem destilarias que as pessoas bebem uísque; é porque as pessoas bebem uísque que existem destilarias."

Isso é Brasil 

Em pleno século 21, na era da tecnologia, do desenvolvimento humano, no Brasil ainda acreditam que o governo (seja ela qual for) é o responsável pelo nosso desenvolvimento e por consequência um aumento no IDH.

Figuras como essa ainda pensam dessa forma:

"A revolução não pode parar"

Quantos ainda precisam morrer para afundar esse conceito de revolução?

Me citem uma única revolução que não tenha produzido mais catástrofe e/ou matança?

Quem me dera uma esquerda civilizada nesse país, seja lá o que significa esquerda ou direita depois da queda do muro. Como não voto nem nunca votei em ninguem da suposta direita me resta ficar com coluna do meio.

Padrões não são gambiarras

Ultimamente vi uma série de posts no meu feed reader coincidentemente encadeados falando sobre padrões de projeto e os considerando genericamente gambiarras.

Tudo comecou no post do Giovane Roslindo Kuhn falando como é legal usar patterns para a comunicação da equipe. O entendimento que se dá no código quando ele é estruturado seguindo convenções estabelecidas em padrões. Claro que esse não é uma das características de se usar um padrão, mas sim um beneficiamento dele (mesmo quando evidentemente não necessitaria haver a presença de um padrão).

Motivado por esse post, o Vítor Ferreira Pamplona escreveu um outro dedicado aos anti-patterns e a prejudicial característica da comunidade java ser reconhecida como a comunidade pattern. Evidenciou a necessidade que programadores empolgados com uma nova linguagem agirem como se essa linguagem fosse uma bala-de-prata e resolvesse todos e quaisquer problemas.

Os próprios padrões de projeto conhecidos podem se tornar um anti-pattern se forem usados para um contexto diferente do que se propõe inicialmente. Quem nunca viu aí uma estrutura cheia de commands para simular MVC em um sistema web levante a mão.

Após o post do Vítor o Thiago Arrais publicou um artigo chamando os padrões de "gambiarra com nomes" que acabou gerando outro artigo do Marcos Tapajós no blog da Improve It na mesma linha.

Concordo com muitos pontos colocados por ambos mas quero fazer uma ressalva, uma gambiarra é uma solução improvisada (deveria também ser temporária) e fora dos procedimentos legais. Um padrão pode ser uma gambiarra mas em essência não é.

Gambiarra "Orientação a Objetos"

Se levarmos ao pé da letra essa consideração podemos então supor que Orientação a objetos seria uma gambiarra, porque os desenvolvedores C já simulavam os conceitos de orientação antes do surgimento do C++, que apenas forneceu ADTs nativos específicos para o desenvolvedor. Linguagens como Smalltalk que foram concebidas tendo em mente a orientação a objetos seria únicas verdadeiras OO mesmo que internamente seu interpretador faça algo parecido com uma linguagem não pura. Mas a única diferença entre as duas é a familiaridade da arquitetura interna da linguagem com o padrão/conceito que se deseja implementar. Uma esconde do desenvolvedor a implementação a outra temos que criar nosso próprio dialeto e não se beneficiar das otimizações e checagens que por ventura a plataforma faça.

Vícios

Temos programadores que acham que podem viver conhecendo apenas uma linguagem e que esta deve servir para tudo, com isso aceitam estruturas estabelecidas mesmo que sejam nocivas.

A Sun criou o conceito de Java Beans para componentes visuais e extendeu esse conceito para sua plataforma Enterprise para designar ADTs que encapsulam suas propriedades.

Hoje a maioria dos desenvolvedores quando codificam suas classes o fazem com um passo-a-passo em mente:

  1. Cria uma classe que representa uma tabela no banco de dados;
  2. Cria as propriedades referentes as colunas nessa tabela;
  3. Atribui private para todas as propriedades;
  4. E por fim cria métodos "set" e "get" para todas as propriedades indiscriminadamente.

Se voce criar uma construção que acesse "objeto.propriedade" é pecado mortal em java, não segue a "convenção".

Em linguagens que implementam o ECMAscript voce tem no BOM (Browser Object Model) o método setProperty(chave, valor) nativo que atribui um valor à propriedade  indicada e não necessita implementar um atribuidor para cada método. Sabiamente não existe um getProperty, voce acessa diretamente.

Em java se uma propriedade é read-only tem coerência voce aplicar um private no qualificador e criar um método getX, outra situação é se voce deseja manipular o valor em tempo de execução, então um método get e ou set tem necessidade. Fora isso  é desnecessário e a propriedade é pública.

Generalidade vs Especificidade

O problema maior com padrões é querer extender uma linguagem além do que ela foi arquiteturada. Como simular Continuations que é nativo da linguagem Scheme, ou Design By Contract do Eiffel. Voce pode fazer ambos em Java, tanto Continuations como DbC podem ser feitas mas com gambiarras, não são inerentes da arquitetura concebida na plataforma Java. Existem até Framework e Container Java que implementam continuations, mas sofridamente.

Inclusive alguns entusiastas do Ruby mais afoitos (A.K.A novatos) fazem bastante algazarra em listas de discussões de como conseguem fazer uma iteração ou outra operação específica com menos linha de código que linguagens como Java ou C++. Claro que é perda de tempo total tentar dialogar e mostrar a necessidade da escolha ideal para o determinado propósito, os programadores de verdade sabem que Ruby também não será o fim dos tempos, conceitos surgirão e retornarão dependendo da situação.

Outra situação depende do ambiente, como simular MVC em uma ambiente web, devido a diferença de contexto do ambiente http em detrimento ao ambiente standalone de um desktop surgiu o famigerado MVC model 2 que deu cria a aberrações como Struts e derivados. Isso hoje pode ser contornado mas ainda é incipiente.

Na mesma forma acontece com padrões, como o contexto de uma linguagem está atrelada a determinado ambiente é vital incorporar conceitos deste contexto na sua semântica e deixar a extensão para o desenvolvedor do que ser genérica e causar improdutividade com tarefas repetitivas, vide sucesso do ruby na construção de aplicações web com o Ruby On Rails.

Em diversas épocas os padrões como Singleton e Factory vão e voltam com desenvoltura, em momento amado e indispensável, outro odiado e suplantado. Mas são padrões universais para resolver um determinado problema, catalogado e disponível para quando forem requisitados.

Padrões são assim, como quase tudo na vida, desnecessários as vezes e se usados com moderação são benéficos. Como dizia minha vó, "tudo demais é veneno".