O lado negro da força

August 27th, 2009 § 8 comments § permalink

Dez horas da manhã, eu recebo um e-mail com uma singela planilha de Excel para revisar. Clico na planilha, ela começa a abrir e o Excel trava.

Legal, cliente de e-mail dos infernos–eu penso.

Queimo o processo do Excel e tento abrir a planilha de novo. Nada, o Excel trava de novo. Pontinha de dúvida bate, será que alguma coisa cagou na instalação dele?

Queimo o processo de novo e tento abrir outro arquivo. Excel trava. Nesse momento, bate a preocupação: caramba, se o Excel não está funcionando, como é que eu vou revisar a planilha e atualizar as outras coisas que estão pendentes. Pior, vou ter que acionar o help-desk, esperar um técnico aparecer–Caramba! Eu preciso desse Excel funcionando.

Nessa hora já estou hiper-ventilando. Voltando ao passado distante de programador, abro uma janela do console, encontro o arquivo de preferência do Excel e removo o arquivo. Tento tudo de novo e nada.

Finalmente, já desesperado, lembro que tenho o OpenOffice rodando–resquício também da época em que programava e fazia questão de usar software livre, nada dessas coisas corporativas e só de vez em quando para alguma coisa mais simples. OpenOffice trava também.

Começo a pensar que o problema deve ser no arquivo. Veja se não tem nada pendente de processos, abro um arquivo diferente e tudo funciona as mil maravilhas. Pelo visto, quando tentei abrir o outro arquivo da primeira vez, o processo ainda estava pendente e travou também.

Peço à pessoa para enviar outra versão do arquivo e consigo abrir. Ufa! Dia, vida, trabalho–todos salvos.

É só aí que caí a ficha: eu fui convertido ao lado negro da força.

Acho que vou precisar de terapia depois disso.

Joie de Vivre

June 4th, 2009 § 6 comments § permalink

Alguns anos atrás, trabalhei por alguns meses em uma empresa pequena–quatro funcionários na época–fazendo aplicações corporativas em PHP. Eu estava cansado de programar em ASP e queria espairecer um pouco em outras arenas.

Infelizmente, a alegria durou pouco. Por várias razões–falta de planejamento, dificuldade em conseguir recursos, falta de pessoal qualificado, etc–a empresa não vingou. Na época, meio do primeiro governo Lula, isso não era tão fora do comum mas faltou também uma pitada de sensatez de todo mundo para lidar com a situação. O meu tempo lá não foi de todo perdido. Rendeu boas estórias e duas amizades queridas que ainda preservo mesmo com a distância.

Por outro lado, foi a única vez em que pedi demissão em ira. Ira por planos que não chegavam a lugar nenhum. Ira por promessas não cumpridas. Ira por várias outras razões que na época pareciam bem válidas. Parti para outra, mas carregando aquele peso comigo de assunto não resolvido.

Demorou muito tempo para perceber que, na verdade, a minha ira não derivava dos problemas que eu percebia na empresa. Ao contrário, vinha de um sentimento de que faltava joie de vivre no ambiente de trabalho.

E joie de vivre –em uma tradução direta e meia-boca, alegria de viver–era algo que eu sentia mais falta no intercâmbio com meus pares de desenvolvimento do que em relação à própria empresa. Como em outras empresas que trabalhei desde então, a sensação de que os desenvolvedores ao meu lado não experimentavam isso era a parte mais terrível de qualquer situação. Eu, que sempre tive um pé no mundo livre, em projetos paralelos, conseguia derivar isso mesmo na ausência de outros fatores.

Não é de se estranhar, por exemplo, que o grande selling point do Rails tenha sido o fato de que ele devolvia ao programador a alegria de desenvolver. O Rails não se tornou um dos frameworks mais bem-sucedidos de todos os tempos por causa de suas proezas técnicas. Ruby mais Rails se tornaram um combinação imbatível em trazer joie de vivre aos desenvolvedores.

Não há nada que compre joie de vivre . É algo que só você pode conseguir e somente em certas circunstâncias. Não dá para construir nem criar, exceto por prover [condições apropriadas para que ele aconteça][1]. E como eu queria que outros pudessem experimentar isso também. Pena que quase nunca seja o caso nos ambientes que temos.

[1]: http://logbr.reflectivesurface.com/2009/04/22/a-pobreza-das-conexoes/

A pobreza das conexões

April 22nd, 2009 § 17 comments § permalink

