Archive for January, 2010

Última Parada no Brasil: Vejo Vocês no Rio!

Thursday, January 28th, 2010

Tem um tempinho que comentei sobre os eventos de recrutamento da ThoughtWorks Brasil (não tem porque fingir que não e chamar os eventos de outra coisa, este é o objetivo! Uma surpresa boa é que a Suzi, de quem falei no último post, me pediu para ajudá-la com o evento do Rio, que será realizado no próximo Sábado, dia 30:

Host: ThoughtWorks Brazil
Date: Saturday, 30 January 2010
Time: 09:00 - 13:00
Location: Mercure Botafogo, Sala Petrópolis, Rua Sorocaba, 305- Botafogo
Description
ThoughtWorks is hiring in Porto Alegre. We recognise that not everyone’s lucky enough to live there yet, so we’re giving people in Rio the opportunity to find out more about us and to take our assessments :-)

Please note that we do not currently have plans to open an office in Rio. Please only come to this event if you are serious about relocating to Porto Alegre in the next couple of months. I will beat you with twigs if you come along and don’t want to relocate.

ThoughtWorks’ hiring process includes some assessment tests. Many ThoughtWorkers consider them fun, although they are challenging. We’re running some sessions for you to take them and to give you a chance to find out more about ThoughtWorks.

We are currently hiring Java developers and testers with automation experience. To be considered for a developer role, you’ll need to convince us that you’re already a pretty good Java/Ruby/C# developer who’s passionate about software development, team work and Agile development. Testers can come from a variety of backgrounds, but you’re going to be open-minded about a whole new way of testing.

While we usually start our hiring process with a telephone interview, we’re mixing it up a bit and giving people the opportunity to take our assessments first. The next stage, for developers, is to write some code and testers will do a telephone interview.

If you haven’t already, please send your CV to work@thoughtworks.com and questions to suzi@thoughtworks.com, or post on here. You only need to attend one event, and numbers are limited to 25 people per session. It would be great if we know in advance that you are coming. So, if you plan to attend, either accept on here or email me.

Mais detalhes na página do Facebook do evento. Você deve ir na página e dizer que vai para prepararmos o evento, qualquer dúvida me mande um email.

Infelizmente eu não vou ter muito mais que algumas horas para ficar no Rio, mas vai ser uma ótima oportunidade para conhecer e bater um papo com as pessoas que têm interesse em trabalhar para a ThoughtWorks. Não perca esta oportunidade!

Domain-Driven Bolovo, Passando Conhecimento e etc.

Monday, January 18th, 2010

Segue uma seqüência aleatória quase coesa de pensamentos que me vieram a cabeça enquanto esperava meu vôo para Salvador.

Paulo Silveira surgiu com o termo BOLOVO, usado para indicar uma arquitetura baseada em VOs e BOs, enquanto preparávamos os slides para nossa apresentação em conjunto no JustJava em 2007.

O artigo original sobre BOs e VOs fala basicamente sobre como a arquitetura proposta por EJBs na especificação antiga (2.x) prejudicou o entendimento da comunidade em geral sobre como criar a aquitetura de uma aplicação.

Três anos se passaram mas o artigo ainda recebe um numero de acessos razoável –e eu vivo prometendo que vou atualizá-lo. A última vez que tive que escrever um EJB 2.x foi em 2007, desde então –talvez por sorte- nunca mais entrei em um projeto que usasse estas aberrações. Muitos programadores de hoje em dia começaram suas carreiras na época que EJB já estava morrendo e nunca tiveram o desprazer de lidar com esta porcaria. É de se esperar que estas pessoas, tendo estado sempre cercado por IoC, DDD e técnicas bem razoáveis, iria olhar para um artigo como o que escrevi da mesma forma que eu olho para um livro de linguagem de máquina para Apple II –interessante no contexto histórico mas quase que apenas uma curiosidade.

Vira e mexe, entretanto, eu sou lembrado do porque o artigo ainda recebe tantas visitas todo dia. Os programadores mais novos podem não ter sido influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.

