Quando eu comecei a trabalhar com computação o mercado contratava Digitadores, Programadores e Analistas de Sistemas. Os digitadores só digitavam e os programadores só programavam os sistemas especificados por um “Analista de Sistemas”. Esse era “O Cara”.

Como vocês podem ver a divisão do trabalho e responsabilidades era bem diferente do que temos hoje. Hoje temos umas divisões meio esquisitas tipo “backend” e “frontend” e um eixo, e divisões bem nebulosas como “Júnior”, “Pleno” e “Sênior” em outro eixo. Tem uns caras que correm por fora também: “devops”, “architects”, “leaders”, …

Na mesma época em que comecei a trabalhar também já estava rolando um movimento onde contratavam os “Analistas Programadores”. Um cara que sabia fazer a análise de sistemas e a programação. Obviamente, como vivemos em um sistema capitalista, o salário desse profissional nunca era a soma dos salários de um programador e de um analista. Tipo um programador ‘fullstack’ recebendo salário de ‘front’ ou ‘back’. Precarização nunca foi um assunto novo.

Mas essa introdução toda é só pra falar que quando estudei Processamento de Dados (outro termo que foi caindo em desuso junto com CPD) em uma ETEC eu tinha uma matéria chamada “Análise de Sistemas”.

Naquela época eu já trabalhava com programação então eu matava boa parte das aulas para aperfeiçoar minhas técnicas em coisas importantes como jogar Truco. Com certeza valeu a pena.

Mas as aulas de “Análise de Sistemas” do professor Peccini eu fazia questão de assistir. Queria assistir porque logo nas primeiras aulas ele falou coisas bem intrigantes sobre “Sistemas”.

Uma das coisas que ele disse foi que “Sistemas” não tem uma relação direta com computadores. Sistemas sempre existiram e sempre vão existir. Com computadores ou sem eles.

O trabalho de um analista de sistemas, então, com o perdão da redundância, é analisar esses sistemas e, eventualmente, propor mudanças. Que tipo de mudanças? Mudanças que possam tornar os sistemas mais eficientes ou até mesmo extinguir eles completamente. Automatizar certos sistemas com o uso de computadores é apenas um tipo de mudança em um grande universo de possibilidades.

Ele também falava coisas como “Você não transforma um sistema ruim em um sistema bom colocando computadores e automatizações nele”. Ele falava que fazer isso era só “automatizar a burocracia”.

Temos vários exemplos disso em nossa vida. Basta ir em um cartório e ver quantos computadores eles tem lá dentro.

Naquela época a gente era jovem e adorava ficar de frente para o computador “codando” as coisas. Mas as aulas do Prof. Peccini eram na sala de aula normal. E ele dava coisas em papel pra gente estudar.

Modelagem de Dados

Algumas coisas que o Prof. Peccini ensinou pra gente é modelagem e normalização de tabelas.

Em uma das aulas ele pegou um “talão de pedidos” que ele tinha comprado em uma papelaria e levou para a sala de aula. Ele ia destacando as folhas do talão e entregando para cada um dos alunos da turma.

Depois que cada um de nós tinha uma folha dessas ele disse: quero que vocês criem uma ou mais tabelas no dBase III Plus (outro professor já tinha ensinado isso em outra matéria) para guardar informações de pedidos.

Muitos alunos da turma modelavam apenas uma tabela e repetiam os dados comuns em todos os registros. Não julguem! É um curso onde as pessoas estão aprendendo as coisas. Lembrem que o normal é não saber o certo até que se aprenda.

Eu, como já disse, por já estar trabalhando na área, fiz a minha modelagem certinha (pequeno ajuste aqui e ali). Mas confesso que fazia essas coisas por pura intuição.

O professor então revisou os trabalhos com cada aluno e foi dando as orientações necessárias para cada um deles pensar em melhorias. Ele só dava dicas e fazia perguntas para os alunos. Os próprios alunos acabavam chegando à modelagem mais adequada. Depois desse exercício ele corrigiu tudo e deu notas (boas) pra todo mundo.

A partir daí ele deu algumas aulas com exercícios mais convencionais sobre “normalização” de tabelas e usava sempre os erros iniciais dos alunos para ilustrar cada uma das técnicas de normalização.

As aulas eram incríveis. Melhor que as melhores partidas de Truco que disputei na escola.

Dicionário de Dados

Antigamente os analistas de sistemas produziam muitos documentos sobre… sistemas. Um desses artefatos era o Dicionário de Dados.

Um dicionário de dados servia para dar nomes, tipos, descrição e outras informações sobre entidades, relacionamentos, atributos, propriedades e domínio dos negócios.

Era um troço chato pra cacete de produzir. Mas era um ótimo exercício para “dar nome aos bois”. Servia para desambiguar nomenclaturas e chamar as coisas certas pelos nomes certos.

Ele dizia que se tá difícil achar bons nomes para algo ou se tinha duas coisas diferentes com o mesmo nome isso era um sintoma de problema no sistema.

Ele também falava que dar o mesmo nome para coisas diferentes em contextos ou com perspectivas diferentes era “ok”, mas o dicionário de dados devia deixar explícito esses contextos e perspectivas.

Exemplo disso? A palavra de “Produto” tem significados diferentes para o estoquista, pro operário da linha de montagem, pro profissional do marketing, etc. Em um sistema que envolva todos esses atores é importante mapear todos esses usos e significados.

Recentemente, no trabalho, um amigo citou um outro professor (Prof. Imre Simon da USP). Segundo esse amigo o Prof. Imre havia dito algo como “Um dos grandes problemas da computação é dar nomes diferentes para a mesma coisa e dar o mesmo nome para coisas diferentes” (não encontrei a citação original, então, me perdoem por eventuais equívocos).

Na primeira edição do livro eXtreme Programming do Kent Beck e no livro Domain-Driven Design do Eric Evans também se fala um pouco sobre esse nivelamento de termos usando o conceito de metáforas de sistema (System Metaphor). Isso mostra que comunicar um sistema é um problema bastante antigo mas ainda presente e importante para o nosso trabalho.

Modelagem de Sistemas em Software

Se tem uma coisa que faço bem é modelar sistemas em software. Não consigo explicar porquê e nem tenho plena consciência do que eu faço para executar essa tarefa tão bem. A coisa simplesmente acontece. Acho que é o que chamam de “intuição”.

Não sou infalível e já cometi muitos erros nessa tarefa. Mas na mediana eu tenho um saldo positivo.

Sonho em, algum dia, ter uma consciência maior sobre o processo que acontece no meu cérebro quando estou modelando um software. Gostaria muito de escrever e ensinar isso para outras pessoas igual o Prof. Peccini fazia.

Mas enquanto isso não acontece eu vou falar uma coisa ou duas aqui que eu acho que fazem parte desse conhecimento.

Quando o professor falou que sistemas existem independentemente de computadores ele destravou algum circuito no meu cérebro que me permite observar um sistema funcionando e então partir desse sistema para guiar a minha modelagem. Independentemente de falhas e ineficiências ele é um sistema que já está sendo usado.

Então eu sempre começo a modelar um sistema de software partindo do sistema real. Esse processo inclui a modelagem de dados, processos e o dicionário de dados.

Aí eu lembro que o professor falou que colocar um software que reproduz problemas e ineficiências de um sistema é meramente “automatizar a burocracia”. A imagem de um cartório invade minha mente e eu inicio a busca por problemas, ineficiências e o que eu chamo de “armadilhas de modelagem”.

Quando estamos modelando um sistema de software é bastante comum olhar para outros sistemas similares como referência (benchmark) e é bem comum a gente cair em armadilhas nessa brincadeira. Vou dar um exemplo.

Uma vez (mentira… foram várias) precisei modelar um sistema de gestão de pedidos para um site de e-commerce. Pedidos nascem quando você finaliza sua compra e, geralmente, possuem um workflow que é implementado com uma máquina de estado. Então o pedido transiciona de “novo” para “pago” e para “faturado“, “enviado“, “entregue“, etc. Tem o estado “cancelado” também. Quase todo mundo modela assim e aí vários problemas começam a acontecer.

Você percebe, por exemplo, que a gente não “envia um pedido”. A gente “envia pacotes com produtos pedidos”. Onde o estado “enviado” (e o “entregue”) deveria estar? No pedido? No “pacote”? A solução correta depende muito do significado de cada modelo de negócio. Mas a mensagem aqui é: pare para pensar no que acontece na vida real antes de colocar isso no seu software.

Outro exemplo nesse mesmo sistema: cancelamento. Quando você para pensar na vida real você percebe que um pedido pode ser cancelado a qualquer hora. Pelo código de defesa do consumidor o cliente poderia cancelar esse pedido até 7 dias depois que o produto chegou na casa dele. Então a máquina de estado (bem simplificada) ficaria mais ou menos assim:

Parece certo isso? Não, né? Ah! E as ações para cancelar um pedido variam dependendo da etapa em que ele foi cancelado. Imagine a complexidade disso.

E se a gente quiser implementar o conceito de suspender um pedido sem cancelar (para conversar com o cliente sobre alguma dúvida que ele tenha)?

Você vai modelar um sistema de gestão de pedido e quando olha em volta todo mundo modela mais ou menos desse jeito. É muito fácil cair nessa armadilha. Eu mesmo caí várias vezes.

Talvez, e só talvez, “cancelado” não seja um estado dessa máquina de estado? Será que não poderíamos usar outro workflow/máquina-de-estado para gerenciar suspensões e cancelamentos?

Outra armadilha no mesmo domínio de negócio tem relação com os termos usados para se conversar sobre o sistema. Uma frase como “Vou colocar o produto pra vender no site” pode induzir o analista de sistemas a criar uma entidade Product no site de comércio eletrônico quando na verdade você não tem um produto de verdade lá. O que a gente tem em um site de comércio eletrônico são anúncios de itens (SKUs – Stock Keeping Unit) de um produto (GTIN/EAN/ISBN) produzida por uma marca.

