Scott Adams was right

03.junho.2009
dilbert2

De volta ao Brasil, e de volta à programação normal.

A propósito, um desafio geek. Refatore o código abaixo:

do {
} while (window[++scan] == window[++match] && window[++scan] == window[++match] && window[++scan] == window[++match] && window[++scan] == window[++match] && window[++scan] == window[++match] && window[++scan] == window[++match] && window[++scan] == window[++match] && window[++scan] == window[++match] && scan < strend);

Simples 😛

Anúncios

Entrevista de emprego

15.maio.2009

dilbert-1

Há seis meses fiz uma entrevista de emprego totalmente improvisada e despreparada. O carinha não entrou na empresa, o que não considero necessariamente negativo, e eu não participei de nenhuma outra entrevista de emprego, o que foi muito positivo. Para ser bem honesto, eu nem mesmo acho que o resultado daquela entrevista serviu pra alguma coisa.

As vezes, mais como um exercício mental, eu penso como seria uma entrevista de emprego para minha empresa fictícia, para uma vaga de desenvolvedor. Vamos supor que seja para trabalhar com Java, que é meu atual ambiente natural.

Primeiro aquela olhada no currículo. O cara tem meia dúzia de certificações, um emprego numa fábrica de software conhecida, formado numa faculdade da moda e chega de gravata para a entrevista. Sem julgamentos precipitados, lembre-se que esse é o perfil padrão de qualquer entrevista de emprego. Pode apostar, pelo menos um candidato vai aparecer nesses moldes. Numa empresa comum, ele estaria muito bem cotado a entrar.

Mas vamos à parte que interessa.

Antes de aplicar qualquer prova escrita, vou fazer algumas perguntas. Poucas, e em português mesmo. Considere que a entrevista é um momento tenso por natureza, e que não vai ajudar em nada piorar essa situação. Lembre-se de que a vaga é para desenvolvedor Java, e não para atirador de elite da SWAT.

Você gosta de ler? Qual a sua média de livros técnicos por mês? Você dá preferência a livros traduzidos ou em inglês?

Caso responda ‘não’ à primeira pergunta, podemos encerrar a entrevista por aqui mesmo. Preferência por livros traduzidos ao invés de livros em inglês, para mim, pode denotar preguiça e comodismo. Mas não acredito que esse ponto seja fundamental para definir a qualidade do profissional nesse ponto da entrevista.

Você já leu “Effective Java” (Joshua Bloch), “Test-Driven Development” (Kent Beck) e “Refactoring” (Martin Fowler)? O candidato ganha bônus se também já leu “Practices of an Agile Developer” (Venkat Subramaniam e Andy Hunt), “The Art of UNIX Programming” (Eric Raymond). Claro, pergunte também o que ele pensa dos livros e, principalmente, em que pontos ele discorda.

Eu considero os três primeiros leituras obrigatórias para qualquer programador que se considere profissional. Os seguintes são leituras importantes que não podem ser ignoradas. Se bem que, atualmente, se eu entrevistar um sujeito que realmente leu e consiga levar uma discussão rápida sobre todos eles, é bem provável que eu encerre a entrevista ali mesmo e o contrate de imediato. Novamente, se o candidato não leu nenhum deles, podemos encerrar por aqui para evitar mais perda de tempo.

O candidato conhece o Manifesto Ágil? Não estamos cobrando aqui nenhuma certificação-papel-de-bobo de Scrum ou coisa parecida (acalmem-se trolls, eu também tenho uma). Também não quero que o cara tenha o Manifesto decorado na ponta da língua. Importante é conhecê-lo e entender o que significa. Conhece TDD (ok, mesmo lendo o livro) e consegue usar essa abordagem de forma pragmática? Por pragmática entenda-se: sim, você tem que escrever testes antes de codificar. Não, você não pode perder tempo tentando alcançar utópicos 100% de cobertura de código. A tarefa do programador não é entregar as Obras Completas de Shakespeare em Java, mas sim código de qualidade em tempo relativamente curto. Utópico, mas que entrevista de emprego não é?

O candidato tem algum pet-project? Participa ou participou de algum projeto open source? (tradução de arquivos de i18n não conta). Programa porque gosta ou apenas porque alguém disse que dava dinheiro? Estuda tecnologias, linguagens ou abordagens que não estão necessariamente relacionadas ao trabalho? Conhecer Lisp, Erlang, Haskell e/ou linguagens dinâmicas ajuda a enxergar maneiras novas e até mesmo mais simples e limpas de se resolver um mesmo problema.

Na seqüência, se ainda não foi encaminhado à porta de saída, o candidato deve escrever uma dissertação breve, de vinte linhas, sobre algum assunto relacionado à área. A idéia aqui é apenas avaliar a clareza de raciocínio ao passar idéias para o papel e evitar futuros problemas com analfabetos funcionais. Seco e direto assim.