Quando estava preparando a primeira iteração do workshop de Domain-Driven Design que faço em parceria com a Caelum eu escrevi um texto para explicitar meu raciocínio sobre como Domain-Driven Design se difere de Orientação a Objetos. No workshop em si eu dediquei boa parte da manhã falando sobre este tema.

E por quê? Porque da mesma maneira que as pessoas utilizavam os conceitos de EJB completamente fora de contexto o mesmo está acontecendo com Domain-Driven Design. É bem comum, em uma conferencia ou algo do tipo, alguém vir conversar comigo sobre como a empresa dele está eliminando todos os BOs e VOs. No meio da conversa a pessoa começa a me explicar a arquitetura e eu vejo que praticamente o que eles fizeram foi renomear UsuarioBO para UsuarioService e UsuarioVO para Usuario. Repositórios, então… estes são tão mal utilizados que deram origem à vários textos aqui:

Independente do uso de DDD e seus padrões ou não eu realmente esperaria que, em 2010, as pessoas já houvessem entendido como objetos deveriam ser criados. A quantidade de material disponível gratuitamente na Internet e em múltiplos idiomas é ridiculamente grande.

Me levou muito tempo para entender que não importa a quantidade de material disponível. Em minha experiência, a maneira mais eficiente de introduzir estes conceitos é programação em par. Quando um cliente me chama para introduzir estes conceitos em seu time eu sempre tenho que tentar explicar porque isso não pode ser apenas um treinamento. Ë difícil de entender porque eu posso treinar alguém em algo complexo como uma linguagem de programação mas não em uma técnica com mais de 40 anos que exige como pré-requisito nada mais que conceitos lógicos básicos. Eu, pessoalmente, não faço a menor idéia do porque as coisas são assim, só sei que o são.

Normalmente eu começo o trabalho com uma apresentação rápida, apenas para tentar fazer as pessoas entenderem o que diabos eu vou tentar fazer. Um exemplo de uma destas apresentações:

E logo depois começamos a parear. O ideal é termos pelo menos 1 coach para cada dois pares, mas nem sempre este número é viável. Quando a quantidade de pessoas exceed muito a quantidade de coachs a melhor solução parece ser pareamento promíscuo, mudando os pares em intervalos bem curtos de tempo.

Nestes últimos anos eu tive diversas oportunidades de reencontrar clientes e parceiros depois da conclusão do projeto ou treinamento. Na minha experiência os times que tiveram apenas treinamento retêm apenas uma ou outra coisa do todo, eles entendem o todo mas não conseguem aplicar na prática –e aí mora o perigo do Domain-Driven BOLOVO. Os times onde utilizei coaching como meio de transmissão de conhecimento tendem a ser o contrario: eles usam as técnicas no dia-a-dia mas não entendem o todo. Ao não entender o todo eles não conseguem evoluir alem do que o que lhes foi passado durante aquele período.

É de se esperar que o primeiro grupo seja mais valioso para um empregador. Na prática, entretanto, não parece ser o caso. Um treinamento, um livro, etc. podem curar a deficiência do segundo grupo e tendem a ser bem mais baratos e eficientes que gastar dinheiro com um consultor que cobra por hora. O grande benefício que o consultor vai te trazer é que ele sabe –ou deveria- como utilizar aqueles conceitos na prática. O melhor uso do consultor neste caso é trabalhar com o time no dia-a-dia e realizar pequenas sessões de treinamento –no meu caso geralmente isso significa 20 minutos por semana- conforme necessário.

ThoughtWorks Brasil: Pronto para Mudar?

Thursday, January 14th, 2010

Estava eu nas minhas férias na bucólica Hamilton island quando recebi um pedido vindo direto da ThoughtWorks Brasil: um cliente precisava de mim por quinze dias. Assim que retornei da ilha passei em casa, desarrumei as malas, as arrumei novamente com menos roupas de banho e embarquei para minha terceira cidade favorita no Brasil, Salvador -primeira e segunda são Niterói e Rio, claro. É de cá que vos escrevo.

