Na Myfreecomm temos alguns programadores lentos, graças a Deus. Conversando sobre isso com o Henrique, ele disse que merecia um post. Atendendo a pedidos, aí está.

Depois de bastante tempo sem programar, eu passei dois dias escrevendo um pequeno sistema para integrar a parte de pagamento de uma aplicação com o Paypal.

O fato de ter voltado a programar, depois de mais de um ano apenas gerenciando projetos e equipes, e estudando metodologias ágeis, me fez optar por escrever uma aplicação 100% testada, em Ruby, utilizando Sinatra. Gostaria de aproveitar para agradecer o Rafael Souza que me ajudou bastante no início.

A escolha de Ruby (ao invés de Python por exempo) e Sinatra (ao invés de Rails por exemplo), não importa. O que importa é que eu poderia fazer tudo “scriptado” (aka cuspido), mas achei que não deveria. O primeiro motivo é que se trata de um middleware para um processo crítico que não pode falhar, o pagamento. Segundo, por que na minha cabeça não fazia sentido cuspir um código e fazer funcionar o mais rápido possível.

Isso me fez pensar sobre o paradoxo da qualidade x velocidade. A conclusão que tirei das minhas reflexões é que os programadores que se dizem lentos, na verdade não são lentos.

Para você dizer que alguém é lento, você tem que comparar com outra pessoa. Lentidão é relativo. Você não é lento e ponto final, você pode ser lento se comparado com outras pessoas.

Minha conclusão foi que na verdade o “programador lento” faz as coisas no tempo em que elas realmente precisam para serem feitas da maneira que funciona. Na verdade, os outros que são rápidos de mais. Adianta ser rápido e ter bug?

Analisando sob essa ótica, e considerando a premissa de que a maioria das pessoas (rápidas) fazem errado, vide relatório Chaos Report do Standish Group, posso dizer que programadores lentos são bem-vindos.

Hoje, eu vejo essa característica como um sintoma de que ele programa com boas práticas e com o cuidado necessário para o software funcionar.

No final da conversa eu disse para o Henrique: “Se em uma entrevista de emprego, um programador me diz que é lento, eu vou vê-lo com bons olhos”.

Abraço e até a próxima.

Estamos desenvolvendo na Myfreecomm um sistema de cobrança que está ficando muito interessante. Ele irá resolver um problema real e trará muita conveniência no dia-a-dia das empresas que realizam cobrança com integração com os bancos.

O sistema está quase pronto e estamos neste momento definindo aqueles detalhes que fazem toda a diferença.

A concepção foi baseada em um fluxo único de uso, de forma que os itens de menu contemplassem as ações que o usuário irá realizar, como se o sistema todos fosse um grande wizard. As páginas acessórias são acessadas apenas por links contextuais. Não temos menu e submenu, nem breadcrumb. E te digo, fazer o sistema assim é um desafio!

A interface ficou bem simples, sem muitas opções e com links no lugar certo e na hora certa. Quando fazemos sistemas deste gênero as palavras e termos utilizados nos itens de menu, nos títulos e nos links são muito importantes. É preciso que o usuário consiga se situar de forma rápida e entenda o que irá acontecer a cada clique.

O Allan é o responsável por fazer com que o sistema seja entendido pelos usuários. Ele está escrevendo o manual, pensando em que lugares existirão links para o manual, quais são os pontos que podem gerar dúvidas, etc. E nesse processo ele está revendo os termos utilizados a todo momento. Inclusive nas interações chegamos a perceber e incluir na histórias novos status para determinada entidade e tudo.

Hoje ele levantou uma bola que gerou uma discussão muito saudável. Uma das ações do usuário no sistema é juntar várias cobranças para que elas sejam enviadas para o sistema do banco. Até hoje, o termos utilizado para esse conjunto de cobranças era Remessa. Tínhamos termos tais como: Preparar Remessa, Enviar Remessa, Remessas Pendentes e Remessas Enviadas.

A questão levantada foi: “Não deveria ser Lote ao invés de Remessa?”

A conclusão imediata depois de um rápido brainstorm foi de que tanto faz, afinal dá no mesmo, lote e remessa são a mesma coisa. Bem, depois de muita conversa e esclarecimento sobre entidades, estados, tempos, etc chegamos a uma opinião diferente.

Buscamos definições de lote e remessa no Google, depois fomos aos dicionários priberam e Aurélio. Mais alguns minutos de discussão e desenho foram neecessários para concluirmos que Remessa é algo que foi enviado, ou seja, que já passou pelo processo de envio. Se existe algo que pode ser remetido, mas ainda não o foi, isso não pode ser chamado de Remessa.

Donde se concluí que  dizer “Enviar Remessa” está errado e o termo “Remessa enviada” é um pleonasmo. Se é Remessa, é por que já foi enviado.