Entendem o problema que a ambiguidade da palavra “produto” pode trazer pra sua análise?

Óbvio que eu caí nessa armadilha inúmeras vezes. Honestamente eu caí nessa armadilha *todas as vezes* que tentei modelar esse software.

Então… esse casos servem para ilustrar, na prática, algo que acontece intuitivamente no processo de análise de sistemas que eu faço. Como não consigo fundamentar essas explicações eu espero que os exemplos ajudem vocês de algum modo.

É certo que tem mais técnicas e processos que eu uso e conforme eu for tomando consciência deles vou tentar trazer aqui pra vocês.

Sou extremamente entusiasmado com tecnologia e adoro até mesmo aquelas tecnologias que chegam pra quebrar tudo que já existe. Tecnologias disruptivas, na maioria das vezes, empurram a sociedade pra frente. Na terminologia usada na política eu seria chamado de “progressista”. O oposto de um “conservador”.

Mas ser um progressista não deveria impedir as pessoas de apontarem os problemas causados por novas tecnologias. É necessário que isso aconteça para que a sociedade coloque essas novas tecnologias problemáticas como pauta para novos “progressos”.

Tecnologias usadas nas redes sociais, os tais “algorítmos”, produtos construídos no bojo da Inteligência Artificial (Machine Learning, Deep Learning, etc), Deep Fake, e etc já estão se mostrando bastante problemáticas em muitas aplicações. Não quero que elas acabem (até porque seria impossível) mas precisamos entender elas melhor e ajustar o seu uso.

Mas não pretendo tratar desses grandes tópicos aqui. Eu sequer teria capacidade para abordar esses assuntos. Vou tratar de uma tecnologia bem mais prosaica: as novas ferramentas de comunicação empresarial.

Vou falar sobre o Slack mas acho que os pontos aqui também se aplicariam a ferramentas similares como o Teams, Rocket Chat, e até certo ponto, o Discord. E vou falar mais do Slack porque é a que tenho usado por mais de 5 anos infelizes.

Comunicação

Existe uma classe de medicamentos chamada de “genéricos”. A piada (ruim) diz que os medicamentos genéricos servem para curar problemas genéricos.

Se existe uma classe de problemas genéricos essa classe é a dos “Problemas de Comunicação”.

Eu aposto uma jujuba que em quase toda reunião de feedback, sprint review, ou post-mortem/lessons-learned, alguém vai logo dizer “ah! mas isso foi um problema de comunicação”, ou, “acho que é só a gente melhorar a comunicação”.

A comunicação… ah essa malvada! Sempre essencial e importante e tantas vezes negligenciada.

A comunicação é composta de vários elementos: emissores, receptores, mensagens e meios e para que ela funcione bem todos esses elementos precisam funcionar corretamente. Se tudo isso funcionar corretamente a gente acaba com uma comunicação efetiva.

Não importa se a comunicação é síncrona, assíncrona, rápida, lenta, detalhada, superficial, urgente, importante, online, offline, etc. Tudo isso pode variar e mesmo assim você pode ter uma comunicação efetiva.

Vai falar que comunicação assíncrona é melhor para aquele cara que quer avisar que o sistema principal da empresa caiu. Uma plataforma de chat, um mensageiro eletrônico ou até mesmo um telefone são muito mais adequados para comunicar essa ocorrência do que um e-mail em um grupo de discussões, um telegrama ou uma carta.

O oposto disso seria o processo de comunicação necessário na criação de um novo produto. Não me parece que usar um chat seja o melhor lugar para conduzir a comunicação necessária nesse processo.

Nesse caso uma reunião presencial (quando possível), uma reunião online com um documento compartilhado ou uma thread em um bom fórum/grupo de e-mail funcionaria bem melhor. No caso do fórum/grupo você ainda incluiria aquele coleguinha que não pôde participar da reunião por um motivo qualquer (ex. férias, doença, compromisso pessoal, …).

Indolência

Eu comecei esse artigo com uma reclamação no Twitter. Logo vi que parte das pessoas não entenderam muito bem o meu ponto por lá. Sabe porque? Porque o Twitter é uma péssima ferramenta de comunicação para expressar tudo o que estou colocando aqui.

Por esse motivo achei importante escrever exatamente o que eu penso aqui. Um meio muito mais adequado para comunicar ideias mais elaboradas. Eu precisei ser menos indolente (slack) e menos negligente (slack) na minha comunicação.

Eu tenho dois filhos que fazem parte das gerações Z e Alpha. Essas últimas gerações tem algumas características em comum e uma delas é a de que eles querem tudo na hora, só clicando um botão. Eles não querem profundidade. Preferem respostas rápidas. On-demand. Just in Time.

Eu sou de outra geração (acho que é a Gen X) mas já tinha essa mesma ansiedade. Quando eu era criança falava que iria aprender tudo o que a humanidade sabia. Achava que todo o conhecimento da humanidade era o que estava dentro dos 10 volumes da Enciclopédia Trópico que a gente tinha em casa. Era bastante coisa para uma criança mas, ei!, eu tinha uma vida toda pela frente!

Aí a criança cresceu e o mundo foi crescendo junto. Os horizontes se expandiram. Começou a ficar claro que a humanidade sabe muito mais coisas do que aquilo que estava na Trópico. O entusiasmo de aprender tudo virou um: ih! fodeu!

Acabei deixando meu plano de saber tudo o que a humanidade sabe on hold (mais um na lista de projetos paralelos sem finalizar) e optei por desenvolver um MVP: aprender tudo sobre computação. Como já dá pra ver a primeira característica de um bom programador já estava presente: subestimar o tamanho dos problemas.

Trinta anos depois de ter estabelecido essa meta eu posso dizer com tranquilidade: tá foda! 🙂 Não desisti ainda, mas preciso dizer para todo mundo que está começando na computação que não é fácil e leva tempo.

Não conheço muito sobre outras áreas e profissões mas imagino que não seja muito diferente. Se embrenhar por uma carreira sempre vai exigir dedicação e tempo.

É claro que hoje eu consigo aprender uma nova linguagem de programação muito mais rápido do que acontecia 20 anos atrás. Também consigo entender o que uma ferramenta faz com poucos parágrafos de texto ou em uma boa conversa no boteco com amigos da área (saudades disso!).

Porque eu consigo entender e aprender algumas dessas ferramentas tão rápido? Porque depois desse tempo todo eu adquiri experiência.

Experiência é o produto de dois fatores: prática deliberada e tempo.

Sem a prática deliberada você não ganha experiência. Sem tempo você também não ganha experiência.

Oportunidades

Grandes Oportunidades requerem Grandes Experiências

Tio Benedito (eu acho)

Já faz algum tempo que o setor de Tecnologia da Informação anda muito aquecido. Tem um mundo vagas abertas para diversos tipos de posições e com o aumento de oportunidades de trabalho remoto esse mercado expandiu ainda mais.

Por conta dessa efervescência tem muitas pessoas chegando ou migrando para a área de TI. E eu acho isso ótimo! Pra falar a verdade eu acho até que “tá pouco, manda mais”!

Nesse processo tem chegado todo tipo de pessoas com todo tipo de experiências, expectativas, e necessidades. Para alguns é uma jornada para a vida. Para outros é só mais uma ‘corrida pelo ouro’. Pra ser honesto eu não ligo muito para as motivações dessas pessoas porque cada um sabe quando o boleto vence.

Mas no meio desse pessoal que está chegando tem um grupo que me preocupa um pouco mais: os jovens que anseiam por resultados rápidos.

Eles me preocupam porque, como meus filhos, eles anseiam por resultados e respostas rápidas para tudo. Inclusive para suas carreiras. E é mais provável que esses resultados não cheguem tão rápido para quem está só começando. Bons resultados surgem com boas oportunidades e a probabilidade de uma boa oportunidade surgir para uma pessoa com pouca experiência é muito baixa.

Então é preciso adquirir muita XP antes de encarar os chefões do jogo.

É fácil. Mas é Difícil.

Sempre que alguém me pergunta se é muito difícil aprender a programar eu respondo: é fácil mas é difícil. Obviamente, depois da brincadeira boba, eu explico melhor.

Para se tornar um programador é necessário dominar várias técnicas (ex. dividir um problema grande em problemas menores, experimentação, etc), algumas ferramentas (ex. computador, linguagem de programação, editor de texto, controle de versão, banco de dados, etc) e algumas práticas (ex. escrever testes, revisar código, etc).

Como você pode ver um programador não aprende só programação. Tem um portfólio completo de coisas que precisam ser estudadas em maior ou menor profundidade para se tornar um programador melhor e melhor.

Algumas dessas coisas vão ser fáceis de aprender e entender. Outras serão bem desafiadoras. E eu não consigo fazer uma lista classificando quais são fáceis e quais são difíceis porque isso varia muito de pessoa para pessoa. Eu sofri para aprender programação OO. Amigos meus ‘sacaram’ o paradigma lendo um livro.

Mas insisto em dizer que todo mundo consegue se tornar um programador mas não espere que seja só fazer um curso mágico e pimba! Sou um programador! Nem mesmo uma boa universidade sozinha vai fazer isso pra você.

Se você pode fazer uma boa universidade aproveite a oportunidade e faça. Vai te ajudar muito na sua jornada. Mas lembre-se de que a jornada é sua e é você que precisa praticar programação.

Aprender programação se parece muito com aprender uma arte marcial. Você não aprende Kung fu lendo um livro ou assistindo vídeo de aulas no Youtube. A menos que você seja o Neo no filme Matrix você só aprenderá Kung fu praticando.

