Archive for the ‘Carreira’ Category

Mais 10 livros recomendados para desenvolvedores

Monday, March 3rd, 2014

Lá atrás em 2008 escrevi um post sobre 10 livros recomendados para desenvolvedores. Na época o post foi bastante popular e eu sempre pensei em escrever uma continuação, que acabei nunca fazendo.

Enfim, a hora chegou e aqui vai mais uma lista de outros 10 livros recomendados para desenvolvedores! Mas antes disso, alguns detalhes sobre como cheguei nessa lista:

Por que apenas 10 livros e não 20 ou 30? Não sei dizer – o primeiro post foi assim então vou continuar. :) O bom é que isso me deixa uma quantidade de livros mais do que suficiente para no futuro escrever vários posts!

Por que essa lista tem livros sobre “processos” como Kanban ou Lean? Não era para ser livros para desenvolvedores? Não tenho pretensão de escrever aqui uma lista definitiva e restrita a apenas um tópico, mas sim listar alguns livros que pessoalmente acho importantes para desenvolvedores de software e que me marcaram de alguma forma. Nosso trabalho não é só programar direito mas também saber se organizar (ou organizar um time) para que se entregue mais software, com mais qualidade e em tempo recorde, portanto acho esses tópicos super importantes.

Por que um livro sobre JavaScript e nenhum sobre Ruby, Python, Java ou qualquer outra? Tem alguma preferência de linguagens rolando aí? Não tem preferência não. O “Good Parts” é sensacional porquê me fez entender e respeitar JavaScript de um jeito completamente diferente. Não acredita? Leia o livro então! Acha que é perda de tempo? Eu acho que não, JavaScript hoje em dia é uma das linguagens mais populares e é indispensável conhecê-la bem para fazer desde um simples website como este blog até gigantes como Yahoo e Facebook.

Por que todos os livros são em inglês? 99% de toda a literatura relevante de tecnologia é em inglês e em muitos casos não há tradução disponível, portanto se você ainda não está craque, pule esta lista e vá urgentemente aprender inglês antes de mais nada! De todas as linguagens (de programação ou não) que você pode pensar em aprender, essa é provavelmente a mais importante.

Clean Code: A Handbook of Agile Software Craftsmanship Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
Test Driven Development: By Example Test Driven Development: By Example
Kent Beck
Growing Object-Oriented Software, Guided by Tests Growing Object-Oriented Software, Guided by Tests
Steve Freeman e Nat Pryce
Code Complete: A Practical Handbook of Software Construction Code Complete: A Practical Handbook of Software Construction
Steve McConnell
Working Effectively with Legacy Code Working Effectively with Legacy Code
Michael Feathers
JavaScript: The Good Parts JavaScript: The Good Parts
Douglas Crockford
Kanban: Successful Evolutionary Change for Your Technology Business Kanban: Successful Evolutionary Change for Your Technology Business
David J. Anderson
Lean Software Development: An Agile Toolkit Lean Software Development: An Agile Toolkit
Mary Poppendieck e Tom Poppendieck
The Lean Startup: How Today The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
Eric Ries
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
Jez Humble e David Farley

Estamos contratando no Yahoo! Brasil

Thursday, November 18th, 2010

Estamos contratando desenvolvedores para o Yahoo! Brasil!

Nosso time é responsável pelo desenvolvimento e manutenção do Yahoo! Meme. Para trabalhar conosco é imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil (especialmente XP), conhecer ferramentas de testes unitários, ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial. Como trabalhamos com web, também é necessário ter conhecimento em HTML, CSS e desenvolvimento de aplicações cross-browser.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos em C, C++, arquitetura de serviços, desenvolvimento de mashups, experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) e experiência em desenvolvimento para iPhone/iPad são bons diferenciais, porém não são requeridos.

Para estas posições é necessário saber inglês bem, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e vale refeição. Estamos localizados na Vila Olímpia em São Paulo. Geralmente contratamos pessoas de outros estados, mas desta vez infelizmente só estamos contratando pessoas de São Paulo/Capital. Update: Voltamos a contratar pessoas pessoas de outros estados e oferecemos auxílio para mudança (passagem, hospedagem, etc.).

