sexta-feira, 26 de setembro de 2008

Caído na Calçada



Crônica do David Coimbra publicada hoje no jornal Zero Hora. Muito boa!

"Ontem saí de casa mais cedo do que o normal e a temperatura era amena de primavera e o dia estava amarelo e azul e do som do meu carro se evolava o rock suave da Itapema e eu me sentia realmente bem. Estacionei numa rua quase bucólica do Menino Deus e vi que ali perto um catador de papel puxava sua carrocinha sem pressa.

Era magro e alto, devia andar nas franjas dos 50 anos e tinha a pele luzidia de tão negra. Ao seu lado saltitava um menino de, calculei, uns quatro anos de idade, talvez menos. Devia ser o filho dele, porque o observava com um olhar quente de admiração, como se aquele homem fosse o seu herói. Bem. Ao menos foi o que julguei, certeza não podia ter.

Já ia me afastar quando, por entre as grades da cerca de uma creche próxima, voou um brinquedo de plástico. Um desses robôs cheios de luzes e vozes, que se transformam em nave espacial e prédio de apartamentos, adorado pelas crianças de hoje em dia. Algum garoto devia ter atirado o brinquedo para cima por engano, ou fora uma gracinha sem graça de um amigo. O menino que era dono do brinquedo colou o rosto na grade como se fosse um presidiário, angustiado. O filho do catador de papel correu até a calçada, colheu o robô do chão e não vacilou um segundo: retornou faceiro para junto do pai, o brinquedo na mão, feito um troféu. Olhei para o menino atrás da cerca. Estranhamente, ele não falou nada, não gritou, nem reclamou. Ficou apenas olhando seu brinquedo se afastar na mão do outro, os olhos muito arregalados, a boca aberta de aflição.

Muito orgulhoso, o filhinho do catador de papéis mostrou o brinquedo ao pai. O pai olhou. E fez parar a carrocinha. Largou-a encostada ao meio-fio. Levou a mão calosa à cabeça do filho. E se agachou até que os olhos de ambos ficassem no mesmo nível. A essa altura, eu, estacado no canteiro da rua, não conseguia me mover. Queria ver o desfecho da cena. O pai começou a falar com o menino. Falava devagar, com o olhar grave, mas não parecia nervoso. Explicava algo com paciência e seriedade. O menino abaixou a cabeça, envergonhado, e o pai ergueu-lhe o queixo com os nós do dedo indicador. Falou mais uma ou duas frases, até que o filho balançou a cabeça em concordância. A seguir, o menino saiu correndo em direção à creche. Parou na grade, em frente ao outro garoto. Esticou o braço. E, em silêncio, devolveu-lhe o brinquedo. Voltou correndo para o pai, que lhe enviou um sorriso e levantou a carrocinha outra vez. Seguiram em frente, o pai forcejando, o filho ao lado, agora não saltitante, mas pensativo, concentrado.

Então, tive certeza: aquele olhar com que o menino observara o pai era mesmo de admiração, ele era de fato o seu herói. "

terça-feira, 16 de setembro de 2008

Boys/Girls on Wheels



Antes de mais nada, quero deixar claro que apoio todas as políticas de inclusão de deficientes físicos e não tenho nada contra algum deles.
Mas que isto aqui ficou engraçado, ah ficou:

Boys On Wheels



Girls On Wheels

Candidatos Famosos a Vereador



Em época de eleição, o que não falta são pessoas que se tornaram famosas por um ou outro motivo que desejam se candidatar a vereador. Alguns exemplos são os candidatos abaixo:

Lacraia - Dançarina(o) que fez sucesso dançando ridicularmente com o funkeiro MC Serginho


Alberto Cowboy - Ex BBB (7)


Adriano Didi - Ex BBB (faz tanto tempo que nem lembro qual)


Enéas Filho - O Filho do Homem. Notem que é a cara do pai!


Sérgio Mallandro - Apresentador infantil de sucesso nos anos 80. Vai abrir a "Porta dos Desesperados" na Câmara de São Paulo


Milena - Em 2006, deixou uma promissora carreira de suplente de vereadora para posar nua. Agora tenta de novo (rezamos para que deixe a carreira de vereadora de lado novamente).


Netinho de Paula - Ex-cantor, ex-apresentador, agressor de esposas, agressor de repórter do Pânico, mano!


Ovelha
- Outro ex-cantor, depois de aparecer cantando de sunga no Pânico (não clique neste link, é deprimente), nada mais natural que tentar ser vereador!


