Histórias de TIrror – Episódio de Hoje: Vampiros de Alma

Essa é macabra mesmo.

Mais um daqueles projetos intermináveis, daqueles que a gente não vê a luz no fim do túnel. O time já vinha trabalhando numa média de quinze horas por dia, pelos últimos dois meses. Sabe quando o gerente de projeto vem com aquela de “Sábado é dia útil” e “Domingo, Ponto Facultativo”? Pois é, mais ou menos assim.

Segundo o que me contaram, o sujeito estava programando por mais de 36 horas seguidas (imagina o código que estava saindo) quando teve um colapso e caiu no chão. As pessoas que estavam no local relataram que ele caiu e ficou na mesma posição que estava na cadeira, como se ainda estivesse programando deitado no chão. Olhos esbugalhados e uma babinha escorrendo pelo canto da boca, o que não preocupou ninguém porque ele já babava normalmente.

Nenhuma palavra, estado catatônico.

Levaram para a emergência, e o diagnóstico, adivinhem? Colapso causado por overdose de trabalho e stress, quem poderia imaginar uma coisa dessas. Mas o mais estranho ainda estava por vir. Ao acordar no hospital, doze horas depois, ele não se lembrava de nada da sua vida nas últimas duas semanas. Nada, nadinha, o sujeito teve as duas últimas semanas completamente apagadas da memória. E até o fechamento dessa edição, cinco anos depois, ele ainda não havia recobrado lembrança daqueles tristes dias.

Sacanagem, para isso não tem backup.

[]s
Jack DelaVega

Leia Mais

Aprendendo 2 vezes

Recentemente me vi na situação de ter que ensinar noções básicas de programação para um grupo de pessoas totalmente leigas em computação. Era um mini-curso sem muitas pretensões. Eu e o grupo havíamos concordado que em 8 horas-aula seria humanamente impossível ensinar a qualquer um a difícil profissão de desenvolvedor de software. Mas combinamos que iríamos tentar.

Na primeira aula, 4 alunos. Calados, céticos, eram como cobras prontas para dar o bote. Aos poucos tentei seduzí-los e, sempre usando de muita honestidade, mostrei que mesmo as coisas mais difíceis são possíves quando se tem um sonho. Acho que na prática foi isso mesmo que tentei fazer: fomentar o sonho de tornar-se um programador dentro de cada um deles. O final da primeira aula foi sensacional pra mim. É sempre uma sensação gratificante ver as pessoas sorrirem após uma explicação ou concordarem com a cabeça após um exemplo. A palavra aluno tem em sua origem um significado que não gosto muito: aquele que não tem luz. Já tive vários alunos imensamente 'iluminados' e aprendi bastante com eles. Mas tenho que confessar que o maior prazer em dar aula está na sensação que às vezes temos de realmente estar iluminando as pessoas.

Na segunda aula, 10 alunos. Aqueles 4 da primeira aula convidaram conhecidos e fizeram boas recomendações. Mais explicações, exemplos, exercícios e novos mundos desvendados. Ao final da aula, abraços, agradecimentos e muita emoção.

Já tenho alguma experiência como professor, mas com certeza esse foi o momento mais marcante pelo qual já passei. Percebi que aquelas pessoas que menos esperam (e que na verdade mais necessitam) dessa tal 'luz' são as que tornam o nosso trabalho mais gratificante. Um pequeno gesto, uma pequena atenção faz uma enorme diferença na vida delas, e nos faz sentir importantes, nos dá um sentido.

Meu pai já dizia que é possível aprender duas vezes, basta ensinar. Acho sinceramente que se você quer dar um sentido extra à sua carreira, procure sempre ensinar o que sabe. Sem interesses, sem segundas intenções. O resultado, eu garanto, vale à pena.

Reggie, the Engineer.

--

Leia Mais

Dez Coisas que Odeio em Você

Uma dos Dez comportamentos mortais para qualquer Gerente, sob o ponto de vista dos gerenciados. Compilação livre, não necessariamente em ordem de importância:

1. Micro Management.
2. Tem medo de assumir riscos.
3. Me cobra justamente pelas coisas que eu não deveria fazer.
4. Simplesmente desliga e pára de me ouvir após 20 segundos de conversa, mas continua concordando com a cabeça como se estivesse entendendo.
5. Espera que eu faça as coisas exatamente como ele faria.
6. Usa expressões como “Concordo com o que você está dizendo, mas”, e aí discorda redondamente do que eu falei.
7. Prefere me contar uma “história para boi dormir” ao invés de concordar que realmente temos um problema na empresa e que deveríamos fazer algo para resolver.
8. Precisa de uma explicação de 45 minutos para tomar a mesma decisão que eu havia sugerido no início da conversa.
9. Ele não tem idéia do que eu faço.
10. Chega atrasado a uma reunião e pede para que todo mundo repita o que foi dito, fala o óbvio, e nos faz perder meia hora.
    

