ericlemes

jul 252015
 

geekandpoke

O que me deixa preocupado sempre que vou escrever sobre um desses temas é que o leitor deve achar que eu não faço ou nunca fiz besteira na vida. Sim, eu fiz, e bastante. O que me deixa ligeiramente confortável em escrever um post desses é que talvez eu tenha aprendido um pouco sobre elas e ao menos percebo as falhas que antigamente nem sabia que estava cometendo.

A algum tempo, principalmente depois de observar melhor um “time” trabalhando junto motivado pela integração que as metodologias ágeis promovem, comecei a levar muito mais a sério o tema de soft skills, ou competências interpessoais ou habilidade de lidar com gente. Chame como quiser.

O fato é que desenvolvedores tem opiniões fortíssimas sobre muitas coisas e é muito freqüente ter discussões improdutivas simplesmente para saber quem está certo ou errado, sendo que muitas vezes os dois estão certos ou os dois estão errados. É bem desgastante para qualquer empresa, líder ou gerente administrar esses conflitos.

Quando estou entrevistando candidatos eu sempre gosto de puxar um pouco para esse lado. Tento colocar pessoas no time que não só possam trazer contribuições técnicas, mas também contribuições ao ambiente e à sintonia do time. E não é raro recusar candidatos muito bons tecnicamente porque eles não seriam bons para o time no aspecto pessoal. Escrevo esse post motivado por dois candidatos que recusei por causa dos soft skills.

Um dia eu li num desses posts sobre recrutamento uma ótima pergunta (eu não uso essa): “Conte-me sobre um conflito que você teve no ambiente de trabalho e como você fez para resolvê-lo”. Essa pergunta caiu que nem um raio na minha cabeça por duas razões: eu tinha dificuldade de reconhecer os conflitos que eu tinha e talvez nunca tivesse conseguido resolver um. Se me fizessem essa pergunta numa entrevista, eu seria recusado imediatamente.

Se você responde: eu nunca tive conflitos. Caramba… você é o mestre da convivência! Se você responde: já tive mas não consegui resolver, vc assume sua incompetência interpessoal. Se você não consegue citar um exemplo prático, você não consegue evidenciar que tem o skill e perde também. Bela pergunta, não?

Inspirado nesse tipo de pergunta, desenvolvi uma das minhas favoritas adaptadas a desenvolvedores: “Imagine que você está dando manutenção num sistema e recebe um código terrível. Como você lida com essa situação?”

Não, eu não vou dizer qual é a resposta que eu espero, porque meu objetivo é fazer você pensar (aquela pergunta do conflito me rendeu 6 meses de trabalho comigo mesmo), mas compartilho algumas respostas que recebi:

  • “Eu xingo ele (em tom de brincadeira)”. Mas não conseguiu responder a pergunta (interprete a resposta do jeito que achar mais conveniente)
  • “Eu sou adepto do ‘se não está quebrado, não conserte'”. Em outras palavras, eu não faço nada pra resolver o problema (nem técnico, nem interpessoal) e deixo ele lá.
  • “Eu provo pra ele que o código dele é uma porcaria”.
  • Uma longa pausa seguida de um “essa é uma pergunta complicada” e uma seqüência de respostas evasivas sempre levando a discussão mais para o problema técnico do que o pessoal.
  • Milhares de argumentos técnicos sobre o código ruim, sem nem considerar a hipótese de discutir o problema com o companheiro de equipe.

O interessante dessa pergunta e me motiva a escrever esse post é que são raras as respostas satisfatórias para essa pergunta. Quem nunca abriu um código e pensou “que p* é essa?” que atire a primeira pedra.

O fato é que desenvolvedores tem uma paciência enorme para ler um livro técnico de 1000 páginas mas não tem coragem de ler um livro pequeno sobre relações humanas, ou menos perceber a importância disso.

Quando estiver sendo gerenciado ou liderado por uma pessoa que não sabe programar, ou ganhando menos que um vendedor que não sabe o que vende e que vende o que você faz, sugiro que comece a pensar um pouco sobre essa pergunta. #ficaadica

fev 042015
 

Quem acompanha o blog deve estar sabendo que eu estou passando uma temporada (?) na Inglaterra. E sim, tem muito trabalho para desenvolvedor aqui, principalmente desenvolvedor bom.

