Herberth Amaral Software development adventures

25Dec/093

Boas Festas!

Galera, aí vai meu voto de boas festas:

lol

Brincadeiras a parte, espero que todos nós tenhamos um 2010 melhor que o 2009. Boas festas :D

  • Share/Bookmark
Tagged as: 3 Comments
21Dec/096

Foco e produtividade – A tecnica do Pomodoro.

O que?! Vai dizer que você caiu nessa denovo?

Quem nunca passou por uma situação parecida com essa aí de cima que jogue a primeira pedra!

1 - O problema

Esse tipo de situação acontece com muitos profissionais todos os dias. E, no meu ver, o principal problema é a liberdade. Digo, não a liberdade em si, mas o seu mau aproveitamento. Muitos de nós, profissionais de TI, não somos questionados sobre o que estamos acessando e que horas estamos acessando, desde que entreguemos tudo no prazo. Daí você já viu: hora extra, noites sem dormir e finais de semana em casa para cumprir com aquele prazo...

Várias metodologias foram criadas para sanar o problema da procrastinação. Uma delas é o famoso Getting Things Done (GTD) ou no seu título em português: A arte de fazer acontecer. O GTD tem seus pontos fortes e fracos. Dos pontos fortes, o principal é que ele fornece um "framework" para organização de vários níveis de tempo: desde de como vai ser cada hora do seu dia até planos para daqui dez anos. O ponto fraco é quase o mesmo que dá o ponto forte, pois, por ser um "framework", ele é genérico. A maioria das coisas que eu li nele são simplesmente frutos do bom senso comum.

2 - A Técnica do Pomodoro

A técnica do pomodoro é um pouco diferente. Ela é simplesmente prática, vai direto ao ponto e é bem simples: você trabalha 25 minutos, pausa 5, trabalha mais 25 e pausa mais 5 e assim por diante. Cada 25 minutos corresponde a um Pomodoro. Depois de 4 pomodoros, você pode fazer uma pausa maior (25 minutos).

Cada Pomodoro é indivisível, ou seja, você não olha seu Twitter, email, chat ou responde à sua mãe quando ela pede uma sugestão pro almoço durante estes 25 minutos. Totalmente focado no trabalho. A mágica da técnica do Pomodoro é que você sabe que você terá seus 5 minutinhos de descanso pra olhar seu Twitter, seu email, zuar o colega do lado e talvez até beber uma água (e esse tempo geralmente dá pra fazer isso tudo! Experiência própria.)

Essa explanação foi bem básica. Você pode conferir mais detalhes no livro disponível gratuitamente em PDF.

3 - Um pouco de história

A técnica foi criada por um sujeito italiano chamado Francesco Cirillo. O Francesco estava passando por maus bocados com os estudos pois ele não conseguia se concentrar nos estudos. Foi aí que ele olhou pra cima de sua geladeira, viu um Pomodoro (aqueles timers em forma de tomate que são usados na cozinha) e pensou consigo mesmo: "Será se eu consigo me concentrar só nisso durante 10 minutos?". Dito e feito. O sujeito pegou o timer, ajustou pra 10 minutos e desceu a lenha no livro. Wow! E ele conseguiu se concentrar por 10 minutos.

Vai um tomatinho aí?

O episódio descrito acima aconteceu em meados da década de 1980. De lá pra cá, ele vem experimentando diferentes timeboxes (diferentes tempos para o Pomodoro), também vem ministrando palestras e organizando workshops e chegou na conclusão que 25 minutos é o tempo que funciona bem para maioria das pessoas. Mas isso é somente um conselho, você pode colocar um timebox mais curto ou mais longo, dependendo da sua necessidade.

4 - Mãos à massa! Já!

Com o GTD você tem N desculpas para procrastinar. Com o Pomodoro não. São apenas 25 minutos, o que é que lhe custa? Teste por uma ou duas horas e veja qual foi o resultado.

Há pessoas que tem dificuldade (ou preguiça) de fazer a lista de tarefas e ainda sim utilizam a técnica do Pomodoro. Elas conseguem sucesso porque conseguem eliminar a ansiedade. Elas sabem que terão os 5 minutinhos pra fazer o que está em segundo plano e sabem que isso irá faze-las render no trabalho.

5 - Minha experiência

No início é cansativo. Os 25 minutos não parecem passar nunca e os 5 minutos são simplesmente muito curtos. Dá vontade de desistir. "Po, isso não é humano", pensei eu. Mas depois de dois dias de trabalho utilizando a técnica eu já consegui me acostumar.

Hoje eu tenho 4 meses de Pomodoro. Cinco minutos é tempo suficiente pra fazer muita coisa. De fato, 5 minutos hoje parecem mais suficiente para muita coisa. Eu tenho um nível de produtividade que eu invejável pelo Herberth de 4 ou 5 meses atrás, não sofro mais da ansiedade do email não lido ou do tweet não respondido, não tenho medo de ignorar o Google Talk (tem uma parte do livro que fala como lidar com interrupções, é bem interessante) e meu serviço rende bem mais.

