Da programação à liderança: bastidores de um Lead Developer na Imaginary Cloud

João Pinto, Lead Developer na Imaginary Cloud, esteve à conversa com o Teamlyzer sobre o seu percurso profissional e os desafios de liderar equipas técnicas. Numa entrevista que aborda desde metodologias de desenvolvimento até à gestão de projectos inovadores, o João revelou-nos os segredos de uma liderança técnica bem-sucedida e as práticas que fazem a diferença no desenvolvimento de software.

1# Como descreves o teu percurso de carreira até chegares a uma posição de liderança técnica?

Tive a oportunidade de passar por muitos projetos e vários clientes em diferentes ramos e diferentes tecnologias, com muitos colegas e pessoas de backgrounds, carreiras e culturas distintas com as quais aprendi imenso e que me ajudaram a ter uma visão bastante abrangente do mundo do desenvolvimento de software.

Sempre que possível dei prioridade em trabalhar como developer fullstack pois sempre quis perceber como funciona um sistema de uma ponta à outra, pelo que tentei sempre envolver-me em tarefas que englobassem a stack tecnológica completa dos projetos onde trabalhei.

O resto surgiu naturalmente. Quando me tornei sénior comecei a ter mais responsabilidades a nível de entrega e de mentoria de outros colegas da equipa, até que surgiu uma oportunidade de liderar uma equipa e eu aceitei.

2# Quais foram os principais motivos que te levaram a escolher a Imaginary Cloud (IC) como o local para desenvolveres a carreira como Lead Developer?

Escolhi a Imaginary Cloud porque identifiquei na empresa uma oportunidade de crescer como profissional num ambiente que valoriza inovação, trabalho em equipa e desenvolvimento contínuo.

Fiquei impressionado com a cultura de colaboração e o foco em criar produtos digitais que fazem a diferença. Além disso, a abordagem da IC em relação a boas práticas de desenvolvimento e design alinhava-se com os meus próprios valores e objetivos de carreira.

3# Como tem sido a experiência em liderar equipas de desenvolvimento na IC e quais são os desafios mais frequentes no teu dia a dia?

A experiência em liderar equipas de desenvolvimento na IC tem sido bastante enriquecedora. Uma das coisas que mais valorizo é o ambiente colaborativo, onde todos os membros da equipa contribuem para o sucesso dos projetos, e o suporte que recebo da empresa para criar soluções de qualidade. Ser Lead Developer na IC tem-me permitido crescer como profissional, tanto em competências técnicas, soft skills, comunicação e gestão de pessoas.

Os desafios mais frequentes estão relacionados com a gestão de prioridades e expectativas, tanto da equipa como dos clientes. É necessário garantir que os prazos são cumpridos sem comprometer a qualidade do código ou o bem-estar da equipa. Outro desafio comum é a necessidade de equilibrar o trabalho técnico com a liderança, ou seja, encontrar tempo para apoiar o desenvolvimento técnico e, ao mesmo tempo, manter uma visão estratégica do projeto. É também preciso saber dizer não a pedidos que não sejam exequíveis por parte dos clientes mas saber conduzir a conversa de modo a descobrir uma solução, que apesar de ter alguns compromissos, não irá comprometer a visão final do cliente.

4# Que tipo de projectos são desenvolvidos pela IC?

A Imaginary Cloud desenvolve uma ampla variedade de projetos, atendendo a diferentes indústrias e necessidades. A empresa é especializada em desenvolvimento de software à medida, com destaque para soluções como aplicações web, móveis, cloud, e produtos que integram inteligência artificial e ciência de dados. Estamos envolvidos nos projetos desde o design e prototipagem até a implementação e entrega final.

Os projetos incluem tanto soluções completas, desenvolvidas internamente para empresas sem equipas técnicas, quanto extensões de equipas para apoiar projetos existentes. A Imaginary Cloud tem experiência em áreas como SaaS, automação de processos, e desenvolvimento ágil, sempre focada na criação de produtos eficientes e bem sucedidos no mercado.

5# Fala-nos sobre um projeto específico em que tenhas tido um papel fundamental. Qual foi o impacto desse projeto na empresa ou no cliente e quais os principais desafios que enfrentaste?

Posso dar o exemplo do projeto em que estou atualmente – uma plataforma inovadora de gestão contratual que pretende otimizar o processo de negociação de contratos, que atualmente ainda é, em muitos sítios, um processo antiquado e moroso. A solução facilita a criação, revisão, negociação, assinatura e gestão de contratos, garantindo mais eficiência e conformidade com playbooks e políticas internas.