Quando eu li Peopleware pela primeira vez, um dos tópicos que mais me chamou a atenção foi o conceito de flow. Esse conceito, advindo em grande parte do trabalho do psicólogo húngaro Mihály Csíkszentmihályi, descreve o estado em que uma pessoa está inteiramente comprometida com a realidade da execução de uma tarefa, seja qual ela for. Flow, em outras palavras, é a imersão completa em uma atividade ao ponto em que a pessoa chega a perder a consciência de que está fazendo algo até que o trabalho esteja completo–ou o estado seja interrompido.

No contexto de Peopleware–e, de fato, do campo da computação/programação em si–flow é algo bem conhecido. Programadores rotineiramente experimentam isso como parte do seu dia-a-dia. Existem argumentos de que não há como existir trabalho produtivo sem flow e livros inteiros dedicados ao tópico de redução de interrupções no ambiente de trabalho para aumentar o tempo em que programadores passam nesse estado. Obviamente, o trabalho de Csíkszentmihályi se aplica a qualquer campo em que criatividade e expressividade sejam parte da equação e existe literatura correspondente para tal.

Eu estava conversando com um gerente recém-promovido cujas preocupações são aumentar a produtividade de sua desmotivada equipe. Uma das atividades que sugeri a ele–retirada diretamente de Peopleware e cujo objetivo é sensibilizar a direção de uma empresa para a necessidade de flow–foi medir o quanto de trabalho um de seus programadores conseguia realizar em um dia e o quanto de interrupções ele sofria. O resulto foi revelador: trinta minutos de trabalho útil para mais de seis horas de interrupções (entre as quais, a importante atividade de atender a porta da empresa, perto da qual o programador em questão está sentado).

E claro, uma das propostas da empresa para aumentar a produtividade dos funcionários é remover o acesso a instant messaging e redes sociais. Como é comum nesses casos, o escape que o funcionário possui da, de outra forma, entediante realidade de seu trabalho, é fomentar suas conexões. Obviamente, como Peopleware discute muito bem, a remoção de tais privilégios terá um único efeito: aumentar o turn-over experimentado pela empresa.

O que me leva a pensar na ironia de uma questão fundamental que aflige a raça humana. Eu não quero filosofar banalidade aqui, mas uma das perguntas fundamentais que permeiam a nossa vida–junto com as tradicionais “quem sou?”, “de onde vim?” e “para onde vou?”–é como escapar da mediocridade que insiste em se insinuar por tudo o que fazemos.

Confrontados com seus dez ou quinze anos de carreira ou com o gênio unidirecional de Albert Einstein e Garry Kasparov, ou, pior ainda, com as realizações de polímatas como Leonardo Da Vinci e John von Neumann, são poucos os que admitem (publicamente, pelo menos) o pavor da mediocridade que assombra os horizontes futuros de suas vidas.

Novamente, a ironia disso tudo está nas substituições precárias que fazemos. Algumas vezes acertamos, mas como o motivo permanece incorreto, a continuidade do que acreditamos ser mediocridade é garantida.

Conversando com um amigo recentemente, falávamos sobre as aulas de Arte (com A maiúsculo) que ele recebe de um conceituado artista brasileiro. Em nossa conversa, a tema central era o real significado de criar Arte e se qualquer pessoa pode atingir esse ideal. Existem milhares de guitarras abandonadas em quartos escuros, esperando a mão que poderá transformá-las em algo transcendente–não para outros, já que é impossível realmente conhecermos o Outrem–mas pela beleza do próprio eu, trazendo à tona o real significado da Arte. Tudo o que se requer dessa mão é dedicação, transformando o tempo que de outra forma seria perdido; um entendimento, enfim, de quais são os demônios a serem combatidos. São os demônios, não a mediocridade, que deveriam nos assombrar.

O que nos leva de volta ao flow e as parcas e infundadas tentativas de produzi-lo através da remoção de artefatos que em outras circunstâncias seriam vistos como incentivos. Mas, o são realmente?

Eu não consigo deixar de pensar em como a manutenção de conexões extrínsecas é um pobre substituto para o tipo de reflexão e prática associados com Arte e Realização (aqui, no sentido filosófico/matemático de atualizar, tornar real, reificar).

Malcolm Gladwell, em seu mais recente trabalho, popularizou a conhecida regra das dez mil horas como sendo o tempo necessário para que alguém se torne proficiente em uma atividade. Gladwell foi criticado pela simplificação, mas quando a asserção é vista no contexto do trabalho de Csíkszentmihályi, ela começa a fazer mais sentido. Flow requer investimento de tempo, e se flow é um pressuposto para trabalho produtivo e permanente, se segue que a manutenção de conexões efêmeras é algo que está na contramão da realização.