O mais legal de tudo é quando as pessoas começam a sincronizar pomodoros. Além de divertido, essa forma de fazer as coisas ajuda para que você não desista.

6 - Timers para o Pomodoro

Bem, eu imagino que a maioria das pessoas que estão lendo esse post não tem um timer de cozinha. Então, há alguns programinhas legais para ajudar você a praticar a técnica do Pomodoro. Segue a lista de alguns deles:

(Essa lista pode aumentar. Comente esse post se você achar um que não está listado aqui).

Galera, acho que é isso. Bom Pomodoro pra vocês também!

P.S: Esse post foi escrito com 2 pomodoros e duas interrupções. Nesse meio tempo eu tive 14 tweets não lidos (thank you, ChromedBird), 4 emails a mais na minha caixa de entrada, duas conversas não respondidas no Google Talk e minha mãe realmente pediu uma sugestão para a janta :)

  • Share/Bookmark
19Dec/090

Ano novo, coisas novas pra aprender.

Esse ano foi o melhor da minha vida em questões profissionais e de conhecimento. Desses 6 anos que eu me interesso por TI, esse foi o que eu mais aprendi e o que mais me agregou experiência. Vou começar com uma retrospectiva antes de passar para o planejamento:

1 - Retrospectiva

A Infobits, juntamente com seu Grupo de Web, me deu experiência mais gerencial, mesmo coordenando poucas pessoas. Eu era e ainda sou um cara muito técnico e participar de um projeto como esse, em que eu tinha que coordenar e orientar pessoas, me ajudou a ver o outro lado da moeda. Sair do nível técnico para o gerencial é complicado. Ainda bem que eu tenho uma equipe pequena agora: menos gente, menos preocupação, mais comunicação, mais ágil.

Ter sido demitido foi uma das experiências mais marcantes que tive. Mexeu com meu ego (que por sinal não é pequeno) e eu me focei a ver o que eu tinha feito de tão errado pra ter merecido isso, já que boa parte da justificativa do meu ex-chefe não fazia sentido pra mim. A retrospectiva de um ano de empresa  foi uma coisa tão foderosa, que eu atribuo mais de 80% do meu conhecimento adquirido neste ano às coisas que eu aprendi nesse processo. Até brinquei com um amigo esses dias, dizendo que se eu soubesse o quanto isso te faz evoluir, eu procuraria ser demitido mais vezes. Por exemplo, eu não teria tido o interesse ou a iniciativa de ter ajudado a iniciar o nosso Coding Dojo se não tivesse sido demitido.

Vendo pelo lado acadêmico, esse ano também foi o mais produtivo: eu apresentei e publiquei 6 trabalhos e pretendo seguir o ritmo no ano que vem, mas mais voltado pra minha linha de pesquisa (Recuperação de Informação).

Quase ia me esquecendo do Coding Dojo: apesar de termos somente duas reuniões até agora, eu tou colocando muita fé nele.

2 - Para o próximo ano

Enfim, foi um ano cheio e eu estou prevendo que o próximo ano não será muito diferente, pois será o ano que eu irei me graduar. Daí vocês já tiram: monografia "comendo solta" o ano inteiro :)

Seguindo o conselho dos Pragmatic Programmers de aprender ao menos uma linguagem por ano, eu vou escolher as minhas aqui agora:

Lua

Lua é uma linguagem de programação brasileira que tem atraído muita gente no exterior, mas é pouco conhecida/valorizada aqui no Brasil. Pelo que eu pude ver, Lua é uma linguagem de altíssimo nível, bonita, elegante e que pode me ensinar alguma coisa valiosa. Outro motivo por escolher Lua é minha vontade de aprender mais sobre programação funcional. Isso me passa para a próxima linguagem:

200px-Scala_logo

Pra mim, Scala começou a ganhar atenção quando o Twitter começou a substituir Ruby por Scala no seu backend. Mas não é somente por isso que eu escolhi Scala em detrimento de Haskell, Erlang, Scheme ou Lisp. Eu realmente queria aprender todas elas, mas acho que Scala pode ser um bom começo. O objetivo é aprender programação funcional, certo? ;)

ruby

Esse ano eu comecei a aprender Ruby para apresentar um trabalho. A linguagem é legal, mas eu ainda estou longe de ser um cara competente em Ruby. Por isso, Ruby vai ser uma das linguagens que irei aprender no próximo ano. Ruby é bastante usada em alguns Coding Dojos do mundo todo e por isso vai ser legal usar Ruby no DojoMoc.

3 - Além de programação

Eu ainda pretendo continuar com meus estudos sobre desenvolvimento ágil, voltado principalmente para técnicas de desenvolvimento (pair programming e TDD, principalmente), automatização de tarefas de produção de software, produtividade e arquitetura de software.

No meio acadêmico, eu pretendo procurar aplicar tudo isso aí em cima no processo de desenvolvimento do produto que será minha monografia (fazer um crawler de pequena/média escala não é tarefa fácil...). Pretendo também continuar publicando pra ver se em 2011 eu já entre em algum programa de mestrado, mesmo como aluno especial.

