O futuro do presente

March 23rd, 2008 § 11 comments § permalink

Eu sei que muita gente ficou curiosa sobre o que me trouxe a São Paulo. Com as coisas se definindo, eu posso adiantar que vou trabalhar com o Manoel Lemos e o pessoal do BlogBlogs, mas não somente neste último.

O Manoel me convidou para olhar o que ele e sua galera estão fazendo e me perguntou se eu teria interesse em fazer parte da equipe. Eu vim, vi e gostei do que o pessoal estava aprontando. O resultado é que eu já estou em São Paulo e amanhã pegamos firme nos projetos novos que serão lançados nas próximas semanas e meses.

Quem já acompanha o blog já há algum tempo sabe que meu trabalho anterior na empresa envolvia basicamente .NET, com um tanto menor de Rails. Esse novo trabalho é todo sobre Rails com metodologias ágeis e um bocado de arquitetura sobre tópicos que estão se tornando freqüentes em qualquer discussão da Web 2.0.

Assim que eu tiver mais novidades, é claro, eu posto por aqui. Por enquanto, um obrigado especial ao TaQ que deu uma força por trás das cenas em vários aspectos.

A mala e a cuia

March 20th, 2008 § 4 comments § permalink

Cheguei em São Paulo. A cidade me recebeu bem com uma chuvarada boa, congestionamento e o cinza usual. Sem problemas. Aliás, é impressão minha ou até os relâmpagos são maiores aqui? :-)

Brincadeiras à parte, agora vem a hora do ajuste–e da procura de um local para ficar. Vou precisar de sorte, muita sorte.

Loucuras ocasionais

March 7th, 2008 § 3 comments § permalink

Dois textos interessantes sobre experimentos e sugestões para melhorar o ambiente de trabalho, satisfazer as pessoas que trabalham para você e economizar no geral:

Se você observar as sugestões, verá que nenhuma delas é excessiva e nem além do que a maioria das empresas um pouco mais estabelecidas podem fazer. Aqui no Brasil, entretanto, só de pensar em fazer alguma coisa assim já dá calafrios em praticamente todo e qualquer empresário, mesmo os que mexem com Internet.

Eu sempre fui um cara meio rebelde–em certos aspectos–nas empresas onde que trabalhei. Sempre procurei seguir a linha que o Joel Spolsky sugere de tentar transformar um ambiente menos do que o ideal por meios de pequenas ações. E já tive minhas fases de loucura que chocaram meu empregador mas muitas vezes serviram para dar um toque de que a coisa não estava indo bem.

Eu me lembro de alguns anos atrás quando trabalhava em uma empresa com poucos funcionários. Como o chefão ficava perto de todos nós, era bem fácil interagir e conversar sobre potenciais problemas.

Na empresa, tínhamos umas cadeiras bem confortáveis. Nenhum Aeron, mas o suficiente para não deixar ninguém com problemas de coluna para o resto da vida. Depois de alguns meses trabalhando lá, chegou a notícia de que a empresa iria se fundir com outra maior. Eu, contra o meu melhor julgamento, fiquei. O processo de fusão, alguns meses depois, foi até sem problemas. Houve um período inicial de ajuste, mas como as equipes eram fundamentalmente diferentes, no primeiro momento não houve nenhuma explosão ou migração.

Agora, em termos de ambiente, embora a nova sede fosse linda, o local era horrível. Baias, costas para a mesa dos novos chefes, e por aí vai. Eu, no primeiro dia, sem perguntar para ninguém, já me mudei para o local mais interessante do ambiente. Mas as cadeiras eram horríveis. As boas que tínhamos foram substituídas por genéricas que me deixaram dolorido em menos do que duas horas. Depois de uma semana assim, cansei. Conversei com o chefe anterior e a desculpa foi que não dava para comprar boas para todo mundo e o menor denominador teria que prevalecer.

Dois dias depois, a loucura baixou. Quase na hora do almoço, com as costas explodindo, eu me levantei, fui na sala de um dos chefes–não o meu–peguei uma das cadeiras de visitas chiques na frente dele e pus a minha horrorosa no lugar. O cara ficou me olhando sem saber o que dizer.

É claro que no dia seguinte fui chamado para uma reunião. O resultado é que algumas semanas depois, todo mundo recebeu cadeiras novas. Eu achei que ia ser despedido, mas nada. O pessoal acabou vendo que a coisa toda não doía e a produtividade de gente bem sentada era obviamente melhor.

Eu sai da empresa logo depois. O ambiente não era para mim, como eu já previa. Mas foi uma época engraçada. E ficou a lição: só trabalhe em um local que vai ouvir você. Ou trabalhe por conta própria. Foi o que eu fiz. Nunca mais trabalhei em nenhum lugar em que economia é mais importante que o funcionário.