Pit Bitoca - Depois de fazer sucesso junto com Tom Cavalcanti e escrever um blog de tecnologia em um grande portal de internet, agora tenta ser vereador em Taubaté!


Rita Cadillac - Ex-chacretem ex-animadora de presídios. Vereadores também precisam ter a mãe por perto!


Thammy Gretchen - Ex-mulher, filha da rainha do bumbum dos anos 80. Já que a mãe tentou ser prefeita, ela tenta ser vereadora!


Túlio Maravilha - Ex-centroavante. Já chegou a ser goleador do Campeonato Brasileiro. Para quem já jogou no Vila Nova/GO, trabalhar na Câmara de Vereadores deve ser luxo!

quarta-feira, 10 de setembro de 2008

Projetos pessoais não são projetos da empresa onde você trabalha



Quase todas as pessoas que conheço possuem projetos pessoais, que vão desde comprar um carro até fundar uma nova companhia.
Entretanto acho deplorável que pessoas tentem realizar projetos pessoais enquanto trabalham em outra empresa.
Apenas como exemplo: uma pessoa trabalha em uma empresa de tecnologia, na área de criação de novos produtos. Esta pessoa é paga para pensar em novos produtos para a empresa (geralmente bem-paga). Entretanto, esta pessoa usa todas a sua criatividade para, ao invés de criar produtos para a empresa, criar produtos para si próprio e, posteriormente, vender para a empresa onde trabalha.
Um outro exemplo: uma pessoa é contratada para trabalhar para uma empresa, entretanto ela utiliza o tempo dentro da empresa para realizar os seus projetos pessoais.
Algum destes comportamentos é correto? Na minha opinião não. Mas vejo isto acontecer muito nas empresas com que tenho contato.
O que você acha disto?

terça-feira, 9 de setembro de 2008

Aprenda a Programar em Dez Anos



Por: Peter Norvig
Tradução por: Augusto Radtke

Entre em qualquer livraria. Você vai ver "Aprenda Java em 7 dias", assim como diversas variações oferecendo lições de Visual Basic, Windows, Internet e por ai vai, em dias ou horas. Eu fiz a seguinte pesquisa na Amazon.com:

pubdate: after 1992 and title: days and (title: learn or title: teach yourself)

Encontrei 248 entradas. As primeiras 78 eram livros sobre computadores (número 79 era "Learn Bengali in 30 days"). Troquei "dias" por "horas" e encontrei resultados incrivelmente similares: 253 livros, 77 de computadores, seguidos de "Teach Yourself Grammar and Style in 24 Hours" no número 78. Do total de 200, 96% eram livros de computadores.

A conclusão é que: ou as pessoas estão com muita pressa de aprender sobre computadores, ou computadores são extremamente mais fáceis de aprender do que qualquer outra coisa. Não há livros de como aprender Beethoven, ou Física Quântica ou até adestramento de cães em alguns dias.

Vamos analisar o que um título como "Learn Pascal in Three Days" (Aprenda Pascal em três dias) pode significar:

  • Aprenda: Em três dias você não terá tempo de escrever programas significantes e aprender com seu sucesso ou fracasso. Você não terá tempo para trabalhar com um programador experiente e entender o que é conviver neste ambiente. Em resumo, você não terá tempo para aprender muito. Logo, eles só podem estar falando a respeito de entendimento supercial e, como disse Alexander Pope, "aprender pouco é uma coisa perigosa".
  • Pascal: Em três dias você deve ser capaz de aprender a sintaxe do Pascal (isso se você já conhece uma linguagem similar), mas não vai aprender muito sobre como utilizar essa sintaxe. Em resumo, se você era, vamos dizer, um programador Basic, você pode aprender a escrever programas no estilo Basic usando a sintaxe do Pascal mas não aprender em que o Pascal é bom (ou ruim). Então, qual o ponto? Alan Perlis disse certa vez: "Uma linguagem que não afeta a maneira que você pensa sobre programação, não vela a pena ser aprendida". Um ponto é se você precisar aprender um pouco de Pascal (ou algo como Visual Basic ou Javascript) porque você precisa interagir com alguma ferramenta existente para uma tarefa específica. Mas nesse caso você não esta aprendendo a programar, você está aprendendo a como resolver essa tarefa.
  • em três dias: Infelizmente, não é suficiente, como veremos a seguir.
Aprenda a Programar em Dez Anos.