Se você se encaixa neste perfil, envie seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. :)

Update: mais detalhes sobre a vaga (em inglês) na página de desenvolvedores do Meme.

Como anda o seu inglês?

Tuesday, October 5th, 2010

Há não muito tempo uma pessoa me procurou no IM para conversar sobre sua carreira. Ela me disse que no momento estava fazendo um curso de Java e me perguntou o que exatamente ela precisava para trabalhar numa empresa como o Yahoo!. Conversamos sobre algumas coisas até que perguntei sobre seu inglês. Para minha surpresa, ela disse que o curso de inglês iria ter que esperar um pouco porque naquele momento ela estava priorizando o curso de Java…

Se você está numa situação parecida, faça o seguinte: pare tudo que você está fazendo e vá aprender inglês. Sério, no nosso mercado é muito, mas muito mais importante do que você pode imaginar.

Em primeiro lugar, alguns dos melhores livros existentes só estão disponíveis em inglês. Poucos títulos são traduzidos e quando são levam alguns meses (ou anos) para tal, isso sem contar que as traduções muitas vezes são ruins. Por exemplo, o Domain-Driven Design do Eric Evans levou aproximadamente 5 anos para ser traduzido, o Patterns of Enterprise Application Architecture do Martin Fowler levou 4 anos, e por aí vai. Hoje em dia o tempo é menor que isso, mas mesmo assim é muito tempo. Ou seja, você não só vai ficar alguns meses (ou anos) para trás como também corre o risco de não ter acesso a uma boa parte do conteúdo mais relevante disponível.

Em segundo lugar, os grandes players de TI publicam seus blogs em inglês – assim como vários dos desenvolvedores mais influentes no mercado. De forma alguma estou desmerecendo os blogs em português (como esse aqui), mas grandes nomes como Robert Martin, Alistair Cockburn, Kent Beck – e mais algumas dezenas que eu poderia citar – escrevem em inglês. Isso sem contar as dúzias de blogs como o TechCrunch, Mashable, High Scalability ou até mesmo o xkcd. Se você não entende inglês você não poderá aproveitar todo esse conteúdo.

Em terceiro lugar, a maioria dos projetos Open Source relevantes são em inglês. Por exemplo, você está acompanhando o desenvolvimento do Node.js? Você já estudou Clojure? E o Rails 3? Linux? Python? Projetos da Apache Foundation? Se você já brincou com alguma dessas coisas (ou todas) certamente foi porque você sabe inglês. E você pode não somente usar essas coisas para desenvolver como também estudar os códigos para entender como funcionam ou contribuir com os projetos. Enfim, um mundo gigantesco de oportunidades.

Eu poderia dar mais um monte de motivos – como dizer que a maioria dos lugares mais relevantes que todo mundo gostaria de trabalhar vão exigir que você saiba inglês – mas acho que só isso já é mais do que suficiente. Inglês é uma das coisas mais essenciais para profissionais de desenvolvimento de software e você não pode ignorar isso. Corra atrás e aprenda inglês “pra ontem”, essa é sua prioridade número um!

O segredo para ser bem sucedido

Thursday, June 24th, 2010

Já me perguntaram mais de uma vez qual é o segredo para ser um bom desenvolvedor de software. Mas será mesmo que tem um segredo? Não sei ao certo, mas eu tenho meu palpite.

Existem várias coisas que te levam a ser um ótimo profissional. Por exemplo, estudar muito e constantemente é uma delas. Não consigo ver como um desenvolvedor poderia sobreviver por muito tempo nessa profissão sem se atualizar profissionalmente e conhecer as últimas novidades do mercado. Entender inglês seria outra delas, visto que a maioria do conteúdo relevante nesta área está apenas em inglês e vários dos melhores profissionais da área só se comunicam/escrevem nessa língua. Também é preciso ser pró-ativo, esforçado, saber trabalhar em equipe, etc, etc, etc. Mas até agora, tudo isso é bem óbvio.

