Sentado num quarto de hotel, longe de casa, com a televisão passando imagens sem som, uma tela de computador cheia de parênteses na minha frente, sentindo uma imensa felicidade por ganhar a vida fazendo aquilo que escolhi, e principalmente, por (re)descobrir o quão divertido e empolgante pode ser esse caminho.

Meu filho, de um ano e meio, me ensina todo dia a ser curioso, a não parar de aprender, me relembra como é bom descobrir o mundo, entender como as coisas funcionam, aprender com os erros. Vejo nele a alegria de perceber pequenas coisas, de querer mais, por mais que isso algumas vezes incomode quem está ao redor.

As pessoas costumam crescer, buscam conforto, buscam um canto macio e aquecido para encostar, um cubículo para se sentar todo dia fazendo o mesmo trabalha de sempre, sem aprender, sem questionar, muitas vezes em entender, ouvindo e dizendo as mesmas coisas todos os dias. As pessoas crescem e perdem aquela alegria da criança ao aprender, se esquecem como é bom entender, perguntar o porquê, colocar a mão onde não é para mexer.

Eu não consigo entender como alguém escolhe se tornar um programador, um desenvolvedor, e não alimenta a curiosidade, não alimenta a vontade de aprender. É pelo salário, já me disseram. Pode ser, mas garanto que estão perdendo o melhor da brincadeira. Eles vão conseguir uma vida confortável, comprometer o orçamento com o que quer seja e logo o lado financeiro não será mais suficiente. Surgirá uma sensação de vazio, de inutilidade, de frustração por trabalhar com algo que não traz nenhuma satisfação, por desperdiçar metade do dia numa vida vazia, metade da vida numa função sem atrativos.

Com a participação de alguns amigos, passamos a compartilhar experiências, conhecimento e novidades com os demais colegas de trabalho. Existem sempre aqueles que nunca estão interessados, como queiram. Mas existem aqueles que logo se tornam sedentos por conhecimento, por novidades, que começam a compartilhar o que sabem, o que descobriram, e isso começa a formar um círculo virtuoso. Essas pessoas passam a relembrar daquela alegria infantil de aprender e entender o mundo, e começam a contaminar as pessoas ao redor, aumentando esse círculo. O ambiente de trabalho passa a ter um clima melhor, apesar de tudo; as pessoas passam a se respeitar mais, a se conhecer melhor, a nutrir admiração uns pelos outros. Obrigado a todos por isso.

Não deixe aquela curiosidade infantil e a vontade de descobrir o mundo morrerem em você. Vale todo o esforço, eu posso garantir.

A cilada típica em ambientes corporativos:

E agora, quem poderá nos ajudar?

Infelizmente, e-mails e reuniões, mesmo em ambientes ágeis, são inevitáveis, e na maioria das situações, tóxicos. Reuniões de 2 horas de duração ou 50 emails diários são sinais claros de que as coisas não andam muito bem.

Atitudes ágeis tendem a evitar “enrolações” que desviem o foco da equipe ou desacelerem a produtividade. A seguir, algumas estratégias e dicas que podemos aplicar para quebrar um pouco essas práticas corporativas cascateiras, ajudar a manter o foco da equipe e produzir mais.

Reuniões

Simplesmente evite reuniões, com temor! Tente resolver os problemas com conversas cara-a-cara, na sua mesa mesmo. Se precisar discutir um assunto por mais de 5 minutos, convide as pessoas envolvidas para um cafézinho, de preferência em pé.

Se não puder evitar a reunião, defina com antecipação: 1) o(s) objetivo(s) e 2) a duração máxima. Limite qualquer reunião a no máximo 5 participantes e duração de 15 minutos. Acredite: é suficiente.

Se um problema for muito complexo para ser resolvido em uma reunião de 15 minutos, quebre o problema em problemas menores, e discuta um de cada vez. Os próximos problemas devem ser discutidos somente quando o problema anterior for resolvido.

