Categories
Etc.

Que ferramentas você vai usar na hora de programar?

Há uns dois meses estava eu numa madrugada típica brincado de escrever códigos aleatórios, dessa vez usando o Google App Engine. Num determinado momento (acho que eu estava testando o versionamento de deploys – que é lindo demais) fiquei tão empolgado que soltei um daqueles posts meio aleatórios no Twitter dizendo: Google App Engine kicks serious ass!. Muita gente estranhou, incluindo o meu amigo Rodrigo Kumpera que prontamente respondeu: @gchapiewski I thought you used to work for yahoo!.

O mesmo “fenômeno” aconteceu no Yahoo! Open Hack Day que fizemos em São Paulo em março. Muitas pessoas acharam estranho e ficaram abismadas pelo fato do Yahoo! e seus funcionários mostrarem hacks que faziam uso de Google Maps, Twitter, Facebook e outros produtos que não são do Yahoo!.

Vamos lá, qual o problema? Sério mesmo, qual o problema? 🙂 Agora que eu trabalho no Yahoo! tenho que usar Y! Mail ao invés de Gmail? Ou então tenho que programar usando apenas YUI ao invés de jQuery? A política do Yahoo! é muito simples e na minha opinião bem coerente: a Internet está cheia de serviços excelentes e nós também temos alguns ótimos serviços. Porque não combinar o que há de melhor e fazer uma coisa melhor ainda?

Sempre falo isso e já até me falaram que parece meio “piegas”, mas é a pura verdade (e nunca é demais repetir): use a melhor ferramenta para resolver cada problema!

Esse modo de pensar é bem difícil nesse mercado. Muita gente acha que linguagens e tecnologias são como religiões, mas não é o que eu acredito. Não me importo de usar Java se for a melhor opção para resolver meus problemas – apesar de adorar programar em Ruby. Ou de aprender uma nova linguagem/ferramenta se ela se mostrar melhor para resolver alguma coisa (como quando eu precisei aprender ActionScript para fazer coisas legais para o Globo Vídeos – apesar de eu nunca ter tido simpatia por Flash).

Para pessoas da nossa área, acredito em um posicionamento profissional baseado em fatos e dados, não em preferências, traumas ou qualquer outro argumento sem lógica. No caso que comecei a contar no início desse post, eu estava programando um webservice REST em Python e o Google App Engine é o melhor lugar para ele estar hospedado. Aliás, eu usei Python já pensando em fazer o deploy lá, porque é super simples de usar, funciona muito bem e vai me liberar mais rápido para fazer outras coisas interessantes. É óbvio que todos temos nossas preferências de linguagens e tecnologias, mas o papel de um profissional é ser pragmático é fazer o que for mais adequado para cada situação.

Sempre que você está programando você precisa atingir um objetivo. Como eu ouvi falar esses dias, você “não senta e começa a programar igual a um cavalo”, você está desenvolvendo um produto ou alguma coisa maior e precisa ter isso em mente o tempo inteiro. Seu objetivo é entregar um software de qualidade, performático, bem testado, manutenível e que atenda ao seu cliente/objetivo. O seu objetivo não é usar as ferramentas da sua empresa ou as tecnologias que você gosta. Pense nisso.

Categories
Carreira Etc.

Plano de cargos e salários…

Me incomoda muito o fato de que desenvolvedores precisam virar gerentes ou coordenadores para ganhar mais.

<história>
Era uma vez um desenvolvedor muito bom e muito eficiente. Ao longo da sua carreira ele foi aprimorando suas habilidades e técnicas e se tornou um super desenvolvedor com um conhecimento técnico absurdo, uma vasta experiência em arquiteturas de software e poliglota em linguagens de programação. Nesse momento ele repara que já é um desenvolvedor sênior ++ na empresa que ele trabalha e por isso não tem como ganhar mais do que ele já ganha a não ser que ele vire gerente. Então, querendo ganhar mais, o excelente técnico que programava e resolvia problemas técnicos com eficiência é obrigado a virar um gerente, porque a empresa não dá para ele outra forma de evoluir financeiramente. O detalhe é que ele não tem nenhuma habilidade para gerir pessoas ou projetos, além de que ele odeia fazer isso. O que ele gostava mesmo era de programar, mas ele não teve escolha. Resumindo: a empresa trocou um excelente técnico por um péssimo gerente e ainda está pagando mais por isso!
<história/>