Na minha opinião o segredo é a paixão.

Veja só, eu não acordo todo dia e vou para o trabalho só porque quero ganhar dinheiro ou porque sou obrigado a fazer isso. Não fico até as 5 horas da manhã hackeando as “entranhas” do Rhino com Java porque alguém na minha empresa pediu ou espera que eu faça isso. Não fico pensando em separar um tempinho por dia para ler as últimas novidades ou testar novas APIs porque sei que preciso me atualizar senão vou ficar para trás. Faço tudo isso e muito mais simplesmente porque adoro o que eu faço. Não é um grande esforço ou uma obrigação, é simplesmente natural.

No meu modo de ver as coisas, o sujeito que vai para o trabalho “bater ponto” e não gosta do que faz tem poucas chances de ser um ótimo profissional. Ele pode até conseguir fazer as coisas que lhe pedem, mas será apenas mais um cara mediano no meio de muitos outros.

Olhando para trás e vendo os profissionais mais bem qualificados com quem já trabalhei ou trabalho, grande parte deles faz(ia) a diferença porque são apaixonados pelo que fazem. Eles não apenas fazem o que precisam para concluir o seu trabalho, mas são aqueles que se dispõem a ir além de onde todos os outros vão, porque querem exceder as expectativas e querem ser os melhores. Além da minha experiência pessoal, essas pessoas bem sucedidas me fazem acreditar ainda mais que a paixão é um dos fatores mais importantes para o sucesso profissional.

Empenhe-se e dê o melhor de si que os frutos virão com o tempo. Trabalhe com o que você ama e não tem como dar errado, você será bem sucedido!

Yahoo! procura Ninjas

Thursday, January 14th, 2010

Estamos procurando Desenvolvedores e Scrum Masters Ninjas para integrarem nossa equipe no Yahoo!

Nosso time é o que chamamos de “Innovation Cell”, que é algo como uma incubadora de projetos, responsável por pesquisar e criar novos produtos. Atualmente nosso carro-chefe é o Yahoo! Meme, que foi inteiramente desenvolvido no Brasil no último ano e já está em vários outros países como Indonésia, Filipinas, México, Argentina e Taiwan.

Desenvolvedor Ninja

Os Desenvolvedores Ninja serão responsáveis pelo desenvolvimento e manutenção de aplicações web, em especial o Yahoo! Meme e outros aplicativos de integração com redes sociais. É imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer bem pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos de OpenSocial, desenvolvimento de mashups, arquitetura de serviços e experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) são diferenciais.

Scrum Master Ninja

O Scrum Master Ninja deverá ajudar o time de desenvolvimento a produzir no máximo da sua capacidade. Sua missão será organizar e facilitar os Sprint Plannings e Reviews, bem como Retrospectivas e o que mais for necessário para suportar os times de desenvolvimento e produto. Ele deverá identificar e remover impedimentos, ajudar o time a manter o foco mas dando todo o espaço e autonomia que ele precisa para se auto-organizar e gerenciar. É necessário já ter tido alguma experiência anterior relevante nesta posição.

Como o Yahoo! é uma empresa que em sua maioria ainda trabalha com métodos tradicionais de desenvolvimento, esta pessoa também será responsável por fazer com que o time esteja dentro das normas da empresa, gerando relatórios para as células de gerenciamento de projetos e fazendo algum trabalho burocrático de registro e comunicação de métricas.

Queremos um Scrum Master influente, que seja capaz de entender questões técnicas mesmo que em alto nível, que seja apaixonado por procurar maneiras de melhorar o processo de desenvolvimento, construtivo na hora de resolver problemas e solucionar conflitos e com muita vontade de descobrir novas maneiras de trabalhar com métodos ágeis. O Yahoo! é uma empresa que ainda está engatinhando em métodos ágeis e por isso precisamos de alguém com muita disposição e vontade de mudar a empresa!

Por último, experiência com XP, Lean Software Development, Kanban e diversos métodos ágeis são diferenciais.