Pesquisadores (Hayes, Bloom) tem demonstrado que leva em torno de dez anos para desenvolver perícia em qualquer uma das variadas áreas, includindo jogar xadrez, compor músicas, pintar, tocar piano, nadar, jogar tênis e pesquisar neuropsicologia ou topologia. Aparentemente não há atalhos: até Mozart, que foi um prodígio musical aos 4 anos levou mais 13 antes de compor música de primeira classe. De outra forma, os Beatles parecem ter disparado nas paradas em primeiro lugar com a aparição no show do Ed Sullivan em 1964. Mas eles estavam tocando em pequenos clubes em Liverpool e Hamburgo desde 1957, e mesmo após conseguirem uma aparição em massa, o primeiro grande sucesso mesmo (Sgt. Peppers) foi lançado em 1967. Samuel Johnson pensa que pode levar mais do que dez anos: "Excelência em qualquer departamento pode ser alcançada apenas com o trabalho de uma vida toda; não é possível compra-lá por menos". E Chaucer reclamou: "vida tão curta, leva tantu pra aprender". Sim, é "tantu", e não "tanto", um dia você entende.

Então aqui vai minha receita para sucesso na programação:

  • Aprenda inglês. Leia o original deste texto. Essa tradução só está aqui para exercitar o meu inglês, não o seu. (Nota do tradutor)
  • Se interesse por programação, e faça porque é legal. Tenha certeza que isso continue a ser legal para você dedicar dez anos nisso.
  • Converse com outros programadores; leia outros programas. Isso é mais importante do que qualquer livro ou curso de treinamento.
  • Programe. O melhor tipo de aprendizado é aprender fazendo. Colocando de uma forma mais técnica, "o nível máximo de performace individual em um domínio não é alcançado automaticamente em função de uma experiência extendida, mas sim aumentado mesmo por indivíduos extramente experientes por um esforço deliberativo de melhorar". (p. 366) e "o aprendizado mais efetivo requer uma tarefa bem definida com uma dificuldade apropriada para o indivíduo em particular, dado que exista um retorno sobre a experiência e oportunidades de repetição e correções de erros". (p. 20-21) do livro "Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life", que é uma referência interessante deste ponto de vista.
  • Se você quiser, gaste quatro anos em uma universidade (ou mais em uma pós-graduação). Isso lhe dará acesso a alguns empregos que requerem alguma formação e um grande entendimento do campo de trabalho. Mas se você não gosta muito de ir para a escolha, você pode (com alguma dedicação) conseguir alguma experiência similiar sobre esse tipo de trabalho. Em qualquer caso, apenas ler livros não será suficiente. "Educação em ciências da computação não faz de ninguém um gênio em programação tanto quanto estudar pincéis e pigmentos não fazem um bom pintor", diz Eric Raymond, autor de "The New Hacker’s Dictionary". Um dos melhores programadores que eu já contratei tinha apenas o segundo grau, e ele produziu vários softwares incríveis, tem seu próprio grupo de discussão, e fez dinheiro suficiente em ações para comprar seu próprio clube nortuno.
  • Trabalhe em projetos com outros programadores. Seja o melhor programador em alguns projetos, seja o pior em outros. Quando você é o melhor você testa suas habilidades para liderar um projeto, e para inspirar outros com a sua visão. Quando você é o pior aprende o que os mestres ensinam e o que não gostam de fazer (porque eles fazem você fazer por eles).
  • Trabalhe em projetos após outros programadores. Esteja envolvido em entender um programa escrito por outro. Veja o que é preciso para entender e consertar quando o programador original não esta por perto. Pense em como desenvolver seus programas para que seja fácil para quem for mante-lós após você.
  • Aprenda pelo menos meia dúzia de linguagens de programação. Inclua na lista uma linguagem orientada a objetos (como Java ou C++), uma que seja de abstração funcional (como Lisp ou ML), uma que suporte abstração sintática (como Lisp), uma que suporte especificação declarativa (como Prolog ou C++ com templates), uma que suporte co-rotinas (como Icon ou Scheme), e uma que suporte paralelismo (como Sisal).
  • Lembre-se que há um "computador" em "ciência da computação". Saiba quanto tempo leva para o seu computador computar uma instrução, carregar uma palavra em memória (com e sem cache), ler palavras consecutivas do disco rígido, procurar por uma nova posição no disco.
  • Se envolva no esforço de padronização de uma linguagem. Pode ser o comite ANSI C++, ou na padronização de programação na sua empresa, se utilizaram identação com 2 ou 4 espaços. Em qualquer caso, você aprende o que outras pessoas gostam em uma linguagem, o quanto eles gostam e talvez um pouco do porquê eles gostam.
  • Tenha o bom-senso de cair fora desse processo de padronização tão rápido quanto possível.