A empresa que eu trabalho está procurando mais gente para compor o time. O que estamos procurando?

Em primeiro lugar, o processo ainda não está dando sponsorship para vistos. Mas se você tem nacionalidade italiana, portuguesa, espanhola ou de qualquer outro país da união europeia, você pode trabalhar aqui sem problemas e o processo seletivo vale para você.

Esse não é o job description formal, mas estamos procurando algo como:

  • Perfil técnico: C#/.NET, SQL Server, Web services (REST/WCF), etc. Coisas básicas como princípios SOLID, design orientado a objeto, design patterns também entram na conta
  • Práticas, processos, etc: metodologias ágeis, Test-Driven Development, pair programming, automação de build e release (obviamente isso inclui integração contínua, CI servers, MSBuild, NAnt ou qualquer coisa parecida).
  • Perfil pessoal: saber lidar com humanos (isso inclui humanos não-desenvolvedores), engajamento em comunidade, capacidade e receptividade para aceitar críticas no código e sugerir melhorias, trabalhar colaborativamente, etc.
  • Bonus: Desenvolvimento para devices (Windows CE/Mobile, Android, etc), conhecimento em virtualização com Vagrant, ferramentas de provisionamento como Puppet.

Ahhh, e se você pretende trabalhar e morar na Inglaterra, é realmente importante falar inglês!

Se quiser mais informações sobre a empresa e o produto, veja o vídeo abaixo:

Caso esteja interessado, me procure.

dez 292014
 

Os duendes de estatísticas do WordPress.com prepararam um relatório para o ano de 2014 deste blog.

Aqui está um resumo:

A sala de concertos em Sydney, Opera House tem lugar para 2.700 pessoas. Este blog foi visto por cerca de 21.000 vezes em Se fosse um show na Opera House, levaria cerca de 8 shows lotados para que muitas pessoas pudessem vê-lo.

Clique aqui para ver o relatório completo

dez 022014
 

Introdução

Durante os anos que tenho trabalhado como desenvolvedor ou liderando equipes de desenvolvimento, venho observando determinados padrões de comportamento nos desenvolvedores ou mesmo nas equipes.

Confesso que já pratiquei bastante esses padrões e caí nessas armadilhas. Superei alguns, outros ainda me pego fazendo e sempre tenho minhas recaídas. Não é fácil para nenhum desenvolvedor esse negócio de habilidades com pessoas.

Resolvi escrever esse post, com o objetivo de ajudar meus companheiros de profissão a superarem determinadas barreiras, seja para o crescimento profissional, seja para ter uma vida mais saudável.

Por que há tanto conflito em desenvolvimento de software?

conflitosA resposta mais correta, verdadeira e sincera é: não faço a menor idéia. Meu melhor palpite, eu compartilho.

Fazer software exige dos desenvolvedores muito esforço lógico e racional. O tempo todo lidamos com coisas abstratas (criamos coisas que a maioria das vezes não são vistas) utilizando linguagens de programação que por definição são linguagens extremamente rigorosas. A máquina não aceita erros. Se tem uma vírgula errada, não compila. Se tem uma instrução errada, compila, mas muitas vezes não funciona. Se deixamos passar um detalhezinho sequer, coisas ruins acontecem.

Dentro desse rigor, existe ainda a necessidade de criatividade. Para resolver problemas é necessário pensar em formas diferentes, caminhos diferentes para chegar na solução. Caminhos estes que precisam ser provados pelo mesmo rigor de um compilador, que não aceita vírgulas erradas.

Para tornar ainda mais complexo esse ambiente que mistura raciocínio abstrato com rigor matemático entra o ingrediente fatal: pessoas. Criar é difícil. Criar coletivamente é uma tarefa árdua. Cada um tem uma experiência diferente e opiniões diferentes sobre uma série de coisas. E o pior, você precisa conseguir sair com acordos desse ambiente para fazer qualquer coisa se movimentar em qualquer direção.

Esse acho que é o papel que mais gosto de ter nas equipes hoje. O de líder técnico. Pra mim o que esse cara faz é: ter conhecimento técnico suficiente para ser respeitado por sua equipe (desenvolvedor não se subordina a quem não respeita) e poder servir como uma espécie de bússola para orientar o time no sentido da solução, facilitar os conflitos e as decisões técnicas e propor as melhorias necessárias no ambiente para que o trabalho tenha fluidez.

