A maioria dos portfólios de developers que encontro tem o mesmo problema. Mostram que a pessoa consegue construir coisas, mas não dizem muito sobre como pensa, como toma decisões ou o que torna o seu trabalho diferente. São basicamente listas de tecnologias e projetos sem muito contexto.
Quando comecei a pensar nesta versão, quis fazer algo diferente. Não necessariamente mais impressionante visualmente, mas mais honesto sobre o que o trabalho realmente é e como eu o abordo.
O problema com portfólios estéticos
Há um padrão comum em que os developers gastam muito tempo a tornar o seu portfólio visualmente distinto e pouco tempo a pensar no que ele realmente comunica. Resulta em algo que parece bom numa captura de ecrã mas que não responde às perguntas reais que um recrutador ou outro developer tem ao visitá-lo.
Perguntas como: o que é que esta pessoa constrói? Como pensa sobre os problemas? Pode trabalhar em sistemas reais, não apenas em projetos paralelos isolados? Um portfólio centrado na estética raramente responde bem a estas perguntas.
O que tentei focar em vez disso
Em vez de começar com o design, comecei com o que queria que as pessoas entendessem depois de visitarem o site. Quis que ficasse claro que trabalho em sistemas completos, não apenas em interfaces. Que escrevo sobre o que aprendo, não apenas listo o que sei. Que penso sobre manutenção e escalabilidade, não apenas em fazer as coisas funcionar.
Isso moldou o que entrou no portfólio e o que ficou de fora. As secções não são apenas convenções. Cada uma existe porque responde a algo específico sobre como trabalho.
Conteúdo como sistema, não páginas estáticas
Uma das decisões mais deliberadas foi construir o portfólio como um sistema de conteúdo real em vez de páginas codificadas. Projetos e artigos vivem numa base de dados. Adicionar novo trabalho não requer um redeploy. Isso pode parecer excessivo para um portfólio, mas reflete como penso sobre a construção de coisas que precisam de crescer sem se tornarem difíceis de manter.
Também tornava a demonstração de skills mais direta. Se estou a afirmar que sei construir sistemas com backends próprios e camadas de dados, o próprio portfólio deve refletir isso, não apenas afirmá-lo.
Design que fica fora do caminho
A escolha de design foi deliberadamente mais contida do que versões anteriores. Menos personalidade visual, mais facilidade de leitura. O objetivo era que qualquer pessoa que chegasse ao site, seja um recrutador, outro developer ou alguém que simplesmente navega, conseguisse perceber rapidamente o que eu faço e o que tenho feito.
Isso não significa sem opinião. Significa que as escolhas de design servem a legibilidade primeiro e a expressão pessoal em segundo. Em versões anteriores era o contrário, e raramente resultava bem na prática.
Escrever como parte do portfólio
Adicionar uma secção de jornal não foi uma reflexão posterior. Escrever sobre o que estou a construir e a aprender é parte de como processo o trabalho. Torna o pensamento visível de uma forma que listas de tecnologias não conseguem.
Também é mais útil para as pessoas que visitam o site. Ler como alguém pensa sobre um problema é muito mais informativo do que ver que conhece as ferramentas certas. A maioria das pessoas com alguns anos de experiência conhece as ferramentas. O que é mais difícil de transmitir é como usam essas ferramentas para resolver problemas reais.
O que realmente ficou bem
A coisa mais satisfatória na construção disto foi a separação entre conteúdo e código. Adicionar um novo projeto ou publicar um artigo é agora apenas atualizar dados, não redeployar nada. Essa separação foi uma das melhores decisões de arquitetura que tomei, e é algo que agora aplico em outros projetos também.
O outro aspeto que ficou bem foi a intencionalidade. Cada parte do portfólio existe por uma razão. Não há secções que estejam lá porque todos os portfólios as têm. Isso torna o site mais fácil de atualizar e mais fácil de defender quando alguém pergunta porque está estruturado daquela forma.