[]s
Jack DelaVega

Leia Mais

Como acabar com seu futuro em 5 minutos

Prometi pra mim mesmo que um dia desses ia fazer um post com umas poucas pérolas coletadas em entrevistas de TI das quais participei. Pois bem, aqui vão algumas (qualquer semelhança é mera coincidência):

• O candidato era fraco tecnicamente, eu mesmo já o havia eliminado, mas a entrevista prosseguiria até o final apenas por respeito. Foi aí que o representante do departamento de RH largou aquela perguntinha clássica: "qual aspecto negativo você gostaria de mudar em si mesmo?". O candidato respira fundo, e diz que tem uma espécie de alergia no olho esquerdo. Algo que eventualmente o faz lacrimejar muito. Afirma que aquilo o incomoda bastante e que inclusive terá que operar. Se pudesse mudar algo em si mesmo, seria o olho esquerdo. Silêncio fúnebre na sala. Confesso que não larguei uma gargalhada por muito pouco.


• O candidato era um desenvolvedor bem recomendado. Comecei perguntando da experiência atual dele como desenvolvedor e ele rapidamente me interpelou e disse: "Pois é, mas não sou mais desenvolvedor, o currículo que vocês têm está defasado. Agora sou arquiteto". Ah bom, pensei eu, tentando entender como exatamente se dá esse processo de transformação desenvolvedor-arquiteto. Sempre que ouço esse tipo de coisa mudo completamente o rumo da entrevista. Acho justo o cara ser entrevistado como arquiteto, já que é um ;) . Perguntei a ele qual a visão dele sobre Design Patterns e como ele os aplica. Ele me disse que usava muito o padrão "Client-Server". Hummm, entendi. Entrevista encerrada.


• Eu estava entrevistando um desenvolvedor em outro país. O cara tinha uma experiência boa com programação, em empresas e projetos grandes. Entrei um pouco na parte técnica e o cara deixou um pouco a desejar, mas OK. Resolvi então checar o potencial dele para resolução de problemas, e propus a discussão de uma estrutura de pilha. Qual não foi minha surpresa quando ele falou exatamente assim: "Pilha? Nunca ouvi falar nisso...".


• Também entrevistando um líder de desenvolvimento em outro país, questionamos o candidato sobre situações de conflito, e como ele costumava resolver esses problemas dentro da equipe. Sem titubear, o candidato largou: "Bom, se o desenvolvedor não concorda com a minha idéia, eu tento convencê-lo. Caso ele ainda não concorde, eu chamo o supervisor". Achei interessante a estratégia dele.


• Essa eu não estava presente, apenas me contaram, mas tomei a liberdade de colocar aqui. O candidato havia sido bem recomendado e estava "abafando" na parte comportamental da entrevista. Estava praticamente contratado. Resolveu-se então entrar na parte técnica, "só por formalidade". Ao ser perguntado sobre Design Patterns e quais os que ele mais estava acostumado a utilizar, o candidato ficou um pouco hesitante, e disse que estava pensando em um mas não se lembrava o nome. O entrevistador se ofereceu a ajudar e perguntou as características do padrão. E o candidato: "ah, é um que os caras fizeram na Argentina, até ajudei a fazer a nova versão". Não preciso dizer que o entrevistador não conseguiu ajudá-lo.

Recentemente eu e meus colegas Lone Gunmen estávamos discutindo como pequenas coisas nas entrevistas fazem uma diferença enorme. Um atraso, uma frase mal colocada, uma resposta sem noção, etc. Essas coisas quando fora do contexto até podem parecer de importância relativa. Mas a verdade é que eu acredito na abordagem Blink em entrevistas. Eu diria que no meu caso, em 70%-80% dos casos (estou chutando, teria que medir isso), eu já aceitei ou rejeitei o candidato em 5 minutos de entrevista. Normalmente uso o resto do tempo para confirmar a minha decisão. Alguns casos já ocorreram de o entrevistado virar o jogo, para o bem ou para o mal. Mas eles são sempre exceção.

Portanto, muito cuidado nos processos seletivos. Você pode estar acabando com seu futuro em apenas 5 minutos.

Reggie, the Engineer.

--

Leia Mais

Borracharia

Estava consertando o pneu do carro.

Numa borracharia, coisa que eu acho que só existe no Brasil, nunca vi nenhuma nos Estados Unidos, não faço idéia de como eles fazem para consertar um pneu, mas bom, estou divergindo. Voltando ao assunto, estava eu na borracharia, daquelas tradicionais mesmo, pôster da Rita Cadilac do tempo do Chacrinha. O dono, um senhor grisalho dos seus sessenta anos, supervisionando o trabalho de um guri que devia ter por volta de seus treze.

