Continuando a leitura do livro O Programador Pragmático… Acabei de ler o primeira capítulo e novamente mais uma surpresa com o livro. Basicamente ou autores dão uma visão geral de todo o conteúdo do livro e abusam das analogias por todas as partes, e isso pra mim é mais um ponto positivo, o entendimento da ideias e da forma de pensar dos autores ficam muito mais claras, e de forma objetiva.

O primeiro capítulo começa contando a filosofia do pragmatismo, onde os autores falam de onde veio a ideia de pragmatismo.

Agora mais um resumão das partes que mais me chamaram a atenção:

Logo no início os autores exemplificam como um programador pragmático se diferencia de outros, e em um parte está escrito: “Ele raciocinam além do problema imediato […] sempre tentando tomar conhecimento do cenário em maior escala”. Além disso os autores fazem questão de repetir sobre atitude e responsabilidade, onde o programador sempre é responsável por tudo que faz e assume seus erros.

Ainda sobre dar opções os autores falam sobre como dizer que algo não pode ser feito, “[…] Antes de abordar alguém pra dizer que algo não pode ser feito […], pare e escute a si próprio […]. Sua desculpa parece convincente ou estúpida?”

Os autores falam sobre pensar em quais perguntas o ouvinte irá lhe fazer, é bom ter as respostas antes, e se nada pode ser feito, é hora de falar sobre as opções.

Na segunda parte do primeiro capítulo o livro fala sobre não conviver com janelas quebradas, ele exemplifica com mais uma analogia que diz que se você tolerar falhas, logo as coisas vão sair do controle, para saber mais é só procurar sobre a “Teoria das Janelas Quebradas”.

A terceira parte do primeiro capítulo fala sobre estar preparado para mudanças, pois muitas vezes as pessoas tem medo de mudar e os autores propõem que nós devemos ser catalizadores de mudanças, “[...]Planeje o que você deseja pedir. Desenvolva isso bem.[...] Mostre o que obteve as pessoas e deixe que se admirem. Então diga ‘é claro que ficariam melhor se adicionássemos…’”. As pessoas tendem a apoiar ideias que já estão funcionando, então tome atitude e mostre os resultados.

“Aceite e esteja preparado para as mudanças, assuma que o que você está fazendo agora pode não ser o melhor modo amanhã”

Porém, a atitude de mudar deve ser tomada com cuidado!

Continuando a terceira parte os autores falam sobre verificar constantemente o seu cenário, como por exemplo as pequenas falhas que são inseridas diariamente no projeto, em pouco tempo saem do controle, então não tolere janelas quebradas.

A quarta parte fala qualidade, onde você deve desenvolver pensando em qualidade, o sistema deve ser satisfatório para o usuário e também em sua estrutura interna. Você deve se preocupe com a qualidade mas deve saber a hora de parar, isso não quer dizer que é pra fazer código feito, só que devemos saber a hora de para.

O processo de desenvolvimento deve envolver os usuários, já que é pra eles que desenvolvemos (Assunto muito falado nas metodologias ágeis).

A quinta parte é sobre conhecimentos, onde os autores chamam de carteira de conhecimento as habilidades que nós possuímos, e essa habilidades tem prazo de validade. Entra as várias dicas que os autores dão uma que me chamou atenção é a de ler pelo menos um livro técnico a cada três meses. Há também uma parte sobre ter pensamento crítico que é bem legal, esse é um assunto que eu já tinha visto em uma apresentação do Akita (http://www.akitaonrails.com/2008/09/13/off-topic-matando-a-m-dia).

E no final há entre os desafios um que é de aprender um nova linguagem de programação por ano (vide: http://www.programadorpoliglota.com.br/).

Pra finalizar o primeiro capítulo, os autores falam bastante sobre a importância da comunicação, e de saber se comunicar direito independente de ser em uma reunião, apresentação ou e-mail. Nessa parte também há uma pequena receita de bolo de como manter um boa comunicação, e entre essee todos os tópicos há três que eu achei bem interessantes, que são:

1. Saiba o que você quer dizer

2. Conheça seu público-alvo

3. Escolha seu momento

O item número três dessa lista também e exemplificado no livro “[...] Aborde um gerente que acabou de ter problemas com seu chefe porque algum código-fonte foi perdido e terá um ouvinte receptivo para suas ideias sobre repositórios de códigos-fonte[...]”

O item número dois me lembra bastante um artigo que eu li a um tempo atrás na InfoQ BR sobre Diferenças entre Gerações, que por sinal veio a calhar já que na época eu tinha que fazer uma apresentação sobre metodologias ágeis para um professor de COBOL, e após a leitura desse artigo eu percebi que teria de adaptar a abordagem da apresentação.

Gabriel Rubens