O dia em que latitude e longitude me ensinaram sobre padrões, liderança e humildade técnica

Quando trabalhei em uma empresa de engenharia, passei por uma experiência que, na época, foi desconfortável, mas que hoje vejo como uma das melhores aulas práticas que já tive sobre programação, comunicação entre sistemas e cultura de pesquisa e desenvolvimento.

Eu trabalhava no departamento de pesquisa. O setor era liderado por um profissional experiente, com uma idade próxima da que tenho hoje, mas com uma postura pouco flexível em relação a novas tecnologias de programação. Isso me causava certa estranheza, porque, para mim, um setor de P&D deveria ser justamente o lugar onde a experimentação, a comparação de ferramentas e a abertura a novas abordagens deveriam florescer. Na época, eu insistia em usar Python, enquanto ele preferia uma linguagem baseada em Basic, uma herança tecnológica de outro tempo. Não nego que aquela linguagem já havia tido seu valor, mas eu não via sentido em perpetuar uma tecnologia ultrapassada dentro de um departamento que deveria respirar inovação.

Apesar desse atrito silencioso, ele não implicava diretamente comigo o tempo todo. Havia também outro programador muito experiente, com profundo domínio da matemática aplicada à engenharia, além de colegas recém-formados, todos tentando fazer o melhor dentro daquele ambiente. Em determinado momento, fui solicitado a ajudar outro programador que estava aprendendo a construir uma interface para um sistema de coleta de informações. A ideia era receber dados e exibi-los sobre um mapa.

Foi aí que começou o desafio.

Até aquele momento, eu não tinha experiência real com coordenadas geográficas. Para mim, escrever primeiro latitude e depois longitude, ou longitude e depois latitude, parecia apenas uma escolha de ordem. Na minha cabeça, bastava manter coerência interna e tudo funcionaria. Mas programação profissional não vive apenas de coerência interna. Ela vive também de contratos, padrões, documentação e comunicação clara entre partes diferentes de um sistema.

O problema apareceu quando precisei transformar coordenadas geográficas em coordenadas euclidianas para exibir os pontos em uma tela plana. De um lado, eu tinha latitude, que indica deslocamento norte/sul; de outro, longitude, que indica deslocamento leste/oeste. Em um plano cartesiano, porém, o eixo X representa o deslocamento horizontal, e o eixo Y representa o deslocamento vertical. Logo, para uma projeção simplificada em pequenas distâncias, fazia sentido tratar longitude como X e latitude como Y.

A confusão nasceu justamente aí.

No mundo geográfico comum, especialmente em ferramentas como o Google Maps, a forma mais familiar é informar primeiro a latitude e depois a longitude. A própria documentação do Google Maps orienta o usuário a pesquisar coordenadas nessa ordem: latitude primeiro, longitude depois. Já em formatos técnicos como GeoJSON, a ordem da posição é longitude primeiro e latitude depois, exatamente porque segue a lógica mais próxima de coordenadas de plano: primeiro o eixo leste/oeste, depois o eixo norte/sul. O RFC 7946, que especifica o GeoJSON, afirma que os dois primeiros elementos de uma posição devem ser longitude e latitude, nessa ordem.

Hoje isso parece simples. Na época, não parecia.

Eu acabei cometendo um erro de interface. Internamente, fazia sentido converter latitude e longitude para Y e X, respectivamente. Mas a chamada da API, ou seja, o contrato de comunicação com o restante do sistema, deveria deixar claro qual padrão estava sendo seguido. E foi nesse ponto que a falta de documentação do setor pesou. O problema não era o Python. O problema não era a versão da linguagem, que na época era Python 2 e hoje seria Python 3. O problema também não era simplesmente “eu”. O problema era o ambiente técnico não ter deixado explícito o padrão adotado.

Só que, na hora do erro, a reação vinha em forma de grito da outra sala:

“Não estou falando que esse Python não presta?”

E confesso: naquele momento comecei a achar que o problema talvez fosse pessoal. Mas com o tempo percebi que a situação era mais profunda. Em ambientes técnicos, principalmente em P&D, o erro individual muitas vezes revela uma falha coletiva: ausência de documentação, ausência de padrões, ausência de revisão, ausência de cultura de acolhimento ao erro e, principalmente, ausência de liderança técnica voltada ao aprendizado.

Foi ali que aprendi uma lição que levo comigo até hoje: não importa como os dados são tratados internamente; a interface pública do sistema deve respeitar o padrão esperado por quem vai consumir aquela informação.