Señor Developer

O que eu disse até aqui não tem relação com a discussão infrutífera sobre “Senior Developer” que vez ou outra explode em algumas redes sociais.

Essa classificação de senioridade é muito aberta e subjetiva. Ela varia de empresa para empresa e de programador para programador.

Eu tenho minha definição sobre o que é um programador Senior e ela inclui o atributo experiência (ter um bigode grosso é outra coisa que conta para senioridade… brincadeirinha 🙂). Mas para outras empresas ou até mesmo para outros amigos meus isso não é tão relevante. E tudo bem!

Algumas pessoas atribuem senioridade para programadores com experiências relevantes, outros definem que um profissional senior é capaz de ajudar outros colegas de trabalho. Como eu disse, isso varia muito e ficar discutindo o assunto é pura perda de tempo.

Não seja fiscal de senioridade. Se importar muito com isso é um sinal de que algo precisa melhorar em você.

Ceja Bem Vindos!

No mais eu gostaria de dizer à todos que estão chegando e deixar aberto minhas redes sociais para todos vocês que sentirem que precisam de alguma ajuda nesse processo.

… para pessoas programadoras

Como sou programador eu procuro sempre ter uma abordagem voltada para solução de problemas. Mesmo quando o problema que se apresenta não seja solucionável com software.

No momento que a empresa onde eu trabalhava precisou aumentar a equipe fiquei de frente com alguns problemas importantes: como encontrar e contratar profissionais com o perfil que a gente precisava? Qual o perfil de profissional que a gente precisava?

A empresa estava construindo os alicerces de uma plataforma de software. A pequena equipe que já trabalhava com a gente era muito qualificada e experiente. Também valorizavam a qualidade das práticas e processos de desenvolvimento para entregar sempre o melhor resultado.

Então a gente tinha que contratar programadores que prezam a qualidade das soluções desenvolvidas e fazer essas contratações em ritmo bom.

Perceberam que os dois requisitos podem soar contraditórios? Qualidade ou velocidade? Ambos!… Nessas situação a gente travou um limiar no aspecto qualidade e criou um processo que pudesse agilizar e uniformizar todas as contratações.

Processos & Práticas

Nesse artigo eu vou descrever o processo de seleção que construi, junto com minha equipe e o departamento de Recursos Humanos da empresa. Essa é a versão do processo que estava em uso até o momento que eu deixei a empresa. Não sei se eles ainda estão usando mas eu suspeito que não.

O processo não é perfeito e, como disse, prioriza um perfil de profissional bastante específico: profissionais apaixonados por programação que querem trabalhar em uma equipe que desenvolve software. São profissionais que priorizam muita qualidade e boas práticas.

Falei esse monte de coisas aqui em cima mas o que eu realmente queria fazer era criar o ambiente perfeito para o programador que existe em mim amaria trabalhar. ?

Esse processo não é muito eficaz para empresas que precisam crescer o seu time de desenvolvimento de forma muito rápida ou que estejam em um estágio onde o mais importante é criar soluções rápidas para os problemas que se apresentam. E vocês verão que ele é bem longo.

O processo todo é dividido em 8 fases. Cada prospecto/candidato tinha um card no JIRA que tinha algumas customizações que exigia o preenchimento de certas informações fossem feitas antes de se avançar para a próxima fase. Cada fase do processo era representado por uma coluna no JIRA.

Aviso para candidatos

Algumas informações desse artigo podem ser muito valiosas para vocês também. Entender como um desse processos funciona te permite fazer engenharia reversa e hackear o sistema. Espero que vocês façam bom uso desse material.

Etapas do processo

Etapa 0: Captação

Antigamente as empresas descreviam as vagas com seus requisitos, colocavam em alguns forums e sites de emprego e ficavam esperando a enxurada de candidatos. Aí era só jogar todos esse candidatos nos diversos filtros, avaliar eles e escolher o mais adequado entre todos os finalistas. Essa abordagem passiva para contratar programadores não funciona mais tão bem.

Hoje é muito difícil contratar bons programadores. Contratar bons programadores com experiência está se tornando quase impossível. Não sei se isso vai ser assim pra sempre mas já é uma realidade faz vários anos.

Por conta disso a abordagem passiva para buscar candidatos precisa ser modificada e as empresas, agora, precisam ser pró-ativos na captação de bons prospectos/candidatos (leads). Uma vez que você encontra esses candidatos devemos iniciar o processo de “venda” da vaga para ele.

Na empresa onde eu trabalhava a gente tinha diversas técnicas de captação. Eu vivia me embrenhando em redes sociais e grupos de desenvolvimento de software em busca de projetos bacanas e sempre que esbarrava em um programador interessante eu criava um card no JIRA com as referências desse prospecto.

A empresa também incentivava (e financiava) os programadores da nossa equipe a participar de eventos de tecnologia e levar a palav… digo… apresentar as oportunidades que trabalho que a gente tinha aberto. A gente também tinha um orçamento para patrocinar esses eventos e poder ter uma presença mais marcante nessas ocasiões.

A equipe de RH também ajudava muito na captação buscando leads em plataformas como Linkedin, Stackoverflow, etc.

Eu fiz um breve “treinamento” (uma reunião rápida pra passar umas dicas) com a equipe de recrutadores explicando como abordar esse leads sem soar muito intrusivos. Ensinando a não ter nenhuma abordagem massiva (spam, mail marketing, etc) e sempre abordar cada lead depois de ter lido perfil e se informado sobre o possível candidato. Também expliquei como se comportar em comunidades de FLOSS e nunca postar uma vaga sem antes se apresentar e perguntar quais são as regras daquele grupo para anunciar vagas abertas.

As descrições das vagas precisam “vender o produto”. Então elas precisam ser muito completas e contar até mesmo detalhes das tecnologias, processos, benefícios, etc. Apesar disso, nessa empresa, a gente não anunciava a faixa salarial e sempre dávamos respostas vagas como ‘acima da média de mercado praticadas no Glassdoor’. Não consegui convencer todo mundo sobre a importância de divulgar a faixa salarial. Mas esse assunto é complicado o suficiente e provavelmente merece um artigo só sobre ele.

O processo todo deveria ter como alicerce o respeito total com os candidatos. Respeito com a pessoa, com o tempo da pessoa, e com a dedicação dela ao processo.

Etapa 1: Entrevista Inicial

Com o contato do prospecto e o estudo prévio dele já podemos entrar em contato e marcar a entrevista preliminar caso ele tenha interesse em nos atender.

O dia e horário que você marcar essa entrevista já vai dizer um pouco sobre o ritmo de trabalho da empresa. Então fique esperto com entrevistas em horários bizarros como fins-de-semana ou tarde da noite. A menos que o candidato peça um horário diferente tente falar com ele em horário comercial.

Se ele topou envie o convite por e-mail e marque em sua agenda e JAMAIS se atrase para essa entrevista. É crucial que você respeite o candidato desde o primeiro contato. Lembre que é a sua empresa que precisa dele.

Essa parte do processo é a que vou detalhar menos porque ela era conduzida majoritariamente pelas psicólogas do RH da empresa que, por questões de ética profissional, não podiam detalhar o que faziam. Recomendo muito usar profissionais de psicologia no processo de recrutamento das empresas. A quantidade de informações úteis que eles conseguem trazer para o processo é incrível.

Na entrevista inicial uma das psicólogas iniciava o contato online com o candidato, fazia algumas perguntas para ver se o candidato se encaixava no perfil de profissional que a empresa dava preferência e começava algumas anotações sobre pontos de atenção para serem explorados nas próximas etapas.

Um exemplo: a empresa tem trabalho remoto e o candidato diz que nunca trabalhou remoto antes. Isso obviamente não desclassifica o candidato mas prepara os avaliadores das próximas etapas para ver se o candidato consegue se desenrolar bem nessa modalidade de trabalho.

Aliás, essa etapa dificilmente ‘desclassificava’ alguém. Ela era muito mais útil para fornecer subsídios para os avaliadores. Em alguns raros casos a recrutadora era desrespeitada durante essa entrevista e, nestes casos, obviamente, o candidato caia por ali mesmo.

Uma vez que a psicóloga estava confortável pra enviar o candidato para a próxima fase ela já apresentava o teste técnico (próxima fase), explicava como proceder com o teste e já deixava um contato para eventuais dúvidas. O teste não tinha prazo máximo pra ser feito mas a psicóloga contactava o candidato regularmente (semanalmente) pra perguntar se estava tudo ok com o teste. Algumas vezes os candidatos abortavam o processo e não avisavam nada pra gente e essas ligações serviam pra gente mover o card desse candidato pra coluna de finalização.

Uma observação importante: a recrutadora também era a coordenadora do processo de cada candidato. Ela que “batia o bumbo” para que os processos andassem e os prazos fossem cumpridos. Ela também centralizava a comunicação com o candidato para garantir que ela estava dentro dos padrões.

Etapa 2: Teste Técnico (Candidato)

Eu não gosto de testes de quadro branco e acho esses testes de sites como HackerHank bastante limitados. Por mais que seja bem difícil e trabalhoso especificar um teste técnico que consiga abranger a avaliação de todas as habilidades importantes em um candidato eu acho que vale o investimento.

O teste técnico é peça muito importante de todo o processo. Não só porque ele vai avaliar se o candidato tem o mínimo de conhecimento para trabalhar nos projetos que a empresa precisa. O teste técnico serve como subsídio para algumas etapas posteriores.

O teste técnico que criamos possuíam as seguintes características:

1. Venda seu peixe. O documento com o teste é uma boa oportunidade para mostrar como vai ser legal trabalhar junto com você na empresa.
2. Projeto completo. O teste tem que pedir um projeto completo. Do desenvolvimento até o deployment em produção. Indique sites que possibilitem o deploy gratuito desse teste para o candidato (ex. Heroku).
3. Definição de escopo e requisitos objetiva. O teste tem que ser enviado para o candidato com um único documento contendo todo o escopo do projeto. Se você espera que o candidato saiba inglês, por exemplo, envie esse documento em inglês. O documento deve especificar apenas o Quê precisa ser feito. Nunca diga como fazer à menos que isso faça parte das práticas que o candidato precise dominar mas que seja muito difícil ou demorado para ensinar. Exemplos de coisas que você pode pedir:
   1. Código com strings e identificadores em inglês;
   2. Usar alguma linguagem que a empresa use (para que possa ser avaliado);
   3. Testes automatizados;
   4. Documentação (no idioma que você quer avaliar no candidato);
   5. Armazenado em controle de versão;
   6. Seguir um coding style específico;
   7. Praticar conceitos de 12 Factor-App;
   8. API em um estilo específico (ex. REST, GraphQL, gRPC, etc)
4. Simples e factível em 1 dia. Bons profissionais, geralmente, já estão trabalhando. É importante entender que eles não tem tempo para investir em um teste longo e trabalhoso.
5. Não-relacionado à atividade da empresa. Não faz muito tempo algumas empresas usavam testes técnicos para obter desenvolvimento gratuito de candidatos. Por conta disso programadores são bastante desconfiados de testes que pedem o desenvolvimento de algo que a empresa possa usar sem pagar.
6. Código aberto por padrão. Exceto em casos onde o candidato pede explicitamente para manter o teste dele fechado deixe ele como opensource. Isso diminui as dúvidas sobre o uso do código sem pagamento. Algumas pessoas me perguntavam se isso não pode ser usado por outros candidatos para copiar testes. Sim. E tudo bem, afinal, todo desenvolvedor sempre acaba copiando um código aqui e ali. Nas etapas seguintes é possível levantar o que foi copiado e a motivação para isso. Se foi plágio completo você consegue detectar fácil.
7. Exercitar vários aspectos do trabalho. O teste pode ter uma regra de negócio elaborada, implementar uma API REST, armazenar os dados em um DB, ter modelos diferentes interagindo, etc. Problemas pontuais com coisas como carrinho de compras, gestão de assinaturas e pagamentos, gestão de conteúdo, logística e entregas, etc são ótimas fontes de ‘problemas de negócio’ que podem ser explorados para criar um teste. Lembre apenas de limitar bem o escopo para que seja possível criar algo em um dia.
8. Validade limitada. O teste tem que ter uma validade limitada. A validade serve para que você reabilite candidatos que eventualmente não foram selecionados em um processo anterior a participar novamente. Ele fez o teste-1 e não foi adiante 6 meses atrás mas ele estudou os pontos que você indicou e quer aplicar para uma vaga novamente. Se o teste mudou ele pode reaplicar.
9. Produzir contexto extra-código. O teste precisa permitir que o programador trabalhe nele como ele trabalharia na sua empresa porque não devemos avaliar apenas o código produzido. Precisamos ver a documentação do projeto, a linha do tempo dos commits e as mensagens de commit, abordagens alternativas para solução do problema, etc.
10. Sem prazo para entrega. É importante deixar claro para o candidato que o objetivo dele é fazer o melhor teste que ele puder e não o tempo que ele leva para fazer isso. O tempo para realizar o teste precisa ser descartado completamente da avaliação porque cada candidato tem uma situação completamente diferente de outro candidato. Tem candidato que tem emprego e outro que não tem. Tem candidato que tem atividades paralelas e outros que não tem. Tem candidato que está estudando um tópico novo para fazer o teste e outros que já sabem tal tópico. É importantíssimo reforçar isso para o candidato sempre que entrarmos em contato com ele para que esse contato não se pareça com alguma forma de pressão por entrega. Diga que ele será avaliado pelo que ele entregar e não pelo tempo que ele levou pra entregar.

Abaixo você consegue ver um exemplo de teste técnico:

Assim que o candidato concluir o teste e enviar o material pra você a próxima etapa começa. Chegou a hora de avaliar o teste.

Etapa 3: Avaliação Técnica

A avaliação do teste precisa ser feita por um programador da equipe ou gestor que tenha trabalhado como programador da equipe. Ele vai pegar o código do candidato e uma ficha de avaliação com perguntas claras e objetivas sobre tudo o que a empresa espera do candidato e preencher essa avaliação.

Mais do que a avaliação em si, nesse momento é bem importante que apareçam dúvidas na cabeça do avaliador. Essas dúvidas precisam ser anotadas juntamente com os resultados da avaliação porque elas serão extremamente úteis na próxima etapa do processo seletivo.

Na empresa onde implementamos esse processo a gente criou uma planilha com um questionário com perguntas bem objetivas agrupadas em tópicos. Cada pergunta dessa gerava uma nota entre 0 (min) e 3 (max). Cada nota dessas tinha um peso variando entre 1 e 3 que posteriormente era usada em uma média ponderada.

No final a gente gerava um gráfico do tipo radar com um eixo em cada tópico (ex. Documentação, Modelagem de Banco, Commits, etc) e uma lista de notas e observações do avaliador.

Você pode baixar um modelo dessa avaliação aqui:

Quando o volume era menor a gente colocava dois programadores para avaliar o mesmo teste e depois fazia uma ‘acareação’ mediada entre os avaliadores para evitar problemas de interpretação. Mas em um determinado momento o volume de testes para revisar ficou grande demais e só um programador fazia a avaliação de cada teste.

Fizemos essa mudança porque raramente encontrávamos divergências muito grande e em todas as vezes o motivo da divergência era a falta de objetividade na pergunta do questionário que era prontamente corrigido.

Essa avaliação não pode demorar muito pra ser feita e, se isso acontecer por algum motivo, é importante manter o candidato informado.

Em alguns casos o candidato vai muito mal e recebe avaliações muito ruins e seguir com o processo provavelmente seria um desperdício de tempo para todos.

Nesses casos é muito importante devolver uma resposta para o candidato e, se possível, indicar os pontos de estudo e melhoria para ele. Eu tinha uma lista de links para artigos ou livros para indicar que ajudariam o candidato a cobrir todos os pontos onde ele precisava melhorar.

Esse feedback precisa ser mais abrangente do que específico:

From: [email protected]
 
Olá [candidato],

Após a avaliação do seu teste técnico [url do
teste] nós optamos por não seguir adiante com
seu processo seletivo nesse momento.

Agradecemos o seu tempo e dedicação até aqui e
gostaríamos de vê-lo novamente no futuro quando
lançarmos um novo teste técnico para a vaga.

Para isso gostaríamos de sugerir a leitura dos
seguintes materiais:

* [link para um artigo sobre apis rest]
* [link para um livro sobre modelagem OO]
* [link para livro sobre TDD]
* [link para um bom curso de Python no youtube]

Se você tiver qualquer dúvida ou tiver
interesse em nos dar um feedback sobre
o processo até aqui é só entrar em contato.

Obrigado,
Equipe Empresa Co.

Esse e-mail não é o lugar para escrever coisas como ‘você não foi aprovado porque a sua modelagem de banco estava toda errada’. Prefira indicar um bom livro sobre modelagem relacional. Dê preferência para conteúdo gratuito. Lembrem-se que o candidato pode estar numa situação financeira complicada.

Na empresa onde eu trabalhei eu pedi verba para comprar ebooks e enviar para candidatos que não eram aprovados. Mas a verba não foi aprovada.

Etapa 4: Entrevista Técnica

Assim que a avaliação do teste técnico ficava pronta um gestor de tecnologia poderia prosseguir com o agendamento da entrevista técnica com o candidato. Ele fazia isso sempre buscando o melhor horário para o candidato. A entrevista também precisava ter uma duração fixa pré-determinada. Deve-se evitar dividir essa entrevista em etapas distintas. Ter ela em uma única sessão garante que você vai avaliar o candidato em sua plenitude de humores.

Conduzir uma boa entrevista exige mais técnica do que experiência. Pode ser que eu escreva só sobre isso em um artigo futuro então vou só pontuar algumas coisas que a gente fazia lá.

Antes de ir para a entrevista técnica o gestor já se preparava usando as informações das avaliações feitas pela recrutadora na entrevista inicial, as anotações da avaliação técnica e dando uma conferida no Linkedin ou no Github do candidato. Eu evitava redes sociais não profissionais (Twitter, Instagram, Facebook, etc) porque nas poucas vezes que olhei essas redes acabei sentindo que a entrevista ficou enviesada de forma negativa.

Os gestores que faziam essas entrevistas já tinham alguma experiência com processos de recrutamento mas, mesmo assim, a gente ainda sugeria certos procedimentos para tentar padronizar a experiência. A gente sugeria que o entrevistador criasse um plano para a entrevista com algumas perguntas-guia para fazer para o candidato. Meus planos geralmente tinham umas 3 perguntas padrão que giravam em torno de relacionamento com equipe, processos e experiências anteriores, e umas 2 ou 3 perguntas que variavam em função do resultado das avaliações. Nem sempre eu usava essas perguntas mas sabia que elas estavam lá caso a entrevista ficasse meio truncada.

Condução da entrevista

Essa etapa não era muito padronizada então vou descrever como eu conduzia as minhas entrevistas. Como eu já disse eu iniciava a entrevista com um plano construído sobre as avaliações anteriores e uma breve olhada nas redes sociais profissionais do candidato.

Sabendo que essa entrevista costuma ser a que deixa os candidatos mais nervosos e que muitos candidatos, mesmo aqueles com muita experiência, podem ‘travar’ nesse momento eu dedicava um bocado de tempo no começo só para deixar o ambiente mais leve e as coisas mais calmas. Você precisa que o candidato esteja tranquilo para conseguir uma boa entrevista.