Aqui desempenhei um papel importante na definição da arquitetura do sistema e na configuração de processos de deployment em ambientes cloud usando GCP e AWS. Orientei a implementação de várias integrações importantes, incluindo ferramentas de CRM como HubSpot e Salesforce, sistemas de armazenamento como Google Drive e Sharepoint, assim como ferramentas de assinatura eletrónica como DocuSign e Skribble. Adicionalmente, trabalhei na integração com modelos de linguagem avançados, como o ChatGPT, permitindo análises automatizadas e sugestões inteligentes durante a revisão contratual.

Entre os principais desafios, destaco a interoperabilidade com processadores de texto existentes, o que permite a qualquer momento os utilizadores exportarem o contrato da plataforma editá-lo nas suas aplicações de processamento de texto e depois re-importá-las de novo na plataforma sem perder nenhuma informação. Destaco também a necessidade de garantir a escalabilidade da plataforma para lidar com grandes volumes de dados contratuais usando uma arquitetura serverless e de integrar ferramentas externas de forma segura. Finalmente, a implementação de processos ágeis e robustos foi também essencial para manter a qualidade e a consistência do produto desenvolvido.

A equipa entregou um MVP funcional que está atualmente em produção e já conta com a utilização de vários utilizadores reais, destacando entre eles alguns departamentos legais de empresas conhecidas. Este lançamento foi um passo significativo para validar a solução no mercado, ao mesmo tempo que nos ajudou a capturar feedback valioso para incorporar em melhorias futuras.

6# Como descreverias a evolução da IC desde que começaste até agora, tanto em termos tecnológicos como culturais?

A nível tecnológico, a IC tem demonstrado uma forte capacidade de adaptação às tendências do mercado e às necessidades dos clientes. Houve um aumento significativo na adoção de ferramentas e tecnologias modernas, como frameworks de frontend e backend (React, Node.js, Django) e soluções de inteligência artificial e machine learning (PyTorch, Amazon SageMaker). Além disso, a IC tem também investido em metodologias ágeis e boas práticas de DevOps, o que tem vindo a melhorar a eficiência e a qualidade dos projetos entregues.

No plano cultural, a Imaginary Cloud tem mantido uma cultura de colaboração e inovação, mas evoluiu para ser ainda mais inclusiva e orientada ao bem-estar das equipas. Iniciativas para o desenvolvimento de competências, como formações e workshops internos, tornaram-se mais frequentes. Além disso, a IC tem continuamente valorizado o equilíbrio entre vida pessoal e profissional, continuando a apostar na possibilidade de trabalhar 100% remotamente e disponibilizando escritórios ou espaços de coworking para quando alguém quiser trabalhar presencialmente.

7# Quais as principais competências técnicas e intrapessoais que consideras essenciais para um Lead Developer?

A nível técnico, não é necessário dominar todas as tecnologias usadas nos projetos, até porque muitas vezes tal não é exequível dada a dimensão de certos projetos e respetivas stacks tecnológicas. No entanto, é necessário ter experiência em tecnologias e/ou projetos semelhantes para conseguir orientar a equipa e o projeto numa direção sustentável e na identificação dos padrões que devem ser utilizados. Depois o resto são muitas vezes detalhes de implementação que podem ser delegados para os membros da equipa mais experientes numa determinada tecnologia.

No que toca a competências intrapessoais, as mais importantes são a capacidade de delegar, de pedir ajuda e de manter boa comunicação na equipa. Como referi anteriormente, nem sempre sabemos tudo, por isso devemos ter a capacidade de delegar ou de pedir ajuda a alguém que saiba. A boa comunicação é essencial para o bom funcionamento de uma equipa, facto que é exacerbado quando se trabalha remotamente. O trabalho remoto tem muitas vantagens mas às vezes propicia alguns desentendimentos devido ao facto da comunicação ser muito à base de mensagens de texto. Sou também um grande defensor de ter as câmeras ligadas durante as videochamadas porque acho que nos ajuda a relembrar que do outro lado existe realmente um ser humano e não apenas um avatar ou um nome no ecrã.

É também essencial saber gerir a pressão e o stress, dado que és a pessoa que frequentemente tem que dar a cara pelos resultados da equipa. Aqui acho que realmente só se aprende a lidar com isso tendo passado por situações parecidas no passado. No entanto, acho que podemos incorporar alguns princípios do estoicismo para nos ajudar a lidar com isso, nomeadamente tentarmos apenas preocupar-nos com aquilo sobre o qual temos controlo e tentar ao máximo não pensar no resto.

