Ubíquo Word.

O Word não só matou a documentação técnica como tomou o mundo da documentação de assalto. Desde a composição de documentos de notas com 3 ou 4 linhas, a livros com centenas de páginas, o seu uso é universal. Como as pessoas se habituaram ao Word, exigem receber documentos de Word. A situação chega a ser tão caricata como os seguintes casos reais:

• Cerca do ano 2000 enviei o meu CV em PDF a uma conhecida empresa. Responderam-me a dizer que não o conseguiam abrir – na altura o acrobat reader não estava muito disseminado – e que eu enviasse logo a versão “Word”. Algo impossível tendo em conta que eu não tinha usado sequer o Word para o produzir¹.

• Há uns anos enviei um artigo a um colega meu para revisão. Ele respondeu, algo frustrado, que tinha tido muito trabalho a editar o meu artigo porque eu não estava a usar um formato standard, e recomendou-me que da próxima vez o fizesse, que enviasse um doc de Word. O formato que lhe tinha enviado era HTML.
• Num sítio onde trabalhei havia um processo manual para fazer backups. Eu estava lá contratado para fazer administração de sistemas, mas aproveitei algum tempo livre para desenhar e desenvolver um software que automatizava o sistema de backups. O cliente ficou satisfeito com esse sistema novo mas alertou que não havia documentação. Compilei num README.txt toda a informação técnica sobre esse sistema. Como estava construído, como se instalava no master e nos slaves, como se corria… no dia seguinte mostrei o ficheiro de texto ao cliente. Instantaneamente vira-se para mim e diz: “Isto não é nada” (mesmo assim). Perguntei porquê, o que esperava ter encontrado que não estivesse no documento. Olhou-me de forma estranha, hesitou um pouco e disse que aquilo não era um documento. Apenas. Na realidade ele esperava a mesma informação só que num ficheiro Word. Um ficheiro de texto, apesar de conter o mesmo conteúdo, não era considerado “um documento”.
• Por fim, ainda me recordo de algumas coisas me terem caído ao chão – e não vou detalhar se em sentido alegórico ou não – quando vi este requisito por parte de uma empresa pública: “O adjudicatário entregará à entidade adjudicante (…) a seguinte documentação em suporte digital (.pdf e .doc/.ppt/.rtf) e em papel: (…)”.

---

1. tinha usado groff.↩

15 anos de desenvolvimento de software.

Ao longo de 15 anos na área do desenvolvimento de software, sobretudo no mundo das telcos, eis o cenário que pinto sobre o estado de arte nacional.

1. Não se faz 100% desenvolvimento: ao longo do tempo acabam por se fazer coisas tão díspares como administração de sistemas, coaching, entrevistas, gestão de projectos, burocracia e, sobretudo, pré-venda. Varia com cada um, mas há sempre desvios. Razões para isto?
   • não existe mercado em Portugal para manter uma função exclusiva de desenvolvimento;
   • o desenvolvimento feito em Portugal tipicamente é básico, logo pode ser feito por juniores, logo…
   • não há carreira técnica;
   • não há investimento em inovação, quanto mais em pesquisa;
   • a inovação existente resulta da utilização ou colocação em prática de novos softwares ou práticas vindas de fora, e.g. inovação por compra de novos produtos ou upgrade de versões.

2. A estratégia de TI empresarial está sujeita aos fornecedores tecnológicos.

3. O desenvolvimento nacional é pouco ambicioso e simples: a maior parte dos projectos desenvolvidos de raiz são uma implementação básica – ainda que por vezes massiva e/ou complicada – de um modelo source-process-dump. E.g. boa parte das aplicações web.

4. As necessidades de software mais exigente, do ponto de vista de complexidade, são normalmente supridas por soluções 3rd party.

5. Os projectos atrasam-se ou correm mal raramente por questões técnicas – já que são simples q.b. – mas por:
   • requisitos mal especificados inicialmente e alterados de forma inconsistente – continuando mal especificados – ao longo do projecto;
   • problemas de integração com outros sistemas;
   • indisponibilidade de ambientes e dados.

6. A tecnologia escolhida tem pouco impacto no projecto e é irrelevante para a organização: mesmo que outras linguagens e plataformas melhorassem 10x a produtividade no desenvolvimento e deploy, esse tempo seria diluído nas ineficiências gerais do projecto.

7. A falta de qualidade do código é suprida via testes, ou seja, prática de code-and-fix.