Antes de começar qualquer discussão, faça com que todos presentes tomem ciência dos objetivos e da duração máxima. Assim que alcançarem os objetivos ou o tempo se esgotar, termine a discussão imediatamente! Não dê oportunidade para que alguém inicie uma nova discussão desnecessária.

Diga não! Em certas ocasiões, é a melhor resposta. Se você não é o responsável por determinado problema, desconhece ou não pode ajudar plenamente, simplesmente diga “não, obrigado”.

E-mails

Alguns problemas podem ser resolvidos com um simples e-mail, é verdade. A única regra que devemos seguir é a do “passa, repassa ou paga”. Não deixe os e-mails passarem das tréplicas. Se depois de 3 e-mails o problema ainda não foi resolvido, convide os envolvidos para tomar um cafezinho.

E-mail não é chat. O time deve conversar cara-a-cara, incluindo os clientes. Trocar mais do que 5 e-mails diários entre a equipe é um mau sinal. Se não puder falar pessoalmente, use o telefone ou skype ao invés de mandar um e-mail que pode ser facilmente ignorado pelo destinatário.

E-mail não é documentação. Não é preciso enviar um e-mail a cada decisão tomada pelo cliente ou pelo time. Se algo importante foi decidido, converse pessoalmente com os envolvidos.

Finalmente, use o e-mail com sabedoria, para trocar informações importantes e relevantes entre a equipe. E-mail não deve ser regra, e sim um suporte para comunicação entre a equipe. Lembre-se: quanto mais e-mails você enviar, maior a chance de ser ignorado.

Resumo

Reuniões e e-mails são tóxicos. Evite-os! Se não puder evitar, use-os com sabedoria.

Se identificou com alguma situação? Acha que essas dicas “choveram no molhado”? Concorda, discorda, quer complementar algo? Use os comentários.

Reflexão: quais dessas práticas você aplica no seu cotidiano profissional?

Um amigo escreveu isso há algum tempo e tive a oportunidade de reler hoje.

Sometimes things go wrong: hardware is not acting as expected, the API you rely on is not reliable, some vital information is missing. But you don’t care, as you are a hero, a tough Charles Bronson-like guy that will accomplish the mission no matter what.

Another project is saved? Maybe. But someone made a very stupid choice and will pay for it. And I’m talking about you, Bruce Lee.

In six months nobody will remember the adversities you’ve been through. The sleepless nights. The weird bugs. The managers on you back, asking for status reports every five minutes. But something will linger: your name in the source code. It will be there in the SCM, ready to prove that you are a lousy coder and committed buggy/ugly code.

So, next time you find yourself in this kind of situation, take a deep breath and raise the red flag. Share the problem. It’s not fair to chain yourself to something bad just to show that you are tough.

Eu deveria ter levado esse texto impresso para a Venezuela.

Update em 02/05:
Igor Musardo repostou esse post, e adicionou um excelente vídeo da palestra do DHH na Rails Conf 2009. Recomendo que assistam.

Em um mega resumo, trabalhando muito no Sitefique.me. Acho que este post é uma maneira de mostrar porque está difícil de postar coisas novas, e ao mesmo tempo, oferecer algum conteúdo para nossos leitores.

Hoje em dia, com frameworks “modernos”, é relativamente rápido fazer um site e colocá-lo no ar. O difícil é escrever para o seu público alvo.

Quando se faz uma gem ou lib, o seu público alvo é o desenvolvedor e isto facilita muito, pois você sabe o que ele busca e espera do seu “produto”. Agora, lançar um produto onde o público alvo é o usuário iniciante/intermediário, muda muito as coisas.

Sem entrar em mais detalhes, preparei uma compilação do que venho lendo, estudando e usando, para ajudar nesta nova jornada de montar um produto do zero. São assuntos profundos, que toco de forma superficial (ficou legal né! ). Espero que aproveitem!

Brainstorm