Calmamente ele passava os segredos da profissão para o guri, que apesar de ouvir, não sei se levava muito a sério os ensinamentos do velho. Então ele me colocou na conversa.

“Pois é” – Diz ele, “Tô ensinando a profissão para esse guri, não que tenha muito que ensinar, ser borracheiro não requer prática nem habilidade, não vou mentir pro senhor. Mas o danado do guri não aprende."

O guri tirando o prego do meu pneu. E senhor continua.

“Pra ser borracheiro não precisa ser inteligente, qualquer um consegue, tem meia dúzia de coisas que o cara tem que fazer, descobrir o furo, limpar, lixar, soldar, nada de mais.”

“Nem muita experiência precisa, coisa que dá para aprender em uma semana, no máximo.”

“Estudo? Não. Eu mesmo não completei o ginásio.”

“Tem só uma coisa que o sujeito tem que ter para ser um bom borracheiro.”

“O que?” - Perguntei para mostrar interesse na conversa, afinal ele iria contar de qualquer maneira mesmo.

"Para ser um bom borracheiro só é preciso capricho. Sem capricho não dá, as coisas saem mal feitas, a solda fica suja, não pega. Borracheiro sem capricho não tem futuro.”

Confesso que fiquei surpreso com a sabedoria do velho. Já contei essa história (que é verídica) algumas vezes pra gurizada que trabalha comigo. Costumo dizer que desenvolvedor que não tem capricho com o código não serve nem pra borracheiro.

[]s
Jack DelaVega

Leia Mais

Esse tal de Corporate Game - Parte 1

Quem acompanha esse blog a mais tempo sabe que uma das coisas que mais me tira do sério é o tal do Corporate Game. Já havia pensado em escrever sobre esse tema anteriormente, mas não havia encontrado o formato. Resolvi quebrar o assunto em capítulos. Vamos ver se funciona.

Como bom engenheiro, adoro começar pelas definições. Você já parou pra pensar no que é afinal esse tal de "Jogo Corporativo"? Por que é um jogo? E por que muitos dizem que se não aprendermos a jogá-lo ficaremos sempre à margem das organizações?

Bom, em primeiro lugar chamam de jogo porque ele tem regras. Na minha opinião, as semelhanças param por aí. Porque um jogo tem que ter um objetivo. E para mim não existe o menor sentido em jogar o Corporate Game. Ele é mais uma daquelas sabedorias populares (uma lida de Freakonomics ajuda a entender a idéia aqui) que vai passando de geração de empregados para geração de empregados, quando na verdade não existe fundamento nenhum por trás. Alguém poderá dizer: ah, o objetivo de jogar o Corporate Game é ter sucesso dentro da organização. Imensa besteira. Incomensurável idiotice. Como podemos generalizar sucesso? O que é sucesso para a minha carreira pode ser totalmente diferente do que para os outros. Vejo muita gente comentar: aquele cara chegou até aquele cargo porque sabe jogar o Corporate Game. OK, mas isso é ter sucesso? Se você anda admirando esse tipo de gente dentro das organizações, sugiro rever urgentemente o seu planejamento de carreira e de vida. É apenas a minha opinião, mas eu normalmente tenho asco desse tipo de gente.

Mas voltemos às regras. Ainda que falte um sentido mais nobre ao jogo, vamos aos princípios básicos. Parecem ser inúmeras as ramificações e adaptações das regras, mas tentei reduzí-las ao máximo aqui. Por favor postem as customizações que possam existir dentro das suas empresas nos comentários desse post.

Regra 1 - Você não pode ser o que você é, tem que ser também o que os outros esperam de você

Regra 2 - Você não pode dizer o que você pensa, mas também o que cabe

Regra 3 - Você não pode fazer as coisas do jeito que você gosta, mas também do jeito que os outros lhe pedem

Para mim essas são as três regras básicas do tal Corporate Game, ou como eu prefiro chamar, da hipocrisia generalizada que existe nas organizações. Ao longo da minha experiência, já me peguei inúmeras vezes praticando algumas dessas regras. Normalmente fico muito chateado, porque elas vão de encontro a alguns valores que tenho. O que acabo percebendo é que em inúmeras situações da minha vida sou autêntico, digo o que penso, etc. Mas dentro do dia-a-dia de trabalho, já me flagrei várias vezes interpretando essa espécie de dublê de mim mesmo.

Tenho certeza que acontece com vocês também. Por que a realidade é assim? Por que temos de ser um dublê dentro das organizações? Existe algo errado com isso? Uma organização teria mais sucesso caso promovesse uma cultura anti-hipocrisia?

Não percam os próximos capítulos.

Reggie, the Engineer.

--

Leia Mais