8. Os programadores juniores apresentam lacunas, que são impeditivas de realizar software bem construído embora suficientes para realizar os nossos projectos básicos (ainda que sem uma boa construção), em:
   • estruturação;
   • abstracção;
   • automatização;
   • scripting e prototipagem.

   As práticas de código mais comuns baseiam-se em excesso de programação imperativa mal estruturada com abuso de copy paste. Há evidência baseada em estudos que estes factores não melhoram com a experiência.

Spam surreal.

As motivações do spam são conhecidas e têm o seu racional, ainda que ilegítimo. Agora fazer spam assim ultrapassa qualquer nível de compreensão!

From - Wed Oct 26 10:26:54 2011
Return-Path: <loriannelvira@cnh.com>
Received: from cfirg6vf (Static-96.99.98.14.tataidc.co.in [14.98.99.96] (may be forged))
    by ?????????? (8.14.4/8.14.3) with SMTP id p9Q9JrEL006873
    for <??????????????>; Wed, 26 Oct 2011 09:20:02 GMT
From: "Darcel Karlyn" <loriannelvira@cnh.com>
Subject:  6rr4k5
MIME-Version: 1.0
To: <??????????????>
Date: Wed, 26 Oct 2011 12:16:11 +0200
Message-ID: <98e24f23r72-48175613-679n2l41@hnxbidy>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

jq

As pessoas são recursos?

O uso do termo “recurso” como designação de pessoa tem-se vindo a generalizar e banalizar. Mas são as pessoas recursos?

Um recurso é algo do qual se faz uso para um propósito. Como recurso é indistinguível face a outros equivalentes ou iguais. Por exemplo, posso trocar um carro por outro modelo igual sem perda de funcionalidade ou necessidade de adaptação.

Ora as pessoas não têm “modelos iguais”. Se assim fosse não eram precisas entrevistas no processo de contratação, bastava consultar a ficha técnica da pessoa. Não era preciso haver período experimental, ou outros expedientes usados devido à individualidade de cada ser humano.

O próprio lugar-comum “a maior riqueza são as pessoas” enferma de uma contradição na asserção pessoa-recurso. Se as pessoas se trocam facilmente enquanto recursos, não constituem maior riqueza que os outros recursos da empresa, como instalações, veículos, etc.

Resumindo: uma pessoa é um ser humano, não é um recurso.

Por incrível que pareça há pessoas que têm dificuldade em tratar as outras pessoas por… pessoas.

Notas:

• a expressão “recursos humanos” faz sentido enquanto designação de uma área comportamental ou organizacional;
• a expressão “recurso humano” não faz sentido para mim.

Outras leituras:

• Recursos Humanos na gestão de pessoas - Felicidade em pauta
• Você prefere ser chamado de colaborador ou recurso?
• Pessoas não são recursos!

Lições que podemos aprender com a NASA.

A NASA é a agência espacial dos EUA e é-lhe associada uma imagem de excelência, pelos feitos alcançados ao longo da sua história, apesar de terem tido a sua quota de reveses.

O contexto aeroespacial justifica condições ímpares que uma empresa comum não pode alcançar, no entanto algumas das práticas que a NASA tem empregue não exigem meios significativos e servem como exemplos a seguir.

Aprender com os erros

Especialmente no início da exploração espacial aconteceram muitos erros, houve muitas falhas e alguns desastres com consequências trágicas. O que a NASA fez foi aprender com esses erros. Com isto melhorou os protótipos seguintes, melhorou os métodos de treino, as técnicas de construção, etc.

O conceito de aprender com os erros em si nem é uma grande lição – o termo “lessons learned” ouve-se nestes dias em qualquer empresa – a sua prática efectiva é que o é. É preciso analisar o que se passou com objectividade, fugindo à tentação humana de (des)culpabilização. E com base nessa análise é preciso tomar acções correctivas.

Ora isto é algo que, da minha experiência, nunca acontece. Isto é, ou nem sequer é feita a análise, ou é mal feita, ou não se tomam acções de correcção.

Registos

A NASA dá muito importância aos registos. Registos de construção, registos de procedimentos, registos fotográficos, recolha de amostras, levantamento de materiais e equipamentos, etc.

Os registos são importantes para analisar problemas ocorridos, para servir de base a novos desenvolvimentos, para reconstituir cenários, etc.

Redundância