No meio da discussão chegamos a lembrar que muitas vezes não importa o “certo” e “errado” na gramática formal e que o mais importante é o entendimento do usuário. Mas é o que eu digo, se podemos usar o correto de acordo com a gramática sem afetar o entendimento do usuário, melhor. Se, usando o termo gramaticalmente corrento, ainda assim facilitamos o entendimento do usuário, como foi o caso, melhor ainda!

Por fim decidimos usar o termo Lote ao invés de Remessa e mudaremos para “Preparar Lote”, “Enviar Lote”, “Lotes pendentes” , “Lotes enviados” e outros termos presentes na interface. Como escrevemos todo código de programação em inglês, não tivemos maiores problemas.

Essa experiência foi muito interessante, pois foi legal estudar e discutir sobre o significado destas palavras e foi incrível perceber como uma mudança simples pode ao mesmo tempo melhorar o sistema e facilitar nosso trabalho. Ficará mais fácil agora escrever o manual. É aquela velha história: Se está difícil, está errado!

Uma vez eu li um post da 37signals extamente sobre isso. Agora eu entendo perfeitamente o que eles queriam passar com o post, e é o que eu espero deixar de recado também.

A definição de termos corretos e fáceis de serem compreendidos pelo usuário é fundamental para a boa usabilidade do sistema.

Além disso, escolher as palavras certas facilita a compreensão da relação do que elas representam com o sistema como um todo.

São diversos fatores que tornam um sistema bom ou ruim, difícil ou fácil de usar e complexo ou simples. Usar palavras corretas e de simples entendimento é um fator muito importante. Às vezes parece que está tudo bom, e que as palavras estão certas e serão compreendidas, mas nem sempre é verdade.

Pense no sistema que você usa ou está desenvolvendo. Será que mudando alguns termos não ficaria muito mais fácil de usar? Você tem algum caso similar? Deixe sua história nos comentários!

Abraços e até a próxima.

Essa foi a pergunta que o Carlos Eduardo fez no Twitter.

Eu respondi pelo próprio Twitter, e complementei, mas achei oportuno escrever aqui a minha opinião.

Para mim o cara que faz CSS/XHTML não deve ser considerado programador, é um Designer Web.

Eu acho que é programador aquele que escreve código em linguagem de programação (Turing Complete) e não de marcação.

Não podemos confundir programador com desenvolvedor. Um programador é desenvolvedor, e um designer tmb é desenvolvedor.

Um programador é aquele que escreve código que transforma dados. CSS não trabalha dados, mas sim formatação.

Abraços e até a próxima.

Eu gostei tanto deste artigo que resolvi traduzí-lo e publicá-lo aqui.

Atenção: Este artigo não é de minha autoria. Ele foi traduzido do artigo escrito por Alberto Gutierrez, disponível em: http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/

***

Existem dois conjuntos de habilidades que um bom desenvolvedor precisa cultivar: habilidades técnicas e não técnicas. Infelizmente, alguns desenvolvedores focam somente na parte técnica. Quando isso acontece eles desenvolvem alguns maus hábitos dos quais os seguintes 5 são os erros não técnicos:

1 .- Falta de disciplina.

“Disciplina é a ponte entre estabelecimento de objetivos e o cumprimento de metas.” Jim Rohn.

Sempre achei que disciplina fosse uma das habilidades mais valiosas, não só por ser um desenvolvedor de software, mas também para ser bem sucedido em qualquer outra área da vida também. E é bem verdade que, geralmente, é muito difícil encontrar pessoas que são tanto brilhantes quanto disciplinados.

Steve Pavlina destaca os 5 pilares da auto-disciplina … “[...] Aceitação (Acceptance), força de vontade (Willpower), trabalho árduo (Hard work), esforço (Industry) e persistência (Persistence). Se você pegar a primeira letra de cada palavra, você terá a sigla “A WHIP” (Um Chicote) – uma maneira conveniente de recordá-las, uma vez que muitas pessoas associam auto-disciplica como uma forma de chicotear-se em forma.[...] Eu altamente recomendo que leia sua série de artigos na auto-disciplina.

Como expliquei no meu artigo anterior: 5 dicas para criar bons códigos todos os dias, a minha abordagem pessoal é seguir estes passos todos os dias.

-Prepare sua própria lista de afazeres do dia.
-Faça uma coisa de cada vez
-Faça-o direito
-Não finalize nada até que tenha completado tudo.
-Antes tarde do que arrependido, PORÉM antes arrependido do que nunca.

2 .- Grandes egos.

Pela minha experiência posso dizer que grandes egos e programadores vão de mão em mão, o principal problema de ter um grande ego é que, na realidade, ele te impede de perceber que você o tem. Alguns indicadores que podem ajudar você a saber se o seu ego é grande são as seguintes:

* Você se considerar o melhor programador.

* Você bloquear conversas.

