Se você escreve mal, programa mal

E ponto final.

É impressionante a quantidade de pessoas com curso superior na área de informática (o que sugere que a pessoa deveria ter mais conhecimento do que uma sem curso superior…) que não sabe escrever um texto minimamente coeso, muito menos manter uma linha de argumentação consistente em uma conversa.

Não estou dizendo que sou um professor Pasquale, muito menos um mestre na arte da argumentação, mas sempre gostei das ciências humanas e me esforço para melhorar na comunicação. Por quê? Bom, desenvolvimento de software é 90% comunicação. Comunicação com clientes, com membros da equipe, com parceiros, comunicação do seu pensamento em forma de código.

A “era da internet”, de Orkuts, Messengers e afins, tornou o cenário ainda pior: além da deficiência lógica, a total falta de conhecimento gramatical e ortográfica se tornou uma epidemia. A “preguiça” de escrever corretamente, em nome da agilidade na comunicação virtual, tornou-se hábito e “emburreceu” as pessoas.

Programar é uma atividade criativa, envolvendo muito raciocínio e lógica. O mesmo ocorre com a argumentação. Existem técnicas bem definidas para ambas, mas a qualidade do produto final depende das habilidades do executor.

Como discuti anteriormente, o programador apenas programa, traduz, codifica como uma máquina. O desenvolvedor de software, que tem na programação uma de suas principais atividades, busca mais conhecimento, se aprimora, sabe se comunicar.

Então, como alguém espera (ou afirma) ser um bom desenvolvedor de software quando não consegue escrever uma simples frase sem cometer seguidos erros ortográficos e lógicos?

February 1, 2008 | Filed Under Artigos, Desenvolvimento | 6 Comments 

Programador ou Desenvolvedor?

A diferença entre um programador e um desenvolvedor de software é muito grande, mas quase sempre ignorada.

Presa à um paradigma completamente equivocado, a “indústria” do software busca imitar a indústria “convencional”, baseada no trabalho manual, seguindo muitas das idéias de Taylor e Adam Smith.

Essas idéias e princípios funcionam muito bem no chamado trabalho manual, que, em geral, atinge sua máxima eficiência quando organizado na forma de linha de montagem, com alta especialização e divisão de tarefas. Mais uma vez: desenvolvimento de software não funciona como linha de montagem.

Leia o artigo completo

January 30, 2008 | Filed Under Artigos, Desenvolvimento | 3 Comments 

Code smells

Você sabe o que é um “code smell“? Bem, mesmo sem saber a definição, são muito grandes as chances de que você já tenha se deparado com um.

Code Smell é um sintoma de que algo no código pode estar errado. Geralmente indica a necessidade de um refactoring ou de alteração estrutural da aplicação.

Alguns code smells muito comuns são:

E você, o que já viu por aí?

Veja também:

Code smells taxonomy
Refactoring.com

January 29, 2008 | Filed Under Desenvolvimento, Dicas | 4 Comments 

Entendendo sistemas distribuídos de controle de versão (Git, Mercurial etc)

dvcs

Você ouviu falar de Git e DVCS (Distributed Version Control System) mas ainda não entendeu bem o conceito? Bom, você não está sozinho.

Deixo aqui duas boas referências para aprender mais sobre o assunto:

Boa leitura.

January 23, 2008 | Filed Under Desenvolvimento, Tutoriais | Leave a Comment 

Tradução - Produtividade do desenvolvedor: Média vs. Mediana

Neal Ford, da ThoughtWorks, foi muito gentil ao permitir que eu traduzisse seu artigo “Developer Productivity Mean vs. Median“.

O artigo fala sobre algumas falsas crenças da “indústria” do software: linguagens restritivas, economia na forma de contratação de desenvolvedores medíocres e tentativa de encurtamento de prazos de entrega através da adição de mais pessoas aos projetos, entre outras.

Boa leitura!

Veja o artigo completo…

January 18, 2008 | Filed Under Artigos, Desenvolvimento, Rails, Ruby, Traduções | Leave a Comment 

Passar na prova ou realmente aprender?

cert1

A “cultura” da certificação é uma das “pragas” que infectam o mundo do desenvolvimento de software e da TI em geral.

Instituições e pessoas sem qualquer experiência real criam processos e avaliam empresas e profissionais com base em critérios duvidosos e, muitas vezes, obscuros.

Hoje existe uma série de metodologias e processos desenvolvidos por acadêmicos, que passam a maior parte do tempo estudando a teoria e criando software científico experimental. Essas pessoas podem ter boa vontade, mas não estão acostumadas com o dia-a-dia do desenvolvimento para clientes “reais”: empresas que esperam que o software seja a solução milagrosa para todos os seus problemas e investem muito nisso.

Baseadas nessa experiência acadêmica, essas pessoas criam processos que não condizem com a realidade do mercado comercial e emitem certificações de acordo com critérios igualmente irreais. Resumindo: certificam que você está usando um processo que não serve para o seu negócio (pode até servir para criar software que controla foguetes, mas não para o que a grande maioria das software houses cria).