A entrevista técnica sempre começava com algumas perguntas básicas e despretensiosas sobre o candidato. Começar a conversa perguntando sobre algum hobby ou coisas positivas que surgiram na entrevista inicial tira o peso da entrevista e diminuíam o nervosismo do candidato.

Um exemplo do que eu fazia era só perguntar coisas que o candidato sabe como responder com 100% de certeza. Perguntas como: “Qual seu nome?” ou “Qual sua idade?” estão nessa categoria. “Quais linguagens de programação você gosta?” não está nessa categoria porque o candidato vai começar a pensar sobre qual é a resposta que o entrevistador quer ouvir.

Eu tomava muito cuidado com perguntas sobre a intimidade do candidato (ex. “Você é tem namorada(o)?”). Até pra perguntar se o candidato era casado(a) ou tinha filhos eu evitava. Se eu não estivesse 100% certo de que essas perguntas eram seguras eu não fazia. Por isso o planejamento prévio é essencial.

Uma dica que sempre dou para quem está começando a fazer entrevistas é: você não precisa ser algo que você não é. Se você não é engraçado não precisa ser engraçado. Só tente ter empatia pelo candidato para poder ajudar ele.

Quando você sentir que o candidato está mais calmo você pode serguir com o seu plano para a entrevista. Chegou a hora de falar pouco e ouvir muito.

Aqui eu partia para as perguntas técnicas. É muito comum que programadores estejam mais confortáveis com a parte de hard skills então a transição para essas perguntas acontecia de modo mais natural.

Eu usava o teste do candidato para formular questões bem objetivas. Perguntas do tipo: “Aqui nesse ponto do seu código você fez isso. Porque você fez assim e não assado?” (ex. “Vi aqui nessa parte do seu teste que você modelou esse relacionamento em 1-para-N… mas e se essa entidade estiver em M contextos, não seria melhor um N-para-M?”).

Eu prestava atenção no que estava sendo dito (ex. “eu optei por modelar 1-para-N porque na descrição do problema não existia o requisito que pediria uma modelagem N-para-M”), mas também observe o que não está sendo dito. No exemplo anterior dá pra inferir que o candidato segue bem as especificações mas pode não ser muito pró-ativo em questionar essas especificações. Eu encadeava mais perguntas pra dirimir essa dúvida e não ficar só com a minha “inferência”.

Também gostava de fazer perguntas que podiam ser respondidas corretamente de vários modos diferentes e emendar uma segunda pergunta contrapondo a resposta. Exemplo: “Se você tivesse desenvolvendo um ORM como você faria pra persistir um objeto no banco de dados? Faria obj.save() ou storage.save(obj)?” e a próxima pergunta seria: “Mas [a outra abordagem] não teria a vantagem de [vantagem da outra abordagem]?”. Esse tipo de pergunta permite ver o candidato reagindo à uma situação de argumentação e defesa de seus pontos de vista. Alguns candidatos até explicaram a teoria e as referências para as duas abordagens (Active Records vs. Data Mappers). Esse foi contratado, né? ?

Uma vez que as questões técnicas foram esclarecidas eu partia para as “perguntas difíceis”. Aqui eu queria entender mais sobre os soft skills do candidato. Nesse momento o candidato estava mais amaciado com as coisas que ele (teoricamente) sabia e conseguiria responder com a guarda mais baixa.

Eu voltava então a fazer perguntas relacionadas ao comportamento e relacionamento do candidato com as equipes que ele teve.

Queria saber como era a relação dele com gestores, o que ele gostava no trabalho, o que ele detestava, o que ele gostaria de mudar, o que ele conseguiu mudar, o que ele não conseguiu mudar, porque ele não conseguiu mudar, etc.

Eu sempre tomava notas durante a entrevista. Precisava fazer isso para alimentar o nosso relatório sobre o candidato.

Finalmente chegamos ao fim da entrevista. Você agradece o candidato e avisa que ele receberá um retorno num prazo específico. Cumpra esse prazo.

Retorno

O retorno para o candidato podia ser de 2 tipos:

1. Paramos: agradecíamos o candidato pelo tempo investido no processo, informávamos que ele pode voltar a tentar a vaga no futuro, indicávamos caminhos que ele poderia tomar para ser melhor sucedido na próxima oportunidade, e deixávamos um canal sempre aberto para comunicação com ele. Esse retorno era por e-mail mas eventualmente o RH entrava em contato direto com o candidato.
2. Continuamos: parabenizávamos o candidato e informávamos que a próxima etapa seria uma dinâmica de Pair Programming remoto com um dos nossos desenvolvedores. Pedíamos um espaço na agenda do candidato para essa atividade.

Etapa 5: Dinâmica de Pair Programming Remoto

A equipe de tecnologia da empresa onde implementamos esse processo sempre trabalhou remotamente. Trabalhar remoto é uma atividade que pede certos soft skills importantes (ex. auto-gestão, auto-organização, etc) e o nosso processo precisava avaliar se o candidato tinha essas características, se era necessário desenvolvê-las, ou se a empresa seria incapaz de desenvolver essas qualidades no profissional caso ele fosse contratado.

Quebramos a cabeça pra descobrir um modo de fazer essa avaliação e, certo dia, participando de um Coding Dojo com alguns amigos eu tive a ideia de tentar algo parecido para avaliar a dinâmica de trabalho remoto do candidato. Deu super certo e se tornou a etapa que me deixava mais entusiasmado com os resultados.

Montamos um servidor remoto (usando AWS Cloud9) com a linguagem Python, framework de teste, editor de textos e conectávamos um desenvolvedor da nossa equipe e o candidato para fazer pair programming. Além dos dois programadores um gestor (geralmente o mesmo que fez a entrevista técnica) ficava na audiência coordenando a atividade e observando a dinâmica.

O gestor então apresentava o problema que seria abordado na dinâmica. Eram problemas de Coding Dojo já conhecidos (ex. mostrar números decimais com algarismos romanos). Nenhum dos programadores pode saber qual vai ser o problema de antemão. Tem que ser uma surpresa para ambos.

É muito importante deixar claro para ambos que o objetivo da dinâmica é ver a dupla trabalhando e não a resolução do problema. Deixe claro para o candidato que se não der tempo de resolver o problema está tudo bem.

Uma vez apresentado o problema os programadores começavam a trabalhar nele usando TDD e baby steps. Em intervalos de 5 minutos (cronometrados) os programadores são obrigados a trocar de posições como piloto e co-piloto do teclado.

Assim que o timebox foi atingido o programador pode deixar a sala e o gestor pode conversar com o candidato sobre a dinâmica.

A gente usava essa oportunidade para perguntar sobre situações que aconteceram durante a sessão de pair programming. Fazíamos muitas perguntas sobre comportamento (ex. “naquele momento o [nome-do-dev] propôs algo que você não concordou/entendeu e mesmo assim você seguiu com a proposta dele, porque você não parou pra questionar ele sobre a decisão?”).

Também é possível ver se o candidato consegue expressar bem suas ideias e propostas.

Essa etapa tem que ter duração fixa e não precisa ser longa. Na empresa a duração dessa etapa começou com uma hora de duração e foi diminuindo até durar 40min.

Algumas vezes a gente colhia as impressões do programador da nossa equipe que fez pareou com o candidato para complementar nossa avaliação.

Era muito raro um candidato cair nessa etapa. Se o candidato foi muito mal e a gente entendesse que não daria para prosseguir a gente falava que ele receberia o feedback em alguns dias e procedia com o e-mail de agradecimento e etc.

Se o candidato tivesse ido bem nessa etapa ele já recebia uma lista de dias e horários para a entrevista final com o CEO. Era a única ocasião onde o candidato não tinha o controle total sobre a agenda do processo. Infelizmente a agenda do CEO era uma selva e tinha muito poucos buracos para ocupar com as entrevistas com candidatos. Mas ele fazia questão de entrevistar todo mundo de todos os setores da empresa.

Etapa 6: Entrevista Final

A entrevista final com o CEO era a etapa de consolidação & arremate do processo. Ela existia para determinar se o candidato tinha fit com a cultura da empresa mas também era usada para dirimir alguns questionamentos que ainda estavam aberto sobre o candidato.

Para isso o CEO recebia um “dossiê” com tudo o que foi levantado sobre o candidato nas etapas anteriores bem como alguns pontos de atenção que a gente detectou nas etapas anteriores. A gente chamava esses pontos de atenção de red flags (bandeiras vermelhas).

Uma das coisas que essa entrevista tentava avaliar era o nível de comprometimento com a empresa que a gente podia esperar do candidato. Para a empresa era importante que o candidato fosse trabalhar lá com um certo nível de comprometimento e não chegar lá como um trampolim para outra vaga que pagasse mais. Afinal o time dessa empresa era muito reconhecido no mercado e passar por ele “valorizava o passe” de qualquer profissional.

Nessa etapa todos os candidatos já chegavam travados pelo nervosismo. Afinal, era o CEO da empresa… Então o CEO com a maior calma e paciência ia acalmando o candidato antes de partir para as perguntas.

Durante a entrevista o CEO contrapunha as resposta do candidato com anotações do relatório que ele tinha recebido para tentar encontrar, explorar e esclarecer divergências.

Assim que a entrevista terminava o candidato era avisado de que ele receberia o resultado final do processo em alguns dias. Geralmente era no dia seguinte mesmo. Assim que o CEO terminava a entrevista com o candidato era bem comum ele já reunir o comitê que iria decidir sobre a contratação.

Decisão Final