Apesar de parecer, não é simples escrever. Montar textos como o lançamento e roadmap, é muito custoso para meros desenvolvedores como nós. Estamos usando o Google Docs para trabalhar remotamente e simultaneamente com muito êxito!

Empreendedorismo

Recomendo o blog http://www.saiadolugar.com.br
Muito boa esta apresentação, vale a pena conferir:
Guy Kawasaki – A arte do começo (link direto aqui)

Fora isto, tem uma pá de livro sobre o assunto. Os clássicos modernos da 37signals, Getting Real e Rework.

Controle de Tarefas

Somos em dois desenvolvedores e só! O nosso quadro de tarefas está no lessprojects.com (que por enquanto é de graça). É incrível como os caras são pragmáticos. Este foi um achado do Panachi.

Frontend, Design, layout e cia.

Este é um campo que é necessário ter mindset diferente. Até 2002, me virava muito bem com os layouts “divless”, ou melhor, usando table mesmo (shame on me). Depois da onda tableless, sempre tive dificuldade em desenvolver o frontend (e também nunca fiz muita questão). Agora chegou a hora, e tenho que estudar. É muito importante ter ajuda de quem manja muito! Diego, Gus e Babi. Valeu!

Mail marketing

Enviar e-mail é muito simples. Agora, enviar e-mail com layout legal, com informação relevante, sem ser barrado como spam e renderizar no máximo de webmails e clientes desktop é muito difícil! Encontrei ótimos materiais sobre o assunto:

• Email design guidelines
• 16 Técnicas para Otimizar a Entrega do Email Marketing
• Email Standards Project – Achei animal o objetivo do site. Eles rodam um acid test para uma leva de webmails e clients desktop, e de quebra você ganha uma lista de quem suporta o que ao renderizar html do seu e-mail.

Private Server

É onde hospedamos o produto, repositórios e o que precisar. O ponto é que você vai precisar! Estamos usando o http://webbynode.com. Não tive problemas até hoje. Uma maravilha poder logar via ssh e fazer miséria.

Foco

Se tiver paciência (acho que o post já é um teste!) leia: http://howtogetfocused.com/chapters/how-to-get-things-done-like-a-zen-master

Comentem. Me avisem se este tipo de post é chatão ou legal.

Valeu!

Imagine que você receba a seguinte especificação:

Pegue uma folha de papel A4. Sob a mesa, dobre-a ao meio. Coloque a folha dobrada sobre a mesa.

A especificação parece clara e simples, mas aposto que dobramos as folhas de forma diferente, obtendo resultados diferentes. Eu dobrei a minha folha verticalmente, enquanto provavelmente você dobrou horizontalmente, obtendo uma forma próxima de um quadrado.

Qual foi o problema?

Eu criei uma especificação tendo em mente exatamente o que eu queria. E eu acreditei que aquilo era mais do que suficiente.

Você pegou uma especificação, aparentemente muito simples, e sem questionar seguiu os passos que julgou corretos.

Não houve comunicação, cada parte presumiu coisas e o resultado final não foi o esperado.

O grande diferencial das ditas metodologia ágeis é exatamente permitir a comunicação rápida, clara e sem ruídos entre todos os membros da equipe. Isso não tem nada a ver com post-its, gráficos ou ferramentas na Internet. É por isso que estamos vendo-as falhar, e é por isso que o seu projeto, e o meu, também estão falhando.

É por isso que relacionamentos chegam a níveis insuportáveis de convivência, casamentos terminam, empregos viram um inferno. É por isso que ocorrem desencontros, é por isso que clientes recebem algo que não pediram e que não os atendem.

É por isso também que não consegui comprar um mísero pão doce quando estive fora do país.

Comunicação é, na minha opinião, o fator mais importante, e o menos valorizado. É tudo isso que eu falei, e mais um pouco.

(Escrito pelo autor em 26/01/2009, e muito pouco ou quase nada mudou desde então)

