Como eu sempre gosto de ensinar alguma coisa às minhas leitoras, aqui vão algumas das minhas simpatias para que meu 2010 seja um sucesso. Infelizmente é um pouco tarde para colocá-las em prática, mas pelo menos pode servir de inspiração para 2011.
Para ter dinheiro: minha simpatia para ter dinheiro em 2010 foi trabalhar bastante durante o ano, cumprindo minhas metas e tratando bem meus companheiros de trabalho. Desta forma, continuo sendo considerado útil na empresa onde trabalho e o emprego fica garantido. Em consequência, dinheiro durante todo o ano de 2010.
Para ter amor: tratei bem a minha esposa. Fiz surpresas e dei presentes, ouvi e dei colo, passeei e agradei. Enfim, mostrei que a amo. Desta forma, ela continua me amando e tenho certeza de que terei um ano feliz ao seu lado.
Para ter saúde: evitei comer todo o tipo de besteira durante o ano. Claro que não foi fácil e muitas vezes eu caí em tentação, comendo uma merdinha aqui e outra ali, mas no geral eu melhorei bastante minha alimentação. Ah, claro, eu fui algumas vezes ao médico, aumentando a média de visitas. Desta forma, garanti que o corpitcho está preparado para encarar mais um ano.
Para ter paz: não destratei ninguém; convivi bem com família, vizinhos e amigos; não tenho dívidas e não pedi dinheiro emprestado; ajudei quando podia e ouvi quem queria falar; não cultivei inimizades; não me meti em confusão; prestei culto ao Senhor e li Sua palavra. Com tudo isso, é certo que os que estão ao meu redor não me trarão problemas, logo a paz é certa.
E vocês, queridas leitoras? Quais são as suas simpatias?
Visão do Local de Trabalho III
Esquina da Primeiro de Março com a Presidente Vargas.
É a visão que temos da sala onde trabalho.
É a visão que temos da sala onde trabalho.
Meu Pedido para Papai Noel
Eu gostaria de pedir a Papai Noel apenas uma coisa: que as pessoas que se dizem cristãs passassem a celebrar o Natal como o momento do nascimento de Jesus, nosso salvador, agradecendo e dando graças pela benção da salvação, e não usando-o como uma mera desculpa para gastar dinheiro com presentes.
Feliz Natal a todas as minhas leitoras.
Feliz Natal a todas as minhas leitoras.
O Universo Conhecido
Animação fabulosa que mostra o universo conhecido. Magnificamente lindo. E dá o que pensar: como somos PEQUENOS! E você aí se preocupando com mesquinharias. Dica do C@T.
Ah, sim, uma pergunta: o que há depois do universo conhecido?
Ah, sim, uma pergunta: o que há depois do universo conhecido?
Orquestra Sinfônica Brasileira
Sexta-feira passada, dia 18, fomos à Sala Cecília Meireles, na Lapa, para assistir à última aprensentação do ano da Orquestra Sinfônica Brasileira. Era uma apresentação que eu estava ansioso para ver desde o início do ano, quando comprei os ingressos, porque seria uma noite em homenagem a John Williams. Lá iríamos nós ouvir os temas de ET, Parque dos Dinossauros, Harry Potter, A Lista de Schindler, Indiana Jones e Guerra nas Estrelas.
Eu SABIA que ia ser bom desde o princípio, e quando a última obra da noite - Guerra nas Estrelas - terminou, eu SABIA que tínhamos assistido a uma apresentação memorável e inesquecível, mas nada poderia nos preparar para o que veio em seguida.
Depois que o maestro saiu e todos estávamos aplaudindo, as luzes diminuíram, ligaram uns estrobos no teto e pudemos ouvir uma voz nos chamando:
- Venham para o lado negro da força.
Eis que Darth Vader em pessoa, surgido do meio da platéia, invade o palco e rege o bis - seu tema - usando um sabre de luz, para o delírio da galera. Ao fim, o maestro Roberto Minczuk volta ao palco vestindo uma camisa do Super-Homem e, também com um sabre de luz, luta contra Darth Vader. Com o vilão derrotado e a platéia em polvorosa, o maestro rege então o último bis: o tema do Super-Homem.
Por fim, o maestro se despediu:
- Boa noite, feliz Natal, feliz ano novo, e que a força esteja com vocês!
Parabéns e obrigado à OSB por esta noite inesquecível e magnífica, que fechou dois mil e nove com chave de ouro.
Segue aí o vídeo do fim da apresentação:
Eu SABIA que ia ser bom desde o princípio, e quando a última obra da noite - Guerra nas Estrelas - terminou, eu SABIA que tínhamos assistido a uma apresentação memorável e inesquecível, mas nada poderia nos preparar para o que veio em seguida.
Depois que o maestro saiu e todos estávamos aplaudindo, as luzes diminuíram, ligaram uns estrobos no teto e pudemos ouvir uma voz nos chamando:
- Venham para o lado negro da força.
Eis que Darth Vader em pessoa, surgido do meio da platéia, invade o palco e rege o bis - seu tema - usando um sabre de luz, para o delírio da galera. Ao fim, o maestro Roberto Minczuk volta ao palco vestindo uma camisa do Super-Homem e, também com um sabre de luz, luta contra Darth Vader. Com o vilão derrotado e a platéia em polvorosa, o maestro rege então o último bis: o tema do Super-Homem.
Por fim, o maestro se despediu:
- Boa noite, feliz Natal, feliz ano novo, e que a força esteja com vocês!
Parabéns e obrigado à OSB por esta noite inesquecível e magnífica, que fechou dois mil e nove com chave de ouro.
Segue aí o vídeo do fim da apresentação:
O que é software de qualidade?
Quando vamos iniciar um projeto de um software, seja ele um pequeno sistema de monitoramento remoto ou um grande sistema para operação no mercado financeiro, é importante termos a consciência de que devemos construí-lo com qualidade.
Mas o que é, exatamente, um software de qualidade? O que pode ser usado para medir a qualidade de um software? Beleza? Simplicidade? Quantidade de que merda! exclamados pelos usuários?
Acredito que há quatro fatores fundamentais para que um software possa ser considerado como de qualidade. Em primeiro lugar, sua corretude: o software deve fazer aquilo que o levou a ser feito, ou seja, deve atender às necessidades dos usuários.
Em segundo lugar está sua velocidade: de nada adianta fazer um sistema que faça o que o usuário espera dele, mas leve tanto tempo para isso que o usuário tenha tempo de ir à máquina de café.
Em terceiro lugar vem a facilidade de uso: a palavra está um pouco banalizada atualmente, mas a usabilidade de um sistema é um fator chave para o seu sucesso.
Por fim, sua facilidade de manutenção: este é um dos requisitos com o qual o usuário se importa pouco ou nada, mas que garante a sobrevida do produto, já que todos nós somos péssimos programadores e, uma hora ou outra, vamos precisar acrescentar a ele novas funções ou corrigir antigas.
Como garantir, então, que o software com o qual você está trabalhando tenha estas quatro características?
***
Corretude
Garantir que o sistema faça o que o usuário espera dele requer duas atitudes primordiais: entender e testar.
Entender significa que você deve realmente saber o que deve ser feito, quais são as expectativas do usuário. Aqui não há espaço para achismos. Por experiência própria, eu te garanto: na maioria das vezes em que você tenta adivinha o que o cliente quer, você quebra a cara, e feio.
Nada impede que você sugira idéias. Elas são bem vindas sempre. O que não dá pra fazer é simplesmente supor.
Já testar significa exatamente isto: testar se o que você fez funciona como era esperado. E, além disso, é preciso testar se o que você fez não quebrou alguma coisa que já estava funcionando antes. Eu tenho criado o saudável hábito de escrever uma série de verdade absolutas sobre as coisas que faço, e a cada alteração nos sistemas eu verifico se as verdades ainda estão valendo. Se não estiverem, alguma besteira eu fiz. Sim, eu sei que dá trabalho, mas lembre-se do que diz a regra nove do Padrão Marinato de Qualidade: os testes devem durar duas vezes e meia o tempo de programação.
***
Velocidade
Tem muita gente por aí que, pra tirar o próprio rabo da reta, sugere a compra de mais memória quando o cliente reclama da velocidade do sistema.
Sim, eu sei que há casos em que a culpa é realmente do cliente, que tenta enfiar o mais novo sistema operacional em uma máquina de oito anos atrás, mas é preciso lembrar, também, que todos somos programadores fracos, e é bem provável que você tenha feito alguma besteira, ou que tenha deixado de fazer algo a mais.
Não estou falando de fazer tuning no seu sistema, o que nem sempre é uma boa ideia, mas apenas de prestar atenção nos seus laços e repetições, nas configurações do compilador e no uso de threads, se sua linguagem de programação permitir isso.
Encarei esse problema recentemente no projeto em que estou trabalhando: nele, sempre que uma determinada janela é fechada nós gravamos um arquivo com os dados que estavam sendo exibidos. Este recurso já está pronto há meses, até que um cliente reclamou de um engasgo no sistema sempre que fechava a tal janela.
Fomos verificar e descobrimos que tínhamos feito a besteira de gravar os dados em etapas, abrindo e fechando o arquivo milhares de vezes ao invés de fazer a operação toda em uma pancada só.
***
Facilidade de Uso
De pouco adianta um sistema que faça mil e uma coisas se o usuário se sente como um cego perdido em meio a um tiroteio, diante de todos botões e menus, sendo obrigado a frequentar um curso intensivo de dois meses para usá-lo.
Para se construir um software fácil de usar é preciso estar sempre em contato com o usuário, obtendo seu feedback incessantemente.
E, embora possa parecer frescura, o trabalho de um designer competente é muito importante, já que animal mais raro que programador bom em design só mesmo advogado que não seja venenoso.
***
Manutenibilidade
Qualidade essencial porém invisível para o cliente, a facilidade de se dar manutenção em um sistema é essencial para que ele possa ter vida longa de uso.
Lembre-se que, assim como acontece nos livros de cartório, o que você escreve hoje será lido daqui a seis meses, um ano, dois anos, por você e, com certeza, por muitas outras pessoas, algumas das quais, é certo, não terão você por perto. Ou você não pensa em tirar férias?
Logo, é preciso sempre ter em mente a Grande Lei do Desenvolvimento: escreverás código que humanos sejam capazes de entender. E não apenas isso: adote padrões de projeto que estruturem o seu sistema de maneira que as pessoas, entendendo o padrão, possam saber onde estão pisando.
E, veja bem, querida leitora, quando falo em padrões de projeto, não estou falando só dos Padrões de Projeto que nos ensinam na faculdade, mas também em produzir código padronizado e consistente, com convenções bem estabelecidas e conhecidos por todos.
Estas recomendações culminam, por fim, em um ponto importante: documentação. É preciso registrar o raciocínio por trás de todas aquelas linhas de código. Entender porque determinadas decisões de projeto foram tomadas (ou não) é parte essencial do trabalho de mudar algo que já está pronto.
***
Aí estão, então, os quatro principais pontos com os quais me preocupo quando estou trabalhando na construção de um sistema.
É claro que volta e meia eu escorrego e deixo de seguir uma ou outra de minhas próprias recomendações, mas isso também faz parte do aprendizado.
***
Artigo inspirado por um outro, de Steve Feuerstein, da Oracle Magazine, escrito ao som das músicas religiosas de Elvis Presley.
***
Outros artigos meus sobre análise de sistemas
Mas o que é, exatamente, um software de qualidade? O que pode ser usado para medir a qualidade de um software? Beleza? Simplicidade? Quantidade de que merda! exclamados pelos usuários?
Acredito que há quatro fatores fundamentais para que um software possa ser considerado como de qualidade. Em primeiro lugar, sua corretude: o software deve fazer aquilo que o levou a ser feito, ou seja, deve atender às necessidades dos usuários.
Em segundo lugar está sua velocidade: de nada adianta fazer um sistema que faça o que o usuário espera dele, mas leve tanto tempo para isso que o usuário tenha tempo de ir à máquina de café.
Em terceiro lugar vem a facilidade de uso: a palavra está um pouco banalizada atualmente, mas a usabilidade de um sistema é um fator chave para o seu sucesso.
Por fim, sua facilidade de manutenção: este é um dos requisitos com o qual o usuário se importa pouco ou nada, mas que garante a sobrevida do produto, já que todos nós somos péssimos programadores e, uma hora ou outra, vamos precisar acrescentar a ele novas funções ou corrigir antigas.
Como garantir, então, que o software com o qual você está trabalhando tenha estas quatro características?
Corretude
Garantir que o sistema faça o que o usuário espera dele requer duas atitudes primordiais: entender e testar.
Entender significa que você deve realmente saber o que deve ser feito, quais são as expectativas do usuário. Aqui não há espaço para achismos. Por experiência própria, eu te garanto: na maioria das vezes em que você tenta adivinha o que o cliente quer, você quebra a cara, e feio.
Nada impede que você sugira idéias. Elas são bem vindas sempre. O que não dá pra fazer é simplesmente supor.
Já testar significa exatamente isto: testar se o que você fez funciona como era esperado. E, além disso, é preciso testar se o que você fez não quebrou alguma coisa que já estava funcionando antes. Eu tenho criado o saudável hábito de escrever uma série de verdade absolutas sobre as coisas que faço, e a cada alteração nos sistemas eu verifico se as verdades ainda estão valendo. Se não estiverem, alguma besteira eu fiz. Sim, eu sei que dá trabalho, mas lembre-se do que diz a regra nove do Padrão Marinato de Qualidade: os testes devem durar duas vezes e meia o tempo de programação.
***
Velocidade
Tem muita gente por aí que, pra tirar o próprio rabo da reta, sugere a compra de mais memória quando o cliente reclama da velocidade do sistema.
Sim, eu sei que há casos em que a culpa é realmente do cliente, que tenta enfiar o mais novo sistema operacional em uma máquina de oito anos atrás, mas é preciso lembrar, também, que todos somos programadores fracos, e é bem provável que você tenha feito alguma besteira, ou que tenha deixado de fazer algo a mais.
Não estou falando de fazer tuning no seu sistema, o que nem sempre é uma boa ideia, mas apenas de prestar atenção nos seus laços e repetições, nas configurações do compilador e no uso de threads, se sua linguagem de programação permitir isso.
Encarei esse problema recentemente no projeto em que estou trabalhando: nele, sempre que uma determinada janela é fechada nós gravamos um arquivo com os dados que estavam sendo exibidos. Este recurso já está pronto há meses, até que um cliente reclamou de um engasgo no sistema sempre que fechava a tal janela.
Fomos verificar e descobrimos que tínhamos feito a besteira de gravar os dados em etapas, abrindo e fechando o arquivo milhares de vezes ao invés de fazer a operação toda em uma pancada só.
***
Facilidade de Uso
De pouco adianta um sistema que faça mil e uma coisas se o usuário se sente como um cego perdido em meio a um tiroteio, diante de todos botões e menus, sendo obrigado a frequentar um curso intensivo de dois meses para usá-lo.
Para se construir um software fácil de usar é preciso estar sempre em contato com o usuário, obtendo seu feedback incessantemente.
E, embora possa parecer frescura, o trabalho de um designer competente é muito importante, já que animal mais raro que programador bom em design só mesmo advogado que não seja venenoso.
***
Manutenibilidade
Qualidade essencial porém invisível para o cliente, a facilidade de se dar manutenção em um sistema é essencial para que ele possa ter vida longa de uso.
Lembre-se que, assim como acontece nos livros de cartório, o que você escreve hoje será lido daqui a seis meses, um ano, dois anos, por você e, com certeza, por muitas outras pessoas, algumas das quais, é certo, não terão você por perto. Ou você não pensa em tirar férias?
Logo, é preciso sempre ter em mente a Grande Lei do Desenvolvimento: escreverás código que humanos sejam capazes de entender. E não apenas isso: adote padrões de projeto que estruturem o seu sistema de maneira que as pessoas, entendendo o padrão, possam saber onde estão pisando.
E, veja bem, querida leitora, quando falo em padrões de projeto, não estou falando só dos Padrões de Projeto que nos ensinam na faculdade, mas também em produzir código padronizado e consistente, com convenções bem estabelecidas e conhecidos por todos.
Estas recomendações culminam, por fim, em um ponto importante: documentação. É preciso registrar o raciocínio por trás de todas aquelas linhas de código. Entender porque determinadas decisões de projeto foram tomadas (ou não) é parte essencial do trabalho de mudar algo que já está pronto.
***
Aí estão, então, os quatro principais pontos com os quais me preocupo quando estou trabalhando na construção de um sistema.
É claro que volta e meia eu escorrego e deixo de seguir uma ou outra de minhas próprias recomendações, mas isso também faz parte do aprendizado.
Artigo inspirado por um outro, de Steve Feuerstein, da Oracle Magazine, escrito ao som das músicas religiosas de Elvis Presley.
Outros artigos meus sobre análise de sistemas
Tô Vendendo
Estou vendendo um monitor Samsung CRT 19 polegadas, tela plana, modelo 997MB usado mas em perfeito estado, funcionando 100%, por apenas R$ 50,00.
É um excelente monitor com uma qualidade de imagem excelente, que já me acompanha há quase quatro anos.
Quero me desfazer dele porque ele é muito pesado e estava envergando a minha mesa vagabunda, daí comprei um monitor LCD, bem mais leve.
Ele está em Niterói mas posso levá-lo para Cachoeiras de Macacu se for o caso. Alguma leitora tá afim?
Quem pagar R$ 60,00 ainda leva de brinde uma edição do meu livro Trabalho em Cartório Mas Sou Escritor.
É um excelente monitor com uma qualidade de imagem excelente, que já me acompanha há quase quatro anos.
Quero me desfazer dele porque ele é muito pesado e estava envergando a minha mesa vagabunda, daí comprei um monitor LCD, bem mais leve.
Ele está em Niterói mas posso levá-lo para Cachoeiras de Macacu se for o caso. Alguma leitora tá afim?
Quem pagar R$ 60,00 ainda leva de brinde uma edição do meu livro Trabalho em Cartório Mas Sou Escritor.
Anúncios Que Não Veremos Por Aí
Em Dezembro, conheça a nova coelhinha da Playboy: Ana Paula Valadão.
É de fazer o capeta se regenerar!
É de fazer o capeta se regenerar!
Visão do Local de Trabalho II
Ilha das Cobras, Ponte Rio-Niterói, Baía da Guanabara e, ao longe, a serra de Cachoeiras de Macacu.
É isso que vejo da sala onde trabalho.
É isso que vejo da sala onde trabalho.
Momento de Racismo
Tenho nojo de um colega de trabalho. Ele pode até ser um cara divertido, mas seu racismo o faz perder todo o valor. Frase sua recente:
Eu nunca comi uma preta. Não é nem por questão de higiene, não. É porque...
No fim da frase eu já não estava mais prestando atenção.
Eu nunca comi uma preta. Não é nem por questão de higiene, não. É porque...
No fim da frase eu já não estava mais prestando atenção.
Minha Biblioteca Técnica - Parte II
Segue aí a segunda parte da lista de livros que tenho na minha biblioteca técnica. A primeira parte pode ser lida aqui.
***
Padrões de Acesso a Dados: Na esteira da temática dos padrões, este livro, como o nome já denuncia, cataloga uma série de soluções comuns para lidar com o acesso a dados, indo desde a criação de um ponto único para geração de instruções SQL até estratégias de cache de dados. É uma excelente fonte de informação, evitando que os programas se tornem uma intrincada macarronada onde tarefas de negócio e de persistência se misturam indiscriminadamente. Não tem edição em português.
Programação Extrema Explicada: Na minha faculdade eu quase cheguei a estudar sobre a metodologia XP, mas infelizmente, por troca de professor, acabamos estudando ASP. Por isso, comprei o livro para entender melhor como funciona esta metodologia de desenvolvimento. Apesar de bem interessante, ele não me foi muito útil naquela época porque eu não trabalhava numa equipe, daí muitos conselhos eu não pude aproveitar. Hoje, como faço parte de uma equipe, tenho certeza de que uma relida nele renderá bons frutos.
Redes de Computadores: Na época em que eu estava fazendo várias provas para concursos, vi que precisava entender bem mais sobre redes e este me foi apontado como o livro essencial sobre o tema. E é realmente excelente, cobrindo do hardware mais básico ao software mais avançado. Eu escrevia os artigos para o Vovó Viu a Rede com base no que aprendia com este livro. Infelizmente, com minha troca de emprego, cidade e estado civil, tive que interromper a sua leitura, mas com certeza irei retomá-la em breve.
Design com Multi-Paradigmas em C++: Por enquanto, é o único livro da minha biblioteca voltado para uma linguagem específica. Nele, o autor defende a tese de que programar em C++ utilizando apenas o paradigma de orientação a objetos é desperdiçar todo o poder de fogo da linguagem, algo como comprar um computador só para ouvir música. Ele sugere utilizar, ao mesmo tempo, em um mesmo sistema, vários recursos que vão além da orientação a objetos, como os templates e funções sobrecarregadas, apresentando técnicas de modelagem que indicam a melhor técnica de desenvolvimento e implementação dessas soluções. Já o li uma vez e achei bem difícil de entender, tanto por sua linguagem acadêmica demais, tanto por usar recursos de C++ que eu não faço a mínima idéia do que sejam. Não tem edição em português.
The Timeles Way of Building: não tem nada a ver com informática e fala apenas de arquitetura, mas é o livro que inspirou os autores de Padrões de Projeto. Ele mostra como existem soluções recorrentes para problemas recorrentes na construção de qualquer tipo de prédio, e demonstra como reconhecê-los e aplicá-los durante o projeto deles. Familiar, não? É um excelente texto que me fez ver os sistemas com outros olhos. Não tem edição em português.
Introdução ao Rational Unified Process: Este livro tinha tudo para ser um dos meus favoritos, mas a edição que comprei é tão ruim que eu mal consegui chegar à página 20. Mal-acabado e recheado de erros crassos de tradução, afasta os leitores que querem saber mais sobre o processo unificado da Rational. Ainda vou comprar uma edição decente para poder ler e aprender mais sobre esta metodologia de desenvolvimento.
***
Veja outros artigos que já escrevi sobre análise de sistemas e afins
Design com Multi-Paradigmas em C++: Por enquanto, é o único livro da minha biblioteca voltado para uma linguagem específica. Nele, o autor defende a tese de que programar em C++ utilizando apenas o paradigma de orientação a objetos é desperdiçar todo o poder de fogo da linguagem, algo como comprar um computador só para ouvir música. Ele sugere utilizar, ao mesmo tempo, em um mesmo sistema, vários recursos que vão além da orientação a objetos, como os templates e funções sobrecarregadas, apresentando técnicas de modelagem que indicam a melhor técnica de desenvolvimento e implementação dessas soluções. Já o li uma vez e achei bem difícil de entender, tanto por sua linguagem acadêmica demais, tanto por usar recursos de C++ que eu não faço a mínima idéia do que sejam. Não tem edição em português.
The Timeles Way of Building: não tem nada a ver com informática e fala apenas de arquitetura, mas é o livro que inspirou os autores de Padrões de Projeto. Ele mostra como existem soluções recorrentes para problemas recorrentes na construção de qualquer tipo de prédio, e demonstra como reconhecê-los e aplicá-los durante o projeto deles. Familiar, não? É um excelente texto que me fez ver os sistemas com outros olhos. Não tem edição em português.
Veja outros artigos que já escrevi sobre análise de sistemas e afins
Visão do Local de Trabalho
Mosteiro de São Bento, Baía da Guanabara e Ponte Rio Niterói.
Esta é a visão que tenho da sala onde trabalho.
Esta é a visão que tenho da sala onde trabalho.
Sobre Ofender Quem Faz Melhor Que Nós
Modéstia à parte, eu digito muito bem. Bem pra caralho, pra ser claro. Quando me formei na datilografia (sim, crianças, eu fiz curso de datilografia), eu cheguei a bater 290 toques por minuto. No computador do cartório, acho que devo ter chegado a uns 450, 500 toques. (Né, Thiago?).
Até eu acabo me assustando com minha velocidade, mas pra mim é algo extremamente natural. Eu não preciso de olhar para o teclado para digitar nada. Sabe o Elton John tocando piano? Sabe o Eric Clapton tocando guitarra? É nesse nível.
Tanto que se eu estiver digitando alguma coisa e uma pessoa vier falar comigo, eu viro a cabeça, converso naturalmente com a pessoa e continuo digitando normalmente. Sim, eu sei que é esquisito, mas é assim que acontece.
Como isso não é uma coisa comum, todo mundo se assusta.
- Caramba, quê isso?! Você não está digitando certo!
E vêm olhar a tela do meu computador, só para comprovar que eu realmente estava digitando e que estava digitando tudo certo.
Se a opinião deles acabasse aí, tudo bem. Se eu me surpreendo, nada mais justo que as outras pessoas também se surpreendam. Mas muitas vezes a coisa não acaba aí. Já ouvi, acreditem, frases assim quando eu continuo digitando:
- Seu corno filho da puta, pare de digitar enquanto fala comigo!
Aqui entramos na parte filosófica da questão toda: é justo reclamar de alguém - e pior, ofender alguém - porque ela faz algo que você não é capaz de fazer? Eu pergunto isso às pessoas, porque eu sinceramente quero entendê-las, saber o que elas pensam, mas ninguém tem uma resposta. Geralmente é só ah, deixa de ser ridículo.
Elas simplesmente não têm uma explicação decente para isso. Seu raciocínio é simples e claro: Mário faz algo bem; eu não sei fazer igual; Mário está fazendo na minha frente; então Mário é ridículo/corno/filho-da-puta. Algumas chegam até a se ofender quando eu lhes faço a pergunta.
Mas, digam-me, é justo isso? Imagine que você está em um ginásio assistindo a uma competição de ginástica artística, a Daiane dos Santos sobe lá no tablado e faz aquelas coisas sensacionais que ela sabe fazer. Um maluco, então, corre à beira do tablado e grita pra ela:
- Ei, sua anã preta filha duma puta! Vamos parar com essa porra de duplo twist carpado? Eu não consigo fazer isso, então pare de se exibir, sua piranha!
Claro que não é justo! A pessoa que faz algo bem se preparou para conseguir aquilo, então que faça. Eu fico imaginando estas pessoas na academia, brigando com alguém do lado só porque a pessoa está levantando cinquenta quilos, enquanto ela própria só consegue levantar cinco.
Vai ter leitora alegando que a Daiane está numa competição, então tem que fazer o seu melhor, e que eu conversar com alguém enquanto digito (ou digitar enquanto converso com alguém, sei lá) é pura exibição, mas, peralá!
Eu não sei cozinhar quase nada, sou uma negação pilotando um fogão, mas isso é motivo de eu reclamar da minha esposa quando ela conversa comigo enquanto está cozinhando aquele estrogonoffe delicioso que só ela sabe fazer? (Ei, pára de mexer nesse frango enquanto fala comigo, sua maluca!) Claro que não.
Sorte minha que eu não me incomodo com a reclamação dos outros. Se estou digitando e alguém vem falar comigo, eu continuo digitando normalmente. Que xinguem à vontade.
Até eu acabo me assustando com minha velocidade, mas pra mim é algo extremamente natural. Eu não preciso de olhar para o teclado para digitar nada. Sabe o Elton John tocando piano? Sabe o Eric Clapton tocando guitarra? É nesse nível.
Tanto que se eu estiver digitando alguma coisa e uma pessoa vier falar comigo, eu viro a cabeça, converso naturalmente com a pessoa e continuo digitando normalmente. Sim, eu sei que é esquisito, mas é assim que acontece.
Como isso não é uma coisa comum, todo mundo se assusta.
- Caramba, quê isso?! Você não está digitando certo!
E vêm olhar a tela do meu computador, só para comprovar que eu realmente estava digitando e que estava digitando tudo certo.
Se a opinião deles acabasse aí, tudo bem. Se eu me surpreendo, nada mais justo que as outras pessoas também se surpreendam. Mas muitas vezes a coisa não acaba aí. Já ouvi, acreditem, frases assim quando eu continuo digitando:
- Seu corno filho da puta, pare de digitar enquanto fala comigo!
Aqui entramos na parte filosófica da questão toda: é justo reclamar de alguém - e pior, ofender alguém - porque ela faz algo que você não é capaz de fazer? Eu pergunto isso às pessoas, porque eu sinceramente quero entendê-las, saber o que elas pensam, mas ninguém tem uma resposta. Geralmente é só ah, deixa de ser ridículo.
Elas simplesmente não têm uma explicação decente para isso. Seu raciocínio é simples e claro: Mário faz algo bem; eu não sei fazer igual; Mário está fazendo na minha frente; então Mário é ridículo/corno/filho-da-puta. Algumas chegam até a se ofender quando eu lhes faço a pergunta.
Mas, digam-me, é justo isso? Imagine que você está em um ginásio assistindo a uma competição de ginástica artística, a Daiane dos Santos sobe lá no tablado e faz aquelas coisas sensacionais que ela sabe fazer. Um maluco, então, corre à beira do tablado e grita pra ela:
- Ei, sua anã preta filha duma puta! Vamos parar com essa porra de duplo twist carpado? Eu não consigo fazer isso, então pare de se exibir, sua piranha!
Claro que não é justo! A pessoa que faz algo bem se preparou para conseguir aquilo, então que faça. Eu fico imaginando estas pessoas na academia, brigando com alguém do lado só porque a pessoa está levantando cinquenta quilos, enquanto ela própria só consegue levantar cinco.
Vai ter leitora alegando que a Daiane está numa competição, então tem que fazer o seu melhor, e que eu conversar com alguém enquanto digito (ou digitar enquanto converso com alguém, sei lá) é pura exibição, mas, peralá!
Eu não sei cozinhar quase nada, sou uma negação pilotando um fogão, mas isso é motivo de eu reclamar da minha esposa quando ela conversa comigo enquanto está cozinhando aquele estrogonoffe delicioso que só ela sabe fazer? (Ei, pára de mexer nesse frango enquanto fala comigo, sua maluca!) Claro que não.
Sorte minha que eu não me incomodo com a reclamação dos outros. Se estou digitando e alguém vem falar comigo, eu continuo digitando normalmente. Que xinguem à vontade.
Assinar:
Postagens (Atom)