Há uns dias eu fui ajudar uma conhecida a usar o notebook que ela comprou para se atualizar tecnologicamente. Vale destacar que ela tem 69 anos de idade.
Eu achei muito legal. A vontade de aprender dela é fantástica.
Começamos por ligar o notebook, novinho em folha com o Windows Vista. Como eu uso o Ubuntu, vindo do XP, não sei usar o Vista como deveria. Assim, para algumas perguntinhas que ela fazia, eu tinha que procurar aonde estavam as opções.
Chegou uma hora que ela me perguntou: "você não trabalha com computador? Não deveria saber isso?" Pois é, quem não é da área acha que a gente sabe tudo. Quando ela me perguntou sobre gravar fotos, tocar música, me deu um arrepio. Mesmo quando eu usava Windows, eu não usava os aplicativos padrão para isso. Agora que uso o Linux, piorou, né? É tudo bem diferente. E ficou complicado para eu explicar.
As dificuldades eram muitas. Ela não sabia nada sobre as setas de movimento, backspace, tab, enter, caixa alta, shift, etc. Entre minha explicação e a tentativa de ela usar, eu ficava pensando como pode existir alguém que não sabia disso. Afinal, era tão óbvio para mim! Algumas explicações eu tentei dar usando a analogia básica: "funciona como uma máquina de datilografia". Sabe o que ela me disse? "A última vez que usei uma máquina de datilografia foi há 50 anos!".
Ela sentiu muita dificuldade em saber quando usar o backspace e a seta para a esquerda. Às vezes ela insistia em usar a seta para a direita quando queria inserir espaços em branco.
E quando ela me disse assim: "Eu quero ver fotos de Paris. Eu quero usar o computador para viajar sem sair da minha casa. Quero visitar um museu também". Como explicar o conceito da internet para uma pessoa que não tem a menor noção do que se passa?!
Até ensaiamos procurar fotos de Paris. Ela me perguntou novamente: "você não trabalha com computador? Não sabe como ver uma foto de Paris?!". Encontramos várias no Google Image Search, mas muitas eram ruins e não mostravam o que ela queria ver. Complicado, né?
Eu percebi que os usuários de computadores não têm a menor noção do que se passa nos bastidores. E não precisam saber, muitas vezes. Mas muitas delas, seria bom se soubessem. Ajudaria um bocado a eles próprios. Mas, como explicar tantos conceitos assim, na lata, já que o computador está sendo vendido pela mídia como mais um eletrodoméstico? Eu acabei dizendo que ela precisava mesmo fazer um curso de como usar o computador.
Se eu quero um forno de microondas, eu ligo na tomada, aperto alguns botões e posso esquentar minha comida. Simples assim. É físico. Com computadores, as coisas são virtuais, não palpáveis.
Para ver as fotos de Paris, eu preciso de:
1) Saber o endereço de um site de busca.
2) Usá-lo para procurar um site com galeria de fotos de Paris.
3) Certamente vamos encontrar vários, portanto, preciso experimentar cada um desses encontrados e ver se é o que eu espero que seja.
4) Quando eu encontrar o site que atenda às minha expectativas, preciso ver as fotos. Mas para isso, seria bom usar a navegação com abas do navegador. Isso agilizaria a visualização das fotos sem recarregar a página da galeria de thumbnail, mas isso seria mais um complicador para minha colega.
Puxa, quanta coisa para uma marinheira de primeira viagem! E muito frustrante. Ela só queria ver as fotos.
Em determinado momento, ela disse que queria mandar um email. Caramba, como explicar que o email do filho dela era UOL e o que estávamos criando para ela era do Hotmail? Ela queria um igual ao do filho! Grande dificuldade foi fazê-la preencher o formulário de inscrição e convencê-la de que preencher um captcha era realmente necessário. Isso ela entendeu. Ela não conseguiu entender como e por quê alguém faria um programa para criar cadastros falsos. E como uma coisa dessa funciona!
E email de confirmação?! Foi um absurdo na cabeça dela.
Como desenvolvedor de aplicativos, aprendi que precisamos fazer as coisas mais claras.
Vi que muitas opções na mesma tela tendem a confundir quem ainda não conhece o jargão da coisa.
Aprendi também que precisamos ter uma linguagem consistente com o usuário do aplicativo. Vi que as coisas mais comuns precisam realmente ter um destaque descomunal para serem encontradas facilmente.
Definitivamente não fui muito bem nessa tarefa de ajudar essa colega. Mas valeu muito a experiência. Tenho certeza de que aprendi muito mais do que ela.
Isso tudo me fez lembrar de uma empresa que trabalhei. Lá, tínhamos um trabalho social voluntário em mente, que era ajudar aos funcionários de uma escola pública a usar os computadores de modo seguro e eficiente. Eu me voluntariei, mas infelizmente não fomos adiante enquanto eu ainda estava lá. Espero que tenham conseguido realizá-lo, pois muita gente precisa de iniciativas assim.
Mas, voltando à minha análise, quando estávamos bolando os tópicos e o tempo de duração das aulas, pensávamos que com uma aula, o aluno já estaria pesquisando no Google e navegando em abas. Na outra, ele já saberia como anexar uma foto num email. Vejo que estávamos redondamente enganados.
As pessoas não sabem usar o mouse. Muitas nunca usaram uma máquina de escrever. Precisamos mesmo frear um pouco para dar oportunidade de adquirir conhecimento.
Se alguém de lá estiver lendo, não deixe o lanbari morrer, viu? Aprendi que tenho muito o que fazer aqui nessa vila de pescadores. ;-)
28 de dezembro de 2009
[Ubuntu] Ripar MP3 no Ubuntu 9.04
Para ripar MP3 no Ubuntu 9.04, tem que instalar um pacote para habilitar o perfil MP3 no Sound Juicer, digitando o seguinte comando no terminal:
Solução simples para um problema que poderia não existir.
Afinal, você já viu alguém que tem um Ogg Vorbis player? Ou um FLAC player?!
Já que MP3 é de longe o formato mais usado no mundo, poderia haver uma mensagem em algum lugar dizendo o que fazer para resolver isso, né?
Fica aqui registrado.
sudo apt-get install gstreamer0.10-plugins-ugly-multiverse
Solução simples para um problema que poderia não existir.
Afinal, você já viu alguém que tem um Ogg Vorbis player? Ou um FLAC player?!
Já que MP3 é de longe o formato mais usado no mundo, poderia haver uma mensagem em algum lugar dizendo o que fazer para resolver isso, né?
Fica aqui registrado.
Sou ágil porque faço ou faço porque sou ágil?
"Por que sua equipe é ágil?"
Se alguém lhe fizesse essa pergunta, como você responderia?
Sua equipe é ágil porque usa Scrum/XP ou usa Scrum/XP porque é ágil?
Essa é uma versão moderna da questão sobre o ovo ou a galinha. Quem veio primeiro?
Afinal, a galinha é galinha porque bota ovo, ou bota ovo porque é galinha?
Tem gente que pensa assim: "Quero ser identificado como agilista. Então preciso usar Scrum e XP. Caso contrário ninguém vai saber que sou ágil."
Outras, já pensam diferente: "Pelo que eu pude ler, acho que estou usando um pouco Scrum. Eu sou ágil!"
Participando de listas sobre ágil há um tempinho, tenho notado que existe a preocupação grande em dar nome ao que se faz. Uma preocupação existente no mundo corporativo é ter títulos ao invés de competências. É uma sopa de letrinhas que não acaba mais. Quem é certificado Java ou PMI que o diga! Minha esposa, que não é de TI, diz que isso é estratégia pra cobrar caro. E ela não deixa de ter razão.
No final das contas o que realmente importa? Ser galinha ou botar ovos? Ser ágil ou usar Scrum/XP?
Outro dia eu conversava com um colega sobre como analisar candidatos para vagas na empresa dele. Eu perguntei como eles avaliavam os currículos. Veja a resposta:
Sua equipe não será ágil simplesmente se vocês usam Scrum ou XP. E, sendo ágil, vocês não necessariamente usarão Scrum ou XP. Aliás, não se usa Scrum ou XP. Na minha opinião, Scrum e XP são aplicados e não usados.
Algumas técnicas são usadas sim, mas o que determina se uma equipe é ágil ou não é a atitude dela e não o que ela usa. O artigo "2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi", do Guilherme Chapiewsky, fala sobre isso, de uma forma diferente. Ele passa muita experiência vivida e por isso vale a leitura.
Tá, mas se você me perguntar: "Pô, se não é aplicando ou deixando de aplicar algumas técnicas, então como saber se estou sendo ágil?"
Simples, meu caro, leia o manifesto ágil!
Há um tempo atrás eu escrevi um artigo que fala um pouco sobre isso, chamado Eu já sou ágil e não sabia. Dá uma lida nele. Isso, clica aí, leia e depois volte para continuar esse artigo aqui.
O grande objetivo por trás do manifesto ágil é encontrar formas melhores de desenvolver softwares que funcionem. D-E-S-E-N-V-O-L-V-E-R. Sacou? Não é preencher planilhas infindáveis, trocar emails quilométricos, participar de reuniões sem fim! Não. O objetivo é desenvolver software. E que funcione.
Ser identificado como ágil significa que você, apesar de ser organizado, consegue resolver os problemas dos seus clientes num tempo aceitável, sem muita burocracia, está aberto a mudanças e pronto a replanejar conforme a necessidade deles, os clientes. Sim, eles são os donos do negócio, o motivo de sua profissão existir e são eles quem devem dizer quais funcionalidades o sistema vai ter. Você sugere, mas ele bate o martelo. Acostume-se a isso, por mais absurdo que possa lhe parecer!
Esqueça os nomes e as sopas de letrinhas. Preocupe-se com a qualidade das soluções que você oferece aos seus clientes, com a transparência nas atividades, com o cumprimento dos prazos e, muito importante, com a comunicação interna da equipe.
É por isso que o quadro branco com post-its é tão difundido no meio ágil. Ele é simples de entender, todo mundo domina essa tecnologia, todo mundo vê, não distrai e é fácil de modificar. Simples e objetivo.
Para ter uma noção mais clara do que estou falando, veja Lean em 4 minutos e assista à palestra ministrada na Câmara dos Deputados pelo Bruno Pedroso.
Se você quiser saber como se faz na prática, dê uma lida no PDF sobre produtividade, da Visie. Se gostar mesmo, pense seriamente em participar do curso XP na Prática, da SEA Tecnologia. Leia o depoimento de um participante.
Com esses recursos você vai sacar direitinho como é ser ágil sem dogmas, mas com muito embasamento. Esse pessoal aí sabe o que está falando. Eles vivem disso, viu?
Participar de uma equipe ágil, é mais ou menos como entregar uma mensagem a Garcia.
Experimente!
Para finalizar, me atrevo a responder a pergunta título desse post: Sou ágil porque faço acontecer.
Se alguém lhe fizesse essa pergunta, como você responderia?
Sua equipe é ágil porque usa Scrum/XP ou usa Scrum/XP porque é ágil?
Essa é uma versão moderna da questão sobre o ovo ou a galinha. Quem veio primeiro?
Afinal, a galinha é galinha porque bota ovo, ou bota ovo porque é galinha?
Tem gente que pensa assim: "Quero ser identificado como agilista. Então preciso usar Scrum e XP. Caso contrário ninguém vai saber que sou ágil."
Outras, já pensam diferente: "Pelo que eu pude ler, acho que estou usando um pouco Scrum. Eu sou ágil!"
Participando de listas sobre ágil há um tempinho, tenho notado que existe a preocupação grande em dar nome ao que se faz. Uma preocupação existente no mundo corporativo é ter títulos ao invés de competências. É uma sopa de letrinhas que não acaba mais. Quem é certificado Java ou PMI que o diga! Minha esposa, que não é de TI, diz que isso é estratégia pra cobrar caro. E ela não deixa de ter razão.
No final das contas o que realmente importa? Ser galinha ou botar ovos? Ser ágil ou usar Scrum/XP?
Outro dia eu conversava com um colega sobre como analisar candidatos para vagas na empresa dele. Eu perguntei como eles avaliavam os currículos. Veja a resposta:
"Se o sujeito diz que é programador, precisa me mostrar código. Se ele não tiver certificações, cursos, faculdade, nem experiência profissional, mas escreve código bom, a gente acha que vale a pena."Como diz o slogan do iG, "o mundo é de quem faz".
Sua equipe não será ágil simplesmente se vocês usam Scrum ou XP. E, sendo ágil, vocês não necessariamente usarão Scrum ou XP. Aliás, não se usa Scrum ou XP. Na minha opinião, Scrum e XP são aplicados e não usados.
Algumas técnicas são usadas sim, mas o que determina se uma equipe é ágil ou não é a atitude dela e não o que ela usa. O artigo "2 anos de Scrum e Agile na Globo.com e algumas coisas que eu aprendi", do Guilherme Chapiewsky, fala sobre isso, de uma forma diferente. Ele passa muita experiência vivida e por isso vale a leitura.
Tá, mas se você me perguntar: "Pô, se não é aplicando ou deixando de aplicar algumas técnicas, então como saber se estou sendo ágil?"
Simples, meu caro, leia o manifesto ágil!
Há um tempo atrás eu escrevi um artigo que fala um pouco sobre isso, chamado Eu já sou ágil e não sabia. Dá uma lida nele. Isso, clica aí, leia e depois volte para continuar esse artigo aqui.
O grande objetivo por trás do manifesto ágil é encontrar formas melhores de desenvolver softwares que funcionem. D-E-S-E-N-V-O-L-V-E-R. Sacou? Não é preencher planilhas infindáveis, trocar emails quilométricos, participar de reuniões sem fim! Não. O objetivo é desenvolver software. E que funcione.
Ser identificado como ágil significa que você, apesar de ser organizado, consegue resolver os problemas dos seus clientes num tempo aceitável, sem muita burocracia, está aberto a mudanças e pronto a replanejar conforme a necessidade deles, os clientes. Sim, eles são os donos do negócio, o motivo de sua profissão existir e são eles quem devem dizer quais funcionalidades o sistema vai ter. Você sugere, mas ele bate o martelo. Acostume-se a isso, por mais absurdo que possa lhe parecer!
Esqueça os nomes e as sopas de letrinhas. Preocupe-se com a qualidade das soluções que você oferece aos seus clientes, com a transparência nas atividades, com o cumprimento dos prazos e, muito importante, com a comunicação interna da equipe.
É por isso que o quadro branco com post-its é tão difundido no meio ágil. Ele é simples de entender, todo mundo domina essa tecnologia, todo mundo vê, não distrai e é fácil de modificar. Simples e objetivo.
Para ter uma noção mais clara do que estou falando, veja Lean em 4 minutos e assista à palestra ministrada na Câmara dos Deputados pelo Bruno Pedroso.
Se você quiser saber como se faz na prática, dê uma lida no PDF sobre produtividade, da Visie. Se gostar mesmo, pense seriamente em participar do curso XP na Prática, da SEA Tecnologia. Leia o depoimento de um participante.
Com esses recursos você vai sacar direitinho como é ser ágil sem dogmas, mas com muito embasamento. Esse pessoal aí sabe o que está falando. Eles vivem disso, viu?
Participar de uma equipe ágil, é mais ou menos como entregar uma mensagem a Garcia.
Experimente!
Para finalizar, me atrevo a responder a pergunta título desse post: Sou ágil porque faço acontecer.
3 de novembro de 2009
Site para leitura mais confortável
Colocar um blog no ar é simples, rápido e gratuito. Mas no afã de dizermos ao mundo o que pensamos, esquecemos do conforto visual dos nossos leitores. Não estou dizendo que você precisa de cores extravagantes ou menus em lugares esquisitos. Coisas assim só atrapalham. Tente seguir os padrões e o bom-senso.
Algumas pessoas já me disseram que gostam de ler os artigos no meu blog. Elas dizem que é confortável. Mas, por que?
São pequenos detalhes. Esse blog aqui usa um tema bem simples, mas personalizado. Muita gente não nota nenhuma diferença, nem percebe que mexi no visual. Na verdade, eu prefiro que seja assim. Não é para perceber mesmo.
Tentando atingir um objetivo do design de interfaces homem x máquina, procuro ser invisível. Eu quero que as pessoas assimilem as informações, e não que fiquem admirando minha obra de arte. Portanto, objetividade é fundamental. O browser Google Chrome também tinha esse objetivo. Na minha opinião eles acertaram em cheio!
Você entra aqui para ler informações. Elas devem ser mostradas rapida e confortavelmente. Eu não posso materializar para você um monitor de 22", mas posso usar algumas técnicas que ajudam a você gostar de ler aqui e sem distraí-lo.
A cor original era um cinza da mesma cor da coluna da direita. Daí eu destaquei o texto dos posts colocando preto neles. Afinal, eles são mais importantes, certo?
As fontes originais do tema são Georgia e Times New Roman. Eu não mudei, porque com a fonte maior, a serifa não atrapalha mais.
Os links são áreas clicáveis e devem ser identificadas como tal ao primeiro passar de olhos. Principalmente dentro de um texto.
Esse tema usava cores pálidas para os links. Resultado: os textos dos links ficavam difíceis de ler. O que eu fiz? Deixei os links sublinhados e em azul para os não-visitados e roxo para os já visitados. Simples assim.
Tem coisa que é melhor não tentar inventar.
Só deixei os links pálidos na coluna da direita, para não brigarem com os que estão nos posts.
Algumas pessoas defendem que linhas limitadas a 66 caracteres ajudam muito a leitura. Outras, acham que desse jeito a largura das telas wide-screen não é valorizada. Essa discussão é grande e não vou entrar nesse mérito.
Nesse blog eu não mudei a largura default do site, mas no Aprenda Python, eu alarguei um pouco e até que ficou bom.
Talvez essa tenha sido a mudança mais simples e que trouxe maior conforto para a leitura do blog.
Se o texto que você tem que ler é grande, parece que as linhas vão "trepando" umas nas outras. Isso pode ser facilmente resolvido com a propriedade
Eu uso o espaçamento 50% maior do que o padrão. Essa altura a mais dá uma folga pro seu olho, fazendo-o descansar quando passa para a linha de baixo e evita ficar com o dedão na tela para não perder a linha que você estava lendo.
Esse é um dos principais motivos que tornam a leitura mais confortável, além do tamanho das letras.
Além dessas personalizações, resolvi colocar a lista dos últimos posts e comentários escritos, para facilitar a vida de quem não assina o feed. Vai que tem ali alguma coisa que o visitante se interessa?
Se você tiver que mostrar algum conteúdo em tabela, leia o texto "(as minhas) 7 boas práticas Tipográficas para Tabelas". É uma receita de bolo bem equilibrada.
E você, o que faz para que seu blog seja mais confortável para os leitores?
Algumas pessoas já me disseram que gostam de ler os artigos no meu blog. Elas dizem que é confortável. Mas, por que?
São pequenos detalhes. Esse blog aqui usa um tema bem simples, mas personalizado. Muita gente não nota nenhuma diferença, nem percebe que mexi no visual. Na verdade, eu prefiro que seja assim. Não é para perceber mesmo.
Tentando atingir um objetivo do design de interfaces homem x máquina, procuro ser invisível. Eu quero que as pessoas assimilem as informações, e não que fiquem admirando minha obra de arte. Portanto, objetividade é fundamental. O browser Google Chrome também tinha esse objetivo. Na minha opinião eles acertaram em cheio!
Você entra aqui para ler informações. Elas devem ser mostradas rapida e confortavelmente. Eu não posso materializar para você um monitor de 22", mas posso usar algumas técnicas que ajudam a você gostar de ler aqui e sem distraí-lo.
Cor, tamanho e tipo da fonte
Eu optei por usar a fonte com 20% acima do tamanho padrão do navegador. O tamanho original do tema era muito pequeno e ficava ruim de ler. Além disso, deixei a coluna da direita com o tamanho de letra menor do que os posts.A cor original era um cinza da mesma cor da coluna da direita. Daí eu destaquei o texto dos posts colocando preto neles. Afinal, eles são mais importantes, certo?
As fontes originais do tema são Georgia e Times New Roman. Eu não mudei, porque com a fonte maior, a serifa não atrapalha mais.
Aparência dos links
De vez em quando eu leio alguma coisa que o Jacob Nielsen escreve, principalmente a coluna Alert Box. Ele é controverso, mas vai ao ponto em certos detalhes que nem nos apercebemos. O artigo Guidelines for Visualizing Links, de 2004, é uma ótima fonte sobre o assunto.Os links são áreas clicáveis e devem ser identificadas como tal ao primeiro passar de olhos. Principalmente dentro de um texto.
Esse tema usava cores pálidas para os links. Resultado: os textos dos links ficavam difíceis de ler. O que eu fiz? Deixei os links sublinhados e em azul para os não-visitados e roxo para os já visitados. Simples assim.
Tem coisa que é melhor não tentar inventar.
Só deixei os links pálidos na coluna da direita, para não brigarem com os que estão nos posts.
Largura das linhas
É certo que linhas longas tornam a leitura mais cansativa e menos produtiva. Mas linhas curtas demais também atrapalham, fazendo muito movimento ocular vertical.Algumas pessoas defendem que linhas limitadas a 66 caracteres ajudam muito a leitura. Outras, acham que desse jeito a largura das telas wide-screen não é valorizada. Essa discussão é grande e não vou entrar nesse mérito.
Nesse blog eu não mudei a largura default do site, mas no Aprenda Python, eu alarguei um pouco e até que ficou bom.
Espaçamento entre linhas
Tão importante quanto a largura das linhas, é o espaçamento vertical entre elas.Talvez essa tenha sido a mudança mais simples e que trouxe maior conforto para a leitura do blog.
Se o texto que você tem que ler é grande, parece que as linhas vão "trepando" umas nas outras. Isso pode ser facilmente resolvido com a propriedade
line-height do CSS, que cuida justamente do espaçamento entre as linhas.Eu uso o espaçamento 50% maior do que o padrão. Essa altura a mais dá uma folga pro seu olho, fazendo-o descansar quando passa para a linha de baixo e evita ficar com o dedão na tela para não perder a linha que você estava lendo.
Esse é um dos principais motivos que tornam a leitura mais confortável, além do tamanho das letras.
Além dessas personalizações, resolvi colocar a lista dos últimos posts e comentários escritos, para facilitar a vida de quem não assina o feed. Vai que tem ali alguma coisa que o visitante se interessa?
Se você tiver que mostrar algum conteúdo em tabela, leia o texto "(as minhas) 7 boas práticas Tipográficas para Tabelas". É uma receita de bolo bem equilibrada.
E você, o que faz para que seu blog seja mais confortável para os leitores?
29 de outubro de 2009
Mantendo o foco
Você já se pegou fazendo uma coisa que não vai te ajudar em nada e, pior, vai te atrapalhar a fazer o que precisa?
Claro que já. Acho que todo mundo passa por esse fenômeno chamado procrastinação. Palavra feia para uma característica mais feia ainda. Eu li um post do Jeveaux intitulado "Procrastinação não" que me inspirou a falar sobre o mesmo assunto, trazendo minha experiência.
Tenho que admitir, sou um procrastinador de carteirinha. Já fui muito pior, estou melhorando. A síndrome do estudante já me pegou de jeito muitas vezes.
Existem alguns motivos para empurrar com a barriga o que a gente precisa fazer:
Às vezes eu sentia que minha tarefa era um "mal necessário". Então, a motivação não vinha mesmo.
Outras vezes eu achava que daria conta do recado, que a atividade era fácil demais e aí, pronto, acabava atrasando!
Há algum tempo eu resolvi dar uma estudada no Getting Things Done (GTD) e isso ajudou um pouco. Pelas navegadas de procrastinação, acabei encontrando o Zen To Done (ZTD) que é um GTD resumido. Existe até uma sugestão do ZTD minimalista -- resumo do resumo -- que é bastante útil para quem está começando nessa empreitada contra a empurrada pra frente. Há outras abordagens, com o Pomodoro, citado no artigo do Jeveaux, que se baseia na ideia de recompensar um tempo que você ficou focado em alguma atividade. Auto-recompensa positiva. Afinal, a psicologia está aí pra isso mesmo.
Levando ao limite o meu lado procrastinador, eu até pensei em desenvolver um aplicativo para me ajudar a não procrastinar! É mole?! Ainda bem que não comecei. Seria mais um projeto idealizado, planejado e empurrado.
Estudar esses métodos é legal, abre um pouco a cabeça, mas a gente acaba se escondendo do real problema: nós mesmos. Há algum tempo eu ouvi que "o pior inimigo de uma pessoa, é ela mesma".
Se não encararmos de frente nossa deficiência, sempre vamos usar a desculpa de estarmos nos preparando para vencer a procrastinação e usar o tempo que deveríamos fazer alguma coisa, para estudar como deixar de empurrá-las. Paradoxal, né?
Portanto, eu resolvi extrair a essência do GTD, ZTD, Pomodoro e outros, e bolei meu sistema pessoal de anti-procrastinação. É bem parecido com o resumo do ZTD, que citei acima.
Eu fiz minha auto-análise e vi que as atividades grandes me causavam dificuldade de vencer a inércia para fazê-las. Então, eu aproveitei um conceito que vi aplicado pela primeira vez nos métodos ágeis: os passos de bebê, ou baby steps. Com tarefas menores, um passo de cada vez, as atividades ficam mais controláveis e você vai vendo o avanço.
Vamos a um exemplo: eu quebrei a atividade "ler emails" em:
Vamos ver como eu estou conseguindo me organizar.
Eu tenho duas vidas: uma pessoal e outra profissional. Elas precisam estar em harmonia e não devem brigar tanto. O Vinicius pai e marido é diferente do Vinicius programador.
Então, minha primeira atitude foi delimitar um horário de trabalho. Como estou trabalhando em casa, essa diferença de papéis é às vezes difícil de se conseguir, sem ter um horário de trabalho.
A segunda ação foi identificar o que realmente é importante para minha rotina diária. Eu dividi o mapa mental em duas partes: pessoal e profissional. Mais uma vez eu usei alguma coisa de técnica ágil e não me preocupei em fazer um backlog grande de atividades que eu penso que são importantes. Só listei as que eu tenho feito normalmente e deixei de lado as que eu gostaria de fazer. Uma lista grande de coisas a fazer também traz frustração e te leva a procrastinar.
A terceira ação foi organizar isso numa agenda. Estou usando dois recursos para me ajudar nessa organização:
Alguns itens parecem bobos, mas se eu estabeleci um horário de trabalho, preciso que meu celular desperte para "começar a trabalhar" e "voltar do almoço", por exemplo.
A quarta ação, que deve estar sempre presente, é a avaliação de o que você estabeleceu de atividade, está de acordo com sua realidade. Por exemplo, eu achei que demoraria 10 minutos para ler os emails da lista X, mas vi que, com objetividade, não passo de 5. Esse ajuste é preciso para ter mais objetividade nas atividades. Aqui, sigo um princípio do Pomodoro e me premio com mais uma tarefa cumprida rapidinho.
Existem algumas coisas que podem nos ajudar ou atrapalhar a vencer a procrastinação.
O Gmail, por exemplo. Ele pode ser seu aliado ou seu inimigo.
Inimigo se você deixá-lo o tempo todo aberto na caixa de entrada. Aliado, se você conseguir configurar filtros eficientes para identificar com labels suas mensagens. Isso sim é GTD! :-)
Afinal, "a diferença entre o remédio e o veneno é a dose".
Eu sofria, como o Jeveaux, do mal da caixa de entrada e do Google Reader e precisava fazer um esforço tremendo para não consultá-los fora de hora. Bem, me libertei desse mal. Como? Deixando o Gmail e o Google Reader fechados. Simples assim. ;-)
Eu não fiquei viciado no Twitter, portanto ele não chegou a ser um problema para mim. Aliás, nem gosto muito dele.
E o instant messenger? Simples, também: não fico nele o dia todo. Eu uso o Pidgin que tem um recurso legal de aviso. Você pode desabilitar os avisos de gente que entra ou sai, mas configurar para ele te avisar quando determinada pessoa entra. Com isso, eu não preciso ficar recebendo os avisos de todo mundo que entra, nem abrindo a lista para ver se fulano está online. Sempre que quero falar com alguém, vejo se a pessoa está online. Se não estiver, configuro o Pidgin para me avisar quando ela logar, ou mando um email. ;-)
Eu descobri que, assim como o celular tem um botão liga/desliga, essas ferramentas também têm. Sério, têm sim! E isso ajuda pra caramba!
Para acompanhar o tempo que levo nas tarefas pequenas, fruto da quebrada de tarefas grandes, uso o TaskCoach. Simples e objetivo. Novamente, uma pitada de técnica ágil aqui.
A quinta ação, a mais difícil de todas, é deixar-se administrar pelos avisos da agenda de compromissos. Aí sim você estará submentendo-se ao seu planejamento. Mas, relaxe. Você deve ser o dono da sua rotina. Se foi você quem a estabeleceu, nada mais lógico do que seguí-la. Faça isso de modo consciente, focando nos resultados.
E veja, o que vai te ajudar a fazer o que precisa, não são os programinhas de controle, mas sua atitude.
Seja seu melhor amigo!
Claro que já. Acho que todo mundo passa por esse fenômeno chamado procrastinação. Palavra feia para uma característica mais feia ainda. Eu li um post do Jeveaux intitulado "Procrastinação não" que me inspirou a falar sobre o mesmo assunto, trazendo minha experiência.
Tenho que admitir, sou um procrastinador de carteirinha. Já fui muito pior, estou melhorando. A síndrome do estudante já me pegou de jeito muitas vezes.
Existem alguns motivos para empurrar com a barriga o que a gente precisa fazer:
- Querer fazer outra coisa
- Excesso de confiança em você mesmo
- Não estar convencido da real necessidade de fazer o que precisa
- Medo de não conseguir fazer
- etc. ...
Às vezes eu sentia que minha tarefa era um "mal necessário". Então, a motivação não vinha mesmo.
Outras vezes eu achava que daria conta do recado, que a atividade era fácil demais e aí, pronto, acabava atrasando!
Há algum tempo eu resolvi dar uma estudada no Getting Things Done (GTD) e isso ajudou um pouco. Pelas navegadas de procrastinação, acabei encontrando o Zen To Done (ZTD) que é um GTD resumido. Existe até uma sugestão do ZTD minimalista -- resumo do resumo -- que é bastante útil para quem está começando nessa empreitada contra a empurrada pra frente. Há outras abordagens, com o Pomodoro, citado no artigo do Jeveaux, que se baseia na ideia de recompensar um tempo que você ficou focado em alguma atividade. Auto-recompensa positiva. Afinal, a psicologia está aí pra isso mesmo.
Levando ao limite o meu lado procrastinador, eu até pensei em desenvolver um aplicativo para me ajudar a não procrastinar! É mole?! Ainda bem que não comecei. Seria mais um projeto idealizado, planejado e empurrado.
Estudar esses métodos é legal, abre um pouco a cabeça, mas a gente acaba se escondendo do real problema: nós mesmos. Há algum tempo eu ouvi que "o pior inimigo de uma pessoa, é ela mesma".
Se não encararmos de frente nossa deficiência, sempre vamos usar a desculpa de estarmos nos preparando para vencer a procrastinação e usar o tempo que deveríamos fazer alguma coisa, para estudar como deixar de empurrá-las. Paradoxal, né?
Portanto, eu resolvi extrair a essência do GTD, ZTD, Pomodoro e outros, e bolei meu sistema pessoal de anti-procrastinação. É bem parecido com o resumo do ZTD, que citei acima.
Eu fiz minha auto-análise e vi que as atividades grandes me causavam dificuldade de vencer a inércia para fazê-las. Então, eu aproveitei um conceito que vi aplicado pela primeira vez nos métodos ágeis: os passos de bebê, ou baby steps. Com tarefas menores, um passo de cada vez, as atividades ficam mais controláveis e você vai vendo o avanço.
Vamos a um exemplo: eu quebrei a atividade "ler emails" em:
- Emails pessoais
- Moderar a lista X
- Ler a lista Y
Vamos ver como eu estou conseguindo me organizar.
Eu tenho duas vidas: uma pessoal e outra profissional. Elas precisam estar em harmonia e não devem brigar tanto. O Vinicius pai e marido é diferente do Vinicius programador.
Então, minha primeira atitude foi delimitar um horário de trabalho. Como estou trabalhando em casa, essa diferença de papéis é às vezes difícil de se conseguir, sem ter um horário de trabalho.
A segunda ação foi identificar o que realmente é importante para minha rotina diária. Eu dividi o mapa mental em duas partes: pessoal e profissional. Mais uma vez eu usei alguma coisa de técnica ágil e não me preocupei em fazer um backlog grande de atividades que eu penso que são importantes. Só listei as que eu tenho feito normalmente e deixei de lado as que eu gostaria de fazer. Uma lista grande de coisas a fazer também traz frustração e te leva a procrastinar.
A terceira ação foi organizar isso numa agenda. Estou usando dois recursos para me ajudar nessa organização:
- Como uso o Ubuntu, instalei o KAlarm que é muito bom para isso.Vale dar uma olhada nos recursos dele.
- O organizador pessoal do meu celular, que está sempre comigo.
Alguns itens parecem bobos, mas se eu estabeleci um horário de trabalho, preciso que meu celular desperte para "começar a trabalhar" e "voltar do almoço", por exemplo.
A quarta ação, que deve estar sempre presente, é a avaliação de o que você estabeleceu de atividade, está de acordo com sua realidade. Por exemplo, eu achei que demoraria 10 minutos para ler os emails da lista X, mas vi que, com objetividade, não passo de 5. Esse ajuste é preciso para ter mais objetividade nas atividades. Aqui, sigo um princípio do Pomodoro e me premio com mais uma tarefa cumprida rapidinho.
Existem algumas coisas que podem nos ajudar ou atrapalhar a vencer a procrastinação.
O Gmail, por exemplo. Ele pode ser seu aliado ou seu inimigo.
Inimigo se você deixá-lo o tempo todo aberto na caixa de entrada. Aliado, se você conseguir configurar filtros eficientes para identificar com labels suas mensagens. Isso sim é GTD! :-)
Afinal, "a diferença entre o remédio e o veneno é a dose".
Eu sofria, como o Jeveaux, do mal da caixa de entrada e do Google Reader e precisava fazer um esforço tremendo para não consultá-los fora de hora. Bem, me libertei desse mal. Como? Deixando o Gmail e o Google Reader fechados. Simples assim. ;-)
Eu não fiquei viciado no Twitter, portanto ele não chegou a ser um problema para mim. Aliás, nem gosto muito dele.
E o instant messenger? Simples, também: não fico nele o dia todo. Eu uso o Pidgin que tem um recurso legal de aviso. Você pode desabilitar os avisos de gente que entra ou sai, mas configurar para ele te avisar quando determinada pessoa entra. Com isso, eu não preciso ficar recebendo os avisos de todo mundo que entra, nem abrindo a lista para ver se fulano está online. Sempre que quero falar com alguém, vejo se a pessoa está online. Se não estiver, configuro o Pidgin para me avisar quando ela logar, ou mando um email. ;-)
Eu descobri que, assim como o celular tem um botão liga/desliga, essas ferramentas também têm. Sério, têm sim! E isso ajuda pra caramba!
Para acompanhar o tempo que levo nas tarefas pequenas, fruto da quebrada de tarefas grandes, uso o TaskCoach. Simples e objetivo. Novamente, uma pitada de técnica ágil aqui.
A quinta ação, a mais difícil de todas, é deixar-se administrar pelos avisos da agenda de compromissos. Aí sim você estará submentendo-se ao seu planejamento. Mas, relaxe. Você deve ser o dono da sua rotina. Se foi você quem a estabeleceu, nada mais lógico do que seguí-la. Faça isso de modo consciente, focando nos resultados.
E veja, o que vai te ajudar a fazer o que precisa, não são os programinhas de controle, mas sua atitude.
Seja seu melhor amigo!
14 de outubro de 2009
[vim] Substituir com parte do que achou
Apesar de o vim ser o editor com o qual escrevo meus programas, eu não o domino como deveria.
Mesmo assim, sempre encontro recursos que me ajudam bastante.
Esses dias eu estava com um arquivo de texto que tinha números e strings entre aspas simples e eu precisava deixar os números sem as aspas simples. As strings deveriam continuar como estavam.
Fazer na mão era muito trabalhoso. O arquivo tinha quase 1000 linhas.
Daí eu resolvi dar uma lidinha no manual online e eis que encontrei a solução!
O comando para substituir (o replace dos editores visuais) é o
Para resolver meu problema o comando completo é
Ele procura no arquivo inteiro (o % diz isso pro comando) uma quantidade qualquer de algarismos (o
A mágica aqui está em colocar o que eu quero preservar (os algarismos encontrados) entre parênteses e usar esse pattern como conteúdo para a substituição (o
O arquivo que eu tinha era mais ou menos assim (a diferença era a quantidade de linhas, como citei acima):
e ficou assim:
Faz uns testes aí e veja como é poderoso!
Mesmo assim, sempre encontro recursos que me ajudam bastante.
Esses dias eu estava com um arquivo de texto que tinha números e strings entre aspas simples e eu precisava deixar os números sem as aspas simples. As strings deveriam continuar como estavam.
Fazer na mão era muito trabalhoso. O arquivo tinha quase 1000 linhas.
Daí eu resolvi dar uma lidinha no manual online e eis que encontrei a solução!
O comando para substituir (o replace dos editores visuais) é o
:substitute ou, simplesmente, :s.Para resolver meu problema o comando completo é
:%s/'\(\d\+\)'/\1/g
Ele procura no arquivo inteiro (o % diz isso pro comando) uma quantidade qualquer de algarismos (o
\d\+) com uma aspa simples antes e outra depois e substitui isso tudo (os algarismos e as aspas) apenas pelos algarismos encontrados (o \1).A mágica aqui está em colocar o que eu quero preservar (os algarismos encontrados) entre parênteses e usar esse pattern como conteúdo para a substituição (o
\1), quantas vezes houver em cada linha (o g no final do comando).O arquivo que eu tinha era mais ou menos assim (a diferença era a quantidade de linhas, como citei acima):
'João', '123', 'M' 'Maria', '7', 'F' 'Fernando', '58', 'M'
e ficou assim:
'João', 123, 'M' 'Maria', 7, 'F' 'Fernando', 58, 'M'
Faz uns testes aí e veja como é poderoso!
7 de outubro de 2009
Senha forte ou fraca?
Durante esses dias tenho lido a respeito das 10 mil senhas do Hotmail que foram publicadas na internet.
Um pesquisador resolveu investigar e descobriu que a maioria dessas senhas não eram muito seguras.
Daí eu me lembrei que sempre quando fazemos o cadastro num serviço de email sério, existe aquele aviso dizendo que a senha é forte (segura) ou fraca (não segura).
Afinal, pra quê existe aquele aviso se a gente sempre coloca a senha que dá na cabeça?
Usar um gerador de senha não é lá muito prático, porque a combinação de caracteres gerados nem sempre é fácil de lembrar.
Daí eu resolvi recorrer a dois serviços que fazem a validação de senha, dizendo se ela é forte ou fraca.
Um é o Strength Test e o outro é o Javascript Password Strength Meter.
Que tal começar a validar suas senhas para não ser pego de surpresa?
Um pesquisador resolveu investigar e descobriu que a maioria dessas senhas não eram muito seguras.
Daí eu me lembrei que sempre quando fazemos o cadastro num serviço de email sério, existe aquele aviso dizendo que a senha é forte (segura) ou fraca (não segura).
Afinal, pra quê existe aquele aviso se a gente sempre coloca a senha que dá na cabeça?
Usar um gerador de senha não é lá muito prático, porque a combinação de caracteres gerados nem sempre é fácil de lembrar.
Daí eu resolvi recorrer a dois serviços que fazem a validação de senha, dizendo se ela é forte ou fraca.
Um é o Strength Test e o outro é o Javascript Password Strength Meter.
Que tal começar a validar suas senhas para não ser pego de surpresa?
28 de setembro de 2009
[Ubuntu] Tamanho da janela do terminal
Tenho usado o Linux direto como meu sistema operacional principal e algumas coisas vão precisando ser personalizadas à medida que vou trabalhando.
Como uso esse ambiente para programar e gosto do teclado, tenho a linha de comando como aliada. O tamanho default da janela do terminal me incomodava bastante. Sempre que a abria, tinha que configurar o tamanho de minha preferência.
Ou seja, toda vez era a mesma sequência de teclas:
Com o tempo meu lado preguiçoso começou a falar alto e acabei achando que o "ALT+T" + "4" deviam ser eliminados.
A primeira ação foi configurar uma profile, certo? Errado! Essa configuração não faz parte da profile do terminal.
Procurei na internet e segui algumas dicas para configurar o tamanho default da janela do terminal no Main Menu passando a opção "--geometry" para o terminal. Não funcionou, pois essa alternativa só é executada quando escolho com o mouse a chamada ao Terminal. Bem, eu já disse em outro post que não sou fã do mouse, certo? ;-)
Procurei mais um pouco e encontrei uma dica que resolveu meu problema: o tópico Terminal size no Ubuntu Forums.
Obs.: O interessante é que a pergunta foi feita originalmente em fevereiro de 2005 e só foi respondida em outubro de 2007! Concluí que pouca gente deve saber disso.
Segue aqui a dica traduzida:
O gnome-terminal usa o arquivo termcap para suas configurações básicas. Para modificar o tamanho default da janela, edite o arquivo xterm com o seguinte comando:
Para mudar o número de colunas, modifique o parâmetro co#.
Para mudar o número de linhas, modifique o parâmetro li#.
Como exemplo, se você quiser um terminal de 132 colunas por 43 linhas (que é o meu caso), sua configuração ficaria assim:
Para essa modificação ter efeito, feche todas as janelas do terminal que estiverem abertas. A primeira que você abrir, já terá o tamanho de sua preferência.
Como uso esse ambiente para programar e gosto do teclado, tenho a linha de comando como aliada. O tamanho default da janela do terminal me incomodava bastante. Sempre que a abria, tinha que configurar o tamanho de minha preferência.
Ou seja, toda vez era a mesma sequência de teclas:
- Super + espaço (para chamar o Gnome-Do -- se você gosta do teclado, use-o!)
- digitar: terminal
- ALT+T
- 4 (para a tela ficar no tamanho de 132 colunas por 43 linhas)
Com o tempo meu lado preguiçoso começou a falar alto e acabei achando que o "ALT+T" + "4" deviam ser eliminados.
A primeira ação foi configurar uma profile, certo? Errado! Essa configuração não faz parte da profile do terminal.
Procurei na internet e segui algumas dicas para configurar o tamanho default da janela do terminal no Main Menu passando a opção "--geometry" para o terminal. Não funcionou, pois essa alternativa só é executada quando escolho com o mouse a chamada ao Terminal. Bem, eu já disse em outro post que não sou fã do mouse, certo? ;-)
Procurei mais um pouco e encontrei uma dica que resolveu meu problema: o tópico Terminal size no Ubuntu Forums.
Obs.: O interessante é que a pergunta foi feita originalmente em fevereiro de 2005 e só foi respondida em outubro de 2007! Concluí que pouca gente deve saber disso.
Segue aqui a dica traduzida:
O gnome-terminal usa o arquivo termcap para suas configurações básicas. Para modificar o tamanho default da janela, edite o arquivo xterm com o seguinte comando:
$ sudo gedit /usr/share/vte/termcap/xtermPara mudar o número de colunas, modifique o parâmetro co#.
Para mudar o número de linhas, modifique o parâmetro li#.
Como exemplo, se você quiser um terminal de 132 colunas por 43 linhas (que é o meu caso), sua configuração ficaria assim:
:co#132:it#8:li#43:\Para essa modificação ter efeito, feche todas as janelas do terminal que estiverem abertas. A primeira que você abrir, já terá o tamanho de sua preferência.
24 de agosto de 2009
O que todo coordenador ou gerente de TI deve saber
Esse post é o outro lado da moeda do post O que todo desenvolvedor deve saber, motivado pelos comentários dos leitores Alexandre Santos, Rafael e Anônimo (do dia 21/08/09 às 17:35).
Minha intenção naquele post era a de mostrar aos desenvolvedores que não conseguimos viver apenas de idealismo em nossa profissão. Temos que tentar ficar antenados com o ambiente que nos cerca, normalmente capitalista e afoito por bons resultados tangíveis.
Neste aqui, pretendo dizer aos coordenadores e gerentes de TI que somos idealistas e que temos vontade própria, como bem ressaltou o Rafael em seu comentário de 21/08/09 às 17:22.
Bem, vamos ao post.
Em todos esses anos de desenvolvedor, já passei pelas mãos de muitos coordenadores e gerentes, e também já coordenei muita gente.
Já trabalhei numa "euquipe" (eu sozinho), já tive coordenador muito bom, já vi gerente de relatórios, já coordenei nó-cego e cara bom de serviço. Já vi gente dizer que para gerenciar técnico, tem que ser técnico. Já vi muita gente dizer que nem sempre isso é necessário. Já vi bons técnicos tornarem-se péssimos gerentes.
Mas nunca vi um bom gerente tornar-se um bom técnico. Será que existe algum motivo para isso?
Por que, geralmente, as pessoas que ocupam posição de liderança esquecem-se de como é ser um técnico? Por que é que quando elas sobem um degrau, começam a comportar-se exatamente da mesma forma que o gerente de quem elas tanto reprovavam as atitudes?
Se você é um coordenador ou gerente de uma equipe de TI, seria bom lembrar de alguns detalhes que para nós desenvolvedores não são meros detalhes.
1. Não somos robôs.
É, não somos seres autômatos que fazem sempre as mesmas coisas, apesar de às vezes isso parecer ser verdade.
Não somos uma peça que pode ser trocada e a outra assume imediatamente nosso papel e função. Se você, coordenador de TI, já ouviu falar da era da informação, sociedade da informação, sociedade conectada e termos assim, já deve ter lido o livro A Empresa na Velocidade do Pensamento do Bill Gates.
Ah, você não leu esse livro? Desculpe, mas acho que você ainda precisa entender como as coisas poderiam funcionar em sua empresa. Depois de entender isso, você vai cair na real e sacar que as pessoas têm um papel fundamental no cumprimento de alguns quesitos importantes em sua equipe.
Se você acha que os desenvolvedores, sendo o "chão de fábrica", são dispensáveis, me explique o por quê de os softwares geradores de código tão promissores nas décadas de 80 e 90 não decolaram. Se você ainda não estava na informática nesse tempo, me diga o motivo de os webdesigners profissionais (aqueles bons e que realmente sabem o que estão fazendo) valorizarem tanto códigos HTML e CSS e dispensarem tanto os códigos gerados pelo Dreamweaver (e, antigamente, pelo Frontpage).
Subindo um pouco o nível, tente dispensar alguém de sua equipe na semana de implantação do sistema em produção!
Pois é, não somos robôs. O conhecimento que está dentro de nossa cabeça não passa por osmose, nem quando programamos em par. Sim, programação em par existe! E é realidade. Não é coisa de futuro, não. Sobre isso, "o Google é seu amigo". Ah, e também não trata-se de meiose. :-P
2. Somos telhado de vidro.
Se você tivesse um telhado de vidro, jogaria pedra nele? Eu não! De jeito nenhum! Pois é por ali que a primeira chuva vai entrar: por onde a pedra caiu.
Muitas vezes nós, os desenvolvedores, somos usados para levar a culpa de inconsistências e de mal-entendidos. Ora, não somos perfeitos e temos a chance de entender errado, certas coisas. Já vi muitos desenvolvedores omissos, que não mereciam ser estagiários, mas eram considerados seniores. Esses, na minha empresa nem chegariam à metade do estágio.
Em contrapartida, pela dinâmica das nossas atividades, não podemos pedir que os usuários assinem tudo. Como queremos entregar nosso trabalho com agilidade, usamos muito de telefone e contato pessoal para tirar dúvidas. Nem tudo fica escrito ou documentado. Quando entendemos o que foi solicitado e mostramos o resultado para o chefe de quem nos deu a informação que faltava, frequentemente ouvimos um claro e alto "não é assim que precisamos!" ou um "não foi isso que eu pedi!".
Nessas horas, o que mais queremos é um aliado, que confie no que dizemos, que acredite que realmente recebemos a informação para fazer assim. Se é para fazer diferente, que seja, mas precisamos de um escudo, não de outra pedra!
3. O que é certo? E o que é errado?
Você já pensou que fazemos muita coisa certa, mas que parece errada? E algumas coisas erradas que parecem certas?
Pense numa totalização de nota fiscal onde o valor desta precisa bater com o total dos valores dos itens, multiplicados por suas respectivas quantidades. Ser rígido assim é correto? Sim, mas nem sempre.
Não vou entrar aqui em detalhes, mas trabalhei por vários anos em empresas de Telecom, onde os itens são trabalhados com 5 casas decimais, mas o valor a pagar pelo consumidor tem apenas 2 casas. Se você já teve problema com arredondamento de valores, vai entender do que estou falando.
Agora me responda: o que é certo e o que é errado nesse caso?
É bom termos as regras de negócio bem claras e usuários que realmente conheçam o negócio. Refiro-me à matemática, não à informática!
Ruim é fazer o certo e alguém dizer que está errado. Isso pode ser trágico, às vezes.
4. Trabalhamos para viver; não vivemos para trabalhar.
Não vou nem escrever sobre isso. Indico a leitura do famoso texto O Cara da Informática.
5. Seria bom você ser um técnico.
Como eu disse, já ouvi opiniões contra e a favor dessa afirmação.
Como técnico, eu gostaria muito que meu coordenador ou gerente fosse "um dos nossos". Seria bom que ele soubesse das dificuldades que enfrento. Seria bom que as pressões e decisões fossem embasadas apenas em critérios técnicos.
Como eu já fui coordenador, sei que não vivemos no mundo perfeito e que esse cenário nem sempre é possível de encontrar. As pressões nem sempre têm coerência técnica, mas as decisões podem ter.
Como coordenador ou gerente, identifique seus técnicos confiáveis e confie neles. Seja o cabeça, mas utilize-os como seus braços. Aliás, sugiro que você os use como seus cérebros sempre que puder. Filtre as coisas, claro, mas use-as!
Seja lá como for, procure entender um pouco do nosso mundo. Converse conosco. Também temos ideias. Aliás, é por isso que ganhamos mais do que muitas profissões mais antigas. Por nossas ideias e soluções. Lembra da sociedade da informação?
6. Pra quê serve o maestro da orquestra?
Seja sincero, você faria uma estimativa com o único objetivo de furar o prazo? Nós também não.
Os desenvolvedores acham que podem fazer mais do que realmente fazem. Frequentemente me pego agindo assim. Somos autoconfiantes e otimistas, mas não chutamos fora por querer.
Às vezes chutamos na trave, às vezes fazemos gol, às vezes a bola vai lá na arquibancada. Os jogadores de fubetol também fazem assim, não vencem todas as partidas, mas ninguém quer mandá-los embora só por causa disso, certo?
Antes de jogar, o time treina. Antes de fazer a apresentação, a orquestra ensaia. E por que, antes de desenvolver, os desenvolvedores não treinam nem ensaiam? Já pensou nisso?
Até hoje, de todas as empresas que eu trabalhei, só uma empresa (uma única! umazinha só!) se preocupava com os ensaios da equipe técnica. Não era obrigado, mas livre para quem quisesse participar. Essa vale a pena citar: é a SEA Tecnologia, que fica em Brasília. Lá tem uns caras feras (mesmo!), e que treinam o tempo todo. O Coding Dojo pode ser uma boa ideia, viu?
Você, como coordenador, se preocupa com o ensaio da sua equipe? Não estou pedindo curso, não. Lembre-se: o técnico treina o time. O maestro ensaia a orquestra. E o coordenador de TI, faz o que?
Pense nisso!
7. Somos pagos para compartilhar conhecimento.
Sim, todos nós! Eu disse todos?!
Ei coordenador, e aquele cara que só esconde o jogo? É o mesmo que não passa a bola. É o cara que só quer ser o solista, o primeiro violino! O cara que só toca o que quer, quando quer.
Será que ele teria espaço no time ou na orquestra?
8. Somos pagos para aprender, certo?
Isso me faz lembrar do item anterior: compartilhar conhecimento.
Se alguém da mesma empresa já sabe o que preciso fazer, que tal você, coordenador, promover um encontro técnico?
Afinal, para a gerência, quanto antes as coisas ficarem prontas, melhor para todos, certo? ;-)
Eu trabalhei recentemente em um lugar onde a internet era bloqueada durante o expediente. Será que existe maior incoerência do que essa? Privar os profissionais de tecnologia de terem acesso a informação?
Como aprender num ambiente assim?
Sem comentários, né?
9. A mesma regulagem para todos.
Se você mede 1,80m e sua esposa 1,50m e vocês compartilham o mesmo carro, o banco do motorista precisa ser ajustado, bem como os retrovisores, certo?
O mesmo acontece com as chuteiras dos jogadores, com os graus dos óculos de quem tem déficit de visão. Cada um tem uma necessidade e preferência próprias.
Se isso é tão claro nesses exemplos, por que nós, desenvolvedores, somos forçados a usarmos as mesmas ferramentas o tempo todo?
Se eu sou produtivo com Eclipse e meu colega com Vim, você pode me explicar por que temos todos que usar Netbeans?
Há em muitos lugares uma situação vista no início do século XX, quando Henry Ford disse certa vez que "você pode ter um carro de qualquer cor, desde que ele seja preto". Uau! :-#
É isso, coordenadores e gerentes de TI. Vamos ficar ligados. Sem paternalismo, mas com discernimento.
Tem muito mais coisa pra falar, mas acho que os comentários vão ajudar a expandir o assunto, certo?
Minha intenção naquele post era a de mostrar aos desenvolvedores que não conseguimos viver apenas de idealismo em nossa profissão. Temos que tentar ficar antenados com o ambiente que nos cerca, normalmente capitalista e afoito por bons resultados tangíveis.
Neste aqui, pretendo dizer aos coordenadores e gerentes de TI que somos idealistas e que temos vontade própria, como bem ressaltou o Rafael em seu comentário de 21/08/09 às 17:22.
Bem, vamos ao post.
Em todos esses anos de desenvolvedor, já passei pelas mãos de muitos coordenadores e gerentes, e também já coordenei muita gente.
Já trabalhei numa "euquipe" (eu sozinho), já tive coordenador muito bom, já vi gerente de relatórios, já coordenei nó-cego e cara bom de serviço. Já vi gente dizer que para gerenciar técnico, tem que ser técnico. Já vi muita gente dizer que nem sempre isso é necessário. Já vi bons técnicos tornarem-se péssimos gerentes.
Mas nunca vi um bom gerente tornar-se um bom técnico. Será que existe algum motivo para isso?
Por que, geralmente, as pessoas que ocupam posição de liderança esquecem-se de como é ser um técnico? Por que é que quando elas sobem um degrau, começam a comportar-se exatamente da mesma forma que o gerente de quem elas tanto reprovavam as atitudes?
Se você é um coordenador ou gerente de uma equipe de TI, seria bom lembrar de alguns detalhes que para nós desenvolvedores não são meros detalhes.
1. Não somos robôs.
É, não somos seres autômatos que fazem sempre as mesmas coisas, apesar de às vezes isso parecer ser verdade.
Não somos uma peça que pode ser trocada e a outra assume imediatamente nosso papel e função. Se você, coordenador de TI, já ouviu falar da era da informação, sociedade da informação, sociedade conectada e termos assim, já deve ter lido o livro A Empresa na Velocidade do Pensamento do Bill Gates.
Ah, você não leu esse livro? Desculpe, mas acho que você ainda precisa entender como as coisas poderiam funcionar em sua empresa. Depois de entender isso, você vai cair na real e sacar que as pessoas têm um papel fundamental no cumprimento de alguns quesitos importantes em sua equipe.
Se você acha que os desenvolvedores, sendo o "chão de fábrica", são dispensáveis, me explique o por quê de os softwares geradores de código tão promissores nas décadas de 80 e 90 não decolaram. Se você ainda não estava na informática nesse tempo, me diga o motivo de os webdesigners profissionais (aqueles bons e que realmente sabem o que estão fazendo) valorizarem tanto códigos HTML e CSS e dispensarem tanto os códigos gerados pelo Dreamweaver (e, antigamente, pelo Frontpage).
Subindo um pouco o nível, tente dispensar alguém de sua equipe na semana de implantação do sistema em produção!
Pois é, não somos robôs. O conhecimento que está dentro de nossa cabeça não passa por osmose, nem quando programamos em par. Sim, programação em par existe! E é realidade. Não é coisa de futuro, não. Sobre isso, "o Google é seu amigo". Ah, e também não trata-se de meiose. :-P
2. Somos telhado de vidro.
Se você tivesse um telhado de vidro, jogaria pedra nele? Eu não! De jeito nenhum! Pois é por ali que a primeira chuva vai entrar: por onde a pedra caiu.
Muitas vezes nós, os desenvolvedores, somos usados para levar a culpa de inconsistências e de mal-entendidos. Ora, não somos perfeitos e temos a chance de entender errado, certas coisas. Já vi muitos desenvolvedores omissos, que não mereciam ser estagiários, mas eram considerados seniores. Esses, na minha empresa nem chegariam à metade do estágio.
Em contrapartida, pela dinâmica das nossas atividades, não podemos pedir que os usuários assinem tudo. Como queremos entregar nosso trabalho com agilidade, usamos muito de telefone e contato pessoal para tirar dúvidas. Nem tudo fica escrito ou documentado. Quando entendemos o que foi solicitado e mostramos o resultado para o chefe de quem nos deu a informação que faltava, frequentemente ouvimos um claro e alto "não é assim que precisamos!" ou um "não foi isso que eu pedi!".
Nessas horas, o que mais queremos é um aliado, que confie no que dizemos, que acredite que realmente recebemos a informação para fazer assim. Se é para fazer diferente, que seja, mas precisamos de um escudo, não de outra pedra!
3. O que é certo? E o que é errado?
Você já pensou que fazemos muita coisa certa, mas que parece errada? E algumas coisas erradas que parecem certas?
Pense numa totalização de nota fiscal onde o valor desta precisa bater com o total dos valores dos itens, multiplicados por suas respectivas quantidades. Ser rígido assim é correto? Sim, mas nem sempre.
Não vou entrar aqui em detalhes, mas trabalhei por vários anos em empresas de Telecom, onde os itens são trabalhados com 5 casas decimais, mas o valor a pagar pelo consumidor tem apenas 2 casas. Se você já teve problema com arredondamento de valores, vai entender do que estou falando.
Agora me responda: o que é certo e o que é errado nesse caso?
É bom termos as regras de negócio bem claras e usuários que realmente conheçam o negócio. Refiro-me à matemática, não à informática!
Ruim é fazer o certo e alguém dizer que está errado. Isso pode ser trágico, às vezes.
4. Trabalhamos para viver; não vivemos para trabalhar.
Não vou nem escrever sobre isso. Indico a leitura do famoso texto O Cara da Informática.
5. Seria bom você ser um técnico.
Como eu disse, já ouvi opiniões contra e a favor dessa afirmação.
Como técnico, eu gostaria muito que meu coordenador ou gerente fosse "um dos nossos". Seria bom que ele soubesse das dificuldades que enfrento. Seria bom que as pressões e decisões fossem embasadas apenas em critérios técnicos.
Como eu já fui coordenador, sei que não vivemos no mundo perfeito e que esse cenário nem sempre é possível de encontrar. As pressões nem sempre têm coerência técnica, mas as decisões podem ter.
Como coordenador ou gerente, identifique seus técnicos confiáveis e confie neles. Seja o cabeça, mas utilize-os como seus braços. Aliás, sugiro que você os use como seus cérebros sempre que puder. Filtre as coisas, claro, mas use-as!
Seja lá como for, procure entender um pouco do nosso mundo. Converse conosco. Também temos ideias. Aliás, é por isso que ganhamos mais do que muitas profissões mais antigas. Por nossas ideias e soluções. Lembra da sociedade da informação?
6. Pra quê serve o maestro da orquestra?
Seja sincero, você faria uma estimativa com o único objetivo de furar o prazo? Nós também não.
Os desenvolvedores acham que podem fazer mais do que realmente fazem. Frequentemente me pego agindo assim. Somos autoconfiantes e otimistas, mas não chutamos fora por querer.
Às vezes chutamos na trave, às vezes fazemos gol, às vezes a bola vai lá na arquibancada. Os jogadores de fubetol também fazem assim, não vencem todas as partidas, mas ninguém quer mandá-los embora só por causa disso, certo?
Antes de jogar, o time treina. Antes de fazer a apresentação, a orquestra ensaia. E por que, antes de desenvolver, os desenvolvedores não treinam nem ensaiam? Já pensou nisso?
Até hoje, de todas as empresas que eu trabalhei, só uma empresa (uma única! umazinha só!) se preocupava com os ensaios da equipe técnica. Não era obrigado, mas livre para quem quisesse participar. Essa vale a pena citar: é a SEA Tecnologia, que fica em Brasília. Lá tem uns caras feras (mesmo!), e que treinam o tempo todo. O Coding Dojo pode ser uma boa ideia, viu?
Você, como coordenador, se preocupa com o ensaio da sua equipe? Não estou pedindo curso, não. Lembre-se: o técnico treina o time. O maestro ensaia a orquestra. E o coordenador de TI, faz o que?
Pense nisso!
7. Somos pagos para compartilhar conhecimento.
Sim, todos nós! Eu disse todos?!
Ei coordenador, e aquele cara que só esconde o jogo? É o mesmo que não passa a bola. É o cara que só quer ser o solista, o primeiro violino! O cara que só toca o que quer, quando quer.
Será que ele teria espaço no time ou na orquestra?
8. Somos pagos para aprender, certo?
Isso me faz lembrar do item anterior: compartilhar conhecimento.
Se alguém da mesma empresa já sabe o que preciso fazer, que tal você, coordenador, promover um encontro técnico?
Afinal, para a gerência, quanto antes as coisas ficarem prontas, melhor para todos, certo? ;-)
Eu trabalhei recentemente em um lugar onde a internet era bloqueada durante o expediente. Será que existe maior incoerência do que essa? Privar os profissionais de tecnologia de terem acesso a informação?
Como aprender num ambiente assim?
Sem comentários, né?
9. A mesma regulagem para todos.
Se você mede 1,80m e sua esposa 1,50m e vocês compartilham o mesmo carro, o banco do motorista precisa ser ajustado, bem como os retrovisores, certo?
O mesmo acontece com as chuteiras dos jogadores, com os graus dos óculos de quem tem déficit de visão. Cada um tem uma necessidade e preferência próprias.
Se isso é tão claro nesses exemplos, por que nós, desenvolvedores, somos forçados a usarmos as mesmas ferramentas o tempo todo?
Se eu sou produtivo com Eclipse e meu colega com Vim, você pode me explicar por que temos todos que usar Netbeans?
Há em muitos lugares uma situação vista no início do século XX, quando Henry Ford disse certa vez que "você pode ter um carro de qualquer cor, desde que ele seja preto". Uau! :-#
É isso, coordenadores e gerentes de TI. Vamos ficar ligados. Sem paternalismo, mas com discernimento.
Tem muito mais coisa pra falar, mas acho que os comentários vão ajudar a expandir o assunto, certo?
11 de agosto de 2009
Scrum fora da TI – Reconhecendo o ambiente
Hoje (10/ago/2009) eu comecei a aplicar um pouco de Scrum em um ambiente que não é o de desenvolvimento de sistemas.
Meu desafio será aplicar Scrum em uma fábrica de roupas na região de Vitória (ES). Em outras palavras, vamos praticar alguma coisa de metodologia ágil em um ambiente altamente tendencioso ao modelo taylorista, focado em procedimentos.
Ter o manifesto ágil em mente é importante para não se deixar levar pelos impulsos naturais, pois a situação da fábrica é muito delicada;
A gerente geral dessa fábrica assumiu há cerca de um mês e encontrou um ambiente completamente desordenado onde as informações vitais simplesmente não existiam. Ninguém sabia o quê estava sendo produzido exatamente. As demandas de produção não eram conhecidas. Também não havia nenhuma noção de agendamento, capacidade de produção, o que deveria ser pago nem quando, nem tampouco o que havia para receber na praça. Resumindo bastante: caos total e muita dívida. Repetindo: muita dívida!
Eu não me lembro de ter trabalhado em um projeto com tanto risco, tanta incerteza e tantas restrições juntos ao mesmo tempo. Talvez o maior risco para mim seja meu próprio salário, mas sou movido a desafios. rsrs
A partir de agora eu pertenço à equipe que tem como objetivo fazer as informações circularem de forma orgânica nessa fábrica. Novamente falando no bom e claro português: estamos apagando o incêndio. Meu foco será a área financeira. Eu não atuarei como desenvolvedor de aplicativos. Não serei o “cara da informática”. Serei o gerente financeiro por algum tempo.
Num caso como esse podem surgir algumas perguntas naturais, que também me vieram à mente, e que tentarei responder abaixo.
1) Ágil fora do desenvolvimento de sistemas?!
Sim, e por mais absurdo que possa parecer para alguns, por que não?Um dos motivos é porque o manifesto ágil nos recomenda valorizar mais as pessoas do que os processos. Não importa o tipo de atividade que façamos. Se essas atividades são executadas por pessoas, estas (as pessoas) devem ser valorizadas.
Além disso, Scrum é um framework de gerenciamento que não me deixa engessado e eu posso adequá-lo às minhas necessidades.2) Usar método ágil num contexto de linha de produção não é incoerente ou incompatível?
A fábrica não são só as máquinas funcionando. Existem as áreas administrativa, de RH, financeira, comercial, compras, logística, etc.Todas essas áreas da empresa têm atividades que precisam ser realizadas em determinada ordem de prioridade. Temos vários projetos sendo executados ao mesmo tempo: entrega de bermudas para o cliente "a"; arremate de peças para o cliente "b"; "namoro" com vários representantes e potenciais clientes e fornecedores ao mesmo tempo; patrocínio de atletas; participação em eventos... e por aí vai.
Engana-se quem pensa que as prioridades nesse ambiente são sempre as mesmas e que não há variação de atividade. O que não existe aqui é uma coisa chamada monotonia, meu amigo!Cada coisa a ser feita é uma história diferente e cada uma delas vai impactar no resultado da empresa de maneira positiva ou negativa, dependendo de nossa decisão. Sim, o termo "história" não foi usado aqui por acaso e tem muito a ver com os cartõezinhos do kanban. ;-)
Toda empresa é um organismo vivo que precisa responder rapidamente às mudanças de mercado, de legislação e estar à frente da concorrência. Ou seja, precisamos ser ágeis.3) Por que não apagar primeiro o incêndio para depois pensar num modelo ágil?
Porque o manifesto ágil nos diz que podemos ter retorno rápido e palpável do investimento.Se eu tenho um cenário de falta total de informação, mas a empresa continua funcionando, tendo que produzir, pagar funcionários, fornecedores e credores, nada mais natural do que utilizar um meio de focar no que é prioritário para ter um grande ROI, o mais rápido possível.
Além disso, para cada tipo de peça fabricada, ou de tecido utilizado, eu preciso saber a capacidade de produção (velocidade) de minha equipe. Note que aqui temos níveis de complexidade diferentes para atividades diferentes.Estamos aprendendo o tempo todo, pois lidamos com tipos de tecido diferentes, arremates mais simples e outros mais complexos, que influenciam diretamente na minha velocidade de produção. Agora você já consegue enxergar alguma semelhança com produção de software?
Alguns podem pensar que são coisas completamente distintas. Realmente são.Outros podem dizer que software não é produzido em linha, como roupas. Novamente, têm razão.
Mas uma coisa é inegável: o manifesto ágil me dá a oportunidade de humanizar mais algumas áreas tidas como "robotizáveis", o que nem sempre é verdade. Me dá também a oportunidade de maximizar o ROI do meu cliente.O Scrum me dá a visibilidade de completamento de tarefas para que as pessoas tenham mais comprometimento e mais responsabilidade em suas atividades. Me auxilia a analisar o que fizemos, onde erramos e o que vamos fazer para não errarmos igual no futuro.
Minha experiência está apenas no início. Ainda teremos muita história para contar e idéias para trocar.
Até breve.5 de agosto de 2009
Todo desenvolvedor deve saber
Estou na estrada de desenvolvimento de sistemas há um bom tempo e tenho visto tecnologias surgirem e desaparecerem.
Tenho ouvido um monte de letras ao longo dos anos. Às vezes siglas exatamente iguais significam coisas completamente diferentes!
A cada 2 ou 3 anos surge uma nova linguagem, um novo framework, uma nova metodologia, uma nova ferramenta... e por aí vai.
Por causa dessas mudanças todas, resolvi relacionar algumas coisas que todo desenvolvedor precisa saber.
A tecnologia conta, mas as pessoas é que colocam a tecnologia em ação.
1. Você é pago para dar lucro.
A despeito de suas preferências e independentemente de quão gente boa você é, você é pago para dar resultado palpável.
A empresa não vai ficar com você simplesmente pelo fato de você ser nerd pra caramba e estar por dentro da última release do kernel do linux, que tem uma nova opção de boot que acelera o processo em 0.50ms.
Acorda aí!
2. Você é pago para compartilhar conhecimento.
Pode parecer meio estranho para alguns, mas o conhecimento que você tem na sua cabeça não é só seu. Ou não deveria. É por isso que algumas empresas dizem que seus colaboradores formam seu capital intelectual.
Capital = dinheiro
Intelecto = conhecimento
Isso nos remete ao 1o item: você tem que dar lucro! Com seu conhecimento, viu?
Então, compartilhe.
Eu tenho um amigo que diz que quem esconde o jogo tem prisão de ventre cerebral.
Pior que ele tem razão! rsrs
3. A empresa tem necessidades que nem sempre são as suas.
Já reparou nisso?
a) aceite as necessidades da sua empresa.
b) encontre alguém que queira aceitar as suas necessidades.
4. Você é pago para aprender.
Esse é o emprego dos sonhos de todo mundo, né?
Nem sempre. Pense bem.
Quando você é pago para aprender sem prazo para terminar, é uma coisa.
Mas quando o projeto tem data marcada, cuidado!
Se você é especialista em PHP, mas tem que fazer alguma coisa em Ruby on Rails em 1 mês, os espinhos do mar de rosas comecam a aparecer e a arranhar, mesmo o mundo todo dizendo que o negócio é facinho pra caramba. Sim, fazer o aplicativo de blog que tem no tutorial é banal. O difícil é fazer o aplicativo que você precisa entregar.
Mas você é pago para aprender. Aprenda ou diga logo que não consegue.
Uma dica: aprenda a aprender!
5. Você é pago para (ou por) saber fazer e conhecer muita coisa.
Você é fera em Python? Bom.
Fera mesmo? Muito bom.
É um dos desenvolvedores da linguagem? Ótimo!
Mas não consegue dar uma palestra sobre isso? Que pena! :-(
A empresa precisa de pessoas multidisciplinares. Ou seja, aquele cara que bate o pênalti e corre p/ defender!
Se você é bom em programação mas nunca pensou em sair de frente do computador para dar uma palestra, reveja seus conceitos.
Se a timidez toma conta do seu ser a ponto de embrulhar seu estômago, suar suas mãos, tremer suas pernas, pense em fazer um curso de teatro. Isso sim é sair da zona de conforto!
6. Sua experiência de vida conta.
Não estou falando apenas sobre quantas linguagem e bancos de dados você conhece.
Estou falado sobre como você se virou pela primeira vez que sua mãe ou seu pai te mandou fazer o 1o pagamento sozinho no banco.
Estou falando sobre a 1a vez que você chamou uma garota p/ namorar e ela aceitou.
É disso que estou falando. Traga suas experiências para a empresa. Conte sua história! Ela vale muito.
Ei, esqueci de falar que um desenvolvedor precisa saber Java, C, Ruby, Python, SQL, HTML, CSS, PHP, Linux, Shell. Precisa saber o que significa ASP (linguagem), ASP (serviço), XML, RPC, DOM, DAO, Controller, MVC, Servlet, SCRUM, XP...
Bem, isso todo mundo já sabe, né? ;-)
Tenho ouvido um monte de letras ao longo dos anos. Às vezes siglas exatamente iguais significam coisas completamente diferentes!
A cada 2 ou 3 anos surge uma nova linguagem, um novo framework, uma nova metodologia, uma nova ferramenta... e por aí vai.
Por causa dessas mudanças todas, resolvi relacionar algumas coisas que todo desenvolvedor precisa saber.
A tecnologia conta, mas as pessoas é que colocam a tecnologia em ação.
1. Você é pago para dar lucro.
A despeito de suas preferências e independentemente de quão gente boa você é, você é pago para dar resultado palpável.
A empresa não vai ficar com você simplesmente pelo fato de você ser nerd pra caramba e estar por dentro da última release do kernel do linux, que tem uma nova opção de boot que acelera o processo em 0.50ms.
Acorda aí!
2. Você é pago para compartilhar conhecimento.
Pode parecer meio estranho para alguns, mas o conhecimento que você tem na sua cabeça não é só seu. Ou não deveria. É por isso que algumas empresas dizem que seus colaboradores formam seu capital intelectual.
Capital = dinheiro
Intelecto = conhecimento
Isso nos remete ao 1o item: você tem que dar lucro! Com seu conhecimento, viu?
Então, compartilhe.
Eu tenho um amigo que diz que quem esconde o jogo tem prisão de ventre cerebral.
Pior que ele tem razão! rsrs
3. A empresa tem necessidades que nem sempre são as suas.
Já reparou nisso?
- O dono da empresa quer que você dê ideias de como ganhar mais dinheiro.
Você diz que seria legal liberar geral o acesso à internet. - O dono da empresa diz que um cliente quer um projeto desenvolvido em Fortran.
Você diz que seria melhor converter o sistema existente lá para Java. - O dono da empresa diz que para trabalhar no cliente, você precisa ir de roupa social.
Você diz que o mundo tá todo errado e que o lance hoje é ir de boné e bermuda. - A empresa arranja clientes que querem um projeto mas não têm tanto dinheiro assim, por isso querem um sistema simplesinho.
Você diz que meia-boca você não faz de jeito nenhum!
a) aceite as necessidades da sua empresa.
b) encontre alguém que queira aceitar as suas necessidades.
4. Você é pago para aprender.
Esse é o emprego dos sonhos de todo mundo, né?
Nem sempre. Pense bem.
Quando você é pago para aprender sem prazo para terminar, é uma coisa.
Mas quando o projeto tem data marcada, cuidado!
Se você é especialista em PHP, mas tem que fazer alguma coisa em Ruby on Rails em 1 mês, os espinhos do mar de rosas comecam a aparecer e a arranhar, mesmo o mundo todo dizendo que o negócio é facinho pra caramba. Sim, fazer o aplicativo de blog que tem no tutorial é banal. O difícil é fazer o aplicativo que você precisa entregar.
Mas você é pago para aprender. Aprenda ou diga logo que não consegue.
Uma dica: aprenda a aprender!
5. Você é pago para (ou por) saber fazer e conhecer muita coisa.
Você é fera em Python? Bom.
Fera mesmo? Muito bom.
É um dos desenvolvedores da linguagem? Ótimo!
Mas não consegue dar uma palestra sobre isso? Que pena! :-(
A empresa precisa de pessoas multidisciplinares. Ou seja, aquele cara que bate o pênalti e corre p/ defender!
Se você é bom em programação mas nunca pensou em sair de frente do computador para dar uma palestra, reveja seus conceitos.
Se a timidez toma conta do seu ser a ponto de embrulhar seu estômago, suar suas mãos, tremer suas pernas, pense em fazer um curso de teatro. Isso sim é sair da zona de conforto!
6. Sua experiência de vida conta.
Não estou falando apenas sobre quantas linguagem e bancos de dados você conhece.
Estou falado sobre como você se virou pela primeira vez que sua mãe ou seu pai te mandou fazer o 1o pagamento sozinho no banco.
Estou falando sobre a 1a vez que você chamou uma garota p/ namorar e ela aceitou.
É disso que estou falando. Traga suas experiências para a empresa. Conte sua história! Ela vale muito.
Ei, esqueci de falar que um desenvolvedor precisa saber Java, C, Ruby, Python, SQL, HTML, CSS, PHP, Linux, Shell. Precisa saber o que significa ASP (linguagem), ASP (serviço), XML, RPC, DOM, DAO, Controller, MVC, Servlet, SCRUM, XP...
Bem, isso todo mundo já sabe, né? ;-)
Livro: Inovadores em ação
Ontem, passeando pela Livraria Leitura, encontrei uma promoção muito boa. Por R$ 9,90 comprei o livro Inovadores em Ação.
O livro conta histórias reais de 32 empresas que, de uma forma ou de outra, saíram do quadradinho, olharam para fora de suas paredes, desafiaram o mercado e deram novo fôlego à competição.
Ainda estou na metade do livro, mas fiquei encantado com a história Arkadi Kuhlmann, um banqueiro norte-americano que criou o ING Direct USA, um banco que tem como proposta não tirar dinheiro dos clientes. Aliás, esse banco não aceita clientes com muito dinheiro. Paradoxal, né? Pois é. Ele já é o 4o maior banco dos EUA!
A Procter & Gamble também tem um caso interessante. Ela pegou a idéia do desenvolvimento colaborativo de software e aplicou à linha de pesquisa de novos produtos. Totalmente surreal para quem não trabalha com software! Antes, faltavam ideias de projetos; hoje, eles precisam filtrar tudo que chega de ideia nova.
Outra história bem diferente é de uma mineradora de ouro que resolveu publicar os mapas de uma de suas minas auríferas, buscando encontrar projetos que pudessem ajudá-la a melhorar a extração naquele local. A princípio ela estaria literalmente "entregando o ouro pro bandido". Leia e veja o resultado!
Uma das coisas que o livro diz é que talvez seja mais importante ter pessoas trabalhando com você do que para você.
Bem, fica aí a dica. A leitura é realmente muito boa e inspiradora.
Se você é um inovador, por que ainda não leu? ;-)
Eu estou lendo e tendo algumas ideias doidonas! rsrs
O livro conta histórias reais de 32 empresas que, de uma forma ou de outra, saíram do quadradinho, olharam para fora de suas paredes, desafiaram o mercado e deram novo fôlego à competição.
Ainda estou na metade do livro, mas fiquei encantado com a história Arkadi Kuhlmann, um banqueiro norte-americano que criou o ING Direct USA, um banco que tem como proposta não tirar dinheiro dos clientes. Aliás, esse banco não aceita clientes com muito dinheiro. Paradoxal, né? Pois é. Ele já é o 4o maior banco dos EUA!
A Procter & Gamble também tem um caso interessante. Ela pegou a idéia do desenvolvimento colaborativo de software e aplicou à linha de pesquisa de novos produtos. Totalmente surreal para quem não trabalha com software! Antes, faltavam ideias de projetos; hoje, eles precisam filtrar tudo que chega de ideia nova.
Outra história bem diferente é de uma mineradora de ouro que resolveu publicar os mapas de uma de suas minas auríferas, buscando encontrar projetos que pudessem ajudá-la a melhorar a extração naquele local. A princípio ela estaria literalmente "entregando o ouro pro bandido". Leia e veja o resultado!
Uma das coisas que o livro diz é que talvez seja mais importante ter pessoas trabalhando com você do que para você.
Bem, fica aí a dica. A leitura é realmente muito boa e inspiradora.
Se você é um inovador, por que ainda não leu? ;-)
Eu estou lendo e tendo algumas ideias doidonas! rsrs
6 de junho de 2009
Se o Linux fosse o sistema operacional mais usado no mundo
Outro dia um colega de trabalho mandou um e-mail com o mesmo título desse post.
Daí eu resolvi colocá-lo aqui na íntegra, com algumas correções de português, para ficar melhor.
Normalmente vemos textos de usuários de Windows falando sobre como as coisas são no Linux. Esse, nos mostra as coisas de um outro ângulo.
Vale a pena a leitura.
Daí eu resolvi colocá-lo aqui na íntegra, com algumas correções de português, para ficar melhor.
Normalmente vemos textos de usuários de Windows falando sobre como as coisas são no Linux. Esse, nos mostra as coisas de um outro ângulo.
Vale a pena a leitura.
Eu compreendo os indivíduos que dizem ter problemas em passar do Windows para o Linux. Senti o mesmo ao experimentar o Windows. Eu decidi experimentá-lo depois de alguns amigos que o usam me dizerem que era ótimo.
Fui até ao site da Microsoft para baixá-lo mas não estava lá disponível. Fiquei frustrado porque não consegui descobrir como baixá-lo. Por fim tive que perguntar a um amigo e ele disse-me que eu deveria comprá-lo.
Peguei o carro, fui até à Staples e pedi a um dos vendedores uma cópia do Windows. Ele perguntou-me qual, eu disse-lhe: "Quero a mais completa, por favor" e ele respondeu: "São €599, ...". Soltei um palavrão e voltei para casa de mãos abanando.
Um dos meus amigos deu-me uma cópia do Windows XP mas disse-me para não contar a ninguém. Achei estranho porque faço sempre cópias do Linux para qualquer pessoa que me pedir, e digo sempre para passar essa cópia a qualquer outra pessoa que esteja interessada, uma vez que já precisei dela.
De qualquer forma coloquei o CD no leitor e esperei que iniciasse o sistema do "Live CD". Não funcionou. A única coisa que fazia era perguntar-me se queria instalar. Telefonei para um dos meus amigos, para saber se eu estava fazendo alguma asneira, mas ele disse-me: "O XP não roda o sistema diretamente do CD". Decidi, então, instalá-lo.
Segui as instruções que apareciam na tela mas comecei a ficar nervoso porque não perguntou nada sobre os outros sistemas operacionais. Quando instalei o Linux, ele reconheceu que tinha outros sistemas operacionais na máquina e perguntou-me se queria criar uma nova partição e instalar o Linux lá. Voltei a ligar para o meu amigo e ele disse-me que, ao ser instalado, o Windows elimina qualquer outro sistema operacional que encontra.
Fiz uma cópia de segurança das minhas coisas e entrei de cabeça na instalação. Foi bastante simples, tirando a parte em que tive que escrever umas letras e um código. Tive de ligar outra vez para o meu amigo mas ele ficou chateado e veio escrever ele próprio o código. Voltou a dizer-me para não contar nada a ninguém (!!!).
Depois de reiniciar o computador, dei uma passada de olhos no sistema. Fiquei chocado quando me deixou mudar as configurações sem pedir o acesso de root. O meu amigo começou a ficar um bocado irritado quando liguei outra vez para ele, mas acabou indo lá em casa. Disse-me que o acesso de root era dado logo na inicialização. Tratei logo de fazer outra conta de usuário normal e passei a usá-la.
Comecei a ficar confuso quando tentei fazer mudanças e o sistema, ao invés de pedir acesso de root, disse-me que tinha que fechar a sessão de utilizador normal e abrir uma sessão como administrador. Comecei, então, a perceber porque é que tantas pessoas entram sempre como root e tive um arrepio na espinha.
Bom, mas já era hora de trabalhar. Fui ao menu "Iniciar -> Programas", para abrir uma planilha que eu precisava terminar, mas não consegui encontrar a aplicação de planilhas. O meu amigo disse-me que o Windows não trazia nenhuma aplicação dessas e que eu teria que baixar da Internet. "Oh...", pensei, "uma distribuição básica".
Fui ao "Adicionar/Remover Programas" do painel de controle (tal como no Linux), mas não havia lá programas para adicionar. Apenas deixava remover os programas.
Não consegui encontrar o botão para adicionar aplicações. O meu amigo disse-me que eu tinha que procurar as aplicações por minha conta. Depois de muita pesquisa no Google, lá encontrei, baixei e instalei o OpenOffice.org.
Para dizer a verdade, diverti-me à beça com o Windows. Não entendi muito da terminologia... porque é que há um drive A, depois um C... onde é que está o drive B?
Achei a distribuição demasiado básica. Não inclui nenhuma aplicação que seja verdadeiramente de produtividade e é muito confuso procurá-la. O meu amigo disse-me que eu precisava de software anti-vírus e anti-spyware, mas o Windows não vinha com nada disso.
Achei-o difícil, confuso e demasiado trabalhoso para mim. Pode ser bom para uma pessoa que seja do tipo técnico, como o meu amigo, mas eu fico mesmo com o Linux, obrigado.
27 de maio de 2009
Linguagem ou framework?
Quem desenvolve para web, há algum tempo vive ouvindo falar de uma coisa chamada framework. Tem Struts (para java), Zend Framework (para PHP), Django (para Python), Ruby on Rails -- ou, simplesmente RoR -- (para Ruby), e por aí vai.
Entretanto você, que é desenvolvedor, vai programar na linguagem ou no framework?
Cada dia a resposta a essa pergunta fica mais difícil, pois os frameworkds que antes limitavam-se a ser um conjunto de funções para auxiliar o desenvolvedor a não realizar tarefas de "baixo nível", hoje cresceu para a geração de código completo e funcional.
Até bem pouco tempo atrás, um framework simplesmente provia serviços que abstraíam o protocolo http ou a camada de acesso a dados, ou a camada de comunicação, por exemplo.
Hoje esse cenário está muito (MUITO) diferente.
Com a popularização das linguagens de script (leia PHP, Python e Ruby, principalmente) os frameworks começaram a entregar novos serviços, tornando o desenvolvedor muito mais produtivo e aumentando o nível do que era considerado "de baixo nível".
O Django, por exemplo, com base em um modelo de banco de dados, entrega prontinho um conjunto de funcionalidades chamado ADMIN. Com o admin do Django é possível popular as tabelas do seu banco de dados sem programar quase nada. Ou seja, fazer CRUD virou tarefa de baixo nível.
O RoR também vigia seu modelo de dados, para que quando ele for alterado, as alterações sejam representadas no servidor de BD. Com isso, executar comandos de atualização de DDL também virou tarefa de baixo nível.
Há muito tempo os frameworks preocupam-se em abstrair o banco de dados utilizado, para que as aplicações possam ser portáveis entre vários servidores de BD. Isso é muito bom e preocupar-se com o BD já era, há muito tempo, tarefa de baixo nível. Agora, os frameworks foram além e implementaram um ORM completo, com sintaxe própria e extensível. No RoR é possível até chamar método que não existe e ele se vira para resolver o que você quer! Agora, programar em SQL também virou baixo nível.
Toda essa melhoria nos frameworks nos leva a uma situação inusitada. As pessoas querem aprender RoR sem aprender Ruby. Tem gente aprendendo Django sem aprender Python.
Essa situação aconteceu há alguns anos, quando ninguém queria aprender orientação a objetos, mas queria saber tudo de Java.
Parece estranho, mas é verdade.
Portanto, caro desenvolvedor, você vai programar tanto na linguagem quanto no framework. Lembre-se que sua aplicação vai passar a ser dependente de mais um componente externo. Já não basta a linguagem, o servidor de BD, as bibliotecas ou classes desenvolvidas por terceiros, agora também tem o framework.
É por isso que as pessoas dizem: "eu fiz o site em RoR" ou "eu desenvolvo em Django".
Mas nunca se esqueça que por trás do framework tem uma linguagem. E conhecê-la faz TODA a diferença na utilização dos recursos do framework.
Portanto, aprenda o framework e também a linguagem. Esse é o casamento perfeito.
Entretanto você, que é desenvolvedor, vai programar na linguagem ou no framework?
Cada dia a resposta a essa pergunta fica mais difícil, pois os frameworkds que antes limitavam-se a ser um conjunto de funções para auxiliar o desenvolvedor a não realizar tarefas de "baixo nível", hoje cresceu para a geração de código completo e funcional.
Até bem pouco tempo atrás, um framework simplesmente provia serviços que abstraíam o protocolo http ou a camada de acesso a dados, ou a camada de comunicação, por exemplo.
Hoje esse cenário está muito (MUITO) diferente.
Com a popularização das linguagens de script (leia PHP, Python e Ruby, principalmente) os frameworks começaram a entregar novos serviços, tornando o desenvolvedor muito mais produtivo e aumentando o nível do que era considerado "de baixo nível".
O Django, por exemplo, com base em um modelo de banco de dados, entrega prontinho um conjunto de funcionalidades chamado ADMIN. Com o admin do Django é possível popular as tabelas do seu banco de dados sem programar quase nada. Ou seja, fazer CRUD virou tarefa de baixo nível.
O RoR também vigia seu modelo de dados, para que quando ele for alterado, as alterações sejam representadas no servidor de BD. Com isso, executar comandos de atualização de DDL também virou tarefa de baixo nível.
Há muito tempo os frameworks preocupam-se em abstrair o banco de dados utilizado, para que as aplicações possam ser portáveis entre vários servidores de BD. Isso é muito bom e preocupar-se com o BD já era, há muito tempo, tarefa de baixo nível. Agora, os frameworks foram além e implementaram um ORM completo, com sintaxe própria e extensível. No RoR é possível até chamar método que não existe e ele se vira para resolver o que você quer! Agora, programar em SQL também virou baixo nível.
Toda essa melhoria nos frameworks nos leva a uma situação inusitada. As pessoas querem aprender RoR sem aprender Ruby. Tem gente aprendendo Django sem aprender Python.
Essa situação aconteceu há alguns anos, quando ninguém queria aprender orientação a objetos, mas queria saber tudo de Java.
Parece estranho, mas é verdade.
Portanto, caro desenvolvedor, você vai programar tanto na linguagem quanto no framework. Lembre-se que sua aplicação vai passar a ser dependente de mais um componente externo. Já não basta a linguagem, o servidor de BD, as bibliotecas ou classes desenvolvidas por terceiros, agora também tem o framework.
É por isso que as pessoas dizem: "eu fiz o site em RoR" ou "eu desenvolvo em Django".
Mas nunca se esqueça que por trás do framework tem uma linguagem. E conhecê-la faz TODA a diferença na utilização dos recursos do framework.
Portanto, aprenda o framework e também a linguagem. Esse é o casamento perfeito.
5 de maio de 2009
Como escolher meu editor de programas
Para quem desenvolve aplicativos é muito importante a escolha de um bom editor de programas. Você já se deu conta de que pode estar usando um que não seja a melhor opção para você?
Já percebeu que para escolher a linguagem de programação que vamos trabalhar, pensamos se ela é bem aceita no mercado, se tem suporte do fabricante ou da comunidade, se é muito nova, quem usa, e coisas assim que acabam influenciando e dando a segurança (ou a impressão) de ser uma boa escolha?
E para escolher seu editor de programas? Que critérios você usou?
Eu concordo com o Andy Hunt quando ele diz no livro The Pragmatic Programmer, que um bom programador deve dominar (DO-MI-NAR) sua principal ferramenta de trabalho, que é o editor de programas.
Afinal, você vai passar a maior parte dos seus dias trabalhando nele, certo? Demora dominar um bom editor. E não é nada agradável trocá-lo por outro. Você já está acostumado com os recursos do anterior. Já sabe os atalhos de teclado de cabeça. Já tem até alguns scripts que resolvem seus problemas sem muito esforço.
Bem, talvez você realmente não saiba os atalhos de teclado nem tenha escrito scripts para automatizar tarefas. Talvez você nem saiba que seu editor tem esses recursos. Se esse é o seu caso, sinceramente, eu sugiro que você comece a pensar na quantidade de trabalho repetido que tem feito no seu dia-a-dia! E como diz o velho ditado, que tempo é dinheiro, se você está perdendo tempo...
Um editor é uma ferramenta de trabalho. Aliás, ele pode ser melhor que isso. Ele pode trabalhar para você!
Um dia, motivado por uma mudança, comecei a procurar o editor de programas definitivo para mim e resolvi relacionar alguns recursos que achei serem necessários.
Você já passou por esse momento?
Seguem abaixo algumas características que um bom editor de programas deve ter, na minha opinião:
- Navegação eficiente no código (mais do que as setas)
- Marcadores (ou bookmarks, como queiram)
- Undo de muitas operações
- Comandos de teclado para todas (eu disse todas?) as suas operações
- Auto-complete
- Auto-correção (sim, nós programadores também erramos)
- Syntax Highlighting
- Gravação de macros (é, você faz algumas coisas várias vezes e da mesma forma)
- Uma linguagem de script (faça seu editor trabalhar para você!)
- Comandos de localizar e substituir realmente poderosos (vá além do óbvio. Experimente as expressões regulares!)
- Folding de código (ok, nem todo mundo gosta disso)
- Responder rápido (isso todo programador quer, né?)
- Vários buffers de copy-and-paste (muito, muito útil)
- Várias janelas abertas ao mesmo tempo
- Auto-identação de acordo com a linguagem
- Integração com shell (prompt do DOS) e compiladores
- Capacidade de repetir comandos
- Personalizar de teclas de atalho
- Extensível com plugins
Depois, achei um bem poderoso, chamado Ultraedit.
Mais tarde, comecei a usar o Context, mas ele não era o que eu esperava. Nem de longe.
O PSPAD passou a ser meu editor oficial por alguns anos. Esse é bom, mas ainda não era o que eu precisava.
Analisei o emacs, mas não me adaptei a ele, apesar de ser muito poderoso.
Finalmente re-encontrei o Vim e resolvi ficar com ele.
Ele é um editor diferentão. É modal, meio feioso, old-fashioned, e demora para aprender a usá-lo. Mas como não pretendo mudar de editor, mesmo mudando de sistema operacional, não vejo problema nisso. É um investimento a longo prazo.
Ele está no mercado há um tempão, tem sempre melhorado e já vem com todas distribuições Linux. Ou seja, é um projeto ativo.
E funciona! No Windows, no Linux e no Mac-OS.
Ele é altamente configurável e tem todas as características que citei acima.
Não, ele não é perfeito. Nenhum é. Nem digo que o vim é o melhor editor de programas. Mas ele é bom e me adaptei a ele numa boa.
E você? Usa bem os recursos do seu editor de programas? Ou usa vários editores para conseguir realizar suas tarefas?
Use a ferramenta certa.
4 de maio de 2009
Use o teclado
Todo mundo que o computador usa o teclado, certo?
Mas será que usa como poderia?
Eu sou programador, tradutor e escrevo alguns artigos de vez em quando. Vivo escrevendo e-mails. Para mim é muito importante conseguir digitar usando os 10 dedos e com velocidade.
Minhas idéias são expressas através de minhas mãos no teclado. Quando escrevo um programa ou um artigo como esse, estou materializando minhas idéias. Portanto, se meus dedos forem muito mais lentos do que meu racioncínio, não dá certo.
Por isso, tenho um hábito visto como esquisitisse por muitos de meus colegas: procurar os atalhos de teclado dos softwares que uso.
E tenho outro também: não gosto do mouse!
Outro dia eu descobri um software para Windows chamado Keybreeze que permite você chamar qualquer programa usando o teclado. Gostei muito dele.
Atualização em 28/09/2009: no Linux (Ubuntu) eu uso o Gnome Do.
Se você tem dificuldade de digitar sem olhar para o teclado, procure um tutorial de digitação na internet. É um esforço compensador.
Fica aí a dica: se você quer ser mais produtivo, não tire as mãos do teclado!
3 de maio de 2009
O editor onipresente
Eu sou desenvolvedor de aplicativos. Por isso, um dia percebi que precisava buscar outra plataforma de trabalho, além do Windows.
Eu mexi um pouco com Unix em 1997 e não havia interface gráfica nos sistemas que eu conheci: HP-UX e IBM S/6000. Hoje, se eu tivesse que re-aprender tudo, o tempo para adotar o novo sistema seria muito grande. E eu não queria me tornar um especialista em Linux.
No meu caso a escolha natural foi o Ubuntu, pela popularidade. No entanto há outros sabores de Linux, como Fedora, Debian, Red Hat, etc. e eu não queria ficar de fora deles. Ubuntu seria apenas uma porta de entrada.
A ferramenta que um programador mais usa é o editor de programas, certo? No Windows eu usei o PSPAD por vários anos e estava muito satisfeito com ele. Mas ele não existe para outros sistemas operacionais. Sim, eu poderia usá-lo com o Wine, mas eu não queria isso.
Resultado: eu teria que aprender um novo editor. Com novos atalhos de teclado, novas opções de menu e novos recursos. Alguns faltantes e outros novos.
Como eu já era bem produtivo com o PSPAD, isso me assustou mesmo! Então resolvi procurar um editor poderoso que funcionasse bem em todos os ambientes, sem que eu precisasse reaprender tudo quando mudasse de ambiente. Seria possível, isso?
Pesquisei bastante e me deparei com duas opções que quase ninguém mais fala e eu pensei nem existirem no mundo onipresente das interfaces gráficas: vim e emacs.
A discussão entre os usuários desses editores é quase religiosa! Parece com as discussões entre torcedores de times de futebol ou entre usuários de Linux, Mac-OS e Windows.
Eu usei um pouco o emacs mas, pessoalmente, não me adaptei a ele. Achei esquisito ter que manter a tecla CTRL pressionada para eu me movimentar pelo programa.
Daí parti para experimentar o vim. Foi impressionante quando eu me deparei usando intuitivamente alguns comandos que eu uso no Gmail e no Firefox!
Quer exemplos?
No Gmail existem os atalhos de teclado "j" e "k" para navegar entre as mensagens e o "/" para pesquisar mensagens. Alguns atalhos iniciam com "g".
No Firefox você pode usar também o "/" para pesquisar na página corrente. Adivinha de onde eles pegaram esse comando? Do vim!
Daí pesquisei um pouco mais e descobri que o vim já vem junto com todas as instalações de Linux e roda até no PS3. E que ele usa muito menos recursos do que o emacs. Além disso, ele também tem uma linguagem de script e grava macros!
Do quê mais eu precisava? Apenas de re-aprender a usá-lo corretamente. Eu poderia usá-lo no Windows em modo gráfico, modo texto, em qualquer Linux e também no Mac-OS!
Dizem que usar o vim é como morar em Brasília: ou você ama, ou abandona. Eu, gostei tanto do editor como da cidade.
Sim, eu uso vim. Gosto da linha de comandos e acho que é possível ser produtivo com ela, sem usar o mouse.
O vim é bom. O emacs também. Não estou dizendo que o vim é melhor do que o emacs. Os dois são poderosíssimos, mas a curva de aprendizado em qualquer um deles é grande. Qual usar é apenas uma questão pessoal.
Sua produtividade está diretamente relacionada ao editor que você usa para escrever seus programas. Pense nisso!
30 de abril de 2009
30 Dicas para escrever bem
Se você gosta de escrever, é sempre bom lembrar de algumas dicas.
Fonte: www.senado.gov.br/sf/senado/portaldoservidor/jornal/jornal64/dicas_escreverbem.aspx
1. Deve evitar ao máx. a utiliz. de abrev., etc.
2. É desnecessário fazer-se empregar de um estilo de escrita demasiadamente rebuscado. Tal prática advém de esmero excessivo que raia o exibicionismo narcisístico.
3. Anule aliterações altamente abusivas.
4. não esqueça as maiúsculas no inicio das frases.
5. Evite lugares-comuns como o diabo foge da cruz.
6. O uso de parêntesis (mesmo quando for relevante) é desnecessário.
7. Estrangeirismos estão out; palavras de origem portuguesa estão in.
8. Evite o emprego de gíria, mesmo que pareça nice, sacou??...então valeu!
9. Palavras de baixo calão podem transformar o seu texto numa m...
10. Nunca generalize: generalizar é um erro em todas as situações.
11. Evite repetir a mesma palavra pois essa palavra vai ficar uma palavra repetitiva. A repetição da palavra vai fazer com que a palavra repetida desqualifique o texto onde a palavra se encontra repetida.
12. Não abuse das citações. Como costuma dizer um amigo meu: "Quem cita os outros não tem ideias próprias".
13. Frases incompletas podem causar
14. Não seja redundante, não é preciso dizer a mesma coisa de formas diferentes; isto é, basta mencionar cada argumento uma só vez, ou por outras palavras, não repita a mesma idéia várias vezes.
15. Seja mais ou menos específico.
16. Frases com apenas uma palavra? Jamais!
17. A voz passiva deve ser evitada.
18. Utilize a pontuação corretamente o ponto e a vírgula pois a frase poderá ficar sem sentido especialmente será que ninguém mais sabe utilizar o ponto de interrogação
19. Quem precisa de perguntas retóricas?
20. Conforme recomenda a A.G.O.P, nunca use siglas desconhecidas.
21. Exagerar é cem milhões de vezes pior do que a moderação.
22. Evite mesóclises. Repita comigo: "mesóclises: evitá-las-ei!"
23. Analogias na escrita são tão úteis quanto chifres numa galinha.
24. Não abuse das exclamações! Nunca!!! O seu texto fica horrível!!!!!
25. Evite frases exageradamente longas pois estas dificultam a compreensão da idéia nelas contida e, por conterem mais que uma idéia central, o que nem sempre torna o seu conteúdo acessível, forçam, desta forma, o pobre leitor a separá-la nos seus diversos componentes de forma a torná-las compreensíveis, o que não deveria ser, afinal de contas, parte do processo da leitura, hábito que devemos estimular através do uso de frases mais curtas.
26. Cuidado com a hortografia, para não estrupar a língúa portuguêza.
27. Seja incisivo e coerente, ou não.
28. Não fique escrevendo (nem falando) no gerúndio. Você vai estar deixando seu texto pobre e estar causando ambigüidade, com certeza você vai estar deixando o conteúdo esquisito, vai estar ficando com a sensação de que as coisas ainda estão acontecendo. E como você vai estar lendo este texto, tenho certeza que você vai estar prestando atenção e vai estar repassando aos seus amigos, que vão estar entendendo e vão estar pensando em não estar falando desta maneira irritante.
29. Outra barbaridade que tu deves evitar chê, é usar muitas expressões que acabem por denunciar a região onde tu moras! ..nada de mandar esse trem...vixi..entendeu bichinho?
30. Não permita que seu texto acabe por rimar, porque senão ninguém irá aguentar já que é insuportável o mesmo final escutar, o tempo todo sem parar.
Assinar:
Postagens (Atom)