Presença, um tópico permanente nas múltiplas ferramentas de conexão das quais a vida moderna parece depender, tem implicações sutis para o flow. Conectividade, vista sobre esse prisma, é uma forma de pobreza porque gera um fluxo constante de interrupções que eliminam completamente a possibilidade da realização de algo de valor concreto. O conectado, em troca da efêmera e duvidosa sensação de intimidade e pretensa consciência do seu ambiente, perde a capacidade de cultivar jardins privados e afastados da Web cujo valor remete ao discutido acima sobre Arte.

Celulares que vibram a cada segundo indicando uma nova mensagem de uma rede social composta essencialmente por estranhos de contato passageiro, o ícone de uma ferramenta de acesso ao Twitter que pisca incessantemente lembrando que alguém acabou de dizer alguma coisa absolutamente sem valor imediato (e muito provavelmente sem valor futuro também), a lista de atualizações de um Orkut ou Facebook desfiando minúcias irrelevantes da vida de outras, vão se compondo, dedos se coçando, porque eu preciso de mais e mais pontos de contato, opondo-se ao virtuosismo representado pelo flow.

Eu não quero somente uma faceta da vida. Eu não quero a mediocridade destilada em pequenas quantidades. Eu quero o imediatismo de uma derrota brilhante no xadrez sofrida para um amigo com o qual compartilho dezenas de horas de conversas entre jogos, estratégia definida em anos e não somente as trocas rápidas e fugidias dentro de uma aplicação Facebook. Eu quero as discussões intensas sobre linguagens de programação esotéricas cunhadas em um des/entendimento mútuo e não somente opiniões (mal) explicadas em cento e quarenta caracteres ou menos. Eu quero o entendimento da transcendência que você vê no jazz e eu vejo no blues, refinada por notas dedilhadas aqui e ali, pelo retorno de uma sessão tocante entre mestres de outrora e do presente, e não por um endereço Web, uma experiência por proxy.

E, acima de tudo, eu quero o tempo necessário para os demônios que me assombram.

A falsa dicotomia: generalista versus especialista

October 22nd, 2008 § 8 comments § permalink

Um papo semi-presente na área de TI é a velha dúvida: generalista ou especialista? Como em essencialmente qualquer carreira em que a dicotomia é possível, há sempre uma grande questão em torno do que decidir quando se pensa em um plano para o futuro.

De um lado, especialistas justificam sua escolha em termos de melhores salários, pouco rotatividade, maior reconhecimento. Do outro lado, os generalistas justificam com maior estabilidade, menos rotina, maior amplitude de oportunidade. Sempre há uma certa tensão entre as duas versões do profissional de TI e como qualquer dicotomia, geralmente a verdade é uma coisa inteiramente diferente.

No tempo que eu tenho de carreira, o que eu observo é que a dicotomia é inteiramente falsa. Se existe o bom profissional, não há como o mesmo ser especialista ou generalista. Em um área como a nossa, onde a velocidade de transformação é enorme, medida em meses e semanas ao invés de décadas e anos, qualquer coisa que não seja a fusão dos dois conceitos é simplesmente impensável.

Ironicamente, algumas das raízes dessa separação refletem, ou talvez até tenham sua origem, na antiga disputa entre consultores e empreendedores–centrada, por sua vez, na igualmente inválida dicotomia entre engenheiros e artesãos. Como a maioria das comparações feitas para explicar o desenvolvimento de software, as analogias passam longe de explicar a realidade.

Recentemente, a popularização de frameworks e linguagens fora do mainstream como Rails/Ruby e Django/Python permitiu uma rara observação de como qualquer separação explícita geralmente é de aplicação limitada.

Um caso usual é tomar um profissional que trabalha com uma dessas tecnologias, que está tentando sair do comum em seu trabalho, seja como forma de criar uma nova carreira ou mudar sua empresa para obter uma carreira mais interessante, e por via dessa necessidade forja uma aliança entre áreas díspares como gerência, design, usabilidade, programação e outras (às vezes acumulando todas essas funções sobre si mesmo) e usar isso como exemplo de que o generalizado é melhor do que o especializado.

O mesmo erro é tomar uma disciplina como medicina e usar para ilustrar a outra proposição. Enquanto o exemplo do parágrafo anterior é um erro ao assumir que o mesmo é um exemplo de arte, o segundo é um erro em assumir que “engenharia” é uma metáfora inteiramente válida para o desenvolvimento de software.

A realidade é que, como em qualquer área, o nosso grau de proficiência é inteiramente dependente do âmbito do que estamos fazendo no momento e das circunstâncias transitórias em que esse trabalho se exprime. A especialização, nesse sentido, vem mais como força da acumulação de experiência do que de uma escolha explícita.