Pessoal, hoje estamos lançando a pesquisa de intenção do nosso próximo produto: Sitefique.me, uma ferramenta online para criação de sites focado na simplicidade.

Sobre o produto

A idéia surgiu há vários anos mas somente agora nos sentimos experientes o suficiente para tirá-la do papel mantendo sua principal característica: ser simples. Se você acompanha nosso blog já deve ter notado que nossa busca por simplicidade é uma constante (e não é uma coisa fácil de se encontrar nos ambientes corporativos).

Foi seguindo essa filosofia, de ser simples, que decidimos criar o Sitefique.me, voltado para pequenas empresas, que têm a necessidade de um site próprio, divulgar seus produtos e serviços ou até mesmo vendê-los pela internet, mas que ainda não encontraram a ferramenta na medida ou que coubesse no orçamento da empresa.

O Sitefique.me permite criar um site do zero em poucos minutos, escolhendo um layout que pode ser personalizado, e criar páginas a partir de modelos prontos como vitrine de serviços, álbum de fotos, localização com mapa e formulário para contato. Tudo muito simples e direto ao ponto.

Precisamos da sua ajuda

A versão final do produto ainda não está disponível. Estamos finalizando os detalhes, cuidando de alguns assuntos legais, e passando aquele pente fino no código, mas pretendemos lançá-lo nas próximas semanas.
Por enquanto, gostaríamos que respondessem nossa pesquisa de intenção, para nos ajudar a decidir sobre alguns pontos do produto, como valores e planos. Quem responder nossa pesquisa e tiver interessado no produto, será convidado para testá-lo antes do lançamento oficial e ainda ganhará o primeiro mês de mensalidade grátis, sem compromisso.

Infelizmente não possuímos capital para investir na divulgação. Tudo que fizemos até agora foi com nosso próprio dinheiro (servidores, etc) e nosso “tempo livre”. Por isso, pedimos sua ajuda para divulgá-lo:

• Se você apóia iniciativas de empreendedorismo como esta, indique o produto para seus contatos ou empresas que podem necessitar desta solução. Você também pode retuitar para seus seguidores.
• Se você é um desenvolvedor, como nós, nos ajude divulgando o produto para sua rede de contatos, como mais um “case” de Ruby on Rails. Você também pode retuitar para seus seguidores.
• Se você tem um tio ou um cunhado que pega no seu pé nos encontros de família: “Ei sobrinho, quando você vai fazer um site para minha lojinha”, nos ajude indicando o Sitefique.me. De qualquer forma, você também pode retuitar para seus seguidores.
• Ou se você simplesmente já sofreu com a famosa Síndrome do Sobrinho, com certeza nos ajudará a retuitar para seus seguidores.

Muito obrigado.

Retuite para seus seguidores. Assine o blog do produto. Conheça a empresa. Entre em contato.

Documentação é aquilo que você reclama para fazer e reclama quando não encontra.

Por Plínio “Chico Xavier” via Twitter.

Isto me fez refletir (bem rápido) sobre as possíveis causas da não-documentação:

• É muito chato ! Editar wiki, doc … é incrível como toda documentação geralmente é feita em algo não produtivo.
• Espaço e Tempo (ou seja, prazo!). Sempre é deixado por último e nunca sobra tempo pra ser feito.
• Não é levado a sério. Levanta a mão que já viu a secretária documentando “tela” de sistema …
• Normalmente o “investidor” do software não vê valor nisto, ou melhor, espera alguém pedir e repassa a tarefa com prioridade “faz rapidinho”.

Ok. Após reflexão feita, hora de atacar o problema.

Usando “guides” para criar um Guide !

Este é um resultado da experiência abaixo:

Com a gem guides, em segundos você tem um scaffold, pronto para ser preenchido.

$ gem install guides

 $ guides #mostra os comandos disponíveis

$ guides new sample

$ cd sample

$ guides build && guides preview

Pronto. Em http://localhost:9292 você terá acesso ao novo guia gerado.