Continuando…

Para ambas as posições é necessário inglês avançado, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e ticket refeição. Estamos localizados na Vila Olímpia em São Paulo. Vamos dar preferência para pessoas de São Paulo mas também vamos olhar com carinho currículos de pessoas de fora e daremos auxílio para mudança caso necessário.

Se você se encaixa em algum destes perfis, mande seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. :)

O que eu acho sobre faculdades de informática

Monday, May 18th, 2009

Para ser bem exato, esse post está em draft no meu Wordpress desde 9 de fevereiro de 2008 quando escrevi um post sobre entrevistas. Enrolei esse tempo todo pra escrever porque é um assunto bem delicado e controverso (e além disso porque eu sou um procrastinador mesmo). Eis que há alguns dias eu vejo dois posts sobre o assunto, um do Fabio Akita e outro do Paulino Michelazzo e, apesar de concordar totalmente com ambos os posts, quero contribuir também com meus 2 centavos. :)

Pra começar, não tem nada no mundo inteiro que descreva melhor o que acho sobre certificados quanto o que o Rodrigo Kumpera escreveu nesse post no GUJ:

“[...] eu dou valor a certificação sim. Quando vou comprar gado mordo no mercado dou preferencia por aquele que é certificado. Afinal, entre duas peças amorfas de picanha, aquela com um selo de qualidade deve ser melhor, não?”

Eu não tenho nenhum problema com faculdade em sí. Para muitas pessoas é muito útil e é uma ótima porta de entrada para o mercado de trabalho. No entanto eu acho imbecil que as empresas avaliem a competência e capacidade das pessoas apenas por um canudo ou certificado. É ingênuo achar que as pessoas são melhores ou piores porque fizeram ou não faculdade.

No meu caso, por exemplo, eu comecei a trabalhar com informática bem cedo quando estava no 2o. grau. Nessa época eu fazia um curso técnico em eletrônica e acabei indo fazer meu estágio obrigatório numa empresa de desenvolvimento de sites. Mesmo fazendo eletrônica eu já tinha descoberto minha vontade de trabalhar com software brincando com Visual Basic, e por isso a oportunidade de ir para essa empresa foi ótima. Quando terminei meu 2o. grau, estava indo de vento em popa no estágio e como eu sempre fui adiantado 1 ano no colégio (porque “pulei” uma série) resolvi esperar mais um ano para começar a faculdade. Nesse ano trabalhei quase que de graça todo dia das 09:00 as 19:00 com um monte de profissionais excelentes e em vários tipos de projeto, o que me fez ganhar uma experiência enorme.

Durante esse ano começei a fazer provas para algumas faculdades para que no ano seguinte já estivesse tudo pronto para iniciar minha graduação. Acabei passando para algumas faculdades (o que não é um grande feito porque até analfabetos conseguem passar para algumas faculdades). A que eu escolheria seria a UERJ, que era do lado da minha casa. Só que eu percebi que se fosse para lá não teria como continuar trabalhando no mesmo ritmo que eu estava, teria que diminui-lo drasticamente. Isso me deixou muito deprimido, porque eu amava fazer o que eu fazia no trabalho e não queria deixar aquilo por nada. Foi quando eu optei por ir para uma faculdade particular, que tinha uma carga horária e programa bem menos “puxados”.

Logo nas primeiras duas semanas eu queria me matar. Era um tédio ter que ouvir aulas de introdução a programação quando eu já estava estudando aquilo diariamente há mais de 2 anos. Mesmo assim eu continuei porque eu queria me formar, mas decidí fazer uma estratégia diferente. Ao invés de ir às aulas, eu tentava ir o mínimo possível (o suficiente para não repetir por faltas) e fazia vários acordos com todos os professores para abonarem minhas faltas. Enquanto isso eu estudava sobre todos os assuntos da faculdade em casa, onde eu conseguia estudar muito mais rápido, no meu ritmo. Mesmo assim, três semestres depois eu ainda estava no primeiro semestre, porque era tão legal ficar no trabalho e estudar em casa que eu acabei repetindo em quase todas as matérias por falta. Três vezes.