Ultimamente eu tenho pensado muito em desenvolvimento OpenSource. Ontem mesmo eu fiz um hack para a lib de autocomplete do jQuery para substituir a YUI numa página que eu estou mexendo no trabalho e pretendo tirar as gambiarras melhora-lo para disponibilizar pra galera. É coisa pequena, mas é um começo :)

Agora é esperar 2011 chegar e ver se eu consigo cumprir pelo menos a metade disso aí :P

4 - Livros

Ganhei alguns livros no meu aniversário e tenho outros encostados. São eles:

  1. O Silmarillion - J.R.R Tolkien
  2. O Caçador de Andróides - Philip Dick
  3. As Crônicas de Nárnia - C.S Lewis
  4. Eragon - Christopher Paolini

Há alguns outros que eu não tenho que eu quero ler:

  1. Blue Ocean Strategy, uma sugestão do Fábio Akita.
  2. The art of Unit Testing - Osherove Roy
  3. Clean Code: A Handbook of Agile Software Craftsmanship - Uncle Bob.
  4. The Art of Agile Development - James Shore
  5. Agile Estimating and Planning - Mike Cohn

Esses são os maiores títulos. Não sei se consigo dar conta de ler todos eles com uma monografia a fazer, mas não custa tentar :)

Até mais!

  • Share/Bookmark
10Dec/0910

“A gente nao quer so codigo… a gente quer codigo, controle de versao e bug track”

Tá certo. A paródia da música dos Titãs não ficou boa. Mas acho que já deu pra sacar do que este post trata.

Enfrentar as matérias de programação na faculdade para quem já trabalha com desenvolvimento deve ser um saco para muita gente. Os professores geralmente não trabalham na área, não sacam nada além da linguagem e ainda tem coragem de nos fazer de trouxa, explicando como é a sintaxe da linguagem, como fazer algumas coisas básicas (leia-se CRUD) e acham que está tudo ok. Não está. Óbvio que não. Então, eu tenho algumas coisas a dizer para tais professores (e para os alunos também).

1 - Ensinar algumas coisas sobre a sintaxe e mostrar um CRUD não é o suficiente.

Precisamos mais além disso para desenvolver um trabalho final decente. Nós, alunos, precisamos aprender a nos virar, mas precisamos saber com o que devemos nos virar. Coisas básicas como indentação de código deveria ser cobrada. Separation of Concerns deveria ser incentivado e cobrado desde o início, por exemplo.

Não serei injusto. Algumas coisas como "comente seu código para documenta-lo" nos é ensinada. Isso é importante para quem está começando, pois saber se orientar dentro do próprio código é uma boa. Mas é algo insuficiente. Eles não ensinam como código pode ser autodocumentado, como bons nomes de variáveis podem ajudar nisso, como codificar "de cima para baixo" e outras coisas relacionadas a codificação.

2 - Nos passar trabalhos em grupo não necessariamente nos ensina a trabalhar como uma equipe.

Há vários trabalhos finais para fazermos e a forma mais fácil de fazer isso é deixar um para cada um. Dá pra eliminar vários problemas de comunicação e sincronização de código assim. Acho que já deu pra perceber que não aprendemos muito sobre ferramentas para desenvolvimento em equipe...

Quem for tentar desenvolver em equipe, provavelmente o fará enviando código por email, trocando pen-drives ou enviando via compartilhamento de arquivos, se tiver na mesma rede (impressionante, mas já vi "profissionais" trabalhando assim) e notarão o trabalho que isso dá. Obviamente, dá pra notar que não tivemos uma aula sobre controles de versão...

3 - O trabalho não acaba com a entrega...

Quem trabalha com desenvolvimento de software há um tempo sabe do que eu estou falando. De acordo com esse paper, mais de 90% dos custos de um software estão na sua manutenção. Vendo por esse lado, não estamos fazendo nem 10% do trabalho que deveríamos fazer.

Várias práticas de programação importantes são feitas durante a manutenção. Uma delas é a adição/mudança de recursos. Se fizéssemos isso, perceberíamos que coisas como refatoração e testes unitários são importantes.

4 - Metodologias são sempre bem vindas

Uma das dúvidas de quem começa a desenvolver é: como devo proceder, qual metodologia adotar. Um professor tem que ser um guia para um aluno escolher um método de trabalho. Praxis? XP? Scrum? PDCA? Sair fazendo na doida não é das melhores escolhas :)

Na matéria de Engenharia de Software, nós temos uma visão teórica de cada uma dessas metodologias. Uma matéria de programação com um projeto pra entregar poderia ser um cenário perfeito para coloca-las em prática.

5 - Conclusão

Matérias como essa são muito desperdiçadas na nossa universidade. E eu imagino que seja em outras também. Se você é professor, comece a pensar nisso e pense em como você pode ajudar a mudar o quadro aqui exposto. Se você é aluno, cobre isso do seu professor. Ou pelo menos tenha a boa vontade de estudar sozinho :)

  • Share/Bookmark