Além das certificações para empresas, há também a delicada questão das certificações para os desenvolvedores (MCP, SCJP, Scrum Master etc). Fico me perguntando o que é que essas certificações garantem? Que alguém decorou centenas de linhas de código e esqueceu dias depois?

Bons desenvolvedores não precisam de certificação. Eles são bons em qualquer plataforma e ponto. Isso não significa que não existam bons desenvolvedores certificados, mas que uma grande massa de desenvolvedores medíocres utiliza das certificações para se “pendurar” em algum emprego que paga bem e ficar lá enganando. Em geral, essas certificações avaliam o “domínio” de técnicas em determinada linguagem ou plataforma, sequer chegando perto de avaliar se uma pessoa sabe ou não sabe desenvolver bom software.

Certificações também são utilizadas por selecionadores de mão de obra que são leigos em tecnologia. Como não sabem como avaliar um desenvolvedor de software, ordenam os currículos por número de certificações e, bingo, acreditam ter selecionado os melhores.

Assim como o Vinícius Teles em seus podcasts, acredito que nesses casos o que acontece é bem semelhante a uma prova escolar: os alunos decoram toda a matéria, fazem a prova e, pouco tempo depois, já não se lembram de mais nada. O conteúdo realmente absorvido é muito pouco.

Jamis Buck escreveu um excelente post sobre o assunto. Aqui vão alguns destaques:

Como regra geral, acredito que certificações são uma piada. Pura e simplesmente. (…) A simples idéia de que um teste pode, de qualquer maneira, implicar em competência é de se gargalhar.

Certificação pode produzir programadores competentes? Eu digo “não”. Se você é certificado e competente, então você era competente antes de ser certificado.

Certificações são usadas principalmente por tomadores de decisão ignorantes como um discriminador. Logo, se alguém quer ser notado por um tomador de decisão, precisa passar no teste. É a certificação pela certificação. Isto encoraja qualquer coisa, menos o aprendizado. Encoraja mediocridade em larga escala, causada por pessoas memorizando exatamente o que o teste exige e nada mais. Encoraja aprender fora de contexto. Encoraja a cópia no lugar de pensamento criativo.

prazo

January 14, 2008 | Filed Under Artigos, Desenvolvimento, Software | 2 Comments 

Expressividade no código ou “Porque testes, código bem escrito e refactoring são melhores que qualquer documentação”

Interessantíssimo o artigo do Phillip Calçado, “Expressividade no código“. Nele, Phillip fala o que todo programador já está cansado de saber mas que a maioria finge não saber ou, simplesmente, acha “trabalhoso” demais. Afinal, desenvolvimento “Quick and Dirty” dá muito menos trabalho, não é?

Pior ainda é conseguir convencer gerentes disso. Gerentes são burocratas por natureza, possuem uma paixão inexplicável por papelada e documentação (que nem eles mesmo utilizam), adoram andar com livros grossos pregando a última “revolução” no mundo dos processos, caçando certificações como Cobit e PMI e, principalmente, não enxergando um palmo à frente do nariz. Não é por acaso que, hoje, a inovação vêm das startups e pequenos grupos de desenvolvedores pragmáticos que focam no que realmente importa: software simples, elegante e que resolve problemas.

Voltando ao artigo, a leitura é altamente recomendada. Com um exemplo simples e direto, Phillip constrói seu argumento com rara habilidade. Habilidade que só a experiência com desenvolvimento real é capaz de trazer.

December 28, 2007 | Filed Under Artigos, Desenvolvimento, Software, Test-Driven Development | 2 Comments 

Google libera API de gráficos

A Google liberou hoje sua API de gráficos. Para usá-la basta chamar uma URL passando alguns parâmetros e você recebe um gráfico pronto para mostrar.

Alguns exemplos (note que não linkei para imagens, estou chamando a API diretamente):

Documentação: http://code.google.com/apis/chart/

Fonte: http://blog.leetsoft.com/2007/12/6/google-chart-api

December 6, 2007 | Filed Under Desenvolvimento, Dicas, Notícias | Leave a Comment 

Domain Specific Languages

Domain Specific Languages (DSLs) são um assunto cada vez mais comum no mundo do desenvolvimento de software. Não são novidades, mas começam a ser utilizadas de outras formas e ganhar notabilidade.

O Rails utiliza DSLs em peso, graças à natureza dinâmica do Ruby e sua flexibilidade.

Como publicado pelo Fábio Akita, a ThoughtWorks lançou, na semana passada, o primeiro episódio de seu podcast IT Matters, falando justamente sobre DSLs. O podcast é muito interessante e conta com ninguém menos que o próprio Martin Fowler e mais alguns membros de sua excelente equipe. Vale muito a pena conferir.

December 4, 2007 | Filed Under Desenvolvimento, Software | Leave a Comment 

Precisando de ajuda com Rails?

Quando você “enrosca” em algum problema durante o desenvolvimento com Rails, existem alguns lugares onde você pode procurar ajuda. A comunidade Rails costuma ser muito “solidária” e prestativa.

Seguem alguns links dos recursos que utilizo quando as coisas não dão certo:

October 18, 2007 | Filed Under Desenvolvimento, Rails | Leave a Comment 

← Previous Page — Next Page →