Não, ainda não sou uma pessoa super-mega-produtiva, mas aqui está como consegui aumentar minha produtividade usando alguns truques (e o incrível sistema operacional que é o Mac OS X em conjunto com ótimas aplicações):

• Não verifique seu e-mail mais de quatro vezes ao dia: se você está esperando algum e-mail importante, peça para quem for enviá-lo que te avise quando isso acontecer, usando, por exemplo, uma SMS;
• Não verifique seu e-mail se você sabe que não estará apto a agir sobre alguma mensagem imediatamente: por exemplo, verificar seu e-mail de trabalho no final da tarde de Sexta – deixe para fazer isso na Segunda;
• Livre-se dos feeds que você assina: você não vai realmente sentir falta deles sem ficar um tempo longe. Se, após alguns dias, você sentir muita falta de ler um deles, assine-o novamente, mas não verifique seus feeds mais do que uma vez ao dia. Essa é uma excelente técnica para descobrir o que é realmente importante dentre tudo que você consome;
• Deixe que as pessoas sejam seu filtro: acredite em mim, se algo é realmente importante (ou banal, mas “quente”), vai chegar a você. Você não precisa ficar garimpando. O recurso de “shared items” do Google Reader é excelente nesse ponto – estou à caminho de usar apenas ele, me livrando de todos os feeds que assino (são por volta de oito hoje). Quando realmente precisar encontrar algo, o Google é seu amigo;
• Desabilite notificações desnecessárias: como muitas do Growl ou os “contadores vermelhos” nos ícones de aplicações na Dock do OS X – mantenha apenas as que você realmente precisa (por exemplo, eu mantenho as notificações do Propane, já que é importante saber o que meus colegas de trabalho dizem no Campfire);
• Não use um monitor muito grande: isso pode parecer estranho, mas pesquisas mostram que, após aproximadamente 26 polegadas, o tamanho do monitor diminui a produtividade. É óbvio: muitas coisas no seu campo visual vão lhe distrair. Use o Spaces e divida as telas de acordo com a tarefa (uma para programação, uma para navegação na internet etc);
• Aumente o espaço livre na sua tela eliminando itens do seu Desktop: configura o Finder para não exibir discos rígidos (eu deixo apenas discos ópticos e dispositivos removíveis). Elimine da Dock as aplicações que você não usa muito frequentemente. Use o QuickSilver ou algo similar para acessar as aplicações e arquivos que você não usa frequentemente, apenas não deixe que eles se empilhem na Dock e no Desktop;
• Elimine da Menu Bar os itens que você não precisa, como o ícone de status do Bluetooth, o indicador AM/PM se você usa o formato americano (é fácil saber isso olhando pela janela), o ícone do Time Machine etc;
• Use o Adium e configure-o para que fique oculto a menos que seja a aplicação ativa (veja aqui: ativo, inativo, configurações 1, configurações 2);
• Use o Fluid para criar SSBs para as aplicações web que você precisa para trabalhar: o motivo para isso é evitar ter um browser repleto de abas abertas te distraindo enquanto você usa uma aplicação para trabalhar. Com as aplicações Fluid você pode focar apenas na tarefa à mão;
• Use o Tags para facilitar o processo de organização e busca de arquivos.

É difícil tomar algumas dessas ações, como se livrar dos feeds que você assina – especialmente porque o número de feeds assinados geralmente é motivo de “disputazinhas” entre nerds/geeks. É estupidez pura, como competir para ver quem dorme menos e fica acordado programando por mais tempo.

De qualquer modo, dê uma chance. Após algum tempo (eu recomendo tentar por, pelo menos, dez dias), você vai sentir falta das coisas que realmente precisa e pode tê-las novamente assim que quiser.

Update: Como bem notado pelo ArthurGeek, a imagem de configuração do Adium para que a lista de contatos se esconda automaticamente estava errada (a que eu chamei de “configuração 2″). Arrumei o link e deixo aqui também: http://yfrog.com/avpicture12xp.

–

Também em inglês.

A intenção é ter algo que possa ser consumido em pouco tempo, resultando numa base sólida para o desenvolvedor profissional (ou seja, não há tópicos básicos para iniciantes) e, ao mesmo tempo, ser mantido como referência (o asterisco denota meus itens preferidos).

Vídeos de conferências:

• Don’t Mock Yourself Out – David Chelimsky
• The Grand Unified Theory – Jim Weirich*
• Mock Dialogue – Joe O’Brien and Jim Weirich
• SOLID Object-Oriented Design- Sandi Metz*
• Testing Heresies – Francis Hwang*
• What Makes Code Beautiful? – Marcel Molina Jr