Depois disso rolou muita história, trabalhei em um monte de lugares e passei por um total de 4 faculdades. Uma delas (a que fiquei mais tempo) me deixava altamente frustrado por não acompanhar as mudanças do mercado. Em 2005, me incomodava muito o fato de saber que a última atualização da programação do curso tinha sido em 1999. Seis anos em informática é muita coisa. Eu me lembro das aulas de introdução a banco de dados onde o professor ainda achava que MySQL e PostgreSQL eram adequados para aplicacões “pequenas”, que open source não tinha futuro e da cara de interrogação dos professores quando eu falei que tinha acabado de conhecer um treco chamado “AJAX” e outro treco chamado “Ruby on Rails“. Talvez para outras profissões que não mudem tanto isso não seja da mesma forma. Minha mãe que é formada em ciências contábeis e administração de empresas em duas boas faculdades aproveita esse conhecimento até hoje. Mas quando falamos de informática e desenvolvimento de software a história é outra.

Passei uma porção de anos vendo como isso tudo funciona, o que as pessoas estudam e como algumas delas se formam nas “coxas”. Por outro lado ví alguns amigos se formarem na Unicamp e irem fazer estágio na Bélgica, outros amigos desenvolvendo jogos no laboratório de programação da UFRJ e nessas mesmas duas faculdades outros amigos eram uns “enganadores” e passavam nas matérias as custas de muita “reza braba”. Uma outra vez trabalhei com um cara que tinha se formado na UFRJ e estava começando uma pós-graduação na PUC e ele não produzia mais do que 30 minutos se não tivesse alguém de babá do lado. Pior ainda que isso tudo é a história bem conhecida entre os alunos da PUC de uma menina de lá que uma vez passou de ano “favorecendo professores sexualmente” mas por outro lado conheço excelentes profissionais que se graduaram lá.

O “x” da questão é o seguinte: não dá pra avaliar as pessoas somente pelos seus diplomas e certificados! Como eu acabei de mostrar, existem casos e casos. Fazendo uma conta rápida cheguei à conclusão que das 20 pessoas mais brilhantes que já trabalharam comigo em toda minha vida, 50% sequer eram formadas, cerca de 20% formados na pior faculdade do Rio e 30% em “faculdades de ponta”, como adoram dizer as consultorias de RH. Todas essas pessoas eram (são ainda) muito acima da média, são pessoas brilhantes, muito inteligentes e que, assim como eu, estudam diariamente desde que perceberam que é assim que se faz a diferença – independente de terem feito faculdade ou não.

Por isso que quando eu contrato pessoas tento conhecer o máximo possível além da sua fachada (que é o currículo). Mais recentemente tenho tentado chamar as pessoas para passarem o dia aqui programando em par com várias pessoas, participando de reuniões e discutindo com outros desenvolvedores em situações reais. Depois disso saber se a pessoa fez ou não graduação, mestrado ou doutorado é completamente irrelevante. Aliás, acabei de me tocar que eu não faço a menor idéia se as últimas duas pessoas contratadas são formadas ou não, porque nem me lembro de ter lido seus currículos. Ao invés disso, elas passaram dois dias aqui, contaram toda a sua vida, mostraram código, programaram em par comigo, saimos pra almoçar e falar besteira e eles se deram muito bem com o pessoal dos times de desenvolvimento.

Para finalizar, de forma alguma estou aconselhando que as pessoas não façam faculdade, muito pelo contrário. Eu sempre aconselho que se estude o máximo possível. Para alguém que nunca teve contato com nada nesse mundo de informática talvez seja interessante. Para alguém que tem sede de aprender e estuda numa boa faculdade com bons professores que vão te levar além do que está na sala de aula, é sensacional (eu já tive professores assim e a experiência é incrível). Porém, se você está lá pelo canudo, esquece: você já é um fracasso. Se você quer se encher de canudos/certificados/selos mas ainda não colocou na cabeça que você vai precisar estudar todo dia para ser algúem nesse mercado de informática, você está perdido.