Um desenvolvedor é um engenheiro? Sim. É um artista? Também. Por extensão, a mesma pergunta pode ser feita para a dicotomia inicial. É um generalista? Sim. É um especialista? Também.

Isso é o que Dave Thomas fala quando explica sobre o Dreyfus model. Você vai de um lado do espectro ao outro e às vezes está em vários pontos em várias áreas. Quando isso é considerado, a dicotomia cai imediatamente por terra.

Em última instância, como a maioria das preocupações similares, o único resultado da eterna discussão é o gasto de tempo e calorias que poderiam ser postos para melhor uso em projetos mais interessantes. Na próxima vez que alguém quiser discutir isso com você, dê de ombros e ignore. Você não estará perdendo nada de valor para sua carreira futura.

Atualização: A propósito, acabaram de chamar a minha atenção que o Carlos Brando e o Fábio Akita fazem essencialmente o mesmo ponto no Rails Podcast Brasil #34. Desnecessário dizer, concordo.

Removendo as pedras

May 15th, 2008 § 2 comments § permalink

Hoje terminamos nosso quarto sprint. Foram duas semanas intensas e estamos bem satisfeitos com o resultado: não só a nossa velocidade (a referência de execução que o Scrum usa) aumentou significativamente (e ultrapassou as expectativas), como ainda tivemos tempo de experimentar com uma série de técnicas que tínhamos vontade de usar e estabelecemos vários utilitários para o time que ajudaram e vão ajudar ainda mais nos próximos sprints.

Nesse sprint decidimos usar pair-programming e ver qual a diferença isso fazia em nosso processo de desenvolvimento. Não só registramos um aumento de produtividade enorme como a qualidade do código gerado deu um salto impressionante. Um dos pontos fortes do Scrum são as medições realizadas que levam ao gerenciamento de expectativas proposto por metodologias ágeis.

O mais interessante, porém, foi constatar que a velocidade dos times é relativamente constante em relação aos outros, o que indica que pair-programming é uma técnica bem eficiente de disseminação de conhecimento. Como ainda tínhamos pessoas com um contato relativamente recente com Rails, eu acho que esse foi um dos principais fatores para que a equipe pudesse chegar a um ponto de familiarização rápida com a tecnologia sem onerar o desenvolvimento.

O melhor de tudo foi constatar que nenhum dos nossos temores em relação a tempo ou pressão se concretizou. Isso, pelo menos para mim, representa um dos maiores ganhos do processo: conseguir precisar entregas realísticas e cumprir essas estimativas. Que jogue a primeira pedra quem nunca reclamou de gerentes que passam prazos fora da realidade e que depois sofreu com a queda de qualidade. Combinar prazos satisfatórios a todas as partes e ainda conseguir qualidade é algo que nenhum outro tipo de processo exceto os ágeis é capaz de dar.

Obviamente, isso não implica que eu acho o Scrum perfeito. Há algumas coisas, que eu quero explorar aqui no futuro, que me incomodam. Apesar disso, a experiência tem sido bem interessante. E que venha mais um sprint.

O presente do presente

May 6th, 2008 § 4 comments § permalink

Há pouco mais de um mês e meio cheguei em São Paulo para o início de uma aventura. Foi uma mudança em todos os sentidos: de uma cidade grande para uma cidade enorme; de um mercado corporativo, fechado para um mercado genérico, aberto; de uma empresa pequena para uma empresa cujos alvos são muito maiores e mais amplos.

Ainda não concluí o processo de mudança, mas esse está sendo sem dúvida um dos períodos mais empolgantes da minha carreira. Trabalhar no Brasigo tem sido uma experiência fascinante em múltiplos níveis. Fazia tempo que a pergunta “e eu ainda sou pago para fazer isso?” não me ocorria.

Voltar a trabalhar em equipe foi uma das coisas que só percebi como tinha sentido falta até estar no meio da galera. Contribuir para um produto e aprender zilhões de coisas novas–não só profissionalmente, mas pessoalmente–é algo que só um ambiente muito bom pode proporcionar. Poder trabalhar e se divertir, em um local bacana de passar as horas de trabalho é algo que não tem preço. Tem o fato que a equipe não vê a hora em que vou soltar uma palavrão, mas isso é algo em que vai ter que rolar um desapontamento básico. :-)