Fim de carreira

February 10th, 2008 § 6 comments § permalink

Chegando nos trinta é inevitável pensar sobre a carreira e sobre os rumos futuros da vida profissional. Agora que eu estou envolvido plenamente na minha empresa, a carreira da empresa e a minha própria carreira estão meio que se misturando e pensar no futuro de uma implica necessariamente em relacionar os rumos prováveis que as duas seguirão.

Ironicamente, quando eu comecei a minha carreira de programação, eu não tinha a menor vontade, idéia ou planos para estar na posição em que estou, mais administrativa do que técnica no dia-a-dia. E, embora eu seja obrigado, por força daquilo que quero e pretendo fazer, a me desenvolver nesse sentido, eu fico me questionando sobre como isso impacta o meu futuro como programador.

Programação é uma coisa engraçada. É um das profissões que degradam com a idade. Não que o programador ou analista perca a sua velocidade ou proficiência. É mais uma percepção do mercado de que programadores jovens são mais capazes de produzir com a velocidade desejada e exercer as longas horas teoricamente necessárias. Obviamente, isso tudo é simplesmente um efeito do passo rápido da tecnologia e facilmente controlável em termos técnicos mas poucas empresas percebem ou aceitam isso.

A minha idéia, quando entrei no mercado, envolvia vinte cinco anos de carreira. Ou seja, começando com aproximadamente vinte anos (comecei mais cedo na verdade) e parando por volta dos quarenta em cinco. Não por não gostar de programar, mas por preferir uma estratégia de saída mais controlada. Embora me atualizar nunca tenha sido um problema e eu–pelo menos até onde percebo–continuo atualizado dentro da áreas nas quais trabalho, a minha vontade era uma finalização formal de carreira que partisse de mim.

Como ainda faltam quinze anos para isso–considerando que eu vou ultrapassar os vinte e cinco anos previstos–ainda há um bom tempo pela frente para decidir o que fazer com a empresa e com o impacto que isso vai ter nessa meta.

Trabalhar do outro lado da equação tem vantagens enormes, é claro, e isso pode significar uma coisa bem diferente daqui a alguns anos se os planos atuais continuarem a se desenrolar de maneira apropriada. No momento, entretanto, eu confesso que a carreira de Letras me parece mais agradável.

Enfim, por enquanto é uma questão de vamos ver no que dá. Mas eu ainda me surpreendo como as guinadas aparecem no caminho inesperadamente e você se vê em uma posição totalmente diferente da que esperava. No momento, não estou achando nada ruim as perguntas que eu estou sendo obrigado a me fazer.

Escolhendo um Controle de Versão Distribuído

August 25th, 2007 § 10 comments § permalink

Uma das tarefas de trabalho do último mês é mover os nossos repositórios para algum sistema distribuído. Principalmente pela questão de deslocamento, um sistema distribuído provavelmente resolverá as pendências que temos como empresa no desenvolvimento de projetos.

O problema agora é escolher um. A arena está polvilhando de sistemas diferentes, cada um com suas vantagens e desvantagens. Fica a dúvida entre continuar com o Subversion–com a camada do SVK–ou escolher algum outro que já foi criado para ser distribuído.

No momento, estou entre o Mercurial e o Bazaar. Para o tipo de repositório que eu tenho em mente–nada enorme como um kernel do Linux ou um Mozilla, os dois parecessem essencialmente iguais.

Eu considerei brevemente tanto Git como darcs, mas o suporte limitado dos dois ao Windows é algo que não posso deixar de considerar no momento.

Se alguém tiver dicas e comparações práticas, fiquem muito à vontade para postar aqui. Eu estou interessado principalmente no uso de respositórios dentro de outros repositórios, incluindo de ferramentas diferentes. Por exemplo, um repositório Subversion sob um diretório versionado em outra ferramenta, ou um repositório independente com outros repositórios sob o mesmo via symlinks e situações similares.

O que você queria saber

July 2nd, 2007 § 6 comments § permalink

Como mencionado aqui alguns dias atrás, o Eduardo Fiorezi me convidou para uma entrevista em seu Tudo que Quero Saber. Batemos um papo longo na sexta-feira passada e o resultado está no oitavo episódio do podcast.

Falamos de Rails, CakePHP, Seaside e um série de outras assuntos que estão mudando a área de desenvolvimento Web. Como eu temia, o sotaque mineirês ficou patente até para meus próprios ouvidos–eu não tinha idéia de que eu cortava tanto as palavras. De qualquer forma, espero que vocês gostem. :-)

Tão verdadeiro

April 12th, 2007 § 5 comments § permalink

Sabe, há dias em que isto é tão verdadeiro: Trapped in an Infinite Loop.

A história com fim