Preenchendo o seu Guia

Em guides.yml (exemplo aqui), está o básico do seu Guia. Nele está o índice de “capítulos”, com resumo e nome do arquivo que o link deve seguir. Os arquivos textile  gerados/criados ficarão na pasta source, o resultado do “guides build” ficará na pasta output.

As páginas são em textile, o que facilita bastante. Mas o grande diferencial, está em alguns helpers disponibilizados pela gem, que torna muito simples criar áreas de destaque como INFO, WARNING … etc e adicionar comandos e códigos.

Para ter idéia de uma página em textile, segue o link source/getting_started.textile (raw).

Repensando a documentação

Com certeza, usando a gem guides, vocẽ consegue um boost na hora de documentar. Já evitando aquela chatice de editar wiki, .doc, controlando versão … etc. Usando textile, seu editor preferido e git, não tem mais desculpas.

Desenvolvendo Frameworks e APIs

Já faz um tempo que eu topo com a vibe Documentation Driven Development. Como tudo na vida, é questão de bom senso. Documentar uma API, nada mais é do que definir a interface dela, e dependendo do caso, isto ajuda bastante antes de começar o desenvolvimento.

Você é um Usuário !

Uma documentação com um monte de imagem e seta, descrevendo o óbvio não serve para nada (além de passar raiva). Uma documentação sucinta, com o básico, por exemplo Instalação, Modo de Usar, Configurações Disponíveis é bem melhor que muito dossiê por aí ! Tente ao máximo se colocar no lugar do usuário ao escrever alguma documentação ou ajuda.

—

Não deixe de contribuir com o post. Mande sugestões, comentários, reclamações etc.

Aproveitando a grande repercussão do post do Plínio sobre atitude empreendedora e um gancho do meu último post sobre simplicidade e prática constante, volto ao assunto depois que o Roger me lembrou deste gist do Vínicius Teles, que foi escrito por Klaus Wuestefeld, autor do manifesto da Computação Soberana e criador do Prevayler, apresentando dicas de conduta na carreira e como aproveitar as oportunidades.

Apesar de ter gerado muita discussão sobre se vale a pena ou não fazer faculdade, a idéia aqui é apenas gerar reflexão e reforçar o que vimos falando nos últimos posts. Divirtam-se!

Torne-se excelente

Seja realmente bom em alguma coisa. Não fique só choramingando ou querendo progredir às custas dos outros. Não pense que, porque você sentou 4 anos numa faculdade ouvindo um professor falar sobre software, você sabe alguma coisa. Jogador de futebol não aprende a jogar bola tendo aula. Ele pratica. Instrumentistas geniais não aprendem a tocar tendo aula. Eles praticam. Pratique. Chegue em casa depois do trabalho e da aula e pratique. No final de semana, pratique.

Crie seu próprio vírus, seu próprio jogo, seu próprio SO, seu próprio gerenciador de janelas, seu próprio webserver, sua própria VM, qualquer coisa. Várias coisas.

Não precisa ser só programação. Pode ser networking, vendas, etc. Só precisa ser bom mesmo. Tenha paixão pela coisa.

As melhores práticas do mercado são polinizadas primeiro nos projetos de software livre. Aprenda com eles.

Discípulo, Viajante, Mestre: Primeiro seja um discípulo, tenha mestres locais, aprenda alguma coisa com alguém realmente bom, qualquer estilo. Depois viaje, encontre outros mestres e aprenda o estilo deles. Por fim, tenha o seu estilo, tenha discípulos, seja um mestre.

Vou fazer o curso da Mary Poppendieck em SP semana que vem e quando tiver o curso de Scrumban do Alisson e do Rodrigo quero fazer também.

“Torne-se excelente” também pode ser chamado de Melhoria Continua ou Learning.

Não seja deslumbrado