Ao longo do tempo popularizou-se o conceito que a NASA faz tudo a dobrar. Isto tem origem nos seus procedimentos reais desde longa data: eles mantinham duas equipas “iguais”, a principal e a de backup, sujeitas aos mesmos treinos durante todo o ciclo de preparação para uma missão, por exemplo. Também tinham réplicas de equipamentos e peças. Os próprios equipamentos construídos eram desenhados com vários sistemas de backup em casa de falha dos componentes principais.

Estar preparado

Além de tudo o exposto, a NASA tem mostrado o conceito de estar preparado, fazendo uso, por exemplo, das mais mundanas técnicas e materiais.

Um exemplo é a fita adesiva, que desde longa data faz parte do material levado pelos astronautas para o espaço, tendo sido já útil por algumas vezes. Não sendo um material de alta tecnologia, foi importante em certos contextos devido à sua versatilidade.

---

No próximo artigo, usando o caso real da missão Apollo 13, mostrarei como muitos dos eventos reais ocorridos se encaixam nestas práticas.

O Word matou a documentação técnica.

Sejamos sinceros: escrevemos pouca e má documentação. Sobretudo técnica. Porquê?

• porque não temos cultura documental: escrevemos pouco… e lemos menos;
• porque não aprendemos a fazê-lo nas escolas;
• porque o mercado é demasiado pequeno para haver technical writers;
• e porque… usamos o Word?

Sim, o Word! O Word porque é universal e porque não é apropriado para escrever documentação técnica. Logo, se universalmente usamos algo inapropriado para uma finalidade, destruímo-la. QED :-)

Universalidade

Ainda estou para conhecer alguém, profissionalmente, que nunca me tenha enviado um .doc ou .docx. Toda a gente usa o Word! Seja para escrever 3 ou 4 linhas de anotações, seja para fazer o CV, seja para escrever regulamentação. Faz-se tudo com o Word. E nem se espera que os destinatários não abram os documentos ou não os consigam editar. É assumido que sim.

Isto “secou” as alternativas, que até existem, mas têm pouca comunidade. Não me serve de muito escrever em markdown (texto) se mais ninguém o fizer.

Inapropriado para documentação técnica

Primeiro algumas premissas que considero pertinentes na produção documental:

• A documentação técnica deve residir ao lado do código, num sistema de controlo de versões (SCV). Para poder evoluir com o código. É a única forma prática de o conseguir.

• Uma parte substancial da documentação deve ser gerada automaticamente, como APIs, tabelas, diagramas ou modelos de dados.

• Ferramentas simples e universais devem poder ser usadas para manter documentação: controlar versões, obter diferenças, corrigir ortografia, substituições massivas, etc.

• Devem poder ser gerados vários formatos finais para diferentes meios de publicação. Exemplos: PDF, html único, html paginado.

• Os formato finais devem poder ser construídos automaticamente.

Ora nada disto se consegue em termos práticos com o Word! O Word implica ter um enorme programa lançado, que só corre em Windows, usando as suas idiossincrasias. Ficamos fechados nesse interface, com um sistema de automatização complexo e limitado em VBA. Torna-se difícil descobrir diferenças entre versões. Torna-se impossível haver edição partilhada.

A técnica mais frequente de edição em equipa é penosamente sequencial: consiste em passar um .doc de mail em mail pelos vários editores. Isto tem impactos em termos de tempo – tem que se esperar que o actual “proprietário” passe o documento – e impede a resolução imediata de conflitos. No cenário em que o editor N estraga parte das edições do editor N-1, como passa o documento em seguida ao editor N+1, o N-1 só lhe voltará a ter acesso na revisão final, o que irá dificultar bastante o seu trabalho de correcção. Na realidade já assisti a muitas edições perderem-se desta forma.

Aos pontos acima acrescento um novo:

• A tarefa de documentar deve ser tão leve e fácil como a de programar!

Abrir o Word para documentar uma API, por exemplo, é pesado e “difícil”. Um fluxo típico de trabalho consiste em saltar de janela em janela, fazendo vários copy-pastes. Copy da janela de código, paste para a janela do Word. Todos os aspectos gráficos terão de ser feitos manualmente, um a um. Exemplo: colocar todas as variáveis em itálico, ou trechos de código numa fonte fixa.

Solução: texto!

Todos os pontos anteriores conseguem-se cumprir facilmente usando texto como representação fonte da nossa documentação.

