Este artigo apareceu primeiro no meu LinkedIn. Visite o link para acompanhar minhas postagens lá.
Recentemente vi o excelente vídeo a seguir do Fabio Akita para a Alura. O vídeo é sobre boas práticas de programação. Mas pode ser ampliado para boas práticas de uma forma geral, para qualquer carreira. E, no fundo, é um vídeo sobre comunicação, como vou mostrar neste artigo.
Não sabe coisa alguma de programação? Sem problemas, o texto não exige isso, é sobre carreira. Mas, se você for de programação ou tiver interesse na área, ao final digo qual linguagem você deve aprender. Vem comigo, vou começar falando um pouco da minha carreira.
Tópicos
Boas práticas na minha carreira… de químico!
Minha formação é de químico e compreendo bem o que significa boas práticas evoluírem com o tempo, uma das ideias apresentadas no vídeo. O tempo passa e as pessoas começam a perceber, devido a experiências nem sempre agradáveis, que algumas práticas não são as melhores como, por exemplo, fumar nos arredores de laboratórios com vapores de solventes inflamáveis!
E mais que isso. Antigamente, acesso a equipamentos para análises químicas era mais restrito e caro, o analista tinha que pensar bem em quais eram as técnicas minimamente necessárias para caracterizar seu objeto de estudo. Para manter o texto simples de entender para quem não é químico vou poupar os termos técnicos, mas saiba que, por vezes, se escolhia técnicas laboratoriais “manuais” ao invés de equipamentos por uma questão de custo ou acesso. Hoje, boa parte dos laboratórios que precisam têm acesso a equipamentos básicos, liberando tempo dos técnicos e químicos para atividades que geram mais valor, tornando-os mais produtivos.
Não por acaso, parte significativa do tempo de formação de um técnico ou graduado hoje é destinada ao estudo de análises instrumentais. Algumas formas de caracterização feitas em bancada que eram boas práticas nos anos 80 e 90, hoje foram substituídas por outras, feitas por equipamentos.
Boas práticas no mundo digital
OK, mas você leitor talvez não seja químico. E daí? Onde chegaremos nesse texto?
Bom, se as análises são feitas por equipamentos, os resultados são fornecidos como arquivos, certo? Dos mais variados tipos e com os mais variados conteúdos a depender de qual análise está sendo feita. E tais arquivos são compartilhados por toda uma equipe de analistas.
Aqui surge a necessidade de práticas que não faziam sentido no passado. Por exemplo: qual o padrão de nomeação dos arquivos? Cada análise vai ter uma pasta própria? A separação dos arquivos vai ser por data da análise? Os arquivos de dados “crus” ficarão na mesma pasta das análises finais? E essas análises finais, caso passem por revisão, como será o sistema de controle de versionamento? Haverá um Procedimento Operacional Padrão (POP, ou SOP em inglês) para este tipo de análise? Não por acaso, hoje há diversas ISOs e normas que abordam tais pontos que são importantes para a reprodução dos experimentos e auditoria. Boas práticas evoluem com o tempo…
Não acredita na relevância do tema? Veja o resultado de uma simples busca por “procedimento operacional padrão” na Amazon. Uma infinidade de livros sobre o tema, para diversas áreas.
Reconheceu essa necessidade na sua carreira também? Lida com procedimentos recorrentes? Lida com arquivos e mais arquivos o tempo todo? Esses arquivos precisam ser compartilhados com toda uma equipe que precisa compreender o contexto de cada um deles? Concorda comigo que é uma questão de comunicação? Qual é o impacto se não houver uma comunicação efetiva na equipe sobre recursos e dados digitais compartilhados? Veja, mesmo se você não for da área de programação, são questões que decorrem da entrada de tecnologia em sua rotina, que faz surgir a necessidade de formas para lidar com tais questões. E é claro que já existia a demanda por boas práticas e comunicação efetiva antes, apenas houve uma potencialização dessa demanda no atual contexto tecnológico.
Comunicação efetiva
Como um vídeo de boas práticas de programação deu origem a esse texto aqui? Simples, todas as áreas possuem o conceito de “boas práticas”. Pouco importa se você é engenheiro, arquiteto, geógrafo, físico, antropólogo, músico, <insira sua profissão aqui>… Certamente, o termo “boas práticas” paira no ar de todas as profissões. E elas podem mudar à medida que o cenário muda como, no exemplo apresentado, por evoluções tecnológicas.
E, considerando o descrito em parágrafos anteriores, muitas das profissões hoje lidam com (excesso de) informações digitais. Você pode não fazer ideia do que é Git ou “nome de variável“, mas, certamente, já viu algum problema de entendimento na sua equipe devido a uso de versões de arquivos antigas ou por algum arquivo ter um nome que não era informativo. Ou por achar que uma dada instrução em um documento significava A, mas, na verdade, é B. É isso.
Já mostrei anteriormente que diversas áreas possuem POPs. O exemplo que citei acima sobre “nomes de variáveis” é bem específico de programação. Dentro desta área, também há diversas tentativas de se definir boas práticas de escrever código. O livro Código Limpo de Robert C. Martin talvez seja um dos mais conhecidos na área. Nomes de variáveis e funções são apenas uma pequena parte, o livro aborda diversos aspectos para se escrever um código que comunique o que se espera do programa para todos os envolvidos no desenvolvimento.
É sobre isso que boa parte do vídeo fala: comunicação efetiva, boas práticas para fazer com que a equipe entenda o contexto de um problema, boas práticas para uso efetivo de recursos compartilhados, boas práticas de linguagem.
Linguagens de programação e programas
“Linguagem”… Será que tudo apresentado como boa prática realmente é? Existem boas práticas universais ou elas surgem localmente? Ou um pouco dos dois? Boas práticas descritas em normas é o suficiente?
Vendo o vídeo com um olhar mais atento vemos que algumas discussões surgem por pessoas tratarem como dogmas o que, na realidade, são práticas ou ferramentas flexíveis que podem (devem) ser utilizadas se, e somente se, fazem sentido no contexto. Para terminar esse texto, vamos, sim, falar um pouco de programação apenas por ilustrar uma experiência pessoal. Mas o que vou falar é breve e geral o suficiente para que todos possam entender.
Já falei como observei a evolução na área de química, minha formação, no que diz respeito a equipamentos. Mas, claro, tal evolução foi acompanhada do surgimento dos mais diversos softwares para analisar os dados gerados pelos equipamentos. Desde as famigeradas planilhas eletrônicas, passando por programas específicos para tratamento estatístico de dados até o uso de linguagens de programação para dar conta da quantidade absurda de dados gerados e para fazer simulações e previsões. Curti tanto essa evolução, e aprendi tanto, que hoje estou migrando para a área de ciência de dados, mas isso é papo para outro artigo. O ponto é: vi surgir muitos “dogmas” que, na realidade, eram boas práticas momentâneas e circunstanciais e, hoje, substituídas por outras boas práticas a depender do contexto.
Apenas um exemplo para ilustrar. Conversando com um colega acadêmico certa vez, disse estar utilizando Python para um determinado estudo. O colega perguntou “O que é Python?”. E expliquei ser uma linguagem de programação que possui diversos pacotes interessantes para a parte estatística e para a apresentação dos resultados do estudo que estava fazendo. A resposta imediata dele foi “Isto está errado. Para isso serve Fortran, é mais rápido, é o padrão, e tem tudo que precisa. Não entendo essas modinhas de usar linguagens diferentes”. Uau… viu a postura dogmática?
Antes de tudo, tenho um carinho especial por Fortran, foi a primeira linguagem de programação que usei de forma recorrente. Fico muito feliz de ainda ter uma comunidade e de continuar evoluindo. E comecei a usar Python porque… as principais bibliotecas científicas de Python usam Fortran por baixo dos panos! Dê uma olhada no FAQ da página do SciPy, por exemplo. Mas se por baixo dos panos é Fortran, por que não usar Fortran direto? Simples, o problema que queria resolver exigia outras coisas além da incrível capacidade numérica do Fortran. Queria integrar com outras ferramentas e a integração era mais simples com Python. Eu me sentia mais produtivo com Python. O código era mais fácil de entender e manter com Python. O público que teria contato com o resultado era mais familiarizado com Python. Logo, numa análise de todo o ciclo de vida do que estava sendo produzido, a melhor alternativa para aquela situação era… Python.
E o que falei aqui sobre Python vs Fortran pode ser replicado em diversos contextos envolvendo outras linguagens de programação ou softwares. Vejo o pessoal das engenharias com discussões análogas envolvendo Matlab vs Python vs R. O pessoal de visuais em discussões sobre Photoshop vs GIMP, Premiere vs DaVinci Resolve. Por quê? Por que se precisa escolher só uma das opções? Alguma delas é realmente uma bala de prata? A opção em si é mais importante que o problema a ser resolvido?
Qual a melhor linguagem de programação?
Estamos em um momento de abundância digital. Há várias escolhas disponíveis de ferramentas digitais e linguagens de programação. Todas as áreas hoje produzem dados e mais dados que precisam ser analisados para tomada de decisões. O mercado está inundado de buzzwords como inteligência artificial, data science, machine learning, personal branding, marketing digital. Inundado de promessas que ao dominar esses campos seu negócio vai deslanchar ou você vai entrar no mercado facilmente. Inundado de cursos de diversos programas para os mais diversos fins. Inundado de cursos de programação e afins desde Excel VBA, SQL até Javascript, R, Python.
O que aprender? Qual é a boa prática do momento? Qual ferramenta? Qual linguagem aprender? Resposta: português. Ou inglês, ou espanhol. Ou sinal de fumaça, que seja. É essa a boa prática, a ferramenta: sua capacidade de comunicação, a preocupação que outros entendam a sua mensagem, o seu trabalho, e você entenda os dos demais. A linguagem que vai permitir você se comunicar efetivamente com seus colegas de equipe e clientes para entender o problema a ser resolvido. Que vai permitir definir as melhores práticas para os envolvidos no contexto, no tempo em que o problema se apresenta. Que vai permitir definir qual linguagem, agora sim, de programação, ou programa, ou qualquer outra ferramenta é a mais adequada na situação.
Se você guiar sua carreira por ferramentas, a ferramenta será você. Ferramentas e boas práticas mudam. O que não muda é a necessidade de sermos capazes de reconhecer um problema e apresentar soluções com base nos recursos disponíveis. E, nesse processo, comunicação é fundamental.
Concorda? Deixe nos comentários sua opinião.
Até a próxima.