Mas também, como não fica empolgado: Rails, Wii, Scrum, conversas cabeça no meio do trabalho, BDD, arquitetura de produtos legais, hard-core programming, experimentos malucos, chefe desencanado, e até mesmo a cidade que não para e onde sempre tem alguma coisa interessante para fazer.

Bem, deu para perceber que eu estou gostando da mudança, mesmo com as confusões de arrumar local para morar e trazer a família. E, para não perder a oportunidade, estamos procurando mais gente para a equipe. Gente boa é sempre bem-vinda. :-)

Não é à toa que chamam de sprint

April 25th, 2008 § 1 comment § permalink

Na próxima quarta, a nossa equipe termina o terceiro sprint do projeto em que estamos trabalhando. O trabalho essencial foi concluído hoje, mas ainda faltam ajustes para fechar e chegar a um sprint review positivo.

E, caramba, não é à toa que chamam as iterações de sprints. É claro que não há acaso na escolha porque a sensação durante a iteração é justamente a de um corredor. Quando chega o dia do review e as coisas se acalmam para uma reflexão, há virtualmente uma sensação física de fim de corrida.

E isso porque a equipe ainda está se ajustando. Eu não quero nem pensar em quando as coisas estiverem rodando em velocidade máxima–sem os empecilhos usuais de um início de projeto. Vai ser alucinante.

Um mês de São Paulo

April 23rd, 2008 § 8 comments § permalink

Um mês na metrópole:

  • Vinte e cinco dias com alergia
  • Chuva ou garoa virtualmente todos os dias
  • Duas vezes em engarrafamentos de mais de uma hora e meia
  • Uma única viagem de trem
  • Nenhuma viagem de metrô ainda
  • Nenhuma participação no #NoB
  • Nenhuma ida a um shopping
  • Uma única ida ao centro da cidade
  • Um terremoto! (boa lembrança do Luiz)

Conclusão: eu ainda estou fingindo que estou em Belo Horizonte, exceto pela alergia.

Scrum

April 3rd, 2008 § 1 comment § permalink

Hoje participei pela primeira vez de um fim de sprint Scrum. Como cheguei aqui e meio que caí de pára-quedas no processo, foi bem interessante participar dessa finalização e entender um pouco mais de como as coisas funcionam dentro dessa estratégia ágil.

O mais interessante foi perceber o quão flexível e adaptável o Scrum é. Como a equipe está se adaptando a uma série de novas situações, é fácil cair no modo de pensamento de que exceções podem ser ignoradas em favor dessa própria necessidade de adaptação. O que mais me surpreendeu durante as duas últimas semanas foi justamente a capacidade do Scrum de evitar exceções pela transformação das mesmas em oportunidades de ajustar o processo de maneira quase que transparente.

Sábado agora vou participar de um treinamento sobre o assunto e estou bem curioso para ver como o processo inteiro funciona. Essa é a primeira vez que eu tenho a oportunidade de fazer parte de uma equipe usando Scrum e depois de ler bastante e ver o pessoal falar muito sobre o assunto nos últimos meses tem sido bem proveitoso poder trabalhar na prática todos os benefícios já examinados teoricamente.

E que venham os próximos sprints!

Brasigo

April 1st, 2008 § 8 comments § permalink

Agora que já é oficial, posso contar mais sobre o que estou fazendo aqui em São Paulo, o que me levou a sair do meu cantinho mineiro e vir para a selva. O nome da empreitada, tocada pelo Manoel Lemos, é o Brasigo, que está começando como um serviço de perguntas e respostas de brasileiros para brasileiros mas que em breve será expandido para vários outros serviços de conteúdo gerado pelo usuário.

Como ainda estamos experimentando e arrumando algumas coisas, o sistema ainda está em beta fechado, mas convites serão distribuídos por vários locais em breve. Qualquer coisa sobre isso eu posto aqui.

É um projeto ambicioso em todos os sentidos e eu já estou me sentido bem desafiado com as coisas que temos que fazer para que tudo dê certo. O melhor é que eu faço parte de um equipe super-jóia que entende de tudo e que já está me ensinando um bom bocado sobre muitos assuntos que eu conhecia em leituras e experimentos mas que agora preciso colocar na prática. Estou a pouco mais que uma semana e meia aqui e já deu para fazer bastante coisa legal.

Como o Manoel disse, é uma aventura que está começando e estamos procurando mais gente para fazer parte da equipe. Se você tem interesse, dê uma passada no blog do Brasigo e faça contato. Ou seja apenas quer usar, deixe seu nome na lista de espera e logo sairão convites.

É isso. Espero ter reduzido um pouco do mistério. :-)

Where Am I?

You are currently browsing the Trabalho category at Superfície Reflexiva.