Como tal a documentação deve ser escrita directamente em texto, ou pelo menos ter uma representação textual ¹, para que possa ser processada por ferramentas simples e comuns. O texto é um formato verdadeiramente universal, logo qualquer ferramenta virtualmente o suporta.

Assim:

• Edição leve e fácil: basta um editor de texto. Pode ser o nosso preferido. Pode ser o mesmo que usamos para editar código. Isto significa que podemos alterar a documentação sem sequer sair do contexto de desenvolvimento.

• Colocando os ficheiros de documentação num SCV a gestão de versões é imediata. Quem editou o quê? O que mudou entre duas versões? Conseguimos reverter uma edição errada, ou até melhor, reverter as porções erradas de um dada edição. Tal como já o fazemos em relação ao código.

• Edição simultânea em equipa: várias pessoas têm a hipótese de trabalhar na documentação em simultâneo, deixando o SCV tratar do merge das edições.

• O sistema de construção do projecto pode ser adaptado para construir a documentação, incluindo também a geração das partes automáticas.

Referências

• http://www.apeth.net/matt/iosbooktoolchain.html: descreve o processo usado para escrever o livro “Programming iOS 4”;

• do blog: documentação ágil;

• do blog: como são feitos estes artigos;

• a documentação oficial do Python usa o sphinx (reStructuredText);

• o projecto de documentação Read The Docs (RTD) também usa sphinx.

---

1. a edição até pode ser visual, através de um editor WYSIWYG, mas o formato dos ficheiros gravados deveria ser texto compreensível.↩

Mais linkedin.

Ainda sobre o meu rant acerca da utilizaçao do linkedin, estava a dar uma olhadela em potenciais grupos do meu interesse e, com o meu olho clínico :), reparei na seguinte preciosidade:

• Gestão de projectos: 3,061 members
• Portugal-a-Programar: 264 members
• Portugal Web Development Professionals: 135 members
• Java Development (Portugal): 107 members

Compare-se a diferença de membros entre o primeiro grupo e os restantes. Depois leia-se o ponto 1 do rant.

7FFP - reuniões.

Contexto: 7 factores que nos frustram a produtividade.

Uma reunião é uma boa “ferramenta” de trabalho: um grupo de pessoas reúne-se para decidir e esclarecer assuntos de forma muito mais célere do que seria feito de outra forma. Infelizmente esta utilidade, a par da facilidade de realização, levou ao seu recurso em exagero, sem preparação adequada, a chamada reunite.

As principais características do fenómeno reunite, segundo a minha experiência, são:

• reuniões em excesso

  Um exemplo notável foi num projecto de 6 meses, sem praticamente qualquer integração com equipas externas, ter sido convocado para cerca de 55 reuniões!

• desorganizadas, confusas, promovem divagações e são demoradas

  São raras as reuniões que têm uma agenda pré-definida ou que aos participantes seja distribuída informação relevante de antemão. A reunião típica é ad-hoc: convocam-se as pessoas e logo se vê. Isto origina divagações, conversas em ciclo que estendem para além do razoável a sua duração.

• pouco esclarecedoras, por vezes inúteis

  Não raramente acontece sair duma reunião demorada sem qualquer resultado prático: os temas entraram em loop, não se chegou a nenhuma conclusão, não foi definida qualquer acção.

Em suma:

• fazer agenda, distribuí-la aos participantes antecipadamente e segui-la durante a reunião;
• enviar informação relevante aos participantes antecipadamente;
• garantir que são produzidos resultados: são tomadas decisões, são distribuídas acções aos participantes.

7FFP - multitasking

Contexto: 7 factores que nos frustram a produtividade.

Apesar de por vezes termos a sensação que conseguimos lidar com vários assuntos em simultâneo, está provado que o ser humano diminui bastante de produtividade quando muda de contexto. Ou seja, as pessoas não lidam bem com o multitasking, mas são comummente pressionadas a fazer demasiadas coisas ao mesmo tempo.

Em suma:

• priorizar e fazer (bem) uma coisa de cada vez.

7FFP - mau uso do mail.

Contexto: 7 factores que nos frustram a produtividade.

O correio electrónico foi dos primeiros meios de comunicação a ser implementado em computadores, mesmo antes de existirem redes. As máquinas albergavam vários utilizadores que enviavam mails uns aos outros, no mesmo computador.