Depois de tanto tempo vivendo diariamente esses conflitos, sendo a causa de alguns e a solução de outros, resolvi compartilhar algumas dicas que me ajudaram a encontrar um pouco de paz de espírito.

Muitos profissionais se questionam porque tem dificuldade de ter evolução na carreira e as razões que o impedem de participar de decisões importantes na empresa, produto ou projeto. Pode ser que esse post lhe ajude.

Distinguir perguntas com respostas objetivas de perguntas com respostas baseadas em opiniões

Para muitas coisas em tecnologia, existem respostas do tipo “certo e errado”. A maioria delas os compiladores, documentos de referência tem a resposta. Outras coisas como qual é o algoritmo mais rápido, é bem simples responder usando técnicas como análise de “Big O” ou mesmo implementando o algoritmo. Não é aqui que moram os problemas.

O problema são nas perguntas: Qual solução é melhor, qual é a pior? Pronto. Imediatamente um acha que o banco de dados resolve tudo, o outro acha que tem que por na nuvem, o outro acha que tem que desenvolver tudo do zero e começam as brigas.

As principais coisas que temos que saber é separar respostas objetivas de respostas baseadas numa recomendação ou opinião. Provavelmente no segundo caso se você perguntar para 10 pessoas diferentes, vai ter 10 respostas diferentes e provavelmente mais de uma certa.

A melhor coisa nesses casos é traçar cenários com prós e contras. Não perca tempo tentando convencer o outro que a sua solução é a melhor. O outro pode ter uma opinião diferente. Nesse caso o melhor juiz são os requisitos, as restrições de prazo, custo e recursos.

Saiba reconhecer que por mais que a sua proposta seja a melhor na sua opinião ou a mais bonita do ponto de vista técnico ela pode não ser escolhida por não atender as principais restrições ou objetivos de negócio da empresa. Isso não faz dela uma solução ou uma idéia ruim.

Viver num mundo em que duas pessoas podem ter opiniões diferentes

Esse está relacionado com o anterior. Ter uma opinião diferente ou não convencer o outro que a sua solução é melhor não faz você pior ou melhor do que ele. Apenas são opiniões diferentes sobre o mesmo assunto. Não seria um tanto quanto pretensioso achar que você está certo o tempo todo?

É importantíssimo aceitar que o outro tem uma opinião diferente, por mais que ela pareça absurda para você. Por causa dessa razão muitas discussões do tipo linguagem A é melhor que a B ou linguagem funcional é melhor que orientada a objetos e vice-versa acontecem. Discussões completamente sem fundamento sem um contexto.

Tirar bom proveito de discussões e saber o momento certo de pular fora delas

Se aprendemos a aceitar que o outro pode ter uma opinião diferente da sua, discussões passam a ter um sabor diferente. Invés de parecerem um duelo infinito que só termina quando o oponente sangra até a morte (ou simplesmente a energia esgota após ofensas intermináveis, como nas listas de discussão), a discussão passa a ser um palco para troca de experiências e aprendizado.

Quando você discute com uma pessoa com ponto de vista diferente do seu, tem uma oportunidade enorme de aprender uma nova perspectiva sobre um mesmo assunto. Invés de ficar tentando provar que o que você faz é o melhor, você passa a entender as razões por trás das ferramentas, técnicas e tecnologias utilizadas pelo outro. Logo, mesmo que no final das contas não concorde com ele, com certeza não sairá da discussão no zero a zero.

Em arquitetura esse tipo de discussão é riquíssima, pois mesmo tendo duas soluções, frameworks ou técnicas de design diferentes aplicados, conseguimos entender as motivações que fazem a pessoa escolher um caminho diferente e potencialmente as conseqüências da decisão tomada.

O melhor momento para pular fora de qualquer discussão é quando acaba a exposição de argumentos. Não tem mais o que explorar nos argumentos e ninguém mudou de opinião, muito bem. Vamos esperar entrar algum novo insumo na discussão para progredir à partir dali. Se uma decisão precisa ser feita, alguém vai ter que ceder. Então o próximo tópico pode ajudar.

Comprometer-se com aquilo que não concorda