Desenvolvimento de software é a mesma coisa há 60 anos: modelo imperativo. Há 30 anos: orientação a objetos. Bancos de dados relacionais: 30 anos. (Web, por exemplo, não é uma tecnologia ou um paradigma. É meramente um conjunto de restrições sobre como desenvolver e distribuir seu software).

Não corra atrás da última buzzword do mercado. Busque a essência, os fundamentos.

Busque na Wikipédia e Grokke: determinismo, complexidade de algoritmos O(), problema de parada de Turing. Pronto, pode largar a faculdade. Falando sério.

Trabalhe com software livre. Não dê ouvidos a grandes empresas, grandes instituições ou grandes nomes só porque são grandes.

Você acha que vai aprender mais, ter mais networking e mais chance de alocação no mercado trabalhando em par comigo no Sneer por um ano, 8h por semana, ou passando 4 anos na faculdade, 20h por semana, pagando sei lá quanto por mês?

Você acha que vai aprender mais trabalhando em par com o Bamboo 6 meses na linguagem Boo e na engine do Unity ou fazendo um ano de pós em “a buzzword da moda”?

“Não seja deslumbrado” também é conhecido como Coolness.

Mantenha-se Móvel

Com a demanda que temos hoje no mercado, se você é desenvolvedor de software e não consegue negociar um contrato com uma empresa onde você é pago por hora e pode trabalhar quantas horas quiser com um mínimo de meio período, você precisa rever a sua vida.

É melhor ter dois empregos de meio período que um de período integral, porque você pode largar um deles a qualquer momento.

Você nunca vai conseguir nada melhor se não tiver tempo, se não tiver disponibilidade pra pegar algo melhor quando aparecer.

Você sustenta seus pais e 7 irmãos? Não. Então pare de ser ganancioso e medroso no curto prazo, para de pagar facu, mestrado, pós, MBA, sei-lá-o-quê e vai aprender e empreender.

Trabalhe remoto. Não é o mais fácil, mas é perfeitamente possível.

Não fique reclamando que está trabalhando demais. Aumente seu preço e trabalhe menos.

Emparceire-se Promiscuamente

Participe de dojos, de congressos, de projetos de software livre. Tenha amigos, colegas, conhecidos. Seja conhecido. Não faça ruído em seis projetos e doze fóruns. Ajude de verdade em um ou dois projetos de cada vez. Ao longo do tempo, você terá ajudado em varios projetos, trabalhado em várias empresas.

Mentalidade de Abundância

Ajude seus amigos sem cobrar (a “camaradagem” do Vinícius). Dê palestras gratuitas. Cursos gratuitos. Participe de projetos de software livre.

Pare as vezes uma tarde pra receber um amigo seu e explicar seu projeto. Vá visitar seus amigos nos projetos deles. Viaje com algum amigo seu pra visitar um cliente dele, só pra conversar e fazer companhia.

Você tem um espaço onde dá cursos? É uma Aspercom, Caelum da vida? Chama os brothers para dar curso. Porra, bola um modelo em que as pessoas podem se inscrever para cursos variados, pagando um sinal, e mantém tipo uma agenda pré-combinada: “Será numa terça e quinta à noite, avisadas com duas semanas de antecedência”. Se rolar, beleza, se depois de meses não der quórum, devolve o sinal. Pode ser curso de Prevayler, de Kanban, de Scrum, de Lean, de Comp Soberana, de Restfulie, de Cucumber, de Rails, de Teste Automatizado Mega-Avançado, qualquer coisa.

Chame amigos seus pra dar curso em dupla com você. Divida clientes. Divida projetos, mesmo que não precise de ajuda.

Dizia o pai de um brother meu de infância: “Tudo que custa dinheiro é barato”.

Busque modelos de custo zero

Trabalhe em coisas que tem custo administrativo / burocrático / manutenção zero. Por menos ganho que tragam, depois de prontas, estarão tendo uma relação custo/benefício infinitamente vantajosa.

Ganhe notoriedade