Essa etapa era rápida e a decisão era colegiada. Um candidato só era contratado se houvesse unanimidade desse colegiado que era formado por todos os gestores e recrutadores que participaram do processo daquele candidato.

A decisão era rápida porque todos já tinham tido acesso ao relatório final com todas as informações levantadas ao longo de todo o processo. Bastava avaliar as forças e fraquezas de cada candidato, traçar um plano para potencializar as forças e lidar com os pontos de atenção do candidato e decidir sobre a contratação.

Feedback

A etapa de feedback tem duas versões. O feedback para o candidato que foi contratado e o feedback para o candidato que não vai seguir para contratação naquele momento.

Para os candidatos que não seguiriam a gente enviava um e-mail bastante completo para informar que a gente não seguiria adiante com a contratação, agradecíamos a dedicação do candidato, indicávamos alguns caminhos para futuras tentativas e deixávamos uma linha de comunicação aberta para esse candidato.

Na linha do respeito ao candidato, algumas vezes, a gente entrava em contato direto com o candidato. Geralmente quando eram candidatos muito jovens que, eventualmente, não conseguiriam lidar muito bem com a não-contratação. As psicólogas avaliavam se isso era necessário ou não e por isso disse que ter esse tipo de profissional envolvido no processo é super importante.

Para os candidatos que foram aprovados a gente mandava um e-mail de congratulações com as primeiras instruções do nosso processo de on boarding que, modéstia à parte, também ficou lindão (e provavelmente vou descrever aqui).

É possível que o candidato recuse a oferta nessa etapa. Esteja preparado para isso e peça, educadamente, que, se possível, o candidato explique o motivo da recusa para ver se é possível melhorar algo no processo. Lembrem que o feedback é uma via de mão dupla e o candidato é o protagonista.

A gente também colhia feedback dos candidatos contratados durante o on boarding. A gente tinha um formulário (Google Forms) interno onde o novo funcionário preenchia suas impressões, apontava problemas e sugeria melhorias. As recrutadoras do RH colhiam essas informações e traziam os feedbacks de forma anônima para nossas reuniões de processos.

Hoje eu estava lendo o artigo Stepping Back from Speaking do Martin Fowler e me identifiquei com muitas coisas que ele disse. Na verdade parece um artigo que eu teria escrito para falar sobre o assunto. Exceto pelo fato dele ser “O” Martin Fowler e eu ser só o Osvaldo, eu passo (ou passava) por tudo o que ele diz ter passado para dar palestras em eventos de tecnologia.

Quando eu era mais novo costumava ser bastante introvertido. Isso mudou quando uma professora de educação artística notou que meu talento para trabalhos manuais era bem limitado e decidiu organizar grupos de teatro na minha turma. Fiz ou ajudei a fazer do roteiro à cenografia e até atuei no palco. Ali eu pude perceber que conseguiria me apresentar para uma audiência.

O tempo passou e a vida aconteceu… veio o trabalho como programador e pude voltar a ser o cara que fica ali no canto, de cabeça baixa, codando.

Mas aí surgiu o meu envolvimento com as comunidades de FLOSS e, principalmente, com a comunidade Python. Nessas comunidades eu achava super importante compartilhar as coisas que eu aprendia. E a forma de fazer isso quase sempre envolvia falar para uma grande audiência (qualquer coisa maior que uma mesa de bar já conta como ‘grande audiência’ pra mim).

E aí acontece aquilo: as primeiras apresentações são péssimas, vão melhorando para ficarem muito ruins e um dia, quando menos se espera, eu estava mandando bem.

Uma das coisas que a gente aprende fazendo palestras é que é muito importante respeitar a audiência. Respeitar a audiência é garantir que você fez o seu melhor para trazer algo relevante para eles. Fazer isso com muito carinho e muita qualidade. Tem gente ali que investiu tempo e dinheiro que vão faltar mais na frente na esperança de ter um retorno por esse investimento. Eu me sinto obrigado a fazer valer esse investimento.

Em eventos de tecnologia é bastante comum ver os palestrantes montando suas apresentações em slides poucas horas antes de apresentar. Tem gente que tem esse talento mas eu não tenho. Sempre cheguei com minhas apresentações preparadas e ‘testadas’ (algumas vezes testava em encontros locais ou eventos menores). O dia antes da apresentação era só pra atualizar uma ou outra informação que eventualmente tinha surgido desde a última revisão.

Causo: durante a PythonBrasil de São Paulo alguns ladrões de notebooks entraram no evento e roubaram meu notebook (e mais um outro da minha amiga Karyn). Minha apresentação estava nele e infelizmente, por negligência minha, não estava sincronizado na nuvem. Eu pedi para retirarem a minha apresentação do evento porque eu não conseguiria fazer ela mesmo conhecendo bem o conteúdo dos slides. Eu entrei em pânico com a ideia de não entregar uma boa apresentação.

No dia em que tenho que fazer a minha apresentação, tal como acontece com o Martin Fowler, eu entro em um estado tão estressante e fico tão ansioso que fica parecendo que estou tendo um ataque de pânico. Eu chego a ter problemas intestinais nos momentos que antecedem a minha fala.

Não abandono o plano porque já sei, por experiências prévias, que essa sensação dura só até os primeiros minutos no palco. Nesse momento eu entro em flow com o conteúdo e consigo superar o mal estar.

Quando a apresentação acaba eu só peço para anotarem a placa do caminhão. Estou exausto e, algumas vezes, até com dores físicas.

Muitas vezes eu cogitei “tomar algumas” (“fumar” poderia funcionar também) para ver se quebrava um pouco a ansiedade mas desistia da ideia por respeito à audiência. Eu não sei exatamente o que aconteceria mas não me perdoaria se a apresentação ficasse ruim porque eu estava alterado.

Apesar disso tudo e, diferentemente do Martin Fowler, eu pretendo continuar fazendo apresentações. Sinto que devo isso à comunidade que me trouxe muitas coisas boas na vida e na profissão. Entretanto, tentarei restringir os convites que aceito e, provavelmente, enviarei propostas para poucos eventos.

Para iniciantes

Se tem algo que eu gostaria de trazer para quem vai começar a se apresentar em eventos, é que eles entendam que esse nervosismo é normal e bem comum. Até mesmo aquela pessoa no palco, que você admira muito, pode estar passando por essa provação.

Se você quer encarar essas experiências entenda que pode acontecer esses contratempos ao longo do caminho. E se você não quiser, ou não puder, encarar essas dificuldades tá tudo bem também.

Hoje eu vi uma pesquisa na internet onde perguntavam como eu me sentia quando via meu código sendo removido por outros desenvolvedores do meu time.

A pesquisa também pedia informações de perfil profissional para tentar entender se profissionais com experiências diferentes reagiriam da mesma forma ao verem seu código removido por outro desenvolvedor do time.

A primeira coisa que pensei foi sobre o assunto foi “depende”. O software continuou funcionando direito depois do “facão”? O código perdeu alguma característica importante?

Sempre que vou revisar um código e vejo um patch que remove muitas linhas a minha primeira reação é de empolgação. Então, por padrão, eu costumo gostar muito de alterações que removem código. Nesse momento eu não sei se o código removido é meu ou não então eu também posso dizer que a autoria do código é indiferente pra mim. Sou devoto da igreja do Collective Code Ownership.

A partir daí eu sigo com a revisão usando outros critérios para validar o que está sendo feito. E é aí que o “depende” entra em ação e eventualmente tenho dúvidas sobre ser favorável ou não à remoção deste ou daquele código.

Código desnecessário

Se o código removido não está mais sendo usado obviamente tem que ser removido. Todo mundo ganha com isso. Aquela API antiga que não tem mais suporte e ninguém usa mais? Apaga. Foi tarde.

Outro tipo de código desnecessário são aqueles trechos que estão comentados dentro dos arquivos. Se você usa um sistema de controle de versão (e deveria) jogue fora isso. Não comente código “pra usar depois”. Se você precisar usar depois busque no controle de versão e use.

Código grande

Algumas vezes a gente vê algum método muito grande e decide melhorar a implementação dele. Como conseqüência o código termina menor do que o anterior e os testes ainda continuam passando. Ou seja, foi uma boa refatoração onde todos ganham.

Mas… tem uma exceção para isso aqui. A legibilidade. Imagine que você tem um código tipo:

for i in range(50):
    for j in range(50):
       double[i][j] = array[i][j] * 2

Aí a refatoração faz isso:

double = [[array[i][j] * 2 for j in range(50)] for i in range(50)]

Claramente é um código mais curto e roda mais rápido. Mas e a legibilidade? Para julgar se essa redução no código é boa ou não precisamos avaliar mais aspectos.

Pra mim, por padrão, esse tipo de remoção de código é um “não”. Mas o desenvolvedor pode me convencer do contrário se dizer algo como “cara, esse método é crítico e essa mudança melhora em 30% a performance dela”.

Código complexo

Alguns programadores (eu aqui!) tem uma tendência de adicionar complexidades desnecessárias no código para tornar ele mais extensível, mais eficiente, etc. Não é muito incomum que um programador precise resolver um problema muito específico com um código bem básico saia criando sistemas de plugins ou configurações em busca de mais flexibilidade.

Por sofrer desse problema não é incomum que eu receba modificações que passam facão geral nessas partes do código que eu tinha escrito.

Sendo bem franco? Eu fico chateado. Mas depois que passa a tristeza e a razão assume o controle é possível entender que a mudança é potencialmente positiva.

Um “causo” (sem desfecho)

Certo momento da minha vida eu pegava muito freela pra fazer. Uma empresa me contratou para desenvolver um software de simulação de empresa para um cliente deles.