Qualquer profissional consegue se comprometer e se engajar com aquilo que concorda. Por isso não é incomum aquelas cansativas reuniões que as pessoas empurram um compromisso goela abaixo, compromissos que são mais aceitos pelo cansaço do que pelo mérito.

Difícil mesmo é seguir adiante com aquilo que você não concorda. Ninguém quer ceder.

Se as conseqüências daquela decisão são pequenas, reveja sua posição. Será que não vale a pena abrir pequenas concessões para não levar aquela fama de inflexível na hora que precisar tomar uma decisão com impactos realmente grandes?

Se você percebe que está num impasse e vai ser impossível construir um consenso, justifique as razões que o fazem discordar daquela decisão, por exemplo, mostrando as possíveis conseqüências e mesmo assim se comprometa com ela.

O que para mim torna essa opção interessante é que mesmo muitas vezes sabendo que as coisas não estão do jeito que você gostaria, você tem a chance dos fatos ajudarem as suas idéias a ganharem mais força, enquanto ficando no impasse você tem a certeza de não ir para lugar nenhum, ou pior ainda, ser simplesmente tirado do jogo e não participar mais da decisão.

Sim, se você não tem participado mais das decisões críticas do seu projeto, pode ser porque você foi tirado do jogo por sempre se posicionar de forma dura e inflexível.

Nada como o tempo para resgatar boas idéias ou enterrar as idéias ruins.

Nunca critique sem ter uma proposta de solução

Essa é a mais clássica de todas. Todo dia ouço várias dessas: a arquitetura é uma bagunça, o projeto é um lixo, o usuário não sabe o que quer, o controle de versão é uma porcaria, e por aí afora.

Pense consigo mesmo e invés de levar as reclamações dessa forma, tente levar da seguinte forma: por que não fazemos a mudança “x” na nossa arquitetura, porque assim podemos tornar o produto melhor e mais fácil de manter? Por que não usamos a técnica “X” de escrever estórias para ajudar o usuário a definir melhor seus requisitos? Por que não instalamos o Git?

Você vai perceber que sua vida pode mudar. Quando você perceber como é difícil propor melhorias e vender os benefícios de determinadas mudanças começará não só a ponderar suas críticas como também a encorajar e apoiar as melhorias propostas por seus companheiros de time.

Vender soluções

A pior forma de fazer alguém concordar com você é impondo sua opinião. Cansei de ver desenvolvedor se descabelando para convencer outro usando abordagens do tipo: porque é certo, porque é assim que aquela empresa bacana com produtos na nuvem faz ou porque o fulano, ciclano ou beltrano falou que é o certo.

Esquece. Se você faz isso de uma forma impositiva, a pessoa vai discordar só pelo prazer de discordar e te deixar numa posição desconfortável.

Quando você pega uma pessoa dura nesse tipo de discussão, a abordagem que geralmente dá resultados é construir a solução em conjunto. Invés de simplesmente jogar a solução resolvida para
ela, jogue o problema. Ela vai apresentar uma solução. Coloque mais elementos que façam com que ela chegue a uma conclusão de que aquilo é uma má idéia. Quando aquele momento de desespero bater e ela soltar um: tá bom, se desse jeito não funciona, como funciona? Aí você coloca um pedaço da sua idéia como uma sugestão: “o que você acha de tentarmos isso?”

As vezes o que acontece também numa situação dessa é que você sai com uma solução melhor do que a que você pensou sozinho. As vezes simplesmente a pessoa tem uma idéia melhor.

O ponto central dessa idéia é que muitas vezes nós pensamos em diversas situações diferentes para chegar numa dada conclusão e como aquilo se torna óbvio para nós, esquecemos de repassar todo o processo que nos levaram a essa conclusão com nosso time, o que faz com que pareça que estamos “atropelando” toda a contribuição do outro.

Conclusão

O interessante deste processo todo é que quando você aprende a observar os seus comportamentos que o tornam uma pessoa difícil de lidar no time (por mais que sua intenção final seja fazer a coisa “certa”, de acordo com seu ponto de vista) e aprende o quão difícil é fazer isso, torna-se também uma pessoa mais tolerante com a falha do seu companheiro de time e aprende a levar a discussão de uma forma mais suave.

O que posso dizer por experiência própria é que quando você começa a encarar esses conflitos de uma forma mais natural e positiva, isso ajudará a trazer mais satisfação e felicidade para seu dia-a-dia.