March 18th, 2007 § 11 comments § permalink

A história se repete vez após vez:

A empresa começa pequena, apenas um punhadinho de funcionários trabalhando duro para colocar o produto no ar, manter os sistemas funcionando, polir a entrega daquele sistema customizado e por aí vai. O clima de camaradagem é excelente ao longo dos rápidos meses seguintes, com todos dando o máximo por uma empresa à qual se sentem orgulhosos em pertencer. O tempo passa e o trabalho duro dá resultado. A empresa cresce, os clientes aumentam e mais e mais funcionários são contratados. A camaradagem continua forte, as horas extras são comuns mas sempre finalizadas por uma passagem no barzinho da esquina para uma relaxada no fim de noite.

Um belo dia de verão, com o sol forte brilhando lá fora e todo mundo andando em um ritmo um pouco mais lento, se preparando para o fim de semana, o gerente de desenvolvimento anuncia que a chefia está passando novas regras: práticas corporativas. Nada sério, ninguém precisa se preocupar. É só uma modernização para entrar em linha com as melhores práticas para empresas bem-sucedidas. A partir da próxima semana, todo mundo vai andar de crachá, chegar e sair no mesmo horário, nada de bermudas durante a semana porque o cliente pode aparecer e achar a atitude pouco profissional, nada de conversas via IM durante o trabalho porque isso atrapalha a produtividade, Internet só na hora do almoço. Nada sério.

Tudo parece normal na semana seguinte. As brincadeiras ainda acontecem, o pessoal trabalha com o mesmo entusiasmo, mas um observador externo notaria que o clima não é o mesmo. As semanas se passam e alguns funcionários deixam a empresa. Geralmente os mais velhos, que se lembram do tempo em que a empresa ainda era pequena. A chefia não se preocupa. O mercado está cheio de novos profissionais querendo trabalhar em uma empresa de sucesso e estes geralmente já se acostumam com as novas regras imediatamente. É claro que eles nunca ficam por muito tempo, mas treinar um funcionário é fácil, não? Duas semanas com outro e ele está rendendo a toda vapor.

Algum tempo depois a empresa nota que seus custos com funcionários estão ficando altos demais e que os sistemas estão apresentando uma taxa de problemas altíssima. Nada fica pronto no prazo, nada parece funcionar bem de primeira, mas esse é o custo de fazer negócios em uma empresa moderna.

Parece familiar? Essa é, essencialmente, a história que Peopleware conta, repetida vez após vez. Poucas companhias parecem seguir o caminho inverso, tendendo a manter o que as levou ao sucesso em primeiro lugar. Na maioria das áreas de produção, o moto é sempre “em time que está ganhando não se mexe”. Em tecnologia da informação, o praticado é o contrário. Existe talvez uma certa similaridade no fato de que a área está sempre em mudança e poder-se-ia pensar que isso incentiva tentativas constantes de reestruturação. Mas isso não é o correto porque a tendência é geralmente em reestruturar em uma direção que favorece o assim chamado padrão de mercado, seja quais forem as conseqüências para a equipe.

Peopleware tem um nome para esse conjunto de práticas destrutivas: equipicídio. As mudanças acima, por melhores que pareçam de um ponto de vista global para a empresa tem um efeito detrimental muito direto na equipe. E isso se aplica não só a “prender” os desenvolvedores em uma jaula de regras, mas a qualquer coisa que fixe a equipe dentro de um padrão estrito de comportamento.

Houve sempre uma discussão na área de desenvolvimento se o que fazemos é ciência (engenharia de software, ciência de computação) ou arte. A tendência, como os nomes anteriores indicam é sempre para a primeira embora a prática mostre claramente que não é possível desprezar os elementos da segunda. E Peopleware, talvez acidentalmente, demonstra a importância desse componente de arte. Há algo no processo que depende do que se poderia chamar a liberdade do artista, a necessidade de uma ambiente que deixe que o desenvolvedor se isole em um conjunto de circunstâncias favoráveis à sua produtividade que tem um certo quê da “inspiração” necessária ao artista.

Em última instância, a grande lição de Peopleware é que desenvolvimento é uma área sem paralelos entre as áreas de produção humana. É uma área mais artesanal e dependente de fatores que não são tão tratáveis pelos processos gerenciais comuns, por mais sofisticados que esses sejam para lidar com as situações normais de produção. Programadores e gerentes igualmente poderiam se beneficiar muito dessa lição. O risco é continuar sempre abaixo da média.

Profissionais insubstituíveis

March 11th, 2007 § 2 comments § permalink

Como tinha mencionado no final do meu comentário sobre o livro Peopleware, eu pretendia escrever um pouco mais sobre o mesmo. Demorou um pouco, mas consegui fazer isso.