Apesar do impacto negativo causado pelo spam e por outras alternativas de comunicação, como as redes sociais, fóruns web, blogs, instant messaging, o mail continua a ser o meio de comunicação primário na internet. Todas as pessoas que conheço têm pelo menos uma conta e consultam-na com regularidade (se prestam a atenção devida aos mails é outra história). O mail tem algumas vantagens enquanto sistema de comunicação: não exige a atenção imediata do destinatário e é um meio rico de transmissão de informação, pode-se enviar desde texto simples a diversos conteúdos multimédia e anexos.

Pessoalmente leio sempre e com atenção os mails que me são intencionalmente direccionados, tal como sempre lhes respondo, sempre que apropriado. Infelizmente não me parece que este comportamento seja generalizado. Do que tenho constatado, as pessoas…

• não lêem com a devida atenção os mails, especialmente se tiverem muito que ler;
• recebem demasiados para que lhes possam prestar atenção;
• algumas não lhe ligam muito;
• algumas não (os) sabem escrever.

“Ler na diagonal”

Ler na diagonal, à letra, não existe. Tipicamente isto consiste em ler as primeiras palavras e, eventualmente, parte das últimas. A pessoa fica com uma ideia incompleta, por vezes errada, do que se tratava. Ou seja, o mail foi inútil.

Actualmente parece estar a surgir um novo chavão a substituir este li na diagonal que é o vi que enviaste mas não li!

Porque recebemos demasiados mails?

• porque estamos subscritos em demasiadas coisas: grupos, mailing lists, etc;
• porque os mails têm demasiada gente em “CC” e acabamos por receber coisas que podíamos dispensar.

Pressão resultante do mau uso do mail

Se a informação transmitida por mail não passa, os destinatários ficam sem conhecimento que deviam ter ou tentam obtê-lo por outros meios (telefone, pessoalmente). Ambos os casos têm consequências directas em perda de produtividade.

Em suma:

• usar classificadores automáticos sempre que possível;
• remover subscrições e sistemas de notificações em que até podíamos estar interessados mas não temos tempo e raramente prestamos atenção, de qualquer modo;
• moderar a quantidade de gente que se adiciona em “CC”;
• resolver (e responder) imediatamente os mails que podem ser resolvidos imediatamente;
• prestar atenção ao que se recebe e escrever com atenção o que se envia: poupa muito tempo e trabalho a todas as partes.

7FFP - demasiadas rotinas.

Contexto: 7 factores que nos frustram a produtividade.

É fácil criar rotinas e definir procedimentos, especialmente quando é para os outros fazer. Facilmente cai-se em exagero ou em inutilidades. Ao longo do tempo tenho assistido a casos que enquadram em um ou mais dos seguintes factores: excesso de rotinas, sobre-complexas, inúteis, evitáveis. Este tipo de situações consomem tempo útil de trabalho e desmotivam.

Em suma:

• automatizar procedimentos manuais;
• não complicar processos.

7FFP - cansaço.

Contexto: 7 factores que nos frustram a produtividade.

Existem pela net muitas histórias de pequenas calamidades feitas a nível profissional devido ao cansaço. As que envolvem administradores de sistemas ou DBAs são particularmente populares, por razões óbvias.

Com a pressão causada por coisas como prazos irrealistas, cortes de pessoal ou má eficiência de organização, entre outros, as pessoas acabam em alturas críticas por reduzir o tempo de descanso, tornando-se menos produtivas e causando mais erros.

Em suma:

• dormir mais;
• ser mais realista.

7FFP - atrasos.

Contexto: 7 factores que nos frustram a produtividade.

O problema dos atrasos é óbvio: enquanto alguém espera por alguém está a perder tempo. Está simplesmente parado, sem produzir, a gastar o seu tempo… à espera.

Infelizmente os atrasos não se resumem apenas a atrasos “sociais”, em que alguém espera por alguém. Também temos atrasos entre equipas, projectos, sistemas, pagamentos… O atraso de pagamentos a fornecedores em Portugal será provavelmente o inimigo número 1 do sector das pequenas e médias empresas.

O irónico dos atrasos é que muitos podiam ser resolvidos a custo zero, bastando “apenas” uma mudança de atitude por parte das pessoas. Assisto a muitos atrasos que não têm qualquer razão de ser: se uma reunião está marcada às 15h, digamos, as pessoas começam a dirigir-se para a sala já às 15h05, sabendo que ainda vão demorar uns 5 minutos a lá chegar, sem que haja qualquer razão para que o não tivessem feito às 14h55 ou até um pouco antes.

