A ideia por trás do worklog é anotar seu impacto direto e indireto num documento para acompanhar suas entregas ao longo do tempo. Esse é um hábito simples que permite registrar diriamente o que você faz no trabalho.
Uma vez estabelecido, esse hábito será de grande ajuda na redação de suas autoavaliações e até mesmo nas revisões de meio ano e anuais.
Recomendo ferramentas como o Google Documents ou páginas do Notion. Use algo muito fácil e rápido de carregar. Não faça use algo complexo. Mantenha-o bem simples. Algumas pessoas usam até mesmo um caderno físico.
Se estiver começando, estabeleça um evento recorrente em sua rotina, seja diário ou semanal, geralmente nas tardes de sexta-feira. Se você tiver dificuldades com esse tipo de hábito, sugiro o livro Hábitos atômicos do James Clear.
É novo em sua empresa? Ótimo, comece a partir do dia 1. No início, você provavelmente anotará muitos itens ou até mesmo itens irrelevantes, e tudo bem. Com o tempo, você entenderá o que é importante para você. É melhor ter muitas anotações do que poucas.
Pode ser uma simples correção de bug, uma atualização de dependência, uma feature, uma correção de vulnerabilidade, um novo serviço, uma melhoria de performance, seja em um serviço de back-end ou uma animação CSS, uma redução de custos, uma entrega de projeto etc.
Obviamente, a entrega de um projeto é o seu objetivo. Mas não subestime as pequenas coisas. Quando se trata de um determinado nível de entrega, tente aplicar métricas, pois isso terá um impacto maior em suas autoavaliações.
Lembre-se que pode colocar projetos onde você trabalhou com outras pessoas, sem problema.
O impacto de um engenheiro de software não está 100% vinculado às suas entregas em produção. Ele também pode ser composto por impactos indiretos, como orientar desenvolvedores mais jovens, fazer uma apresentação sobre um tópico de tecnologia para sua equipe ou organização, ensinar algo em diferentes níveis, ajudar os membros da equipe de alguma forma, escrever documentação, fazer um curso, dar feedback, atualizar rituais da equipe etc.
Isso pode ser muito amplo e também valioso. Converse com seu gerente se tiver vontade de fazer mais em paralelo às suas tarefas diárias. Quanto mais você crescer em sua organização, mais isso será importante. Engenheiros de alto nível escrevem muito menos linhas de código do que os seniors ou plenos, por exemplo.
O modelo a seguir usa um formato por semana. Mas fique à vontade para adaptá-lo. Não se esqueça de usar datas claras, pois isso ajuda a reunir semanas e meses para as autoavaliações. Uma frase por item, geralmente começando com um verbo.
Adicione números/métricas, se possível, e vincule documentos relevantes que possam acrescentar detalhes à sua declaração. Pode ser um link do GitHub PR, uma tarefa do Jira, um documento do Google, um gráfico do Datadog, etc. Também anoto os nomes e os cargos dos colegas de trabalho, quando relevante.
Como esse documento não se destina a ser compartilhado, você pode organizá-lo da maneira que quiser.
Importante, eu recomendo ações passadas, coisas que foram feitas, concluídas ou talvez estejam em andamento. Mas não use esse documento para anotar coisas que planeja fazer.