Faça coisas massa. Participe de projetos de software livre. Dê palestras gratuitas. Promova eventos (dojos, debates, grupos de usuários, etc).

By Dairton Bassi: Não tenha medo!

Meta a cara. Arrisque empreender. Arrisque inovar. O que você tem a perder? No máximo um emprego, mas isso pode ser revertido facilmente em um mercado aquecido como o atual. O pior que pode acontecer é não dar certo. Mesmo assim você terá aprendido muito mais do que batendo cartão.

Saia da zona de conforto. Se o seu trabalho estiver fácil e sob controle, isso significa que ele não está mais agregando para a sua evolução técnica e pessoal.

Não desperdice a chance de trocar de função se a nova oportunidade for mais desafiadora. Isso fará você crescer tecnicamente e o preparará para desafios maiores ainda. Conhecer pessoas novas é tão importante quanto manter-se em contato com código.

Não se detenha por insegurança ou pela sensação de despreparo. Como você acha que vai ganhar experiência em alguma coisa se sempre adiá-la?

Antes de qualquer outra coisa, escrevo esse post em forma de autocrítica e como um tapa na cara em mim mesmo. Espero que a carapuça sirva em você também.

Cena 1: dois programadores estão tomando refrigerante enquanto reclamam do site que um terceiro programador fez, deu certo e e acabou virando a principal fonte de renda do empreendedor.

Cena 2: um grupo de funcionários critica um colega que está ganhando mensalmente o equivalente ao salário com aplicações para iPhone e iPad com frase do tipo ‘isso aí até eu faço’, ou ‘é pura falta do que fazer’.

Cena 3: um programador, desses acostumados a usar paletó, gravata e passar o dia em cima de diagramas de stick figures, setinhas e balões, profere sem o menor pudor: ‘Estudar uma tecnologia nova em casa? Eu só aprendo algo novo se for pago pra isso.’

Cena 4: um colega, inocente e empolgado, convida outro para participar de um Coding Dojo, e recebe como resposta: ‘programar depois do expediente? eu prefiro levar uma topada no dedão’

E a clássica cena 5: funcionários reunidos almoçando/tomando café/fumando/num happy hour e falando mal do coordenador/líder técnico/chefe/diretor/gerente/empresa em geral.

Pense um pouco e você vai perceber que, com certeza, já presenciou ou já fez parte de algumas dessas cenas.

Reclamar, ficar insatisfeito, criticar ou debochar é algo natural, faz parte da natureza das pessoas e, acho eu, até mesmo de certas espécies de animais. O problema aparece quando a crítica vira choradeira e nunca passa disso.

Eu trabalhei numa empresa pequena, com cinco funcionários, onde havia contato direto com o dono e com os clientes. A quantidade de coisas que aprendi ali, tanto profissionalmente quanto pessoalmente é algo que me ajuda até hoje. Porém, talvez pelo fato de eu ter ficado por ali mais tempo do que seria produtivo para ambas as partes, eu perdia tempo demais reclamando, me estressando e agindo de forma infantil e improdutiva. Chegou ao ponto de uma namorada dizer ‘que cada funcionário está na empresa que merece, e cada empresa tem o funcionário que merece’.

Até hoje penso nessa frase e apesar de toda a violência com a qual ela foi empregada, não deixo de notar a realidade por trás das palavras.

Um ex-funcionário do Google escreveu um artigo (se alguém ainda tiver o link, por favor me envie) em que conta que seus colegas reclamavam da qualidade do granulado usado nos doces que eram dados pela empresa no horário de trabalho simplesmente por não terem do que reclamar.

Já presenciei colegas reclamando da qualidade da churrascaria que a empresa escolheu para a confraternização de fim de ano, onde comeram e beberam de graça sem pagar um centavo que fosse. E, honestamente, era um local que eu não teria condições de levar minha família sem deixar uma parcela considerável dos meus rendimentos.