Artigos/Slides:

• Common REST mistakes
• Functional Programming For The Rest of Us* – finalmente alguém que explica programação funcional de forma simples, sem querer parecer um “sabe-tudo”
• How I Explained REST to My Wife* – ótimo artigo, sempre uma referência ímpar
• On The Shortness of Life: An Introduction to Seneca
• Smart Model, Dumb Controller – focado em Rails, mas vale para qualquer MVC
• Top ten things ten years of professional software development has taught me
• Web2.0: Why we got here and what’s next

Pausa para explicação.

O modelo Dreyfus de aquisição de habilidades divide os profissionais em cinco níveis de conhecimento para uma dada habilidade (isto é, você pode estar no nível 1 em culinária e no nível 5 em jardinagem, ninguém “é” um nível 5 e pronto). Bem resumidamente, são eles:

1. Novato: o novato precisa de regras claras e independentes de contexto (“receita de bolo”) para guiar seu trabalho, e não sabe lidar com problemas pois não tem experiência para tomar decisões sozinho. Também não toma responsabilidade pelas regras que segue – “Eu estava apenas seguindo ordens!”.
2. Iniciante avançado: começa a tomar decisões mais básicas pois já possui alguma experiência e percebe que pode adaptar algumas regras a certos contextos. Ainda não toma decisões contrárias às regras, não sabe lidar com problemas inesperados e não experimenta a sensação de responsabilidade pessoal. A maioria das pessoas está nesse nível.
3. Competente: questiona as regras de acordo com sua experiência e percebe consequências a longo prazo. Começa a tomar decisões de acordo com o contexto, resolver problemas inesperados e a tomar a responsabilidade sobre seus atos.
4. Proficiente: se utiliza de pouquíssimas regras, começa a valorizar mais sua intuição e sempre analisa o contexto em que está inserido de acordo com o que já experimentou. Sente-se completamente responsável por suas decisões e respectivas consequências.
5. Especialista: o especialista usa a intuição que adquiriu com a experiência e faz tudo parecer muito fácil. Toma decisões e resolve problemas sem esforço, pois reconhece padrões muito rapidamente. É o pior professor para um novato, pois não segue qualquer receita, apenas sabe o que fazer.

Um ponto interessante é que pessoas nos níveis mais baixos costumam se sobreavaliar, enquanto as pessoas nos níveis mais altos são bem mais críticos em relação ao seu trabalho e nível de conhecimento.

Citando Dave Thomas:

So, high-quality experience turns us from a novice to something approaching an expert. We process information in a qualitatively different way in the two states: novices need rules, experts need concepts and contexts. Novices need external feedback, experts generate their own. Stuff that works when teaching a novice drives an expert up the wall, and vice-versa. Experts are often the worst teachers of novices.

Este modelo foi utilizado na década de 80 para resolver alguns problemas na profissão de enfermagem, problemas esses que são agora enfrentados pelos desenvolvedores de software: a profissão não é valorizada (sendo considerada simplesmente operacional), os salários são baixos (o que torna mais interessante financeiramente dar palestras/consultoria ou partir para cargos administrativos), a educação de novos profissionais piora cada vez mais (devido à sobrevalorização de modelos formais e desvalorização da experiência prática) e a perda de visão do real objetivo (satisfazer aos clientes ao invés de simplesmente “fabricar” software).

Voltando:

Tudo o que você precisa fazer para arruinar o trabalho de um especialista é fazer com que ele siga regras. É o que Andy Hunt chama de “arrebanhar cavalos de corrida”. Para arruinar o trabalho de um novato, deixe-o livre de receitas, o que Andy chama de “colocar ovelhas para correr”. É por isso que metodologias e regras não podem ser aplicadas a todos em uma equipe: equipes são heterogêneas, possuem profissionais em vários níveis de conhecimento em uma dada habilidade. Os chamados “gestores de pessoas” simplesmente não conseguem perceber isso, ou fingem não perceber.

Outro fator que atrapalha é acreditar que todos devem ser tratados da mesma forma ou haverá insatisfação: dado que os tratamentos diferenciados não sejam coisas absurdas e seja deixado bem claro que qualquer um que se torne mais experiente pode alcançar os benefícios, não há problema nisso. Basta haver transparência.

