Afinal, o que os programadores fazem? Como vivem? Como evoluem?

Talvez este seja um post um pouco diferente dos demais. Quis trazer aqui a minha opinião sobre o dia a dia de um programador. Também conhecidos como developers (ou resumidamente ou carinhosamente “Devs”).

Acredito que possa auxiliar as pessoas que necessitam saber mais sobre o dia a dia da carreira de um programador na prática ou que simplesmente tenha essa curiosidade. Pode ajudar, por exemplo, uma pessoa que deseja entrar ou migrar para a área de desenvolvimento de software ou ainda ampliar um pouco a visão de um profissional menos experiente ou que esteja apenas interessado em saber um pouco mais do assunto, seja ele um programador ou de áreas relacionadas.

Mas, afinal o que um programador faz no seu dia a dia de trabalho ? (considerando a data que escrevo :D)

Sintetizei uma lista de tópicos focando em funções que considero mais comuns e primordiais, sem mencionar tecnologias ou métodos específicos.

A intenção deste post, não é a de estabelecer pré-requisitos, longe disso… nem de afirmar que a pessoa interessada na área de desenvolvimento precisa saber de tudo isso para conseguir atuar na área. A ideia não é desmotivar ninguém, pelo contrário, o objetivo é trazer um olhar do que já pude observar até o momento, após passar por situações variadas e desafiadoras e tentar repassar um pouco do que pude aprender com elas. Os conhecimentos e experiências são construídos com o tempo e aos poucos. Isso também vale para o entendimento sobre certos papeis e funções da área.

(Depois de ler, manda esse post para aquela pessoa que diz que você só fica na Internet/Facebook o dia inteiro ou que fica pedindo para você consertar tudo) 😀

Codificar (ou “programar” de fato)

Embora a codificação (ou programação) em si talvez seja a função mais óbvia de todas desta lista, achei pertinente enfatizar mais sobre a função, para as pessoas interessadas em saber um pouco mais. Afinal tem muita gente nova chegando agora nesse novo universo e quanto mais claro forem essas funções, melhor.

A codificação em si, trata-se da transformar as necessidades e requisitos de um software em funcionalidades no software a ser desenvolvido, de forma a traduzir os processos descritos pelas pessoas em funções do programa. Também é muito comum as pessoas mencionarem “programar” como “escrever códigos” ou simplesmente “codar“.

Nem sempre o que será desenvolvido são novas funcionalidades no software, muitas vezes serão tarefas de análise e correção de bugs ou ainda tarefas de manutenção e sustentação do software.

A quem esteja se perguntando sobre a escrita de códigos, para conseguir codificar, um programador precisa combinar conhecimentos como:

• Saber uma ou mais linguagens de programação;
• Entender ou ter uma boa noção de lógica de programação e algoritmos (ainda que em nível mais básico);
• Conhecer pelo menos um pouco sobre uma stack tecnológica (aqui normalmente depende do tipo de atuação do dev, por exemplo se é mais voltado a backend, frontend ou ambos);
• Ter capacidade de imaginação, abstração e resolução de problemas relacionados

Normalmente, conforme a exigência do cargo ou do desafio, também costumam ser exigido um pouco mais do profissional, que muitas vezes precisa ter conhecimentos específicos e/ou mais aprofundados sobre um determinado assunto ou tecnologia. E claro, isso também só pode ser desenvolvido e aprimorado com mais tempo, mais estudos e mais experiências.

Analisar necessidades e requisitos de software

Além de programar de fato, o desenvolvedor também precisa saber analisar as necessidades dos usuários do sistema ou relatadas pelos demais colaboradores do time e dos clientes. Normalmente existe algum tipo de organização e padronização básica para se levantar e registrar as necessidades e requisitos das funcionalidades desejadas. Por exemplo: Ao usar métodos ágeis, as próprias cerimônias do time auxiliam a cumprir essa função, com a ajuda de todos os envolvidos, porém, isso não diminui a importância da capacidade de análise que o profissional precisa ter para progredir no processo de desenvolvimento.