*Update: Outros posts sobre este assunto (de leitura obrigatória):

Plano de cargos e salários…

Sunday, February 15th, 2009

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?

Portfólio intelectual

Saturday, April 12th, 2008

A discussão sobre livros e carreira foi acesa novamente, especialmente depois que escreví um post com indicações de alguns livros importantes para desenvolvedores. Recebí uma meia dúzia de e-mails perguntando sobre outros tipos de coisas que podem ser feitas para alavancar a carreira e até mesmo perguntando se existe algum remédio para ficar acordado e poder estudar mais :)

Não tem muito segredo, basta você encarar sua vida profissional da forma apropriada. Existem várias formas de fazer isso, e uma delas é pensar que você tem que manter o seu portfólio intelectual. No livro The Pragmatic Programmer, Dave Thomas e Andy Hunt apresentam esse conceito interessante que tenho usado há algum tempo:

Your Knowledge Portfolio

Your knowledge and experience are your most important professional assets. Unfortunately, they’re expiring assets. An expiring asset is something whose value diminishes over time. Examples include a warehouse full of bananas and a ticket to a ball game. Your knowledge becomes out of date as new techniques, languages, and environments are developed. Changing market forces may render your experience obsolete or irrelevant. Given the speed at which Web-years fly by, this can happen pretty quickly.

As the value of your knowledge declines, so does your value to your company or client. We want to prevent this from ever happening.

We like to think of all the facts programmers know about computing, the application domains they work in, and all their experience as their Knowledge Portfolios. Managing a knowledge portfolio is very similar to managing a financial portfolio:

  • 1. Serious investors invest regularly—as a habit.
  • 2. Diversification is the key to long-term success.
  • 3. Smart investors balance their portfolios between conservative and high-risk, high-reward investments.
  • 4. Investors try to buy low and sell high for maximum return.
  • 5. Portfolios should be reviewed and rebalanced periodically.

To be successful in your career, you must manage your knowledge portfolio using these same guidelines.

Building Your Portfolio

  • Invest regularly. Just as in financial investing, you must invest in your knowledge portfolio regularly. Even if it’s just a small amount, the habit itself is as important as the sums. A few sample goals are listed in the next section.
  • Diversify. The more different things you know, the more valuable you are. As a baseline, you need to know the ins and outs of the particular technology you are working with currently. But don’t stop there. The face of computing changes rapidly—hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better you will be able to adjust to change.
  • Manage risk. Technology exists along a spectrum from risky, potentially high-reward to low-risk, low-reward standards. It’s not a good idea to invest all of your money in high-risk stocks that might collapse suddenly, nor should you invest all of it conservatively and miss out on possible opportunities. Don’t put all your technical eggs in one basket.
  • Buy low, sell high. Learning an emerging technology before it becomes popular can be just as hard as finding an undervalued stock, but the payoff can be just as rewarding. Learning Java when it first came out may have been risky, but it paid off handsomely for the early adopters who are now at the top of that field.
  • Review and rebalance. This is a very dynamic industry. That hot technology you started investigating last month might be stone cold by now. Maybe you need to brush up on that database technology that you haven’t used in a while. Or perhaps you could be better positioned for that new job opening if you tried out that other language….

Of all these guidelines, the most important one is the simplest to do:

Tip: Invest Regularly in Your Knowledge Portfolio

Goals

