TDC 2010 - Impressões

Compareci ao TDC 2010 em Palhoça, no dia 06/11. O evento foi promovido pela VOffice de Florianópolis, em parceria com a GlobalCode. O evento teve várias trilhas, mas como voces podem imaginar, eu acabei indo na trilha Java (levando tres alunos meus da Assevim que consegui converter).

Diversos temas foram abordados: Ria em JSF, Ginga ( que inclusive me deu uma idéia pra um projeto de pesquisa, caso eu seja aprovado no mestrado ), JPA 2.0, EJB 3.0 e pra não fugir do lugar comum, uma palestra falava sobre o Futuro do Java.

Até aí tudo bem...afinal virou moda falar sobre o que a Oracle vai fazer ou deixar de fazer no "ecossistema Java". O que me chamou a atenção foi que a palestra foi ministrada pelo Bruno Souza (o Javaman). Logicamente eu já havia ouvido falar dele, lido diversos artigos escritos por ele e conhecia seu trabalho junto a Sun, mas nunca havia comparecido em uma palestra proferida pelo mesmo. Bruno falou com extrema propriedade sobre diversos temas recentes da plataforma Java, como por exemplo a aquisição da Oracle, o processo contra o Google e o futuro do Java. Acredito que as informações dele tranquilizaram o pessoal presente e elucidaram diversos fatos que não estavam muito claros. O Javaman toma o cuidado de sempre destacar a importância do software livre, fato que acho extremamente positivo. De qualquer maneira, saí de lá com a impressão de que os desenvolvedores Java ainda verão muitas coisas boas na plataforma.

Mas de todo o evento, o que mais me chamou a atenção foi outra coisa...foi o carinho que todos os presentes lá (num sábado de sol, com mais de 40 praias próximas) mostraram pela plataforma Java. Não vi em nenhuma palestra o símbolo da Oracle e duvido que isso tenha acontecido devido à falta de cuidado dos palestrantes. Todos, sem excecao, utilizavam o símbolo do Java e da própria Sun.

Talvez esse tipo de atitude demonstre um saudosismo meio sem finalidade prática, especialmente quando se fala em profissionais que trabalham com tecnologias de ponta, mas eu sou obrigado a confessar que compartilho do mesmo sentimento.

...you’re not here to write code; you’re here to ship products.

Outro post interessante de Joel Spolsky. Confesso que senti um certo alívio ao lê-lo.

Duct Tape Programmer

Boa Leitura...

if (relevante)

Algumas características das pessoas que trabalham com tecnologia da informação (geeks) realmente saltam aos olhos. Caso voce identifique alguma destas características em alguem que voce conheça, não a confunda com falta de educação...o problema é que o pensamento acaba por se tornar sistêmico. Veja alguns exemplos:

1) Filtro de relevência: se voce estiver conversando com uma destas pessoas e perceber que depois de uns 5 minutos de conversa ela passa a somente acenar a cabeça e dizer "é verdade"... "concordo"... "aham" ao final de cada frase sua, pode ter certeza que voce caiu no filtro de relevancia. Como funciona esse filtro? Simples, normalmente o profissional de TI tem MUITA coisa pra estudar SEMPRE e ele imagina, mesmo que inconscientemente, que o espaço um dia vai acabar, mais ou menos como em um HD. Por isso, caso sua conversa não se enquadre no que é considerado interessante, o pensamento é levado em outra direção e ele somente continuará na sua frente porque é o comportamento socialmente aceitável;

2) televisão: normalmente o geek assite a pelo menos 3 programas de uma vez. Por que? Eu tenho uma teoria de que isso é o mais próximo que dá pra chegar as múltiplas tarefas que o sistema operacional de um computador permite. Como ele entende? Provavelmente ele já assistiu aos 3 programas, e agora só está selecionando as melhores partes de cada um deles ( é uma especializção do filtro de relevância );

3) confundir a programação com a vida real: normalmente o geek imagina as coisas do cotidiano como objetos e interações entre elas ( a OO surgiu de observações feitas por Aristoteles ). Um exemplo disso aconteceu comigo mesmo. Recentemente tive que subir no forro lá de casa pra desligar a água que vinha da caixa pra casa. Chegando lá, percebi que existiam duas torneiras, uma que cortava a água da rede pra caixa e outra que cortava a água da caixa pra casa, só que sem documentação nenhuma. Depois de um teste, descobri qual era qual, peguei um pedaço de telha e rabisquei nos pilares:

// rede

// casa

Percebeu? Na minha cabeça, o // impediria o comentário de ser interpretado pelo compilador.
Não preciso dizer mais nada, certo?

4) Gosto pelo desafio. É simples assim...os geeks gostam de desafios...e enquanto não resolvem o problema não saem de cima. Tenho uma teoria de que isso começa na infancia, com os jogos de video-game. Que atire a primeira pedra quem nunca virou uma madrugada jogando Double Dragon no master system dando 30 voadoras pra ganhar vidas infinitas ( eu disse que tinha mais de 30 ) ou algo do gênero;

5) terminar sentenças com ; como se fosse um aviso para o compilador de que aquela sentença está concluída;

Se voce gerencia uma equipe de profissionais com essas características, esteja atento para utilizá-las em seu proveito. Se voce tem que conviver com um desses ( como minha esposa, por exemplo ) please don´t take this wrong e tente compreender que não fazemos isso por mal :)

Render-se Nunca...Retroceder Jamais

Eu cresci em uma cidade pequena do interior de SC chamada Taió ( procure no google maps ). Durante minha adolescencia, nossas principais diversões eram jogar video-game, jogar futebol ( analógico ), andar de bicicleta e assistir filmes. Era imperativo...TODO final de semana reunia meus amigos lá em casa pra assistirmos algum filme que pegávamos na locadora. Era VHS é claro... já passei dos 30 :) , mas era muito divertido. "O grande dragão branco", "retroceder nunca, render-se jamais", "condenação brutal", "O predador", "comando para matar" eram alguns dos clássicos que assistíamos.

Bons tempos...para matar a saudade segue abaixo o link de um trailer que me deixou com um sorriso no rosto. Só vale para quem tiver assistido aos filmes acima.

...América Vídeo...

Quem é o segundo pior programador da sua equipe?

Li hoje um artigo no Javalobby onde o autor comentava sobre um curso de DDD ( domain driven design ) ministrado pelo Eric Evans em pessoa onde ele avisava " Beware of the second worst programmer of your team". Vou aqui escrever um resumo sobre o que está no artigo e quem quiser ler com mais detalhes basta seguir o link que será passado logo abaixo.

A qualidade do código produzido por sua equipe é proporcional ao conhecimento ( skill ) de seu segundo pior programador. Por que? Bem, TODOS conhecem quem é o pior programador de sua equipe...não adianta fingir que não, TODO programador é egocentrico e caso ele não consiga ser o melhor, trata logo de identificar quem é o pior para não ficar na lanterna. Parafraseando um filme que só vi o começo( honestamente não lembro do titulo... ) se em 10 minutos de poker voce nao descobrir quem é o pato da mesa....VOCE é o pato, então cuidado com isso.

Voltando ao assunto...o pior programador da equipe sempre é fiscalizado pelo gerente ou team leader ou mesmo por outro programador que já teve que corrigir algo mal feito. O segundo pior programador normalmente faz o que quer e escreve o pior código, como uma corrente é tão forte como seu elo mais fraco...

Segue abaixo o link com o artigo na íntegra:
http://gojko.net/2008/10/07/beware-of-the-second-worst-programmer/