Esses mesmos gestores ignoram a intuição dos especialistas e usam a justificativa de que não é científico ou não segue a metodologia XYZ. Desta forma, forçam seus melhores profissionais a seguir regras que não fazem o menor sentido para eles. Resultado: insatisfação, baixa produtividade, qualidade do trabalho acaba menor do que poderia ser e, finalmente, a perda do profissional. Basicamente, pagam mais para os especialistas e desperdiçam o que os torna diferentes. Não é assim em todos os lugares mas, infelizmente, é o que acontece na grande maioria.

Escute seus especialistas. Dê espaço àqueles que já provaram seu valor e são referência dentro de sua equipe. Ignore o senso de “politicamente correto” e, sim, trate os desenvolvedores de sua equipe de forma diferente, de acordo com o respeito natural que surge dentro da equipe em relação aos melhores e mais experientes. Lembre-se que métodos formais não alimentam criatividade, intuição e inventividade. Não há “tamanho único” quando falamos de experiência e competência.

Referências:
Dave Thomas – End of the Knowledge Worker?
Andy Hunt – Pragmatic Thinking and Learning: Refactor Your “Wetware”

Máquinas? Ok, então você desenvolve softwares que são utilizados por máquinas, certo?

Errado. Desenvolvedores trabalham com pessoas. Com clientes, gerentes, vendedores e outros desenvolvedores.

Médicos não trabalham com estetoscópios ou bisturis. Essas são ferramentas. Aprenda a utilizá-las bem, mas não esqueça do foco: pessoas, anseios, desejos, expectativas. Não importa se você domina Python ou 32 frameworks Java: se você não souber satisfazer aos anseios de pessoas, será um fracasso.

Ferramentas vem e vão, se aperfeiçoam, mudam, inovam e são deixadas para trás, ainda mais em nossa profissão. Um pedreiro não usa um martelo para tudo que faz. Um médico não depende de um esfigmômetro para fazer seu trabalho. Ferramentas são facilitadoras, não substituem a competência.

Não se prenda à ferramentas. Não dê atenção apenas aos aspectos técnicos. Uma solução que usa uma tecnologia simples ou “velha” (em TI, 6 meses bastam) que supra as expectativas do cliente é muito (muito mesmo) melhor do que uma solução que usa todos os últimos frameworks e deixa o cliente insatisfeito.

Essas perguntas são sempre muito importante ao analisarmos as vantagens de se fazer algo. Realmente vale a pena? Poderíamos fazer mais simples? Poderíamos fazer outra coisa que agregue mais valor?

Outros pontos de destaque da apresentação:

• Otimize para agora, deixe o amanhã para amanhã;
• As decisões que você faz hoje não precisam durar para sempre;
• Tome pequenas decisões. Elas são mais fáceis de mudar caso não dêem resultado;
• Tenha sucesso e dinheiro ajudando outras pessoas a ter sucesso e dinheiro;
• Comece com o jeito mais fácil. Ele geralmente lhe entrega de 80 a 90% do que você quer;
• Invista mais no que não muda (ex: velocidade de busca sempre será necessário, então a Google investe muito nisso);
• Compartilhe seu conhecimento;
• Interrupções são inimigas da produtividade;
• Seja aberto, honesto e responsável;
• Quase nada é urgente ou complicado demais. Nós é que tornamos assim.

Confira o post de Jason e também o resumo de sua apresentação, feito por Tim Walker. ]]> http://www.makemesimple.com/blog/2008/03/18/jason-fried-questione-seu-trabalho/feed/ 6 http://www.makemesimple.com/blog/2008/03/14/rapido-e-sujo-ou-lento-e-limpo-porque-nao-rapido-e-limpo/ http://www.makemesimple.com/blog/2008/03/14/rapido-e-sujo-ou-lento-e-limpo-porque-nao-rapido-e-limpo/#comments Fri, 14 Mar 2008 17:41:28 +0000 Lucas Húngaro http://www.makemesimple.com/blog/2008/03/14/rapido-e-sujo-ou-lento-e-limpo-porque-nao-rapido-e-limpo/ Há algum tempo atrás assisti ao vídeo da apresentação de Martin Fowler na RailsConf 2006. Nessa apresentação ele fala sobre o que o faz gostar do Rails (e do Ruby) como plataforma para desenvolvimento de software comercial.

Um dos pontos mais interessantes mencionados por ele é o seguinte: com Rails, conseguimos software limpo entregue rapidamente. Antes disso, você tinha duas frentes: a do “Rápido e Sujo”, geralmente representada por PHP e VB (até a versão 6) e a do “Lento e Limpo”, com Java e .NET.