Now that you have some guidelines on what and when to add to your knowledge portfolio, what’s the best way to go about acquiring intellectual capital with which to fund your portfolio? Here are a few suggestions.

  • Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet.
  • Read a technical book each quarter. Bookstores are full of technical books on interesting topics related to your current project. Once you’re in the habit, read a book a month. After you’ve mastered the technologies you’re currently using, branch out and study some that don’t relate to your project.
  • Read nontechnical books, too. It is important to remember that computers are used by people—people whose needs you are trying to satisfy. Don’t forget the human side of the equation.
  • Take classes. Look for interesting courses at your local community college or university, or perhaps at the next trade show that comes to town.
  • Participate in local user groups. Don’t just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.
  • Experiment with different environments. If you’ve worked only in Windows, play with Unix at home (the freely available Linux is perfect for this). If you’ve used only makefiles and an editor, try an IDE, and vice versa.
  • Stay current. Subscribe to trade magazines and other journals (see page 262 for recommendations). Choose some that cover technology different from that of your current project.
  • Get wired. Want to know the ins and outs of a new language or other technology? Newsgroups are a great way to find out what experiences other people are having with it, the particular jargon they use, and so on. Surf the Web for papers, commercial sites, and any other sources of information you can find.

It’s important to continue investing. Once you feel comfortable with some new language or bit of technology, move on. Learn another one.

It doesn’t matter whether you ever use any of these technologies on a project, or even whether you put them on your resume. The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things. The cross-pollination of ideas is important; try to apply the lessons you’ve learned to your current project. Even if your project doesn’t use that technology, perhaps you can borrow some ideas. Get familiar with object orientation, for instance, and you’ll write plain C programs differently.

Opportunities for Learning

So you’re reading voraciously, you’re on top of all the latest breaking developments in your field (not an easy thing to do), and somebody asks you a question. You don’t have the faintest idea what the answer is, and freely admit as much.

Don’t let it stop there. Take it as a personal challenge to find the answer. Ask a guru. (If you don’t have a guru in your office, you should be able to find one on the Internet: see the box on on the facing page.) Search the Web. Go to the library. In this era of the Web, many people seem to have forgotten about real live libraries filled with research material and staff.

If you can’t find the answer yourself, find out who can. Don’t let it rest. Talking to other people will help build your personal network, and you may surprise yourself by finding solutions to other, unrelated problems along the way. And that old portfolio just keeps getting bigger….

All of this reading and researching takes time, and time is already in short supply. So you need to plan ahead. Always have something to read in an otherwise dead moment. Time spent waiting for doctors and dentists can be a great opportunity to catch up on your reading—but be sure to bring your own magazine with you, or you might find yourself thumbing through a dog-eared 1973 article about Papua New Guinea.

Critical Thinking

The last important point is to think critically about what you read and hear. You need to ensure that the knowledge in your portfolio is accurate and unswayed by either vendor or media hype. Beware of the zealots who insist that their dogma provides the only answer—it may or may not be applicable to you and your project.

Never underestimate the power of commercialism. Just because a Web search engine lists a hit first doesn’t mean that it’s the best match; the content provider can pay to get top billing. Just because a bookstore features a book prominently doesn’t mean it’s a good book, or even popular; they may have been paid to place it there.

Tip: Critically Analyze What You Read and Hear

Unfortunately, there are very few simple answers anymore. But with your extensive portfolio, and by applying some critical analysis to the torrent of technical publications you will read, you can understand the complex answers.

Challenges

  • Start learning a new language this week. Always programmed in C++? Try Smalltalk or Squeak. Doing Java? Try Eiffel or TOM.
  • Start reading a new book (but finish this one first’) If you are doing very detailed implementation and coding, read a book on design and architecture. If you are doing high-level design, read a book on coding techniques.
  • Get out and talk technology with people who aren’t Involved in your current project, or who don’t work for the same company. Network in your company cafeteria, or maybe seek out fellow enthusiasts at a local user’s group meeting.

Esse livro é muito bom e tem várias outras dicas importantes como essa que te fazem abrir a cabeça e pensar de formas diferentes. Se você ainda não tem, vá na Amazon agora e compre! (eu não estou ganhando comissão por isso)

10 livros recomendados para desenvolvedores

Thursday, March 27th, 2008

No início do ano escreví um post sobre a importância de nós, desenvolvedores de software, lermos livros, que rendeu boas discussões. Depois disso recebí algumas mensagens perguntando quais são os livros que considero mais importantes para um desenvolvedor.

