Sobre Mim

O Percurso

Escrevi as primeiras linhas de código em 1982, em Portugal, a desenvolver aplicações de negócio para sistemas mainframe — COBOL, CICS, IMS, DB2. Era um trabalho exigente e preciso que me ensinou algo que nunca esqueci: o software que trata dados reais para organizações reais não tem tolerância para o descuido. Cada byte contava, cada transacção tinha de estar correcta.

No final dos anos 80 emigrei para a Austrália, onde completei estudos de pós-graduação no Swinburne Institute of Technology e depois um MBA no RMIT em Melbourne, com foco na gestão estratégica das tecnologias de informação. Regressei a Portugal em 1994, trazendo tanto a base técnica desses primeiros anos como uma compreensão mais ampla de como as organizações usam — e mal usam — os sistemas construídos para elas.

Durante década e meia trabalhei em TI e sistemas de negócio tradicionais. A viragem para a tecnologia geoespacial foi gradual e depois definitiva. A leitura da literatura científica sobre os grandes desafios estruturais do século XXI — a pressão demográfica sobre a produção alimentar, a escassez de água e a desertificação, a desflorestação e os incêndios florestais, o crescimento urbano contra os limites territoriais — levou-me sempre ao mesmo instrumento no centro da análise: o SIG. Não como ferramenta de cartografia, mas como o quadro que torna possível priorizar, comparar e agir sobre problemas que são, na sua essência, espaciais.

Essa percepção reorientou o meu trabalho por completo. Nos últimos oito anos concentrei-me em construir sistemas que tornam a inteligência espacial operacional — não plataformas de investigação nem showcases de visualização, mas aplicações funcionais que as organizações usam diariamente para tomar decisões ancoradas na realidade territorial.

Qualificações Académicas

Como Trabalho

• Open-source, sempre
  Todos os sistemas que construo correm sobre infraestrutura open-source — PostGIS, QGIS, Django, Python, Docker. Sem dependência de fornecedores, sem custos de licenciamento, sem sujeição ao roadmap de uma empresa. O cliente é dono da stack.
• O problema antes da tecnologia
  A escolha das ferramentas decorre da realidade operacional, não o contrário. Um sistema funcional que se adapta à organização vale mais do que um arquitecturalmente elegante que ninguém mantém.
• Entrega e documentação juntas
  Um sistema entregue sem documentação é um sistema que o cliente não consegue manter. Scripts de migração, runbooks e dicionários de dados fazem parte de todos os entregáveis.
• Infraestrutura mínima viável
  Um único VPS bem configurado suporta a maioria das cargas de trabalho reais. A complexidade só é introduzida quando o problema genuinamente a exige — não para tornar a arquitectura mais impressionante.

Trabalho com IA

Utilizo modelos de linguagem de grande escala como parte estrutural do meu fluxo de trabalho — não como substituto de pesquisa ou auxiliar de escrita, mas como camada de execução para um arquitecto que pensa em sistemas.

Durante a maior parte da minha carreira, conseguia conceber soluções que ultrapassavam o que era possível construir sozinho num prazo razoável. O fosso entre a concepção e a entrega era uma limitação prática, não técnica: as horas eram finitas e algumas tarefas de implementação exigiam especialistas a que não tinha acesso como consultor independente.

Essa limitação desapareceu em grande medida. Utilizo agora o Claude (Anthropic) como parceiro técnico colaborativo em toda a stack — desde lógica de back-end em Django e optimização de queries PostGIS até componentes de front-end, configurações Docker e automação de deployment. O modelo trata do detalhe de implementação a um ritmo e amplitude que de outra forma exigiria uma equipa pequena; eu trato da arquitectura, dos requisitos, da modelação de dados e das decisões que requerem compreensão do contexto operacional real.

O resultado é um aumento material do que consigo entregar — em âmbito, em velocidade e na complexidade dos sistemas que consigo sustentar como profissional independente. Todos os projectos listados neste site foram construídos com esta abordagem.

Sou preciso sobre o que isto significa e o que não significa. A IA não substitui o juízo de engenharia. Acelera a tradução desse juízo em código funcional — desde que a pessoa que a dirige compreenda o problema com profundidade suficiente para reconhecer quando o resultado está correcto, quando é plausível mas errado, e quando é a própria pergunta que precisa de ser reformulada.