O grupo do “Rápido e Sujo” promete entregar o software em menos tempo mas, geralmente, o código é uma bagunça e qualquer correção, alteração ou melhoria torna-se um pesadelo.

Já o grupo do “Lento e Limpo” lhe promete entregar uma maravilha da engenharia de software, utilizando cada design pattern já visto nesse mundo (o que é algo bem prejudicial mas, ainda assim, comum), interfaces e IoC por todos os lados, enfim, um código com alta manutenabilidade e extensibilidade (ê palavrinhas…), o que demora uma eternidade e nem sempre é atingido.

Rails estimula uma visão diferente: “Rápido e Limpo”. O framework deve fazer todo o “trabalho sujo” por você, permitindo que você foque apenas no domínio do problema, eliminando muita complexidade acidental e permitindo menores tempos de entrega. Rails atinge isso através do extensivo uso de DSLs e convenções, entre outros conceitos. Além disso, está estimulando essa visão em outras plataformas, o que é muito bom.

Equilíbrio sempre é importante: você quer sim entregar software rapidamente (assim consegue vender mais), mas não quer ficar com uma bizarrice nas mãos para dar manutenção. Por outro lado, não precisa do código mais perfeito do universo, principalmente se isso significa demora excessiva. Pragmatismo é a chave. Faça o que funciona pra você.

Duas observações importantes:

1. Estou generalizando um pouco quanto à PHP, VB, Java e .NET. A qualidade do código depende muito do desenvolvedor, mas algumas linguagens/plataformas estimulam estilos de programação diferentes. Não se sinta ofendido ou menosprezado.

2. Por favor, não faça como muita gente e saia alardeando que Rails permite desenvolvimento rápido e ponto. Muita gente está fazendo todo tipo de atrocidade com o framework em nome da rapidez, isto é, prazos reduzidos. O foco da comunidade é na qualidade, por isso falamos tanto sobre TDD, beleza no código, DRY, KISS e outros conceitos. Os prazos menores são consequências, não são objetivos.

Neste artigo, Chris discute os modelos de negócio utilizados na Web e argumenta que, como poder de computação, largura de banda e armazenamento ficaram tão baratos à ponto de poder ser “desperdiçados”, praticamente tudo que vai para a web tende a tornar-se gratuito (pelo menos aos usuários finais).

Boa leitura!

Resolvi, então, iniciar a série “Developer 101″ onde, à medida que faço minhas revisões, vou publicar um pouco sobre o assunto e listar links para mais recursos.

No primeiro artigo da série, falarei um pouco sobre algo fundamental e, geralmente, negligenciado por escolas e profissionais: a codificação de caracteres. Não é algo muito fácil de entender e muito dessa dificuldade deve-se às confusões e ambigüidades criadas pelas próprias empresas e entidades de padronização.

Em resumo, a codificação de caracteres define como caracteres (grafemas e símbolos utilizados em alfabetos e outros símbolos específicos) são representados internamente para armazenamento, processamento ou transmissão.

Para entender a codificação de caracteres, precisamos de três definições básicas:

1. Repertório de caracteres (character repertoire ou character set)

Um repertório de caracteres é um conjunto de caracteres distintos. Um repertório não tem qualquer ligação com dados computacionais.

Exemplo: o alfabeto grego, o conjunto de caracteres que uma criança chinesa aprenderá na terceira série, etc.

2. Conjunto codificado de caracteres (coded character set)

Um mapeamento um a um entre um caractere de um repertório e um código único. Esse código possui diversas nomenclaturas, como code point, code position ou code value, mas todos se referem à mesma coisa.

Exemplo de conjuntos: Braile, Unicode, I Ching.

Exemplo de mapeamento: o code point U+0041 representa a letra A no conjunto Unicode.

3. Codificação de caracteres (character encoding)

Um método (algoritmo) para apresentar caracteres em formato digital, mapeando códigos de caracteres para bytes. Existem diversos tipos de codificações. Algumas fixam o número de bytes de cada caractere, outros permitem caracteres multibytes variáveis.

Exemplos: ASCII (um byte por caractere), UTF-8 (multibyte variável).

A ambigüidade

O nome character set (conjunto de caracteres) é usado para se referir a repertórios, conjuntos codificados ou codificações. Charset também é bastante utilizado para se referir à codificação. Esse tipo de confusão torna o assunto bastante complexo, por isso é necessário entender bem os conceitos descritos mais acima.

Juntando as partes