Bom, essa pergunta é complicada de responder. Primeiro porque eu ainda não lí todos os livros que deveria, e segundo porque cada pessoa tem seu gosto particular por tecnologias, processos, frutas e etc.

Então, resolví criar a lista dos 10 livros que eu particularmente mais gosto e que recomendo fortemente para qualquer desenvolvedor. Estes livros são alguns dos que mais me influenciaram a melhorar minha forma de trabalhar e programar. Além disso, coloquei link para os sites, blogs ou páginas de informações dos autores, caso alguém ainda não tenha:

Agile Software Development, Principles, Patterns, and Practices Agile Software Development, Principles, Patterns, and Practices
Robert C. Martin
Agile Software Development with SCRUM Agile Software Development with SCRUM
Ken Schwaber e Mike Beedle
Design Patterns: Elements of Reusable Object-Oriented Software Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson e John M. Vlissides
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Extreme Programming Explained: Embrace Change (2nd Edition) Extreme Programming Explained: Embrace Change (2nd Edition)
Kent Beck e Cynthia Andres
Introduction to Algorithms Introduction to Algorithms
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest e Clifford Stein
The Mythical Man-Month: Essays on Software Engineering The Mythical Man-Month: Essays on Software Engineering
Frederick P. Brooks
Patterns of Enterprise Application Architecture Patterns of Enterprise Application Architecture
Martin Fowler
Peopleware: Productive Projects and Teams Peopleware: Productive Projects and Teams
Tom DeMarco e Timothy Lister
The Pragmatic Programmer: From Journeyman to Master The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt e David Thomas

Infelizmente todos os livros são em inglês e nem sei se existe tradução. Se você não souber inglês, matricule-se urgentemente em algum curso porque saber inglês nesta área é muito importante!

Convido vocês a também fazerem suas listas e compatilharem seus livros preferidos :)

Você tem que ler os livros!

Tuesday, January 22nd, 2008

Nos últimos meses já ouví algumas pessoas dizerem que não têm costume de ler livros, ou questionarem a necessidade de lê-los, já que há uma abundância de fontes de leitura por aí na Internet.

Hoje em dia realmente temos milhares de formas de nos informarmos. Me lembro de ter lido em algum lugar que a Internet possui mais de 250 milhões de sites. Se somarmos isso tudo, realmente tem muita informação. Justamente por isso, faz parte da minha rotina diária dar uma navegada no Google Reader, onde tenho cadastrados os feeds de mais de 300 sites e blogs de diversos assuntos que acho interessantes. Essa é basicamente a minha principal fonte de informação diária e é a melhor maneira de me manter atualizado com tantas novidades surgindo por aí todo dia.

Porém, em alguns casos, para aprender e entender certos assuntos, você precisa ler os livros. Não tem jeito! Por exemplo, como é que um desenvolvedor de software pode dizer que entende Domain-Driven Design sem ter lido o livro do Eric Evans ou pelo menos o DDD Quickly? Ou então dizer que sabe sobre metodologias ágeis sem ter lido pelo menos um livro do Ken Schwaber, Kent Beck ou Uncle Bob? Como é que alguém pode se dizer Arquiteto de Software Sênior++ Certified ™ sem ter visto o Patterns of Enterprise Application Architecture e o GoF? Eu respondo: não tem como. Simplesmente não tem jeito, você precisa ler os livros.

Hoje mesmo o Patrick Kua, que trabalha na ThoughtWorks, escreveu um post sobre os livros que ele considera essenciais para saber sobre metodologias ágeis. Ele acredita que você precisa ler 11 livros, O.N.Z.E. livros, para entender sobre o assunto, e ainda completa: “Of course, simply reading the books won’t mean that you’re an expert [...] though it’ll definitely help in providing context, advice or skills that you need to practice.”. Ou seja, mesmo lendo todos esses livros, ainda há muita coisa para aprender… E estamos falando sobre um assunto apenas.

Assim como os blogs e os sites, os livros são uma fonte de informação importantíssima e necessária. Se você quer trabalhar com tecnologia e desenvolvimento de software não tem jeito: tem que ler e ler muito!