Já repararam como esse padrão se repete nas empresas brasileiras?

Se você nunca parou pra pensar nisso, pense agora: é muito difícil um programador ganhar mais do que um gerente e por sua vez é muito difícil um gerente ganhar mais que um diretor. A lógica do mercado é a velha lógica do plano de cargos e salários: quanto maior for o seu nível hierárquico, mais você ganha.

O problema é que isso não faz sentido. O argumento preferido das pessoas normalmente é que “os gerentes ganham mais porque tem mais responsabilidades”. Eu discordo totalmente. Por exemplo, um amigo me contou ontem que um funcionário da empresa onde ele trabalhava tirou do ar o sistema de transações financeiras de uma grande empresa, causando com isso algumas centenas de milhares de dólares de prejuizo em poucos minutos. Neste caso, um erro de um desenvolvedor provocou uma catástrofe maior do que 10 anos de erros de uma dezena de gerentes juntos. E então, quem é que tem mais responsabilidade nas mãos?

Outra coisa que me incomoda nos planos de cargos e salários são aquelas regras do tipo “gerentes ganham na faixa de R$ X a R$ Y“: se o cara ganha menos que X não pode ser gerente e se ganhar aumento para mais que Y tem que ser promovido a diretor. Isso também não faz sentido. Em todas as empresas que eu trabalhei conheci gerentes excepcionais e gerentes absurdamente idiotas. Por incrível que pareça os excepcionais com toda sua genialidade sempre ganhavam (e ganham) o mesmo que os idiotas, por causa do maldito plano de cargos e salários. Isso pra mim soa como gado: independente das suas características individuais, uma cabeça de gado custa o mesmo que outra.

Eu trabalho e já trabalhei com vários desenvolvedores de valor altissimo. Não falo isso pelo que eles ganham ou ganhavam, mas sim porque em várias situações eles criaram soluções que melhoraram ou mudaram completamente (para melhor) a forma que as pessoas trabalhavam. Algumas dessas coisas foram tão geniais que eu diria que o valor foi inestimável. Eu também já tirei meus coelhos da cartola e sei que eles foram de grande valor para as empresas que eu trabalhei.

Não deveriam ser esses tipos de coisas que determinam o quanto as pessoas devem ganhar?

Em empresas de software, onde é comum encontrar esse tipo de pessoas, deveria ser normal ter desenvolvedores altamente especializados com remunerações maiores que as de gerentes ou diretores, mas isso é tão improvável que eu diria que é praticamente impossível – pelo menos no Brasil. Já em empresas como Google, Yahoo e cia., isso é possível e normal. Na Globo.com temos alguns casos desse tipo, mas são excessões. Isso está em fase embrionária e é muito muito muito longe do que deveria ser.

Naquela história que eu contei no início não consigo pensar em um motivo sequer para a empresa não manter o funcionário como desenvolvedor e dar o aumento que ele merece. Esqueça o plano de cargos e salários e veja como faz sentido: isso seria muito melhor para a empresa – porque o funcionário iria agregar muito mais valor sendo desenvolvedor e iria ajudá-la a lucrar muito mais – e seria melhor para o desenvolvedor – porque ele iria fazer o que gosta, o que é mais experiente e o que estudou sua vida toda para fazer.

Até quando as empresas vão continuar colocando as pessoas certas nos lugares errados?

Categories
Engenharia de software Eventos

[JBoss World 2008] Max Ross: Hibernate Shards

JBoss World 2008 - Max Ross - Hibernate ShardsMax Ross, do Google, fez uma apresentação sobre o Hibernate Shards.

Desenvolvido em 6 meses como um “pet project” (projeto pessoal) usando 20% do tempo de 3 engenheiros, o Hibernate Shards foi lançado internamente no Google em dezembro de 2006 e depois doado para a JBoss em maio de 2007.

“Shard” é um termo que o pessoal do Google usa para falar de divisão/particionamento. O Hibernate Shards é um framework de persistência baseado no Hibernate, usado para dividir os dados entre vários bancos de dados diferentes, criando um particionamento horizontal das informações.

Resumidamente, o particionamento horizontal é usado quando você têm aplicações com bancos de dados monstruosamente grandes e você precisa distribuí-los em vários bancos de dados. Então, você tem várias instâncias de banco de dados diferentes, todas com o mesmo schema, e com os dados divididos entre elas. Quem gerencia onde está cada banco de dados e em qual “shard” (partição/bucket/o que você quiser) estão os dados é o Hibernate Shards, de forma transparente para a aplicação. O Shards pode usar qualquer banco de dados suportado pelo Hibernate (ele tira vantagem dos dialects).