Suponha que queremos representar todos os caracteres do alfabeto latino mais todos os símbolos especiais e diacríticos utilizados na língua portuguesa. Esse é o nosso repertório de caracteres.

Para isso, criamos uma grande tabela com todos esses caracteres e, a cada um, atribuímos um código único. Temos agora um conjunto codificado de caracteres.

Em seguida vamos buscar uma forma eficiente de representar esses caracteres em um meio digital. O que vamos representar, na verdade, é o código de cada caractere.

Supondo que temos 1000 códigos, estabelecemos que cada código poderá ocupar até dois bytes de espaço, o que nos habilita a representar até 65536 códigos (2 bytes é igual a 16 bits, 2^16 é igual a 65536). Tomamos essa decisão pois com 1 byte conseguiríamos representar até 256 códigos. Além disso, é sempre uma medida de bom senso deixar “espaços livres” para caracteres especiais (para representar uma quebra de linha, por exemplo) e possíveis necessidades de compatibilidade. Temos, então, nossa própria codificação.

É importante notar que a idéia de caractere é diferente de sua representação. Por exemplo, o conceito da letra “A” é diferente do fonema em português ou da sequência de bytes no UTF-8.

Além disso, cada representação utiliza uma codificação diferente: no exemplo anterior, sons e bytes, respectivamente. Ou seja, uma codificação é uma maneira de representar um conceito.

É por esses motivos que a codificação de caracteres é tão importante: experimente salvar um arquivo em uma codificação (UTF-8, por exemplo) e tentar ler o mesmo arquivo utilizando outra codificação (ASCII, por exemplo). Grande parte, senão todo o conteúdo, será perdido.

Exemplos

Veja, na tabela abaixo, como fica a codificação (representação em bytes) dos caracteres A, א e 好 do conjunto codificado Unicode, nas codificações UTF-8, UTF-16 e UTF-32:

Recomendações para desenvolvimento

Desde o início do projeto, utilize sempre o conjunto Unicode e, de preferência, a codificação (encoding) UTF-8.

Isso abrange o conjunto codificado e a codificação utilizados para salvar cada arquivo com texto (código-fonte, xml, arquivos para internacionalização etc), cabeçalhos HTTP e meta tags content-type em aplicações web, servidores web, armazenamento em banco de dados e conexões com o mesmo.

Lembre-se: isso não é uma verdade universal. Utilizar Unicode e UTF-8 cobre a maioria dos casos, mas não todos.

Finalizando

Desde o início, preste atenção na codificação que você está utilizando ao desenvolver software, pois isso pode poupar muito tempo, evitando sérios problemas.

De forma alguma esse artigo é algo completo, é apenas o que consegui rever com algumas horas de leitura, exposto de forma simples. Aprofunde-se e, se encontrar algum erro ou inconsistência no que escrevi, por favor, me avise.

Veja também

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
• Do you know your character encodings?
• Tutorial: Character sets & encodings in XHTML, HTML and CSS (W3C)
• Unicode and You

É impressionante a quantidade de pessoas com curso superior na área de informática (o que sugere que a pessoa deveria ter mais conhecimento do que uma sem curso superior…) que não sabe escrever um texto minimamente coeso, muito menos manter uma linha de argumentação consistente em uma conversa.

Não estou dizendo que sou um professor Pasquale, muito menos um mestre na arte da argumentação, mas sempre gostei das ciências humanas e me esforço para melhorar na comunicação. Por quê? Bom, desenvolvimento de software é 90% comunicação. Comunicação com clientes, com membros da equipe, com parceiros, comunicação do seu pensamento em forma de código.

A “era da internet”, de Orkuts, Messengers e afins, tornou o cenário ainda pior: além da deficiência lógica, a total falta de conhecimento gramatical e ortográfica se tornou uma epidemia. A “preguiça” de escrever corretamente, em nome da agilidade na comunicação virtual, tornou-se hábito e “emburreceu” as pessoas.

Programar é uma atividade criativa, envolvendo muito raciocínio e lógica. O mesmo ocorre com a argumentação. Existem técnicas bem definidas para ambas, mas a qualidade do produto final depende das habilidades do executor.

Como discuti anteriormente, o programador apenas programa, traduz, codifica como uma máquina. O desenvolvedor de software, que tem na programação uma de suas principais atividades, busca mais conhecimento, se aprimora, sabe se comunicar.

Então, como alguém espera (ou afirma) ser um bom desenvolvedor de software quando não consegue escrever uma simples frase sem cometer seguidos erros ortográficos e lógicos?