Escrevi “apenas” propositadamente entre aspas, porque se há coisas que são fáceis de mudar em teoria mas quase impossíveis na prática, atitudes e mentalidades estão entre elas.

Em suma:

• levantar da cadeira mais cedo!

7FFP - falsa panaceia das aplicações online

Contexto: 7 factores que nos frustram a produtividade.

De há uns anos para cá surgiram as aplicações web e com elas veio o suposto eldorado dos nossos problemas processuais. Na verdade, se não houver reengenharia de processos, uma aplicação web apenas moderniza a burocracia, não a resolve. Exemplificando com a burocracia estatal, substitui impressos por formulários web e balcões por acessos à internet… facilita, mas não resolve o problema base.

Outro problema consiste nas limitações de integração da solução. Se uma aplicação apenas dispõe de um só interface, web, toda a sua interacção tem que passar por aí. Isso obriga o utilizador a abrir o browser, navegar pela usabilidade da aplicação e realizar operações através das interacções web disponíveis. Para pequenas acções pode ser suficiente, para uso frequente talvez não. Num mundo ideal as aplicações web deveriam ser clientes de uma solução SOA. Nesse cenário qualquer pessoa poderia escolher a melhor interacção, mais automatizada e que lhe desse menos trabalho. Infelizmente raramente isso acontece.

Finalmente outro fenómeno usual é a redundância de informação pedida. A falta de single-sign-on é um dos problemas mais frequentes mas também um dos que mais vai sendo endereçado. Coisas como pedir várias vezes os mesmos dados, especialmente dentro de uma organização, como usernames, nomes, centros de custo, managers, departamentos, etc são também frequentes.

Em suma:

• simplificar processos primeiro;
• criar serviços;
• desenvolver as aplicações baseadas nos serviços;
• evitar redundância.

7 factores que nos frustram a produtividade.

Quem nunca chegou ao fim do dia com a sensação de ter estado sempre ocupado mas não ter feito nada? Isso acontece porque ao longo desses dias aconteceram muitas coisas que nos consumiram tempo sem que daí adviesse produção correspondente.

Ao longo do tempo tenho identificado alguns factores genéricos, comuns à maioria das funções, que contribuem para isso. Segue a lista sem qualquer ordenação relevante, ficando o desenvolvimento de cada um dos pontos para artigos posteriores.

• reuniões;
• atrasos;
• mau uso do mail;
• cansaço;
• falsa panaceia das aplicações online;
• demasiadas rotinas;
• multitasking.

3 coisas que aprendi no linkedin.

1. toda a gente é chefe, importante e excelente no que faz.

Pode ser apenas consequência do crescente fenómeno “auto-promoção”, pode ser uma questão de superioridade ilusória, mas o que é certo é que a maioria dos perfis no linkedin com que me deparo são CTOs, CEOs, COOs, directores, project manangers, team leaders, entre outros cargos superlativos, sendo simultaneamente especialistas triple-A em tudo o que fizeram até então e mesmo no que não fizeram.

2. rede de contactos totalmente falhada.

O objectivo do sistema de contactos é construir uma rede de pessoas que se conhecem bem: trabalharam juntas, têm um bom nível de confiança mútuo, etc. Por isso é que os segundos e terceiros níveis podem estar-nos expostos, mediante configuração do nosso contacto de primeiro nível: “eu confio em quem confia em quem eu confio”.

Mas em que se tornou a rede de contactos? Numa lista infindável que tanto é composta pelo nosso “braço direito”, como pelo tipo a quem enviámos um email por engano há 5 anos.

Há dias dei uma olhadela na lista de pessoas que são vistas por quem vê o meu perfil:

• 3 simplesmente não sei quem são;
• 2 são ex-colegas de quem nada sei há mais de 10 anos;
• outros 2 são-me pouco relacionados;
• e finalmente 3 estão mesmo relacionados comigo, sendo os únicos que fazem parte da minha rede de contactos.

3. recomendações recíprocas e avantajadas.

Outro factor curioso é o sistema de recomendações do linkedin ter-se transformado numa espécie de colectânea de eufemismos. Chego a lacrimejar-me todo tão ternurenta é a prosa com que os colegas se mimam.

E em tantos casos de forma recíproca. É que se o A recomenda o B, o B não se fica por menos e recomenda o A. É uma espécie de “cá se faz cá se paga” numa versão positivista do karma.