Com tudo isso em mente, é questionável o quão longe você pode ir apenas lendo livros. Antes que do meu primeiro filho nascer eu li todos os livros de "Como Fazer" e ainda me sentia como um novato. Trinta meses depois, quando nasceu meu segundo filho, voltei aos livros para relembrar? Não, ao invés disso resolvi utilizar minha experiência pessoal do primeiro filho, que se tornou muito mais útil do que milhares de páginas escritas por especialistas.

Fred Brooks, em seu trabalho no "Silver Bullets", identificou um plano em três partes para encontrar grandes projetistas de software:

  1. Sistematicamente identifique os melhores projetistas o quanto antes.
  2. Atribua um orientador de carreira, responsável pelo desenvolvimento cuidadoso de um plano de carreira
  3. Promova oportunidades para desenvolvedores em aprendizado interagir e estimular uns aos outros.

Assumo que algumas pessoas já possuem as qualidades necessárias para ser um grande desenvolvedor de software; o grande trabalho é apenas coloca-los no caminho correto. Alan Perlis coloca de forma mais sucinta: "Qualquer um pode ser ensinado a esculpir: Michelangelo precisaria ser ensinado a não esculpir. É o mesmo com grandes programadores".

Então vá em frente e compre aquele livrode Java; provavelmente você terá algum uso dele. Mas isso não vai mudar a sua vida, ou o seu conhecimento, como um programador em 24 horas, dias, ou meses.

Retirado de: Aprenda a Programar em Dez Anos

segunda-feira, 1 de setembro de 2008

Frases sobre Gerentes de Projeto



ATENÇÃO: Se você é um Gerente de Projeto, saiba que este é um tópico de humor, criado para que os programadores possam se divertir. Claro, se você fizer pelo menos 3 dos itens abaixo, reveja seus conceitos de gerente de projeto!

Todo gerente de projeto ruim que eu conheço:
  • não é técnico
  • quer ser PMP
  • tem medo de tomar decisões
  • acha que pode passar a 6a. marcha e cortar o tempo de projeto pela metade com o mesmo número de desenvolvedores envolvidos
  • quando o projeto atrasa diz: "Eu não sabia de nada"
  • nunca programou
  • possui sólidos conhecimentos em Microsoft Office (e só)
  • vem sempre com aquela historinha: "Pessoal, vamos fazer uma força-tarefa" (quando o projeto está na beira do abismo)
  • fala que todo erro de sistema é algo gravíssimo e tem que ser corrigido no dia (mesmo que só entre em produção 1 mês depois)
  • faz questão de cumprimentá-lo com um lindo sorriso
  • era um péssimo programador
  • senta do seu lado quando o projeto tá atrasado e fica o tempo todo perguntando o que você está fazendo
  • fica olhando para a sua tela e pigarreando quando você não dá bola para ele
  • fala que em breve as coisas vão melhorar, mas não faz nada para que isso de fato aconteça
  • acha que ser programador é coisa de peão, e que essa é uma atividade mecânica que não requer inteligência
  • acha que CMMi vai resolver todos os problemas da empresa
  • te cobra baseado em um cronograma do Project, mas você não teve o direito de falar quanto tempo precisaria para fazer a atividade que está sendo cobrado
  • cobra tarefas que deveriam ser feitas por ele
  • trata você como uma criança, toda hora repetindo as mesmas coisas que você já está cansado de saber e fazer
  • acredita que o salário que as empresas pagam basta como motivação profissional
  • fica querendo dar pitacos na solução técnica, comparando com as que ele aplicou há séculos atrás, quando ainda usava Fortran
  • marca 3 reuniões de 3 horas a cada dia
  • acha que o mundo todo está contra ele
  • diz que quando era programador produzia mais que você
  • busca culpados ao invés de soluções
  • assina a InfoExame e vem cheio de "novidades" sadomasoquistas a cada edição
  • acha que documentação é o principal objetivo de todo projeto
  • responde seus e-mails em, no máximo, 5 minutos (ler e-mails é a segunda atividade dele. A primeira é olhar o Project)
  • quando o sistema tá bom diz: "Nós fizemos". Quando tá ruim: "Eles fizeram".
  • não faz especificação
  • se preocupa mais com %Complete do que com Working Software
  • não leva ninguém da equipe nas reuniões com os stakeholders, pois teme que transpareça que ele não sabe nada
  • não sabem lidar com conflitos humanos
  • entram em conflitos com gerentes de projeto de outras áreas
  • não sabem que uma solução "apagadora de incêndio" é uma solução que deve ser refeita por uma mas elegante

  • é promovido!