As pessoas, incluindo eu e você, deveriam parar de choramingar, de reclamar e de perder tempo com conversinhas inúteis e começar a meter a mão na massa, produzir coisas de que se orgulhem e que sejam úteis para outras pessoas.

Não estou me limitando ao discurso Go Horse de ‘não está feliz, peça as contas’. Estou dizendo para que você pense em como se tornar adulto, até mesmo em como se tornar economicamente autossuficiente (pela Nova Gramática).

Atualmente, o custo de se iniciar um projeto ou de se colocar uma idéia em prática usando a Internet é próximo de zero. Qualquer pessoa com iniciativa e, principalmente, acabativa, consegue colher bons frutos com praticamente nenhum investimento além do próprio tempo.

Fazendo uma conta de padaria: se você investir uma hora e meia por dia estudando e/ou implementando uma idéia, por mais absurda que ela pareça para os outros, em um mês você vai ter investido 45 horas, o que é tempo mais do que suficiente para aprender os fundamentos de uma nova linguagem ou apresentar um protótipo da idéia.

Hoje em dia você tem Rails, Sinatra, Django, web2py, uma lista imensa de ferramentas que permitem a criação rápida de aplicações, sem a perda de tempo de editar arquivos XML, descritores ou ficar desenhando bonecos de palitinho.

Pare de reclamar. Se organize. Tenha metas claras e reais. Pare de apontar o dedo e comece a trabalhar. Leve o problema a quem for devido ao invés de simplesmente adotar uma postura passivo-agressiva. Busque motivação onde ela não existe, ou vá respirar novos ares. Tente uma forma diferente de fazer as mesmas coisas, compartilhe conhecimento, ouça mais e aprenda mais.

Enfim, deixe de ser uma menininha chorona e comece a agir.

E, a propósito, parabéns ao Vinicius Teles e equipe pelo trabalho iniciado, concluído e bem feito.

No final do ano passado, ao ver um twitty do José Valim, fiquei tentando a comprar o livro, mas depois do post Crafting Rails Applications: Why I wrote this book, tive certeza que não perderia este presente de Natal.

Crafting Rails Applications: Expert Practices for Everyday Rails Development

Apesar de poucas páginas, o livro tem muito conteúdo. Logo no começo, em “Who should read this book ?” é avisado, não é para iniciantes. Os capítulos são separados em tópicos interessantes, abordando diferentes maneiras de extender o Rails 3.

Aliás, extender é a palavra chave do livro. Dos projetos que compõe o Rails, somente o Active Resource não foi citado. O livro com certeza pula o básico, ou seja, não espere por explicações em como usar as funcionalidades do Rails.

-

Detalhes que tornam o livro interessante.

• Enginex – é uma Ruby gem que cria um Rails 3 Engine com Rakefile, Gemfile e pronto para rodar testes em cima de uma aplicação “vendorizada”. Ou seja, no livro temos projetos reais, que são executados e tem testes !
• TDD – todo código apresentado, é feito seguindo o Test-driven Development, mostra-se o teste falhando e vai implementando aos poucos, até tudo ficar verde.
• Como melhorar o seu código – conhecendo Responders e o Renderer Stack do Rails 3, você com certeza irá ampliar o seu leque de possibilidades de como melhorar o fonte das suas aplicações. Tem bastante exemplos de Rails Generators também.
• Desmistificando Rails – o Valim realmente conseguiu de forma majestosa explicar as entranhas do Rails 3. A cada capítulo e detalhe explicado, pude ver o verdadeiro trampo que fizeram no projeto, em comparação com o 2.x, o Rails mudou muito (internamente!).

Finalizando…

Se você é um desenvolvedor que se preocupa em conhecer a fundo o framework que trabalha, compre agora! Confesso que depois da leitura, estou muito mais a vontade para navegar no fontes do Rails, inclusive passei a acompanhar os tickets no Lighthouse. Rails 3 definitivamente está mais flexível, e o José Valim conseguiu expor tudo isso com código e uma leitura agradável.