Quando começamos a pensar em montar um escritório da ThoughtWorks no Brasil nós sabíamos que este tipo de coisa ia acontecer. Não só é muito difícil achar bons candidatos para entrar no nosso time local – e se você tem que recrutar pessoas sabe que isto é um problema bem comum – mas também, mesmo se preenchermos todas as nossas vagas em um só dia estes novos ThoughtWorkers ainda precisam de algum tempo de casa para trabalhar em posições mais delicadas, como fazendo coaching, que é o caso.

Mas… e você com isso? Pois é aí que você entra!

Ainda estamos recrutando. A Suzi Edwards – que foi quem fez meu processo de seleção e contratação quando morava na Austrália – vem organizando diversos eventos de recrutamento por todo o pais. Por que tantos eventos? Porque não é fácil achar bons candidatos, vocês se escondem muito bem. Além disso, a última coisa que nós queremos é perder a chance de contratar um bom candidato só porque ela ou ele não pode ir à Porto Alegre fazer suas entrevistas.

O próximo grande evento será em São Paulo dia 23 de Janeiro. Você precisa se informar que vai (RSVP) na página do evento no Facebook para participar – a Suzi precisa ter uma idéia de quanta gente esperar.

A parte mais importante, entretanto, é que o recrutamento é focado em pessoas de São Paulo (assim como outros lugares do pais terão sua vez) mas a vaga é para Porto Alegre. Colando do Facebook:

ThoughtWorks is hiring in Porto Alegre. We recognise that not everyone’s lucky enough to live there yet, so we’re giving people in Sao Paulo the opportunity to find out more about us and to take our assessments :-)

Please note that we do not currently have plans to open an office in Sao Paulo. Please only come to this event if you are serious about relocating to Porto Alegre in the next couple of months. I will beat you with twigs if you come along and don’t want to relocate.

ThoughtWorks’ hiring process includes some assessment tests. Many ThoughtWorkers consider them fun, although they are challenging. We’re running some sessions for you to take them and to give you a chance to find out more about ThoughtWorks.

We are currently hiring Java developers and testers with automation experience. To be considered for a developer role, you’ll need to convince us that you’re already a pretty good Java/Ruby/C# developer who’s passionate about software development, team work and Agile development. Testers can come from a variety of backgrounds, but you’re going to be open-minded about a whole new way of testing.

While we usually start our hiring process with a telephone interview, we’re mixing it up a bit and giving people the opportunity to take our assessments first. The next stage, for developers, is to write some code and testers will do a telephone interview.

If you haven’t already, please send your CV to workthoughtworks.com and questions to suzithoughtworks.com, or post on here. You only need to attend one event,and numbers are limited to 25 people per session. Iit would be great if we know in advance that you are coming. So, if you plan to attend, either accept on here or email me.

To pre-empt some questions:
I am not available at those times. Can I still meet you?
We’re running three sessions and these will keep us busy, so we’re unable to accommodate requests for meetings outside of these times.
I’m away this weekend. When will you be back?
Not sure, but don’t stress. We’ll be back soon.
If I do not live in Sao Paulo, should I fly to this event?
Nope. We’re getting organised on coming to other cities. We don’t suggest people spend money on flying to cities for assessments.
When are you coming to Rio?
Very soon :-)
I am looking to be a Project Manager. Can I come along?
Not recommended. We are not hiring Project Managers at the moment.
Can I tell my friends and pass this along?
Of course!

Our assessments take about three hours and we will be running three sessions this weekend.

Mudar de cidade pode ser algo muito brusco, mesmo que seja para uma cidade próxima. O que é preciso entender, no entanto, é que o único modo de não cair no mesmo lugar é mudar o caminho tomado. E muitas vezes na vida precisamos fazer esta mudança bruscamente.

Te vejo no Away Day.