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.
10 replies on “Que ferramentas você vai usar na hora de programar?”
Por mais que pareça maniqueísta e chavão, os fins justificam os meios e não existe bala de prata. Nessa hora é que o profissional marca presença com sua flexibilidade e criatividade. Para isso é importante que o objetivo seja claro, tanto funcional quanto estratégico, para que a tecnologia esteja alinhada.
Trabalho numa empresa onde 95% das pessoas são focadas exclusivamente em .NET. Infelizmente, o fato de eu já ter trabalhado com C, Java ou PHP não me dão nenhum crédito extra nessa empresa (embora eu procure continuar a ser um profissional de tecnologias e não de linguagens). Sim, é provável que eu esteja no lugar errado, mas há outros desafios por aqui.
No geral, concordo que deveríamos usar sempre as melhores ferramentas para resolver cada problema, mas isso só se aplica nas empresas onde a maioria dos profissionais é bom/muito bom (normalmente acontece em empresas que utilizam tecnologia como fim e não como meio). Em empresas de serviços e seu grande contingente de profissionais médios e ruins (infelizmente não há bons profissionais pra todo mundo), é preciso definir uma série de burocracias/processos/procedimentos/normas e ser menos criativo é melhor para o todo.
Ou vai dizer que todos os dinossauros (os novos e os velhos) já pararam pra brincar com uma API, só porque é legal e faz bem?
É verdade, isso que eu disse tem mais a ver com empresas que utilizam tecnologia como fim e não como meio. E concordo também que nem todo mundo é apaixonado pelo que faz, principalmente nessas empresas “de serviço” como vc falou. Enfim, esse não é o tipo de lugar onde eu escolheria trabalhar.
GC,
Como eu digo (porque ouvi alguém dizendo pra mim), a melhor ferramenta é aquela que temos domínio.
Enquanto vamos obtendo o domínio das ferramentas “da casa”, nada impossibilita que possamos usar e até expandir o conhecimento nas ferramentas disponíveis no mercado.
Ótimo texto, como sempre.
Abraço
Emacs.
Ah, peraí, não li depois do título 😉
(j/k)
“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.” – Infelizmente muitas vezes a gente acaba se deixando levar por traumas 🙁
Como diria o nosso amigo Chad Fowler: “dont put all your eggs in the same basket”.
Toda vez que conheci novas ferramentas especialistas descobri o quão melhor poderia realizar o meu trabalho.
Outro ponto interessante é que essas novas ferramentas sempre conectam a novas ideias/forma de pensar!
Muito bom Guilherme, compartilho da mesma visão.
Sentimos sua falta lá no Agile Brazil. :.(
Abraço,
André Faria
Infelizmente o trabalho me “pregou uma peça” :-S
Bom antigamente eu odiava linguagens proprietárias, de um tempo para eu não vejo mais isso e sim a linguagem que melhor atende o meu cliente apresar de usar para os meus projeto linguagem que eu mais gosto (Python).
Como o GC mesmo falou linguagem não é religião.
Tenho o seguinte pensamento, não é a linguagem que faz o software e sim o programador a linguagem só ajuda na escrita.