Os 3 erros mais comuns de Cientistas de Dados — E que não tem a ver com dados

As dicas mais essenciais para ser efetivo no seu trabalho

Eu costumo ajudar muito a comunidade de DS do Data Hackers com vários tópicos, vamos dizer… ‘não matemáticos’, em muito porque minha formação é de administração. E nesse período eu notei alguns padrões.

Um deles é que é muito comum entre profissionais de dados focarem muito do lado dos dados, da estatística e do ML, e acabem negligenciando uma porção de recursos ou melhorias fáceis.

E eu queria fazer esse post para levar estes pontos porque eles são muito fáceis de serem ignorados. (e também para eu poder apontar pra ele e não ter que repetir o mesmo conselho pela quinqualhesíma vez XD)

1) Não explorar as IDEs e extensões disponíveis

Quando eu comecei na programação na POLI, eu codava no ambiente embutido chamado IDLE… que não era muito mais do que simplesmente um bloco de notas e um terminal, o que fazia sentido pra matéria, porque eu tinha que reproduzir exatamente o meu código a lápis depois na prova… (Barf). Eu cheguei a tentar a montar um RPG de terminal nisso, com batalha e tudo mais… e pra resumir… DEU MUITO ERRADO.

Vou ser direto: Quantas vezes você estava no notebook e o código não compilou por causa de um typo? Ou o seu código agiu errado por causa de má configuração da variável? E quanto tempo você gastou tentando debugar esses probleminhas?

Não seria legal ter uma interface que te ajudasse a evitar esses problemas bobos, ou mesmo acelerar o ritmo em que você programa?

Apesar de tomarem o papel de contrarregra. IDEs são um dos aspectos mais fundamentais do trabalho de um programador, sempre te dando apoio atrás com correções de indentação, auto completamentos*, sugestões de refatoramento e muito mais.

Elas fundamentalmente não te ‘habilitam’ em resolver problemas novos, coisa que os cursos e mercado tanto focam, mas te liberam de microproblemas que queimam seu tempo, permitindo ser eficiente nos estudos.

Eu particularmente recomendo começar a pesquisar IDEs tão quanto você aprender o básico da linguagem de sua escolha. Sim, é tão essencial assim, porque é o que impede de seu trabalho ser enfadonho.

Como exercício e checklist, verifique que você sabe e tem ao seu alcançe:

• Linter pra não ter que ficar corrigindo erros de indentação e compilação.
• Autocomplete pra não ter que ficar decorando tanto a grafia das funções, como também pra trazer a documentação enquanto escreve
• Esquema de cores pra não cansar os olhos (tem um porque de temas escuros serem populares…) e fácil de identificar entre as cores
• Uma fonte fácil de ler, em especial mono espaçada e que não confunda O, 0, I, l e 1. Algumas como a FiraCode tem elementos adicionais para programadores
• Régua/contador de linhas: Pra achar mais rápido a linha que deu bug
• Explorador de variáveis: Pra saber o estado do sistema quando bugar e também poupar printar as variáveis pra ver se funcionou
• Debugger ou execução com paradas: Para ver como o seu programa está se comportando sem ter que desmontá-lo com comentários
• HOTKEYS! Como você pode ser o profissional mais sexy do sexy do séc. XXI se você não é hot? Ok, Piadas a parte, os atalhos de teclado mais comuns vão te salvar um 1 segundo mais de 500 vezes por dia. É trabalhosos decorá-las, mas acredite, o benefício acumula muito rápido.
• Terminal embutido: para testar comandos sem ter que rodar o script inteiro, muito útil enquanto explora bibliotecas novas
• Templates: Apesar de você poder montar o seu próprio e ficar copiando ele pra início de cada projeto, ter uma biblioteca que já te comece com uma te poupa dores.
• E outros recursos e bibliotecas: como um editor para wrangling e um visualizador das transformações

Eu sei, a lista é grande e assustadora, mas relaxe, as boas IDEs já vem com a enorme maioria já pré-configurada, você só precisa confirmar que elas estão ativas.

Uma vez eu comecei a estudar Unity e demorei umas semanas adivinhando comandos do framework dela até notar que o Intelisense do Visual Studio podiam se integrar com ela… não façam o mesmo… não deixem o stress operacional entrar na frente de soluções definitivas…

Existem dois tipos de DSs no mundo. As pessoas que exploraram o ferramental disponível e as que gostam do Jupyter Notebook vanilla. Espero depois disso te ver no primeiro grupo.

*Isso não é muito evidente no python, mas em linguagens mais ‘burocráticas’, como C#, é a única coisa protegendo sua sanidade.

2) Mentalidade Micrista — Ou doença de Kaggle

Se a vida te dá abacates, faça um modelo de ML pra venda vitamina… espera… porque eu estou pegando abacates?

Chegue num DS e pergunte como ele pode melhorar um modelo. A maioria vai te responder*:

• Use mais colunas de dados (vulgo mais recursos disponíveis)
• Crie mais variáveis (mais minúcia)
• Troque o modelo (refatoração)

O que todas essas respostas tem em comum? Elas trabalham num escopo limitado (a idéia de que é um modelo para um problema declarado)e tentam otimizar dentro dele.

Na ciência da Administração a gente tem um tipo de gerente chamado micro-gestor, você já deve ter ouvido falar desse termo pejorativamente, e sim, o estereótipo está certo: É uma pessoa que acompanha processos de perto e realiza otimizações caso-a-caso, mas não tenta mudar a situação dela em si pra não passar mais perrengues.

ML tem essa mentalidade em si: Na maioria dos casos é o ato de criar uma máquina que seja capaz de gerenciar atributos de cada item para otimizar uma métrica.