Peopleware não é um livro muito conhecido aqui no Brasil, apesar de ter conseguido um status quase místico nos Estados Unidos e Europa. A maioria dos profissionais para os quais eu menciono o livro nem sequer ouviram falar sobre o mesmo, embora os assuntos dos quais ele trate tenham uma relação direta com seu dia-a-dia.

Depois de refletir um pouco, eu penso que a mensagem básica do livro é a seguinte: nenhum profissional realmente capacitado e motivo é substituível. O argumento básico dos autores é que profissionais intercambiáveis podem até fazer sentido em áreas de produção em massa, mas não para áreas onde o trabalho intelectual é dominante.

Isso é algo que vai contra a sabedoria adquirida da maioria dos gerentes e mesmo profissionais de tecnologia de informação. Fale sobre isso com um gerente qualquer e ele dirá que é exatamente o contrário, que o mercado possui profissionais em excesso, todos basicamente equivalentes e que ele pode substituir toda a sua equipe sem impactar a sua área.

Tendo trabalhado em várias firmas de tecnologia ao longo da minha carreira, e tendo prestado serviço para dezenas de outras, é fácil confirmar esse padrão. Raras são as empresas que consideram os seus funcionários um verdadeiro capital humano muito mais valioso para o negócio do que qualquer outra coisa dentro da empresa. A individualidade nas condições de trabalho é algo considerado abominável em um tempo de padronização de recursos–palavra, aliás, que eu considero extremamente desagradável quando aplicada a seres humanos, embora não seja tão hipócrita quanto chamar funcionários de colaboradores em uma tentativa banal de motivar um senso de equipe em um grupo de outra forma disperso.

Os resultados desta atitude de que cada profissional é descartável são óbvios: um turnover altíssimo, funcionários sem qualquer lealdade para com a empresa e custos enormes de treinamento. É de se admirar que tão poucos gerentes consigam fazer essa corelação.

Em essencial, Peopleware é um livro que procura educar os gerentes no sentido de maximizar as condições propícias para a produtividade dos profissionais de tecnologia de uma empresa. Um programador, lendo o livro, pode, por vezes, chegar a ficar ofendido com algumas das analogias que os autores fazem. Mas a lição é sutil: apelando para um certo senso de posição inata no assim chamado middle management, os resultados são duplos: programadores satisfeitos e resultados maiores para empresa. O reconhecimento disso é fundamental para as lições do livro.

O momento em que uma empresa reconhece que cada profissional em sua equipe é único e valioso–não por razões humanitárias, mas por um senso real de negócio–é o momento em que a mesma passa de uma mera diletante para uma força a ser reconhecida. É o momento em que a empresa deixa de fazer a pergunta de porque essa ou aquela empresa se tornaram forças dominantes de mercado e passar para a mesma posição.

Infelizmente para os profissionais, isso não é algo que provavelmente vai acontecer na empresa onde ele trabalha. As estatísticas apresentadas no livro são abismais nesse sentido, reconhecendo que pouquíssimas empresa possuem o mindset necessário para a transição. A maioria das empresas vai passar sua existência inteira batalhando por uma forma de subsistência mínima sem perceber aquilo que a está travando. E os profissionais que trabalham nessas empresas vão passar anos tentando entender o que está errado com suas carreiras.

Os autores do livro notam que os profissionais tendem a ter uma certa uniformidade nas empresas para as quais trabalham, ou seja, o ambiente de uma empresa tende a reduzir o profissional ao menor denominar comum, criando um abismo muito grande entre as melhores e as piores empresas do ramo. A curva normal de distribuição é muito puxada para a esquerda nesse caso.

A solução, eles apontam, é simples: a solução está nas mãos do profissional, que deve se recusar a trabalhar em condições que considera inadequadas. É claro que existem dezenas de circunstâncias que podem se estabelecer como empecilho, mas, em última instância, é realmente uma decisão pessoal, considerando a imobilidade inerente das empresas. No mais, o profissional pode tentar dar o livro de presente para o seu gerente e esperar pelo melhor.

Em próximas entradas, equipicídio e ambiente de trabalho.

Repouso merecido

February 27th, 2007 § 4 comments § permalink

Uma das poucas vantagens da vida de empresário é ter uma certa liberdade para fazer o seu próprio horário. Hoje, depois de mais uma viagem que me rendeu dezenas de horas sem dormir, decidi que amanhã tenho que dar uma parada ou corro o risco de desaparecer no éter, sofrer combustão espontânea ou qualquer coisa similar.

Aliás, para certamente deixar alguns com inveja, amanhã vou dedicar o dia à laboriosa tarefa de ver o máximo que conseguir da versão estendida da trilogia O Senhor dos Anéis. Doze horas de filme com quase três horas de novidades.

Where Am I?

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