Era isso!

nov 192014
 

Introdução

O objetivo deste post é explicar como subir uma nova instância de uma Wiki (mesma ferramenta da Wikipedia) num ambiente Linux/Debian. Como eu já fiz isso várias vezes e toda vez esqueço algum detalhe que me faz perder tempo, resolvi escrever esse post.

É possível subir instâncias da Wiki em Windows também, mas acredito que em Linux seja bem mais simples. Todos os softwares usados aqui são Open Source.

Particularmente, acho essa ferramenta espetacular para criar bases de conhecimento em qualquer empresa. A sintaxe no começo pode parecer confusa, mas uma vez que você se acostuma com ela, não a troca por nada. Tem o mesmo esforço de escrever um arquivo texto, com a possibilidade de ter formatação, links, edição colaborativa, controle de versão entre outras coisas.

O nível de segurança previsto para essa instalação é para uma intranet. Se você quer colocar uma wiki dessas na internet, deve se preocupar com várias outras questões de segurança.

Download do Debian

O primeiro passo é fazer o download da sua imagem de Debian favorita. No meu caso, usarei o Debian 7 64 Bits (https://www.debian.org/distrib/netinst, plataforma amd64).

Instalação do Debian 64

Siga os passos na tela. Não é necessário instalar a interface gráfica (o que torna a instalação muito mais leve).

Instalação da Wiki

Se você não habilitou por default o servidor ssh na sua máquina Linux, é uma boa idéia fazê-lo. É bem fácil e relativamente seguro acessar máquinas dessa maneira, mesmo vindo de uma máquina windows ou outra máquina unix.

No Windows, o cliente ssh mais popular é o PuTTY. Se você não habilitou o seu servidor ssh na sua máquina linux, basta instalar através do apt-get:

apt-get install ssh

Para descobrir o IP da sua nova máquina linux:

ip addr

Existe um método mais avançado de autenticação com SSH usando chaves pública e privada. Não é meu objetivo abordar esse método aqui, nem fornecer informações exaustivas sobre como configurar SSH.

Próximo passo é instalar os pacotes necessários para subir a MediaWiki. Como é baseado em php, você terá que instalar php, apache e outras coisas. É possível instalar em bancos de dados diferentes ou servidores web diferentes. Vou pelo que é mais comum: php e mysql. Você pode continuar absolutamente tudo dentro de uma sessão ssh, logado como root.

O primeiro passo, export DEBIAN_FRONTEND=noninteractive serve para evitar que várias configurações sejam solicitadas via terminal. Explicarei quais arquivos editar posteriormente.

export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get install apache2 -y
apt-get install php5 -y
apt-get install php5-intl -y
apt-get install php5-mysql -y
apt-get install php5-mysqlnd -y
apt-get install mysql-server -y
apt-get install php-pear -y
apt-get install php-apc -y

Se você não definiu uma senha para o usuário root do mysql, você precisará definir. Use o seguinte comando:

mysql -u root -e "set password = password('novasenha')"

Desconheço um empacotamento específico para Debian para a MediaWiki. Por isso sugiro usar os seguintes comandos para baixar e descompactar:

mkdir /root/temp
wget https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.6.tar.gz /root/temp
tar -zxf /root/temp/mediawiki-1.23.6.tar.gz --directory=/root/temp

Agora, para copiar os arquivos para o diretório de publicação do apache, excluir o index.html default do apache e dar acesso para a pasta de imagens:

rm /var/www/index.html
cp /root/temp/mediawiki-1.23.6/* /var/www -r
chmod 777 /var/www/images

Agora, usando um browser navegue na nova wiki: http://seuenderecoip

Você cairá nas páginas de setup da WikiMedia. Daqui em diante é tudo muito simples, uma espécie de next/next/finish. Algumas informações sobre o host do seu servidor mysql serão solicitadas (neste caso, mesma máquina e a senha do usuário root que você mesmo definiu).

No final ele pergunta algumas questões adicionais ou se você está entediado. Se você seguir para as questões adicionais, tem algumas coisas interessantes como:

  • User rights profile: Aqui você determina se quer uma wiki fechada ou aberta. Para a maioria das intranets, a opção “Account creation required” é interessante. Qualquer um pode criar uma conta, mas precisa de uma para editar. Isso pode ser interessante para manter um bom histórico de alterações nas páginas.
  • Extensions: SyntaxHighlight_Geshi é bem interessante para “pintar” trechos de código em wiki.
  • Enable file uploads também é bem interessante

Após terminar de configurar tudo, a Wiki gera um LocalSettings.php para você. Você precisa colocar esse arquivo no /var/www da sua máquina remota. Se você está numa máquina Windows controlando um host linux, pode ser um pouco complicado isso. Algumas coisas que podem te ajudar são: WinSCP ou se você tem um Git Bash na sua máquina ou um cygwin, usar:

scp /caminho/para/seu/LocalSettings.php root@seuipremoto:/var/www

Ao acessar novamente sua nova wiki por http, ela estará funcionando (assim espero).

Backup

Para fazer o backup das wiki’s, você precisa se atentar a duas coisas:

  • Dump da sua base mysql
  • Imagens

Para fazer o dump do mysql:

mysqldump -u root -psuasenhado seudatabasegeralmentemy_wiki > /algum/diretorio/temporario/seu_db.dump

Para compactar o dump e suas imagens:

tar -cvpzf /local/destino/do/seu/arquivo/seubackup.tar.gz /var/www/images /local/do/seu_db.dump

Para colocar seu backup no cron, veja /etc/crontab. O jeito mais simples é colocar um link simbólico (ver comando ln) em /etc/cron.daily. O horário que o script será executado depende do que está configurado em /etc/crontab.

Restore

Para descompactar seu backup:

tar -zxf /seu/arquivo/tar.gz

Para importar o dump no mysql (o database precisa ser criado previamente)

/usr/bin/mysql -u root -psuasenha seudatabase < /caminho/para/seu_db.dump

As imagens, é só copiar de volta no diretório.

nov 142014
 

Recentemente, me vi diante de um processo de mudar de país. Quando esta idéia começou a se tornar possível, me vi, da noite para o dia com uma infinidade de coisas para resolver, num tempo muito curto e coisas que não tinha a menor idéia de como resolver. Como lidar com a saudade, pedir demissão do emprego, decidir o que eu vou fazer com o cachorro, decidir o que levar, desmontar a casa, passar procuração, resolver visto, fazer um planejamento financeiro, reservar vôo, tirar carteira de motorista internacional, ver onde ficar temporariamente até alugar uma casa, alugar uma casa em outro país, vender o carro, cancelar contas de prestadores de serviços (água, luz, internet, TV), fazer despedidas para os amigos e família e sai lá quantas outras coisas.

É muito difícil descrever como é essa sensação. Parece que você caiu de pára-quedas no meio de uma guerra.

Se nesse momento, eu tentasse resolver de uma vez só todos os problemas, provavelmente desistiria de tudo. Seria muito mais cômodo deixar tudo como estava. Mudar era um processo cheio de incertezas, riscos e custos.

Como um bom geek, resolvi atacar esses problemas como um projeto. Fui no visualstudio.com, montei meu projeto e comecei a organizar um backlog. Primeiro as estórias (cada uma das coisas que relacionei acima, tratei como uma história pois tinham objetivos e entregáveis bem definidos) depois a prioridade. O que é mais importante e o que tem maior risco primeiro. Depois quebrei o backlog em tarefas, numa idéia de entender o que precisava fazer para atingir aquele objetivo.

Mesmo nos casos onde não tinha a menor idéia de como resolver, como: tirar carteira de motorista internacional, lançava as atividades possíveis como “entender o processo de tirar carteira de motorista internacional”. Coisas como “tirar o visto”, lançava os formulários que tinha que preencher, os documentos que tinha que providenciar, as perguntas que tinha que fazer e as incertezas que tinha que eliminar.

Quebrei a complexidade das coisas definindo sprints. Criei uma primeira sprint com as coisas prioritárias para tornavam o processo viáveis. Nessa sprint entraram: visto, cachorro, pedir demissão e vender carro.

Depois fechei uma segunda sprint com as coisas que precisava viabilizar no processo da mudança. Casa, despedidas, onde ficar temporariamente, vôo.

Por último, deixei as coisas que só poderia resolver quando chegasse no outro país como: carro (se ia querer ou não) e alugar casa

O que é interessante é que a partir do momento que você comecei a definir objetivos menores para atingir um objetivo maior, definir atividades concretas e priorizar, a confusão mental decorrente de toda a incerteza existente no processo começou a ser eliminada. Toda a energia que era gasta com ansiedade e dúvida, passou a ser gasta em resolver de fato os problemas. O simples exercício de tomar notas, tirar as coisas da cabeça e torná-las tangíveis num backlog, abriu o espaço necessário para encontrar soluções.

O processo de quebrar em sprints me ajudava a manter o foco. De nada adiantava eu investir esforço no que estava na 2a ou 3a sprint sem resolver os problemas da primeiro. Isso me ajudava a lidar com a procrastinação. Aquelas coisas importantes, porém chatas de resolver, ficavam evidentes.

Isso foi determinante para viabilizar o objetivo de mudar para o exterior. A medida que eu atacava os problemas conforme a prioridade definida e encontrava as próximas atividades para as coisas que não sabia de antemão, mais aprendia sobre o processo e mantinha o controle dos próximos passos. Isso foi gerando um círculo virtuoso.

Em alguns meses, pouco a pouco, todos os obstáculos foram removidos. Quando menos percebi, estava dentro do avião pronto para recomeçar do outro lado do oceano. Meus agradecimentos ao mindset ágil por essa conquista.

E qual a relação de mudar para fora do país com metodologias ágeis no contexto de desenvolvimento de software?

Todo projeto de fazer um novo software é cheio de incertezas. Você precisa entregar algo que não sabe o que é, que provavelmente nunca foi feito antes, com tecnologias que você não conhece direito e com pessoas que nunca trabalhou antes. O primeiro passo é reconhecer claramente tudo isso. Saber o que fazer é provavelmente cerca de 50% do processo.

Quando você encara isso de uma maneira direta, sincera e honesta, move seu cérebro no sentido da solução. Sua cabeça foca em qual é a melhor alternativa que tem em mãos para atacar cada um desses objetivos. Se você simplesmente tentar prever todas as variáveis possíveis até o final do projeto, vai gastar muito mais energia que possui e provavelmente jogar a toalha no meio do caminho. Vai gastar tanto tempo tentando montar um plano infalível que vai acabar não executando nada deste plano por falta de tempo.

Vai ficar o tempo inteiro tentando fazer a realidade se encaixar no seu plano e não planejar de acordo com a as possibilidades existentes.

No final das contas, acho que é isso que as metodologias ágeis me ensinaram: como lidar com incertezas com naturalidade.

nov 032014
 

Pessoal,

Recentemente, comecei uma nova oportunidade profissional, agora em outro país.

Para não misturar assuntos desse blog (profissional, para desenvolvedores) com outros assuntos, criei um blog separado, o “4 malas e o mundo” (4malas.com.br) para compartilhar um pouco das outras experiências de viver aqui (na Inglaterra).

O primeiro post: Como arrumar emprego na Inglaterra já é um que é interessante para os dois blogs. Terão vários cross-posts.

Caso interesse, apareçam por lá! Aproveitem e cliquem bastante nos Ad’s do outro blog para me ajudar a financiar a empreitada!

Abraço,

Eric

ago 052014
 

Pessoal,

Novamente fui convidado para palestrar no TDC este ano (The Developers Conference) que será na universidade Anhembi-Morumbi. O evento começa em 06/08/2014 e termina em 09/08/2014.

Estarei palestrando na sexta-feira, dia 08/08 na trilha Arquitetura.NET. Esse ano o tema é “A influência dos processos de desenvolvimento na arquitetura”.

Se estiver no evento, será muito produtivo um bate papo presencial sobre tecnologia ou outros temas abordados aqui no blog.

Até lá!

jun 142014
 

6a0120a85dcdae970b012877701400970c-piJoseph Yoder estará ministrando um curso de TDD e Refactoring no Brasil!

Pra quem não conhece o Yoder, ele é um dos fundadores da Refactory, Inc., ao lado do Ralph Johnson e associados como a Rebecca Wirfs-Brock.

Sim, o Ralph Johnson, é um dos quatro da Gang-of-Four, autores do Design Patterns: Elements of Reusable Object-Oriented Software, na minha opinião, uma das pedras fundamentais da nossa profissão.

Em resumo, uma oportunidade talvez única realizar esse curso e conhecer uma figura ímpar como o Yoder. As inscrições podem ser feitas neste link