Os criadores do projeto queriam que fosse fácil e natural para os usuários de Hibernate usá-lo, por isso ele usa vários conceitos familiares como, por exemplo, a ShardedSessionFactory, que implementa a interface SessionFactory. Eles tem uma ShardedSession, e por aí vai.

Apesar do Shards ser totalmente compatível com Hibernate do ponto de vista da aplicação (porque usa as mesmas interfaces), ele não suporta JPA, a implementação de Query ainda não funciona 100% e vários outros probleminhas e “gaps” em relação ao Hibernate…

Confesso que fiquei um pouco decepcionado, porque pelo que eu tinha conversado com o pessoal por aí, parecia que ele seria uma forma de ter um schema distribuído em vários bancos de dados diferentes, e isso ia resolver um problema gigante que tenho. Mas descobrí que isso que eu preciso é particionamento vertical. Perguntei para o Max se daria para fazer alguma adaptação e ele falou que até seria possível escrever um ShardStrategy que quebrasse um galho, mas eu teria muitos problemas maiores pra resolver.

Ao menos serviu para conhecer esses conceitos de banco de dados, que de certa forma eu conhecia mas não da maneira formal.

Categories
Internet Webservices

Web programável

Uma das coisas mais legais que surgiu nesses últimos tempos foi a web programável (a.k.a. programmable web).

A web programável não é uma tecnologia mas sim um conceito. Tecnologicamente falando não há nenhuma novidade. Todas as tecnologias que fazem parte da web programável já estão aí há um tempão: JavaScript, XML, webservices, HTTP, RSS, Atom… O grande barato disso é a idéia, que consiste em os sites disponibilizarem além de suas tradicionais interfaces web HTML, uma interface que possibilite que programas utilizem os serviços que o site oferece.

Isso possibilita por exemplo que você coloque um mapa do Google Maps no seu site, que você tenha um site de comércio eletrônico inteiro usando a infraestrutura de pagamento e shopping cart do PayPal, que você faça um sistema de backup armazenando os seus arquivos no sistema de arquivos S3 do Amazon, que você codifique vídeos em vários formatos utilizando a HeyWatch API e por aí vai… O limite é a imaginação.

Vários grandes players do mercado já disponibilizam suas APIs públicas como o eBay, Google, Yahoo, Skype, PayPal, Amazon, além de muitos outros.

O site ProgrammableWeb é um lugar legal para acompanhar as últimas APIs lançadas por aí. Na última semana com a adição das novas APIs do Google eles anunciaram que já tem mais de 500 APIs catalogadas!

Categories
Google Microsoft

Será que é tão bom assim trabalhar no Google?

Todo mundo já deve ter lido em vários lugares vários motivos para querer trabalhar no Google. Mas até agora ninguém havia escrito nada sobre as coisas ruins de se trabalhar lá.

Eis que acontece o seguinte: pelo que eu entendí, um fulano que trabalhava para a Microsoft saiu da empresa para montar uma startup. Essa startup foi comprada pelo Google e conseqüentemente o cara virou funcionário do Google. Depois de um tempo esse cara foi contratado novamente pela Microsoft. Quando ele foi re-contratado, ele falou sobre suas experiências no Google comparando com as experiências que teve na Microsoft.

Então o contratador resolveu divulgar para a empresa toda (Microsoft) a opinião do ex-Google, e um anônimo pegou este e-mail interno da Microsoft e criou um blog anônimo falando sobre algumas coisas não tão boas sobre o Google e que ninguém até agora havia comentado.

Será que é verdade mesmo?

Categories
Google Notícias

Podcast de desenvolvimento do Google!

O Google anunciou no seu blog de desenvolvimento Google Code Blog a criação de um Podcast sobre desenvolvimento de software!!!

Na semana passada mesmo estava falando com um amigo meu que estava com vontade de assinar um Podcast interessante sobre software e os caras me aparecem com isso! Show de bola, caiu como uma luva!

O tema do primeiro Podcast é o Google Guice, framework de injeção de dependência que eles criaram no início deste ano. Ficou muito legal, mais uma bola dentro do Google.