Agora a sobremesa. A hora preferida do verdadeiro desenvolvedor: a prova prática.

O candidato deve resolver um code kata em tempo pré-determinado (aqui a pressão faz parte do jogo), previamente definido e exibido todo o tempo. Um relógio na parede ajudaria nesse ponto. O desenvolvedor deve conviver com prazos definidos, que geralmente são curtos, e pressão. Nada de anormal. É exigido que o candidato utilize TDD ao resolver. Se ele chegou até aqui, pode apostar que ele consegue.

Ah sim. Arranje uma máquina decente com um ambiente semelhante ao real para que ele faça essa parte da entrevista. Codificar em folha de papel é uma das coisas mais ridículas de uma entrevista. Só perde para dinâmica de grupo e entrevista com psicóloga (note o gênero).

Avalie a expressividade do código. Isso é importante. Você não vai querer pegar um código suíço pela frente, cheio de variáveis enigmáticas e abreviações que não querem dizer nada.

Como eu disse no início desse texto, que saiu mais longo do que eu esperava, isso é apenas um exercício mental. Mas no momento está me parecendo um modo bem mais honesto e efetivo do que passar um dia inteiro numa empresa escrevendo redações sobre minhas férias, sendo entrevistado por psicólogas (de novo o gênero) que mal sabem o que a empresa faz, e para terminar, com fome e dor de cabeça, uma entrevista técnica com um sujeito que não acha a própria bunda usando as duas mãos (do tipo que briga com você jurando de pés juntos que C# aceita herança múltipla). Ouviu, sevencomm?

Bom fim de semana,


O que não é Scrum

13.maio.2009

dilbert-agile-programming

Departamento de sistemas da matriz adotou Scrum como metodologia de desenvolvimento. Bacana, não?

Não.

Primeiro ponto: Scrum é um framework de gerenciamento de projetos, e não de engenharia. Obrigatoriamente você vai precisar de alguma técnica complementar se quiser que seu desenvolvimento de sistemas (no caso) esteja dentro do que se considera aceitável. Os responsáveis pela adoção acreditam realmente que apenas o Scrum vai salvá-los da danação eterna.

Segundo: usar Post-its, quadros brancos, burndown charts e mimimitings não significa que você esteja usando Scrum. Daily Meetings semanais e Stand-up Meetings sentados, com três horas de duração também não tem nada a ver com Scrum.

Terceiro: Aposto um dedo da mão direita como um “Scrum” aplicado dessa forma vai afundar o projeto, ou pelo menos vai gerar um produto de péssima qualidade, caro de se manter e muito, mas muito estressante de se trabalhar.

Aposto outro dedo da mesma mão como o Scrum vai levar a culpa e vai ser banido a pontapés da empresa. Com o risco de alguém olhar para trás e se transformar numa estátua de sal.

Pedir a benção do Papa para ‘implantar Scrum’ dentro da empresa não soa exatamente ágil. O que a empresa teoricamente espera é software que funciona, com qualidade, dentro de prazo e custo estimados. Se você tem que beijar a mão do bispo para conseguir trabalhar direito, a agilidade definitivamente não faz parte do DNA da empresa.

E finalmente, imprimir “Scrum & XP from the Trenches” e ler passo a passo antes de tomar uma decisão só mostra o quão despreparadas estão as pessoas envolvidas. Por maior que seja a boa vontade, não vai rolar.

Scrum é flexível, e muito. Mas mudar os alicerces do framework é como ser católico sem acreditar em Deus.

Como bem escreveu Rodrigo Panachi, “agilidade não é metodologia, é atitude”.

Update: Recomendo a leitura do artigo do Rodrigo Yoshima.


Integração Contínua

27.fevereiro.2009
Instalei em minha máquina de trabalho um servidor de integração contínua.

Quando se trabalha sozinho, num projeto pequeno, isso realmente não faz muito sentido. Porém, trabalhando com um recurso a 500km de distância, e mais dois recursos remotos cuidando de um projeto relacionado, cuja alteração indevida pode quebrar o funcionamento da parte em que trabalho, esse tipo de ferramenta começa a fazer sentido.

O modo correto, antes de mais nada, é instalar esse servidor numa máquina que possa ser facilmente acessada por qualquer parte interessada. Minha máquina de trabalho, obviamente, só fica disponível quando estou conectado na rede da empresa, para quem estiver na mesma condição.

Instalei o Apache Continuum rodando como um NT Service (sim, eu uso Windows no trabalho), acessível como uma aplicação web a partir da porta 8080.

Para quem se interessou, recomendo a leitura do artigo do Martin Fowler sobre Integração Contínua. Estou organizando uma documentação para compartilhar com a equipe e pretendo divulgá-la aqui.

P.S.: Sim, eu sei que tem Bamboo, mas comunicação ainda é um ponto crítico a ser desenvolvido.


Um ambiente agradável

19.novembro.2008
Estava pensando no que faz um ambiente de trabalho um lugar agradável. Com certeza você vai discordar de alguns pontos, mas sinta-se livre para adicionar ou contestar pelos comentários.

  • Liderança, não chefia.
    Isso aqui vai dar assunto para um post inteiro. No sentido utilizado aqui, um líder auxilia, gera motivação e comprometimento. Um chefe dá ordens e trabalha pelo modo de comando-controle.
  • Horários flexíveis
    Polêmico, mas eu acho importante. Existem pessoas que preferem entrar as 8 e sair as 17. Seja para chegar logo em casa, seja para fugir do trânsito. Outras preferem entrar as 9 e sair as 18, ou então chegar mais tarde por ter ficado até tarde no dia anterior. Tudo é questão de conversar e entrar num acordo que seja bom para ambas as partes, usando sempre de bom senso. A abordagem de se utilizar um ‘cartão de ponto’ na entrada do escritório, é algo antiquado e que não traz benefício algum, seja à empresa, seja ao funcionário.
  • Controle por prazos e qualidade, e não por presença física
    Um ponto que dificilmente encontro. A partir do momento que é dada uma tarefa, é definido o que deve ser feito, e o prazo, não vejo motivo para você ficar amarrado ao pé da mesa. Claro, desde que você mantenha a visibilidade do que está sendo feito. Muitos chefes acreditam que um funcionário mantido sob vigilância produz mais. É discutível. Já vi muito projeto dando errado com funcionários cumprindo horário religiosamente e chefes munidos de chicotes e projetos dando certo com lideranças flexíveis e comprometimento de todos os envolvidos.
  • Liberdade técnica
    Um exemplo de como não fazer: você trabalha numa fábrica de software, recebe o diagrama de classes pronto e sua função é rechear os métodos com código que funcione. Refactoring? Nem pensar, isso é retrabalho. E além do mais, quem você pensa que é para questionar o trabalho sagrado do analista/arquiteto/wtv?
    Outro ponto, e esse eu vejo muito em quase todo lugar, é a imagem de que  desenvolver testes automatizados tornam o desenvolvimento mais lento e improdutivo. A minha tarefa, como desenvolvedor, é entregar código funcionando, com qualidade, fazendo o que o cliente precisa, dentro do prazo previsto. Como eu vou fazer isso é problema meu. Esse é o ponto.
  • Ambiente tranqüilo e silencioso
    Me chamem de chato, mas eu não consigo trabalhar com alguém brigando com o namorado pelo telefone, gerente comentando as últimas aventuras sexuais em voz alta ou alguém ouvindo som alto (mesmo que  seja algo que eu goste) num momento em que precise de concentração. Um espaço separado é uma boa idéia, como por exemplo, uma sala de reuniões, ou o uso de fones de ouvido, se for o caso.
    Conversar é proibido? Pelo contrário, é algo importante e necessário, mas novamente, doses de bom senso nunca fazem mal.
  • Temperatura agradável
    Ambiente fechado, abafado e quente é insuportável. Escuro e com ar congelante também não é nada agradável. É difícil encontrar um consenso quando vinte pessoas trabalham juntas, mas fugir dos extremos já é uma boa coisa.
  • Equipe com bom nível técnico
    Por experiência própria, trabalhar com pessoas de nível técnico maior que o seu faz com que você se desenvolva mais rapidamente. Com pessoas com mais ou menos o mesmo nível técnico faz com que a equipe cresça junta, mais lentamente, ou simplesmente fique estagnada, dependendo da motivação de cada um.
  • Ter uma equipe
    Quatro pessoas juntas não formam uma equipe, assim como dois monólogos não formam um diálogo.
  • Café
    Café a vontade e sem miséria, afinal, somos desenvolvedores, não? 😉

Como tem se tornado comum, ao publicar o post eu acabo lembrando de alguma coisa para acrescentar, portanto não estranhe se a lista parecer incompleta.


Um modelo diferente

12.novembro.2008

Estava pensando num modelo de negócios (ach) diferente para lidar com equipes de TI, onde os desenvolvedores (analistas, programadores, testers, etc) receberiam bônus por qualidade de software.

Por exemplo:

  • Quantidade de bugs comprovados (qualidade interna)
  • Avaliação dos usuários (qualidade externa)

e não simplesmente por ‘linhas programadas’, nem por ‘funcionalidades criadas’, já que isso criaria uma corrida do ouro para que fosse feito o máximo de itens possível, com o máximo de linhas possível, mas com a qualidade sendo jogada para escanteio.

Outro item que seria interessante, para evitar que mais nada fosse criado pra nao gerar novos bugs, seria avaliar também o retorno de investimento estimado para os clientes. Ou seja, quanto mais o cliente ganhou com isso, maior seria o bônus. Isso obrigaria a equipe a focar só no que é importante, e fazer bem feito.

Claro que isso ainda é só um rascunho, mas já dá uma boa idéia de como isso poderia funcionar.