8# Que estratégias utilizas para garantir a qualidade do código e a eficiência das equipas que supervisionas durante os ciclos de desenvolvimento?

Relativamente ao código gosto de automatizar tudo o que seja possível automatizar e o que não for possível gosto de elaborar style guides (onde se definem, por exemplo, convenções de código, como estruturar as aplicações, etc.) com a equipa para que se perca o mínimo de tempo possível em coisas que não interessa discutir e que surgem recorrentemente quando se fazem code reviews.

Por exemplo, em todos os projetos em que estou envolvido configuro sempre linters e formatadores de código que asseguram que o código tem sempre um aspeto consistente. Asseguro que as mensagens de commit do Git também seguem todas o formato e regras usando ferramentas como https://commitlint.js.org entre outras. Chega ao ponto de até as chaves do project.json estarem automaticamente ordenadas com bibliotecas como a sort-package-json para que tudo seja consistente e previsível.

Uma grande vantagem de tudo isto, para além de reduzir o esforço cognitivo de tomar todas estas pequenas decisões no dia-a-dia e assegurar um aspeto consistente para todo o projeto, é a minimização de problemas de merge conflicts quando se integra código dos diversos elementos da equipa, que são conhecidos infamemente na nossa área por causarem grandes dores de cabeça e perdas de tempo. Todas estas ferramentas depois correm com hooks em determinados comandos do Git ou em CI dependendo do tipo de ferramenta e do tempo que demoram a correr.

Sempre que possível tento prevenir silos de conhecimento, para evitar que apenas certos membros da equipa tenham conhecimento de uma determinada área da aplicação e introduzir alguma redundância, algo que pode ser feito envolvendo as pessoas em code reviews e também em pequenas demos internas (caso não haja nenhuma com o cliente).

Sou também um grande defensor de strict type checking, pelo simples motivo de apanharmos os erros muito mais facilmente e mais cedo no ciclo de vida do produto, mesmo em linguagens que por predefinição não o têm, como é o caso da maior parte das linguagens interpretadas como, por exemplo, o JavaScript em que podemos usar JSDoc ou TypeScript em modo strict e o Python com Mypy e Pyright.

É também essencial ter uma estratégia de testes e testes automáticos e aqui para mim não há uma única solução que funcione sempre. Há projetos que vão ter mais testes unitários e menos testes de integração, outros focados mais em testes funcionais e e2e, etc. Vai depender muito do tipo de projeto, do time to market pretendido e da composição da equipa existente, como por exemplo haver ou não QA dedicado. A grande vantagem aqui, para além de obviamente validar o correto funcionamento do software desenvolvido, é proteger-nos de regressões. Sempre que produzimos novo código ou novas funcionalidades podemos correr a suíte de testes e termos confiança de que nada do que foi feito anteriormente deixou de funcionar.

Finalmente, ter algum tipo de documentação é essencial. A granularidade da mesma vai depender da complexidade do projeto, mas defendo que deve sempre haver uma plataforma (e.g., Confluence) onde se pode ir deixando notas ou documentando certos aspetos do projeto. Há certos tipos de documentação que julgo só fazer sentido para certos projetos, como, por exemplo, haver design documents sempre que se trabalha numa nova feature (para projetos mais complexos), mas um tipo de documentação que defendo que deve existir sempre é documentação relativa a correr o projeto, aos seus vários processos (e.g., CI, Release, Deploy) e também a coisas que não queremos descobrir como fazer quando elas acontecem como por exemplo restaurar um backup numa base de dados de produção ou reverter um deployment para uma versão anterior.

9# Que iniciativas ou práticas adotadas pela IC consideras que promovem o crescimento e desenvolvimento contínuo das suas equipas de programação?

Um dos principais mecanismos que a empresa utiliza é o ciclo de avaliação bi-anual, que permite um acompanhamento regular do desempenho individual de cada membro da equipa. Esta prática garante que todos tenham a oportunidade de receber feedback construtivo, discutir o seu progresso e definir objetivos de desenvolvimento de forma clara e personalizada.

Outro pilar importante para o desenvolvimento contínuo das equipas é o programa de formação oferecido pela IC. A empresa investe em programas de treino/aprendizagem e formação contínuos, proporcionando aos seus colaboradores acesso a cursos e certificações especializadas o que permite que as equipas estejam atualizadas com as mais variadas tecnologias, melhorando tanto as competências técnicas como a capacidade de aplicar novos conhecimentos em projetos reais.