Além da identificação e definição de requisitos e aspectos do que será desenvolvido, em alguns casos o desenvolvedor também precisará que realizar atividades relacionadas a arquitetura de software ou de soluções, tais como mapear pontos de risco, criar provas de conceitos (PoCs), desenhar visões e modelagens para apresentar ao time e clientes. Embora tais atividades normalmente estejam mais relacionadas ao papel de um arquiteto de software ou analista de sistemas, em determinados contextos pode ser bastante comum e até necessário que o desenvolvedor execute essas funções.

Para reflexão adicional nesse assunto… Mencionei no tópico anterior que é necessário fazer a tradução dos processos para funcionalidades. Imagine que entender claramente o que uma pessoa necessita já pode ser bastante desafiador e complicado, agora imagine ter que entender vários processos de usuário ou da empresa? O desafio aumenta, não é? …mas calma que nem sempre é difícil, existem diferentes cenários, e depende da maturidade profissional e experiência dos envolvidos (clientes, projetos, time, empresa, etc.).

Apesar de haver certas dificuldades, também aprendemos muito a lidar com tais situações e até gostar dos desafios. 😉

Codificar testes

Embora muitas vezes também exista um papel específico para escrever e executar certos testes, normalmente conhecidos com o “Analista de Testes” ou “QA (Quality Assurance)”.

É muito comum e até recomendado que um programador escreva testes de código, para melhorar e garantir a qualidade das funções que foram desenvolvidas. Normalmente os desenvolvedores estão mais focados em escrever códigos para testes de unidade (unit tests) ou testes de integração (integration tests), enquanto que um QA, por exemplo, escreve e configura testes de interface, testes de aceitação, testes de regressão, etc. mas claro, não existe uma regra geral. Tudo varia conforme a necessidade e contexto em que o profissional está inserido.

Analisar e revisar código de outras pessoas (code review)

Outra atividade muito comum no dia a dia do programador é a revisão de código de outros programadores ou a realização de algum tipo de análise antes da funcionalidade desenvolvida avançar para testes e outras etapas posteriores. Tem sido cada vez mais comum e recomendado para equipes a prática do code review, não com a intenção de desconfiar da capacidade da outra pessoa, mas sim no sentido de olhar o mesmo código com “outros olhos”, sob outra perspectiva e com isso também ajudar a manter as boas práticas do time.

Em alguns lugares algumas pessoas ainda não aplicam essa prática ou podem demonstrar alguma resistência, por motivos como: falta de prioridade, processo indefinido, não reconhecer a importância do code review, questões relacionadas ao ego do programador ou simplesmente por timidez ou medo de alguma repreensão de outras partes. Nesse sentido, para resolver ou amenizar a situação, é sempre muito importante a conscientização e o espírito colaborativo de todos os envolvidos, visando melhorar a cultura, a confiança e a comunicação do time, de forma a direcionar o foco para a solução e a maturidade do time ao invés de analisar ou culpar pessoas.

Certamente, quanto mais maduro for um time, menos problemas como esse haverá.

Fazer Pair Programming

Pair programming ou programação em par, nada mais é do que a prática de desenvolver alguma feature ou implementar alguma correção junto com outra pessoa. Isso tem se tornado uma prática cada vez mais comum em várias equipes e empresas. E realmente pode trazer diversos benefícios para os projetos, principalmente quando as pessoas estão de fato engajadas e focadas na solução.

Dentre os principais benefícios, podemos citar questões como, troca de conhecimento, aprendizado mútuo, revisão de código em tempo real, auxílio na manutenção de boas práticas e processos de equipe, aumento significativo do foco, se considerarmos que uma pessoa pode ajudar a outra se manter mais concentrada e menos dispersa com questões individuais.

Configurar sistemas e ambientes de desenvolvimento

Embora o nível de configuração e conhecimento relacionado seja relativo de empresa para empresa ou de projeto para projeto, sempre haverão configurações que o programador precisará compreender, principalmente as que estão mais ligadas ao desenvolvimento de software.