Se internamente eu preciso transformar longitude em X e latitude em Y, tudo bem. Mas a função, o gateway, a API ou o protocolo precisam deixar isso explícito. Melhor ainda: devem usar nomes claros, como latitude e longitude, em vez de parâmetros genéricos como x, y, coord1 ou coord2, quando o domínio ainda é geográfico. A conversão para coordenadas euclidianas deve acontecer em uma camada própria, documentada, testada e isolada.

Aquele sistema, na prática, era um gateway: recebia posições geográficas e as convertia para uma representação plana. Como as distâncias eram pequenas, eu não precisava lidar com todos os detalhes da curvatura da Terra ou com projeções cartográficas complexas. Mesmo assim, o pequeno detalhe da ordem dos parâmetros foi suficiente para causar confusão, tensão e retrabalho.

E é aqui que entra a grande lição humana.

Para um departamento de pesquisa e desenvolvimento funcionar bem, é preciso liberdade para criatividade e inovação. Mas liberdade não é bagunça. Criatividade sem padrão vira ruído. Inovação sem documentação vira dependência de memória oral. E liderança técnica sem abertura ao novo transforma P&D em museu de tecnologia.

Ao mesmo tempo, também aprendi a olhar para meu próprio erro com mais maturidade. Quando descobri que o GeoJSON usava a ordem longitude, latitude, senti certo alívio. Vi que minha intuição não era absurda. Ela apenas estava aplicada na camada errada. Eu não estava completamente errado; eu estava incompleto. Faltava contexto, faltava padrão, faltava documentação e faltava uma fronteira mais clara entre dado geográfico e dado cartesiano.

Essa diferença é preciosa. Estar errado é uma coisa. Estar sem informação suficiente é outra.

Por isso, hoje, quando desenvolvo sistemas que comunicam módulos diferentes, equipes diferentes ou tecnologias diferentes, procuro tratar o contrato de dados com muito mais respeito. Uma API não é apenas uma função. Uma API é uma conversa formal entre partes que talvez nunca se encontrem. E, como toda boa conversa, ela precisa de vocabulário comum, ordem clara, nomes precisos e documentação mínima.

Também passei a valorizar mais a liderança que cria segurança psicológica. Em equipes inovadoras, as pessoas precisam conseguir fazer perguntas, admitir dúvidas, testar hipóteses e corrigir erros sem serem humilhadas. Amy Edmondson, professora da Harvard Business School, trabalha bastante esse conceito de segurança psicológica, defendendo ambientes onde as pessoas possam falar, perguntar e corrigir falhas sem medo paralisante. Isso é especialmente importante em P&D, porque pesquisa envolve incerteza. Se tudo já estivesse resolvido, não seria pesquisa; seria apenas execução.

Para quem lidera times de software, uma boa leitura complementar é Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams, de Mickey W. Mantle e Ron Lichty. O livro trata justamente dos desafios de liderar programadores, formar equipes produtivas e criar uma cultura técnica mais saudável. Para uma visão mais ampla sobre inovação e resistência a novas tecnologias, The Innovator’s Dilemma, de Clayton Christensen, também é uma leitura valiosa, pois discute como organizações bem-sucedidas podem falhar justamente por se prenderem demais a decisões e tecnologias que fizeram sentido no passado.

No fim, aquele episódio de latitude e longitude não foi apenas sobre mapas. Foi sobre comunicação. Foi sobre padrões. Foi sobre liderança. Foi sobre humildade técnica.

E foi também sobre uma frase que hoje eu repetiria para mim mesmo naquela época:

“Carlos, o Python não é o problema. Mas documentar melhor a fronteira entre latitude/longitude e X/Y teria evitado uma bela dor de cabeça.”

Referências para leitura futura

• Google Maps Help — Find or enter latitude & longitude
• https://support.google.com/maps/answer/18539
• RFC 7946 — The GeoJSON Format
• https://www.rfc-editor.org/rfc/rfc7946
• Amy C. Edmondson — The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth
• Livro recomendado sobre segurança psicológica, liderança e ambientes de aprendizado.
• Mickey W. Mantle e Ron Lichty — Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams
• Livro recomendado sobre liderança de equipes de software.
• Clayton M. Christensen — The Innovator’s Dilemma
• Livro recomendado sobre inovação, resistência organizacional e adoção de novas tecnologias.