* Você pedir verificações de códigos não para obter opiniões críticas, mas para mostrar quão bom o seu código é.

Existem artigos muito bons na internet sobre programadores e seus egos, eu recomendo dois deles, este artigo de Mike Bernat: “Programação sem ego algum” e esta dicussão em stackoverflow.com.

3 .- Ser um mau comunicador.

“Se eu for falar por dez minutos, eu preciso de uma semana de preparação; se quinze minutos, três dias; se meia hora, dois dias, se uma hora, estou pronto agora“. Woodrow Wilson

Como a comunicação é nossa principal atividade. Ser um bom comunicador é difícil, porém essencial à nossa profissão, estamos continuamente trocando opiniões sobre designs, códigos, fazendo revisões, escrevendo documentações, tentando convencer os outros que nosso projeto é melhor, escrevendo código…

Bons comunicadores são pessoas que, quando estão explicando alguma coisa, sua explicação é a seguinte:

* Foco. Eles só falam sobre o que é preciso para se compreender.

* Clareza. Fácil de entender.

* Breve. Nada a acrescentar, nada a retirar.

Para ser um melhor comunicador, tenho dois conselhos:

* Se você acha que não é um bom comunicador, prepare o que vai falar até ficar focado, claro e conciso.

* Se entrar numa conversa, primeiro ouça, depois pense e depois fale.

Há mais algumas dicas para melhorar a comunicação quando tiver uma reunião neste artigo que publiquei anteriormente “7 melhores práticas para tomar decisões no desenvolvimento de equipe“.

4 .- Esquecer o cliente.

“Se não cuidarmos do cliente … alguém vai cuidar.”

Você está aí por uma razão apenas, seu cliente. É fácil, as vezes, esquecer isso. Estive em equipes que se concentraram em tecnologias e plataformas, em vez de ter um cliente feliz. Gastaríamos meses criando uma estrutura que não proporcionaria valor algum para o cliente, e pelo tempo que começaríamos a usá-la, iríamos acabar descobrindo que não se encaixa nas nossas necessidades.

5 .- Não priorizar o trabalho corretamente.

Os programadores que estão sempre se atualizando muito, pesquisando novas e mais interessantes tecnologias, mais soluções de engenharia ou simplesmente fazendo tudo o que acham mais legal, são empecilhos para o projeto. Não estou dizendo que não é normal que se engaje em atividades paralelas ao longo do tempo, pois todos nós precisamos de distrações, mas se você se encontra normalmente nas situações ditas antes, você deve reconsiderar a forma como prioriza seu trabalho, mais uma vez vou recomendar que leia as ‘5 dicas para criar bons códigos a cada dia‘.

Este texto foi copiado do post do Henrique.

Novamente estamos procurando por um Desenvolvedor Ninja para integrar permanentemente o clã da Myfreecomm. Desta vez a vaga tem o foco principal em Python e Aplicações Web.

Buscamos Ninjas com sólidos conhecimentos teóricos de computação, experiência e capacidade de adaptação. Nosso clã preza a colaboração e a constante busca pelo aperfeiçoamento. Por tanto, espírito inovador, curiosidade e paixão por tecnologia são características essenciais de um Desenvolvedor Ninja.

Na Myfreecomm, buscamos criar o melhor ambiente possível. Acreditamos que o segredo do melhor software é a melhor Equipe de Desenvolvimento, e não apenas a melhor ferramenta. Por isso, adotamos o Manifesto Ágil, o Manifesto for Software Craftmanship, e quaisquer idéias que promovam processos melhores e mais inteligentes para o desenvolvimento de software.

As missões-ninja são realizadas no Centro do Rio de Janeiro, 8h por dia, iniciando entre 9:00h e 10:00h da manhã. Para realizá-las, o Ninja deverá ter as seguintes aptidões:

1. Python, SqlAlchemy, Pyro
2. Aplicações Web, Javascript, JQuery, Ajax, Template Engines
3. Gecko, Webkit, CSS2, CSS3, HTML
4. Banco de Dados, SQL, PostgreSQL
5. Unix, Windows XP, Windows Vista, Processos, Threads, Redes
6. OO, MVC, Design Patterns, CRUD, TDD
7. SOA, SOAP, REST, XML-RPC
8. Git
9. Scrum

Eventuais conhecimentos em desenvolvimento de aplicações Desktop ou Client/Server serão considerados diferenciais.

Você pode saber mais sobre a definição de “Desenvolvedor Ninja” lendo nosso primeiro anúncio e o causo que originou o termo. Naquele caso, recebemos muitas respostas interessantes e preenchemos definitivamente a vaga em questão.

Se você se sente capaz de encarar este desafio, envie seu currículo para todentro at myfreecomm dot com dot br com o valor pretendido para sua recompensa e uma breve descrição do seu interesse e aptidão pela oportunidade.