Você deve estar se perguntando qual é o problema então… e é simples: A máquina é o micreiro, não você! Você tem que pensar fora do escopo por ela! A ser que esteja numa equipe muito grande, você deveria focar em questões mais empreendedoras como:

• Garantir que o problema de negócio sendo resolvido é valoroso pro nível de esforço do DS e da máquina, e caso não, explorar outros fronts de aplicação
• Explicar/vender a sua solução para os outros e ver se ela faz sentido no contexto de decisão - Uma clássica é saber se precisa de mais velocidade ou mais performace preditiva
• Angariar recursos pro seu modelo na forma de coleta de dados, verba pra nuvem, ou até mesmo pra recrutar um subordinado pra otimizar e corrigir o modelo
• Saber MVPar e coletar feedback sobre as decisões de negócio e o nível de drift - Não ‘segure’ o modelo por tempo demais, não tem aperfeiçoar os detalhes quando outros grandes problemas estão passando em branco
• Controlar sinergias e o encaixe de tempo das coisas - Como “isso tem que estar pronto para o Natal” e “Podemos usar nosso minerador NLP nesse caso também”

Esses tipos de ação obrigatoriamente requerem soft-skills e experiência de front, mas são exatamente elas que impedem que seu trabalho seja engavetado e esquecido no final. Por isso que DS com conhecimento de negócio é tão valorizado.

Infelizmente isso é uma coisa que você não vai pegar fazendo competições de ML**, cursos e projetos individuais***. Estes eventos possuem escopos estritamente fechados e não possuem meios pra alterá-los, induzindo você ao micro.

Nesse caso, eu acho que a melhor forma é trabalhar em grupo mesmo (não tenha medo do cliente!), e manter uma cabeça aberta sobre os próprios objetivos.

* Esse problema é tão pandêmico que já desenvolvemos estruturas organizacionais pra resolver ele em outras áreas: Olá, Product Owners e equipes de produto pelo mundo! Apesar de funcionarem bem em nível de equipe, infelizmente há o colateral de distanciamento e super especialização no nível individual.

** As competições de negócios são viáveis, mas elas funcionam de outra forma das de ML… pra você ter uma ideia, você vai ter que escolher suas próprias fontes de dados

*** Esse último até tem potencial, mas você já tem que ter noção de negócios pra começar a ir nessa direção… mas é uma bela maneira de começar acidentalmente uma startup ou uma biblioteca para os outros programadores.

3) Não pensar na estratégia de storytelling

Quando eu recebo um projeto com storytelling, eu sei que vem uma de duas: Ou vai ser muito bom, ou vai ser miserável. Nunca encontrei um mais moderado.

O motivo pra isso é que storytelling é uma habilidade fácil de executar, mas difícil de integrar*. Ela envolve mais percepção do que conhecimento e habilidade; e por causa disso é fácil errar, não notar, e insistir no erro.

É como se fosse um revolver, você pode atirar com ele facilmente, e com a mesma facilidade você pode se atirar no pé.

Ainda me lembro do triste caso em que alguém apresentou um relatório de umas 20+ páginas pra um teste prático*, a ideia era apresentar uma análise de mortalidade como se fossemos uma seguradora…

Primeiras páginas e ele estava relatando a história de X que entrou no portão Y… saltei pro meio do report… e ele ainda estava dramatizando enquanto fazia um wordcloud dos nomes dos passageiros e tinha um desenho dramático do navio afundando… perdi a paciência.

Também convenhamos… todo mundo pula as partes chatas pra salvar tempo. Se não, olhe nos fundos dos olhos do meu avatar (ali em cima) e diga que você não pulou a seção de introdução desse próprio artigo e que não vai pular a conclusão. Vídeo: https://www.youtube.com/watch?v=GZPRrYLGrhI e extensão pra pintar os segmentos inúteis é o sponsor block

Eu sei que pareço injusto aqui, mas tem três motivos para não:

1. Ele descumpriu o objetivo, o pov era explícito de uma seguradora, e não um documentário — Claramente a abordagem não era pra ser emocional
2. A abordagem dele iria ser menospresada no ambiente de trabalho. Não era esse estilo que convenceria as pessoas do lugar, não havia fit.
3. Eu e ele temos tempo limitado, e ele não valorizou o dele nem o meu.

Não tinha muito argumento pra manter ele no processo, independente do esforço.

Existem diferentes maneiras de apresentar seu trabalho dependendo do conhecimento, disposição e objetivo do público, e esses estilos são antagônicos, em especial em questões de tempo. TEDs são diferentes de aulas técnicas de pergunta aberta, que são diferentes de resumos de artigos científicos, que são diferentes de livros, que são diferentes de fichas técnicas… que é diferente… disso aqui.

Storytelling é que nem escolha de modelo, existem mais de uma estratégia possível, e pelos exemplos de documentário e posts de redes sociais, somos enviesados aos mais narrativos. Mas ser curto e grosso tem suas vantagens, e ter o tato nisso é o segredo. Na dúvida, não adicione mais material.

Storytelling de dados é mais sobre como passar a progressão dos achados nos dados, e não necessariamente contar histórias; não fissure em narrativas.

* Um óbvio overwork; e que fique de dica para todos: Um trabalho grande demais na realidade está sendo ariscado de não ser lido, da mesma forma que as pessoas tem receio de começar vídeos longos, você está dando bandeira de que não é sucinto.

Bem, era isso que eu queria contar. Nenhum algoritmo maneiraço, mas ainda assim importante pra adicionar ao profissional de dados efetivo.

Se alguém quiser mais conversar sobre, pode me mandar uma mensagem pelo Meium ou Linkedin, mas é mais fácil pelo Data Hackers em si… por sinal, você já entrou na maior comunidade de Data Science do Brasil?