Conhecimentos inesperados de um Tech Leader | Pesadelo na Cozinha: Introdução

Você é a vergonha da profissão

Introdução

Recentemente em minhas buscas por programações para entretenimento me deparei com o programa Pesadelo na Cozinha apresentado por Erick Jacquin. Os episódios que usaremos no decorrer dos posts estão disponíveis no canal deles no YouTube.

Basicamente o programa nos mostra Jacquin interagindo com vários restaurantes e mostrando pontos de desorganização e desperdícios.

O foco da série que vou escrever não vai girar em torno da veracidade de tudo, porque eu às vezes fico com pé atrás em programas que as pessoas sabem estar sendo gravadas e agem de determinada maneira ¯\_(ツ)_/¯. Então, sim, tenho minhas dúvidas sobre a espontaneidade dos participantes, inclusive do Jacquin, mas isso não será problema para as análises que vamos fazer aqui.

Afinal, o que isso tem a ver com Tech Leader?

Uma das coisas que tento fazer é não desassociar meu “eu-profissional” do meu “eu-pessoal”. Quando vejo filmes, séries, leio livros, ouço músicas geralmente tento fazer paralelos dessas coisas com a minha vida de modo geral. Isso pode ser visto em alguns posts que escrevi como:

• Não seja esse tipo de desenvolvedor: post inspirado no excelente mangá Terraformars e no seu paralelo com o mundo do desenvolvimento. Wolf Redfield é um desenvolvedor de software no mangá e essa parte da história mostra algo que muitos desenvolvedores passam diariamente, e algo, que como mostrado, tem um efeito devastador: necessidade de entregas cada vez mais rápidas e entregas cada vez maiores.
• Departamento de Polícia da Física e Testes de software: post inspirado na HQ DPF onde as constantes físicas já não são mais constantes, e um paralelo como às vezes nossos “testes unitários” parecem testar coisas que “não confiamos”, como adicionar elemento a uma lista e testar em seguida que a lista não está vazia ¯\_(ツ)_/¯ ou testar se o save e findById do Spring Data… salvam… e… recuperam por id (para quem não trabalha com Spring, esses métodos já são dados pela interface que implementamos… testar o default nesse caso seria testar o framework, como se o próprio projeto spring-data não o fizesse). O objetivo do post é discutir o que são regras que são constantes e o que são regras passíveis de testar, um teste em que criamos um objeto com new e em seguida fazemos uma asserção para validar se ele não é nulo só quer dizer que não confiamos nas regras constantes da nossa linguagem.
• [Review] O Ponto da Virada - Malcolm Gladwell: post em que faço um paralelo com um artigo chamado Test Infected de Kent Beck e Erich Gamma.
• Série de livros de Paul Arden: nesses posts escrevo sobre 2 livros de Paul Arden e questões como feedback, discordância de pontos de vista, DevOps, até sobre como apliquei ArchUnit em um projeto o.O…

Realmente é bem interessante ler sobre o que você escreveu há um tempo…

Com o Pesadelo na Cozinha não foi diferente, ao acompanhar os episódios foi possível enxergar uma certa padronização de ações que davam para serem isoladas no “modus operandi” do programa:

• Teste de resiliência/ exploratório individual, quando Jacquin pede vários pratos de uma vez só, validando a atenção no processamento das informações e em como tarefas “simultâneas” são executadas.
• Teste de resiliência múltiplo, quando o restaurante é submetido a um pico de requisições em um dia cheio.
• Validação de sobreposição de funções ou ausência de funções no time. Definição de Chefes.
• Anti-Pattern “Ah, eu sempre digo isso mas ninguém me escuta”.
• Anti-Pattern “Ah, só somos assim porque não temos x”.
• Execução de um novo prato ensinado.
• Falha e sucesso na execução de um novo prato ensinado.
• Adesão de maquinário e novos pratos.
• Falha e sucesso mesmo com novo maquinário e novos pratos ensinado.

Cada um desses pontos pode ser analisado sob uma ótica de liderança, falarei sobre a liderança técnica, mas poderia ser outra ou outra analogia.

Por exemplo, quando vejo pessoas que dizem que “só” não evoluíram por falta da ferramenta x, y ou z tem um ponto que geralmente esquecemos, que mesmo se tivéssemos a melhor ferramenta e melhores definições, ainda sim, precisamos estar prontos para executar isso. Isso fica bem evidente quando a equipe recebe todo um novo maquinário e isso não resolve os problemas deles, porque a questão não é a ferramenta pela ferramenta apenas, mas como extrair o melhor dela com nossas habilidades.

Outro exemplo é o anseio de pessoas em serem Chefes sem terem passado por desafios que as direciona a tal, algo semelhante ao que vemos de pessoas que estão no começo de suas carreiras e já querem ser sênior com pouco tempo, sem perceberem os desafios e exigências dessas funções.

Enfim… começarei a escrever cada um desses pontos em artigos separados, só ainda não fechei o número de posts, mas ao menos cada ponto mencionado acima dá um…

E você? Consegue enxergar mais alguma analogia? Se sim, me fala… Também irei escrever em outros idiomas como inglês e espanhol para treinar um pouco, sendo assim, qualquer sugestão de melhoria é bem-vinda. Uso muito o Grammarly e o Language Tool para isso, um mais focado em inglês e outro com suporte a mais idiomas.