Por último, a realização de workshops internos também é uma prática fundamental na IC. Estes eventos são organizados de duas em duas semanas para incentivar a partilha de conhecimento entre os trabalhadores da IC. Os workshops proporcionam uma plataforma para discutir novas tecnologias, metodologias e boas práticas, promovendo um ambiente de aprendizagem colaborativo.

10# Que conselhos darias a um developer que deseja evoluir para a função de Lead Developer?

Para evoluir para a função de Lead Developer, é essencial desenvolver uma combinação de competências técnicas e interpessoais. Além de um bom conhecimento técnico, é também importante ter uma visão abrangente dos vários sistemas e ser capaz de tomar decisões estratégicas sobre arquitetura, design e escolhas tecnológicas. Isso inclui uma compreensão sólida de várias linguagens de programação, frameworks e metodologias, assim como a capacidade de aplicar esse conhecimento de forma pragmática.

A liderança e a capacidade de comunicação são igualmente importantes. É preciso saber orientar a equipa, resolver conflitos, manter todos os membros alinhados com os objetivos do projeto e oferecer apoio e feedback construtivo que ajudem a equipa a crescer.

Gerir eficazmente o tempo e as diversas prioridades é outra competência crucial. Com múltiplas responsabilidades, desde code reviews, participação em inúmeras reuniões até à resolução de problemas complexos, é preciso ser capaz de manter o equilíbrio e garantir que a equipa é produtiva e que tem todos os meios à sua disposição para o ser. A empatia e as habilidades interpessoais são fundamentais para se ser capaz de criar um ambiente de trabalho colaborativo e de confiança, o que leva a uma equipa mais coesa e motivada.

Finalmente, é importante investir na aprendizagem contínua, participando em cursos, workshops e eventos. Esta atitude de crescimento constante ajuda a acompanhar as mudanças tecnológicas e a manter as competências e habilidades relevantes.

11# Quais são os recursos ou fontes que utilizas para te manteres atualizado tecnicamente e sobre tecnologia?

Existem três principais fontes/recursos que utilizo para me manter informado:

• Newsletters que recebo por email.
• Youtubers aos quais estou subscrito.
• Subreddits que sigo.

Das newsletters que recebo destaco a do DEV Community (https://dev.to) e a do ByteByteGo (https://bytebytego.com) sendo que a primeira explora os mais variados temas relacionados com tudo o que seja programação e desenvolvimento de software, enquanto que a segunda se foca mais em system design.

Uma das coisas que gosto bastante da newsletter do ByteByteGo é que muitas vezes partilham grandes desafios de engenharia e de como foram resolvidos. Por exemplo, numa das edições mais recentes é apresentado o problema com o qual a Uber se defrontou de gerir petabytes de informação em tempo real e como este foi solucionado.

Relativamente a Youtubers gosto muito do canal CodeOpinion do Derek Comartin e do canal do Milan Jovanovic, que abordam principalmente padrões de desenho e de arquitetura de software empresarial. Apesar da tecnologia principal ser .NET/C# os conselhos deles aplicam-se a qualquer outra. Uma das coisas que mais valorizo neles é que são pessoas pragmáticas que demonstram inúmeras vezes que no que toca a estas coisas não há apenas uma única solução e que recorrentemente põem em causa conselhos dogmáticos muito prevalentes na nossa área que no final de contas às vezes fazem mais mal do que bem.

Num registo assim mais informal, gosto também do canal Fireship que todas as semanas faz um apanhado do que se passa no mundo tecnológico num formato bastante divertido mas na mesma informativo.

Por fim, sigo alguns subreddits no Reddit que me ajudam a manter-me a par daquilo que se passa em certas comunidades. Por exemplo, para ter um apanhado geral do mundo da programação recomendo o r/programming e o r/webdev, e depois baseado nos interesses de cada um recomendo subreddits mais específicos como por exemplo r/reactjs e r/typescript respetivamente para pessoas que usem React.js e TypeScript.

A grande vantagem destas comunidades é que muitas contam com um grande número de participantes (à data de escrita o r/reactjs tem 427 mil utilizadores) e é fácil de partilhar problemas e pedir ajuda. Prefiro pedir ajuda nestas comunidades que se dedicam a uma determinada tecnologia/assunto do que por exemplo recorrer ao Stack Overflow, que é infame por ter um conjunto avultado de regras e de moderação que muitas vezes tornam difícil de publicar as nossas questões.