Torsten Paul Nelson

Tivemos a oportunidade de assistir a uma palestra do Sr Torsten Paul Nelson, Engenheiro de Software do Google, que esteve visitando a unidade de produtos digitais do Grupo RBS no TecnoPUC.

O tema da palestra foi o “Desenvolvimento de Software: Fazendo a Teoria da Faculdade funcionar”, Torsten é Ph.D. em Ciência da Computação pela University of Waterloo, na área de engenharia de software. Mestre e Bacharel em Ciência da computação pela UFMG.

Atuou como Gerente de Projetos de Software na Vetta Technologies e hoje trabalha no Google, no escritório de Belo Horizonte. Possuidor de grande experiência como Engenheiro de Software, compartilhou conosco alguns aspectos importantes relacionados ao planejamento e desenvolvimento de software.

Show, a seguir a minha percepção daquilo que mais me chamou a atenção:

Problema ou solução

É comum quando um usuário ou requerente solicita algo, tentar pedir já a solução imaginada e não uma declaração exata do que é o problema a ser solucionado, pois talvez a melhor solução seja outra. Ele citou um case de duas mesas, que durante uma mudança de endereço, acabou ficando com apenas uma das estruturas e os dois tampos de madeira, ele procurou um serralheiro para fazer um pé “igual” ao que ele ainda tinha e só ao receber percebeu que os tampos tinham furação diferentes … o problema não era copiar a estrutura existente, mas fazer uma estrutura nova para um dos tampos que estava sem.

Inovação

A inovação normalmente não depende do cliente, mas do fornecedor, que detem o conhecimento e os meios para imaginar uma solução melhor que algo existente, em sistemas, cabe ao fornecedor (nós) entendermos o “problema” e buscarmos alternativas inovadoras para propôr fazer mais e melhor.

Não existe uma “equipe de inovação” ou “sala de inovação”, posto que inovação não acontece por decreto, o correto é entender que existe a cultura da inovação, disposta a tentar coisas novas, flexível na aceitação dos erros inerentes a estas tentativas e consciente de que tentar inovar custa caro.

CHA (Conhecimento + Habilidade + Atitude)

As pessoas saem da academia sem terem sido orientados, treinados ou educados na habilidade de trabalhar em equipe, verdadeiramente, pensando no objetivo como resultado de um trabalho coletivo, reconhecido desta forma, com uma atitude construtiva e convergente, ao invés de individualista e competitiva.

Debatido com a platéia sobre as 5 principais virtudes de um desenvolvedor, listou aquelas que lhe parecem mais verdadeiras e basilares :

1º. Paixão pelo aprendizado, vontade permanente de crescer, de saber mais.
2º. Saber comunicar-se em Português claro, assertivo, agradável, educado, …
3º. Saber Inglês, posto que é a lingua internacional mais usada.
4º. Saber trabalhar em equipe
5º. Dominar algoritmos

Produtividade com qualidade

A técnica de revisão de código, quando um profissional inspeciona o trabalho de outro é a técnica que mais garante qualidade e difusão de conhecimento. Enquanto o “pair programming” os dois programadores constroem a solução juntos, na revisão o desenvolvedor é obrigado a usar as melhores práticas possíveis para que o código fique limpo, bem documentado, fácil e completo.

Uma ferramenta de busca de código é essencial para evitar retrabalho, quando um desenvolvedor cria um programa ou parte dele, quando um ou mais colegas já o fizeram antes. Essencial que os programas estejam auto-documentados e utilize-se um repositório centralizado de código e collection de indexação. A idéia defendida é não fazer a mesma coisa 3 vezes, uma esta correto, duas é retrabalho e disperdício, três vezes é inadmissível.

Testes devem ser automatizados e devem rodar o tempo todo, sempre, é aceitável que um desenvolvedor irrite-se em ter que testar toda uma funcionalidade a cada vez que tiver que fazer qualquer tipo de customização ou refatoramento.

Prazo

É muito difícil dar um prazo, uma data-marco para a entrega de um trabalho de desenvolvimento, pois fazê-lo possui um grande número de riscos, internos a equipe ou externos. O melhor é ter-se uma meta que é revisada continuamente, qualquer outra forma de fazê-lo é comprometer-se com uma mentira, pois sabemos que não cumpriremos uma data prevista com muita antecedência.

Um comentário sobre “Torsten Paul Nelson

  1. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s