Também pode parecer óbvio para quem já tem uma certa experiência, mas para os novatos na área é importante ressaltar este ponto, pois no dia a dia de uma empresa, nem sempre é claro a definição de quais configurações são responsabilidades de um programador ou de outro profissional ou área.

Exemplo: Configurações de preparação e entrega de software. Há casos em que o próprio programador precisa saber e prover o ambiente e as configurações necessárias e há outros casos em que isso é feito por outros profissionais ligados a infraestrutura ou DevOps.

Participar de reuniões com outras pessoas e grupos

Reuniões, fóruns, discussões, debates técnicos são coisas bastante corriqueiras no dia a dia de um desenvolvedor de software ou de áreas relacionadas. Afinal quase ninguém mais trabalha isolado como nos primórdios da computação. Embora isso ainda possa ocorrer, tem sido cada vez mais comum as pessoas trabalharem em times, ainda que pequenos ou com apenas 2 pessoas por exemplo.

Normalmente os times (ou squads) são multidisciplinares e são formados por profissionais como desenvolvedores, QAs, líderes de time ou de projeto, gerentes, Product Owner (POs), designers, arquitetos de software ou de soluções, etc.

Além das reuniões e ritos do próprio time em que está inserido, também é bastante comum ter reuniões de planejamento e alinhamento com clientes ou parceiros.

Estudar novas tecnologias e métodos

Deve ser praticamente unânime a constatação de que os profissionais ligados a tecnologia da informação nunca podem parar de estudar ou que estão sempre aprendendo alguma coisa, afinal as tecnologias ou metodologias não para de surgir ou evoluir. Sendo assim, é natural que os programadores precisem se manter atualizados, ainda que razoavelmente, através de estudos, cursos, participação em eventos, fazendo experimentos, etc.

Vale reforçar que o ato de estudar NÃO está diretamente ligada a escolas ou universidades, principalmente hoje em dia, em que podemos aprender de múltiplas fontes. O ponto aqui é o profissional se tornar um autodidata ou que ao menos desenvolva sua capacidade de autogestão e autoplanejamento

Ressalto que a importância de que se manter atualizado não é só uma questão de saber e conseguir contribuir com a equipe, mas também uma questão de evolução de carreira e manutenção de sua empregabilidade no futuro.

Ajudar na entrega e manutenção do software

Conforme mencionado em um dos tópicos anteriores, nem sempre haverá alguém ou uma equipe a disposição para resolver configurações e problemas de entrega e liberação do software. Muitas vezes é o próprio programador que precisa exercer tais funções, ainda que em um grau mais iniciante ou intermediário, principalmente se estiver um pouco mais envolvido com atuação de backend. Algumas funções comuns aqui são:

• Configurar e manter repositórios de código fonte
• Configurar ambientes de desenvolvimento (IDEs, servidores, contêineres de aplicações, redes, bancos de dados, serviços e APIs externos, etc.)
• Configurar arquivos e esteiras de Continuous Integration e Continuous Delivery (CI/CD) para as aplicações
• Contribuir em processos, cultura e com ferramentas de DevOps
• Configurar ambientes de Cloud Computing
• Analisar e configurar ferramentas e acompanhar informações relacionadas a Observabilidade (logs, métricas, tracing, monitoramento)

Contribuir para melhorias de processos de desenvolvimento

Além das atividades já citadas, algo que pude perceber e exercer com o tempo é que, na medida que vamos ganhando mais entrosamento e experiência em um time ou projeto, conseguimos sugerir e propor mais coisas visando o benefício dos processos de desenvolvimento. Desde a forma de escrever histórias de usuários e requisitos de software até as melhores formas de resolver dívidas técnicas e configurações.

Sugerir melhorias pode ir muito além do código! Sem um processo bem definido no seu time e no seu ambiente fica muito mais difícil do produto evoluir e também de você, como profissional, evoluir junto.