O cliente deles tinha um curso de administração e empreendedorismo e criou um simulador de empresa usando Excel. É. Recebi uma planilha com cerca de 30 abas (não é uma hipérbole) onde você controlava estoque, verba de marketing, salários, de uma empresa hipotética e a planilha ia “reagindo” a essas mudanças e mostrando a evolução do seu negócio.

Eu ia levar 1 mês só com a engenharia reversa daquela planilha para então começar a criar uma aplicação Django pro cliente do meu contratante (Django era requisito do meu cliente).

Então pensei: e se eu implementar um motor de planilha no Django? Criaria o motor, faria “copy & paste” das fórmulas da planilha para o banco de dados da aplicação e profit!.

Era uma ideia meio ousada e, por isso, fiz uma prova de conceito para mandar pro meu contratante avaliar. Ele apagou tudo e substituiu as fórmulas da planilha por código Python tradicional. Ele refez o que eu tinha feito só que hardcoded.

Obviamente, como era só uma prova de conceito com um subconjunto bem pequeno da planilha, o meu “motor” era bem maior do que um conjunto hardcoded de condicionais. Na minha solução o cliente (treinado) poderia ajustar os parâmetros e fórmulas da simulação. Na versão nova só um desenvolvedor poderia fazer isso.

A alteração feita reduziu muito o código em troca de flexibilidade e de fato ficou bem mais simples e fácil de compreender. Mas foi um bom negócio? Não sei. O cliente deles desistiu do projeto por questões financeiras e nunca soubemos qual abordagem seria melhor.

Esse caso mostra bem como eu tenho uma forte tendência ao over-engineer. Sempre bom ter alguém ponderado por perto pra segurar minha onda.

Código ingênuo

Quando estamos atacando um problema pela primeira vez é bem comum criar soluções muito muito ingênuas para esses problemas. Essas soluções até servem por um certo período de tempo mas logo se mostram insuficientes.

Olhando deste modo isso parece algo ruim mas é melhor optar por uma solução ingênua do que uma alternativa flexível que inevitavelmente traria complexidade desnecessária pra solução.

É importante entender que, com o tempo, vamos entendendo melhor o problema e adquirindo mais sabedoria sobre como resolver ele de uma maneira mais adequada. Esse é o momento de melhorar o código e jogar fora o código antigo (se não for possível melhorar ele).

Quando sabemos que esse momento chegou? Não sabemos. Provavelmente jogaremos fora esse código novo também. E assim a vida segue. Por isso chamamos de software ?

Um exemplo…

Já tive que implementar determinados tipos de código mais de uma vez ao longo da minha carreira. Alguns desses reincidentes são os sistemas de autenticação/autorização e os sistemas de assinatura/pagamentos.

É impressionante. Eu fiz errado na primeira vez, na segunda vez, na terceira vez, … e na última vez.

Em cada ocasião eu fiz o sistema mais flexível que o anterior e pensava: “dessa vez vai”. Não ia. Acho que nos cursos de Marketing e Administração eles ensinam uma matéria “Como encurralar Devs”. Eles sempre conseguem criar um modelo de assinatura, pagamento, pacotes de permissões, etc que você nunca imaginou. Sempre. Não tente lutar contra isso.

Por isso o melhor caso aqui é faça um código que só resolva o problema na mesa. Quando outro problema surgir, escreva um código que resolva os problemas que você precisa e jogue o anterior fora. Não tente prever os eventuais futuros problemas porque é perda de tempo.

Hoje eu terceirizo alguns desses sistemas sempre que dá. Desisti de tentar. Acho que é Senior que chama, né? ?

Remover código é bom

Como podem ver, tirando algumas exceções, apagar código é uma coisa boa. Vamos apagar código até termos “low code” ou “no code“… brincadeirinha ?

Oi Pessoal, hoje eu estou aqui pra anunciar a criação do meu primeiro canal de Youtube: Osvaldice.

Ele começa pequeno e ainda sem um formato bem claro mas eu pretendo colocar lá algumas reflexões que tenho e até mesmo algumas coisas da minha vida pessoal e profissional.

O nome do canal é Osvaldice porque é um trocadalho ruim mesmo ?

Pretendo lançar vídeos semanais mas ainda não consigo garantir a regularidade das publicações porque estou em processo de mudança para o Brasil e as coisas estão meio bagunçadas por aqui.

O canal vai começar com 3 vídeos que gravei na última semana e fiz todos eles em uma situação meio improvisada aqui na Alemanha por motivos de “meu equipamento principal está indo para o Brasil”.

Estou criando esse canal para experimentar e aprimorar minhas habilidades de produtor de vídeo para viabilizar meu segundo canal: Cômputos. Já faz vários meses que estou trabalhando no Cômputos mas ainda não consegui encaixar o formato dentro de algo que me deixe feliz. Então o Osvaldice pode me ajudar nessa tarefa e me deixar mais “acostumado” com a câmera.

O canal Cômputos vai ser destinado à apresentar a computação como algo lúdico e divertido. Computação como hobby.

Quando o canal sair eu volto aqui pra avisar.

PS. O blog continua, ok? Se o assunto for mais denso e cheio de referências eu provavelmente vou postar aqui no blog. Se o assunto for mais rápido e informal eu posto lá no Osvaldice.

Dentre vários assuntos que tenho interesse na computação um deles é sobre o aprendizado de programação. Principalmente para crianças e jovens. Já li muita coisa e ouvi opiniões muito distintas sobre as melhores formas de se ensinar e aprender a programar um computador.

Existe muita discussão sobre se ensinar crianças a programar seria algo bom ou não, mas não pretendo descer muito nesse aspecto do debate. Para fins práticos vou partir da premissa de que ensinar crianças e jovens a programar não faria mal para eles e acrescentaria algumas habilidades úteis aos seus repertórios.

Lembrando sempre que ensinar programação para crianças não tem nada a ver com encaminhar crianças para a profissão de programador.

Como ensinar programação?

Nas minhas conversas sobre esse assunto, com diversas pessoas, eu já vi abordagem bem variadas para ensinar alguém a programar. O nível de convicção desses interlocutores sobre sua abordagem favorita variava muito. Alguns “achavam” que sua abordagem era boa e outros tinham “certeza” de que a sua abordagem era a melhor.

Um padrão que eu detectei foi: quando mais fácil foi para o interlocutor aprender a programar, mais certo ele estava de que o método usado com ele é o mais adequado.

Isso complica muito a discussão porque faz parecer que reproduzir um desses métodos vai funcionar pra todo mundo. E isso não é assim.

O que esses bons resultados, com abordagens diferentes revelam é justamente o oposto. Revelam que o que dá certo é usar abordagens diferentes com pessoas diferentes.

Abordagens

Eu me deparei com sugestões para os mais diversos tipos de abordagens para ensinar programação para iniciantes.

Existe uma abordagem que busca ensinar teoria e “lógica de programação”. Com computadores de verdade ou com computadores de papel. Alguns sugerem escrever código em “Portugol” em um pedaço de papel para fazer os famigerados “teste de mesa” e só depois ir para o computador. Outros sugerem usar Portugol direto no computador (ou Pascal).

Outras pessoas já me disseram que programador tem logo que começar a aprender a programar em C pra já ficar mais próximo da máquina. Eles sugerem C porque seria uma espécie de “assembly multiplataforma”.

Estou lendo um livro muito bom que sugere ensinar computação (e não só programação) partindo de portas lógicas NAND até implementar um jogo de Tetris.

Por outro lado outros amigos imaginam que o melhor mesmo seria usar alguma linguagem de nível mais alto mas que ainda são linguagens de uso geral como Python, Javascript, Processing, Arduino/C++, etc.

Alguns outros adoram ver seus filhos se divertindo com plataformas especificamente criadas para crianças como Scratch.

O que eu acho dessas abordagens? Na verdade não importa o que eu acho porque não estamos falando do meu aprendizado. Eu já aprendi a programar (eu acho?) e cada uma dessas abordagens funcionou para algumas pessoas e também falhou com outras.

Qual abordagem é melhor?

Ok. Então significa que não existe uma abordagem que funcione para ensinar programação? Não exatamente. Não existe uma abordagem que funcione. Existem várias.

Pessoas diferentes aprendem de modo diferente e isso precisa ser respeitado. Então o certo seria iniciar o ensino com uma das abordagens apresentadas e ir iterando sobre ela para ir ajustando o curso. E focar muito nas práticas e atividades que funcionam melhor para aquele aluno ou para a média daquela turma (caso não seja possível individualizar o ensino).

Dentre várias práticas observadas por cientistas que já se debruçaram sobre o assunto as que mais se mostram positivas para facilitar o aprendizado são aquelas que apresentam o feedback mais amplo e rápido para o aluno.

Quando um aluno experimenta algo no computador e vê o resultado daquilo surgindo instantaneamente o cérebro dele dispara recompensas que ajudam muito a fixação do aprendizado. Por outro lado se ele observa o feedback com a visão, com o olfato, com o tato, com a interação com pessoas, etc o efeito dessa recompensa é potencializada ainda mais.

Essa potencialização do feedback é que fez com que o Seymour Papert, criador do ambiente LOGO para ensino de programação para crianças, disponibilizasse uma tartaruga robô no ambiente que ele desenvolveu. O robô existia para reforçar o feedback das crianças quando ela digitava um comando “PARAFRENTE 10” (ou “FRENTE 10” na variante Microsol LOGO) e via aquele robozão andando sozinho obedecendo à instrução fornecida pela criança. Isso tudo está descrito em seus dois livros.

A ideia de feedback rápido também é explorada nesse artigo incrível do Brett Victor chamado Learnable Programming que serviu de referência para a Apple criar o ambiente Swift Playgrounds.

Então, se voltarmos para as abordagens propostas que descrevi acima, podemos trabalhar com várias delas desde que seja possível obter feedback amplo e rápido nas atividades desenvolvidas.

Tanto o Seymour Papert quanto o Brett Victor apresentam outras práticas úteis no ensino de programação (e, acredito, de qualquer outro tipo de conteúdo). Sugiro a leitura de ambos para se preparar para a tarefa de ensinar programação.

Qual abordagem funcionou pra mim?

Eu sou um privilegiado sortudo. Tive pais que tinham uma boa condição de vida (aka classe média) e nunca pouparam grana e esforço em me apoiar.

Eu já contei um pouco essa história aqui mas resumidamente eu era uma criança de 9 anos que brincava com Eletrônica junto com um amigo e esse amigo ganhou um computador de natal. Eu fiquei completamente entusiasmado com aquilo e pedi um computador pro meu pai.

Demorou um pouco pro meu pai conseguir comprar o meu primeiro computador (MSX Expert) usado de um tio mas ele chegou lá e eu comecei a estudar com os livros que acompanhavam a máquina. Mas aí eu travei em um ponto do aprendizado e passei a usar a máquina só pra jogar.

Meu pai viu aquilo e me cobrou: poxa filho… investimos uma grana alta nesse computador pra você aprender a usar ele e você fica só jogando? Você já tinha um videogame pra jogar (um Atari), não precisava de um computador caro pra isso.

Expliquei pra ele que eu já tinha lido todos os livros e feito todos os experimentos que vinham nele e “não tinha mais pra onde ir”.

Ele entendeu o problema e perguntou se eu queria fazer um curso de computação? “- Claro!”.

Ele encontrou uma escola de computação no bairro onde eu morava através da lista telefônica (é… anos 80/90…) e me matriculou lá. Meu pai não entendia nada de tecnologia e me matriculou nessa escola só porque eu poderia ir sozinho até ela (bairro Boa Vista em São José do Rio Preto – SP).

E até aqui mostra como fui/sou uma pessoa privilegiada. Mas agora vem a parte onde eu fui sortudo…

Essa escola perto de casa, no interior de SP, era de um casal que tinha ganhado uma grana alta em um desses de plano de demissões voluntárias e foram para os Estados Unidos, no MIT, estudar no grupo LOGO do próprio Seymour Papert, pra trazer o método pro Brasil. Eles montaram essa escola usando essa abordagem.

E é aqui que eu ganhei na loteria.

No curso eu aprendi LOGO (variante Microsol LOGO) e BASIC em máquinas Apple II (TK3000 e Exato Pro). Eu saia da aula todo dia e tentava refazer tudo o que aprendi no meu MSX Expert (que não tinha LOGO e tinha um dialeto diferente de BASIC).

Depois eu ia para a casa daquele meu amigo que tinha um Apple II (um raríssimo Spectrum ED) onde ele já estava ralando pra aprender Assembly de 6502 (e eu ali do lado me aventurando junto).

Em dezembro de 1989 eu concluí o curso na “Escola Inteligente” (é… era o nome da escola) e me formei em programação LOGO e BASIC aos 12 anos de idade. Alguns meses depois eu comecei a trabalhar como programador em uma imobiliária da cidade, mas isso é outra história.

Conclusão

Depois desse tempo todo eu acho que não importa se você vai ensinar programação com Scratch, Python, C/C++, Arduino ou pela eletrônica. O importante é que você consiga produzir feedback rápido e amplo por todo o caminho do aprendizado.

No artigo anterior vocês viram que comprei um Raspberry Pi 400. Quando enviei o artigo pro meu Twitter algumas pessoas pediram um review. Então esse post aqui é uma tentativa de mostrar o computador com mais detalhes.

Especificações

O Raspberry Pi 400 tem as configurações muito parecidas com a do Raspberry Pi 4 Model B de 4GB de RAM. As únicas diferenças estão no clock mais rápido (1.8GHz vs 1.5GHz) e a adição de uma porta USB 2.0 extra. Diferente do que se possa pensar não é um Raspberry Pi 4 montado dentro de um case com teclado. Todo o desenho da placa de circuito foi refeito e levou em consideração aspectos como temperatura de operação do circuito.

• Broadcom BCM2711 com 4 núcleos Cortex-A72 (ARM v8) 64-bit SoC @ 1.8GHz
• 4GB LPDDR4-3200
• Wi-Fi Dual-band (2.4GHz e 5.0GHz) IEEE 802.11b/g/n/ac
• Bluetooth 5.0, BLE
• Gigabit Ethernet
• 2 × USB 3.0 and 1 × USB 2.0 ports
• Conector Horizontal 40-pin GPIO
• 2 × micro HDMI (com suporte até 4Kp60). O kit que comprei já acompanha um cabo micro-HDMI/HDMI com aproximadamente 1m.
• H.265 (4Kp60 decode); H.264 (1080p60 decode, 1080p30 encode); OpenGL ES 3.0
• Entrada para cartão MicroSD (o kit que comprei acompanha um cartão de 16GB da Sandisk já com o SO instalado e pronto pra usar)
• Teclado compacto 78/79-teclas (dependente do layout)
• Conector para fonte 5V DC com conector USB-C (o kit que comprei já acompanha uma fonte compatível com pinos US
• Dimensões máximas 286 mm × 122 mm × 23 mm

Eu adquiri o kit completo com layout US no teclado com a fonte também US (depois descobri que tem a opção US com fonte européia que certamente funcionaria com as tomadas brasileiras também). O kit também inclui cabos, cartão MicroSD com Raspberry Pi OS, e uma cópia impressa do livro The Official Raspberry Pi Beginner’s Guide 4th Edition (o link aponta para a terceira edição).

O kit completo aqui na Alemanha, onde moro, saiu por 97,38 € + 5,80 € de frete (total de 103,18 €).

Conectividade

O Raspberry Pi 400 oferece conexão para quase tudo o que você precisa.

Todas as conexões ficam dispostas na parte traseira do case e, conforme podemos ver na foto acima, temos (da esquerda pra direita):

1. Conexão GPIO de 40 pinos no formato já padronizado pelas outras versões de placas Raspberry Pi.
2. Slot para MicroSD.
3. 2 x conectores Micro-HDMI para usar com até 2 monitores. Eu ainda não usei ele com 2 monitores mas consegui resolução de 3840 x 1080 no meu monitor Samsung Ultrawide 8k.
4. Conector USB-C para carregador (não serve para dados).
5. 2 x conectores USB-A 3.0.
6. 1 x conector USB-A 2.0 para o mouse. Na internet as pessoas reclamam que o mouse fica ligado do lado esquerdo do computador e o fio é um tanto curto para alcançar o lado direito. Como eu sou canhoto e uso o mouse com a mão esquerda eu não senti o problema que parece ser real.
7. 1 x conector Ethernet Gigabit.
8. Wireless: ele disponibiliza Wi-Fi e Bluetooth 5.0 BLE.

Uso

Eu usei o meu Raspberry Pi 400 apenas 1 vez por algumas horas. Conectei todos os cabos, liguei, e logo já pude ver o splash screen com a framboesa na tela. Em poucos segundos a interface gráfica carregou e um aplicativo de configuração inicial começou a executar.

O aplicativo pergunta coisas sobre qual idioma você pretende usar, qual o layout do teclado, configuração de rede e por último pergunta se você quer atualizar o software.

Fiz a atualização de software que demorou uns bons minutos e então comecei a usar normalmente.

A primeira coisa que me impressionou bastante foi o fato de que ele conseguiu usar toda a tela do meu monitor com boa resolução (3840 x 1080). E olha que não é “qualquer” monitor.

Experimentei vários aplicativos que acompanham o Raspberry OS. Dos mais leves (Terminal) aos mais pesados (LibreOffice e Chromium). Naveguei por vários sites e assisti videos no Youtube. A máquina se comportou bem e se mostrou bastante usável como uma máquina para o dia-a-dia.

Mas atualizar pacotes e usar IDEs mais pesadas mostraram que ela não é uma máquina destinada à um uso profissional para programadores. É importante lembrar que se trata de uma máquina com processador ARM, logo, vários softwares proprietários distribuídos em formato binário para Linux (ex. Zoom) não vão rodar nela. Lembre-se disso ao pensar em comprar um.

Um teste que infelizmente não consegui fazer é o de som. O Raspberry Pi 400 não possui auto-falante interno mas, em teoria, transmite audio pelo sistema HDMI (em teoria porque só testei em meu monitor que não tem sistema de audio). Eu conectei meu fone de ouvido Bluetooth nele e consegui assistir um video com audio no Youtube sem nenhum problema.

Quando liguei ele pela primeira vez o meu monitor não reconheceu ele de imediato (meu monitor é meio enjoado com conexões HDMI enquanto ele está ligado) e por isso pensei em resetar o Raspberry Pi 400 pra forçar a inicialização da conexão HDMI. Mas… descobri que ele não tem botão de Reset e nem botão de Liga/Desliga. Essa talvez seja a única coisa que senti falta no conjunto todo. A outra coisa que eu achei ruim foi precisar de um adaptador de tomadas para o formato US, mas descobri que foi erro meu em não ver a opção de tomada européia no site.

Resumo

Enfim, como eu disse no meu artigo anterior, eu curti a sensação de usar o Raspberry Pi 400 e fiquei muito feliz com a compra. Pretendo usar ele na minha bancada de eletrônica assim que comprar um monitor pra conectar nele. Mas certamente não servirá como uma máquina principal.

Eu também não recomendaria ele para usuários de outros Raspberry Pi’s se você usa esses dispositivos como proxy, roteador, NAS, media player, ou emulação de consoles. Pra esses casos eu ainda ficaria com as placas convencionais. Não vale a pena gastar dinheiro extra por um computador que tem um case com teclado se você não vai usar ele como um computador.