Contribuir para melhorias nos produtos e projetos

Como mencionado no tópico anterior, além dos processos de desenvolvimento em si, com o tempo também conseguimos propor melhorias específicas para os produtos digitais que estamos envolvidos, sejam a nível de aplicações ou em colaboração com profissionais ligados ao negócio.

Certamente que, contribuindo para o processo de desenvolvimento, você também contribui para o produto, mas eu quis destacar aqui sobre esse outro olhar que os desenvolvedores também podem desenvolver. Afinal, questões de negócios são essenciais para as definições e para o sucesso do produto ou projeto.

Não adianta ter um processo excelente se o produto não atende a demanda dos usuários e clientes. (Normalmente é o que paga a conta! :D)

Auxiliar a tomada de decisão de negócios

Sendo capaz de contribuir com melhorias para os processos, projetos e produtos, naturalmente também será capaz de auxiliar o time, o parceiro ou cliente em decisões mais estratégicas dos negócios.

Ainda que nem sempre seja possível ter esse nível de contato ou de influências, acredito que seja importante ter essa consciência. Muitas vezes precisamos ou podemos ajudar em pontos fora da codificação de fato… Trazer luz em algumas discussões, conversar sobre ideias e viabilidades. Quase toda experiência direcionada importa.

Sempre bom lembrar que o valor que você agrega pode e deve ir muito além do código que você produz

Achei que iria só programar, e agora?

Esta pode ser uma percepção muito comum, principalmente para quem está iniciando na carreira de desenvolvimento de software, pois muitas vezes não conhecemos certos detalhes e nuances de uma carreira ou dos projetos em que iremos atuar. Embora isso possa trazer ansiedade e preocupações adicionais ao profissional, o importante é não se desesperar e dar tempo ao tempo. Tudo é aprendizado e tudo é construção.

Algumas coisas acontecem mais rápido que outras. Afinal, ainda que nem sempre seja perceptível, tudo está em constante mudança e o mercado é dinâmico. Boas empresas e bons profissionais sabem disso e também existe muito esforço da parte deles em contribuir com as pessoas.

Nesse ponto, uma reflexão adicional é que em diversas ocasiões pode ocorrer de alguns desenvolvedores não gostarem e até mesmo evitarem algumas dessas funções descritas. Motivos comuns pra isso são questões como, se sentirem sobrecarregados com funções “extra codificação”, não estarem habituados a atividades que exigem mais comunicação (reuniões, interações…), não gostarem de atividades de análises/levantamentos específicos, ou simplesmente pelo fato ter uma preferência mais direcionada e exclusiva a atividades de codificação em si.

Para lidar com essas questões, um pensamento que sempre me ajudou e talvez também possa te ajudar é olhar para atividades diferentes sob outras perspectivas, inclusive as “não técnicas” …e também considerando seu desenvolvimento como pessoa, evoluindo suas “people skills” e “analytical skills“.

Pense que, ao longo do tempo, se for capaz de resolver desafios diferentes, certamente também terá desenvolvido competências diferentes, se tornando um profissional mais preparado para desafios e adversidades.

Algo mais? 😀

Bom, estas foram algumas funções que consegui recuperar no momento para trazer neste post. (Até que lembrei e relacionei bastante coisa, não é!? :D)

Reforço que nem sempre você vai precisar exercer todas essas funções, mas pode ser importante ter essa consciência e claro, ir conhecendo e respeitando todos os papeis e pessoas envolvidas.

Como mencionei antes, a clareza sobre essas funções e papeis vai ficar melhor com o tempo. Certamente algumas dessas práticas podem mudar ou evoluir no futuro, afinal as mudanças não param… Só nos resta ir aprendendo com as experiências e nos adaptando como pessoas e profissionais.

Agora me diz aí, foi possível ampliar sua visão sobre o papel do desenvolvedor de software nessa época em que escrevo?

Ficou com alguma dúvida? Ou faltou algum tópico? Comenta aí!

Thanks for reading! 😉