sexta-feira, 2 de abril de 2010

Novo Blog

Minhas postagens agora serão direcionadas para http://www.aleuai.com.br/blog

terça-feira, 30 de março de 2010

Em Busca da Perfeição

Alguém por acaso já ouviu o termo: encontro da perfeição? Eu nunca vi. Em meu pequeno mundo e em minha parca experiência, principalmente no ramo industrial onde trabalhei por alguns anos, jamais vi uma gerência ou diretoria falar do encontro da perfeição. Inclusive, o termo em busca da perfeição é parágrafo garantido de algumas políticas de qualidade.
Seria a perfeição então algo inatingível? E se sim, porque ainda a buscamos? Tenho me perguntado isto ultimamente devido a uma incapacidade de entregar um certo projeto. No caso específico, o cliente deixou de se comportar como tal, e acabou passando por uma metamofose, transformando-se em adjunto de avaliação técnica. Embora não domine, acredita que o projeto não pode estar concluído se não possuir a capacidade de se comportar bem quando ocorrer um fato, ainda não determinado, no futuro. Meu pai de santo se recusou a fazer consultas compulsórias.
Claro, esta metamorfose não teria ocorrido se minha capacidade de dizer não estivesse mais apurada. Isto não importa. O fato é que o projeto não se materializa como produção porque foi andar no   infindo caminho da busca da perfeição.
Neste meu estudo de “caso perdido”, pude notar que o perfeito de agora é simplesmente o imperfeito de anteontem. E que o perfeito de ontem, é um caso a ser estudado, mas que não necessariamente é necessário. Ou seja, o projeto deve ser orientado a conjunturas e especulações.
Uma outra coisa que pude notar é o receio de que o projeto não fique a cara do adjunto de avaliação técnica, mesmo que ele sequer vai usar o projeto, neste caso um sistema. Assim, o meu não mais cliente usa de um pré-contexto: a sua experiência deverá prevalecer da forma que é contextualizada no seu conhecimento.
Se fossemos capazes de interpretar estas variações do conhecimento, a produção de software estaria num patamar futurístico. Isto porque nosso conhecimento se apresenta em função das necessidades intelectuais de um determinado momento. Ocorre um problema, e se ele nos é desconhecido nosso raciocínio é direcionado a encontrar a maneira mais rápida de solucioná-lo, não a melhor. Se este mesmo problema ocorre novamente, é simples para o cérebro recobrar uma solução já aplicada, nos dando tempo para projetar uma outra soluções e então poder avaliá-la como melhor ou pior, e assim sucessivamente. Assim formamos a experiência.
No entanto é individual, depende de quantas vezes o problema é apresentado a cada pessoa e em que tipo de ambiente. E, claro, qual a solução rápida de cada um, que originou o ciclo pessoal da experiência.
A busca pela perfeição aplicada a este meu projeto, o torna um celeiro de experimentações, que jamais terá fim. Nenhuma tentativa será boa o suficiente a partir de amanha, e todas serão obsoletas depois de amanha, podendo ser o algo perfeito no mês que vem.
Para este caso, não há solução. A impressão de um projeto inacabado já está presente no adjunto de avaliação técnica, que neste momento retorna a crisálida e volta a ser cliente. E faz uma distinção de papéis: o cliente é quem se aborrece, o adjunto tem méritos das boas ideias, mas se não vai para produção ou não termina nunca a culpa é do desenvolvedor.
Qual a melhor saída neste caso? Continuar a busca pela perfeição? Abandonar o projeto? Acredito que um debate, não embate, é sempre a melhor opção. Claro, não será uma especificação assinada com sangue com resolverá os problemas. Ao contrário, pode até piorar.
Neste meu caso em específico, tentei mostrar ao cliente sua posição de Stakeholder, como uma parte interessada para que ele pudesse se manifestar em entregas e não em projeções que ainda não foram desenvolvidas. Solicitei que analisasse o quão genérico deveria ser a aplicação, para que outras opiniões fossem ouvidas. E o principal, que o todo fosse repartido em partes, segundo o negócio, para que cada uma fosse avaliada em particular.
Mas não é uma solução, e sim um paliativo. Não é possível saber quanto tempo meu cliente se comportará como cliente. Tudo isto porque houve uma falha de planejamento: a da definição de papéis. Ou seja, a culpa realmente é do desenvolvedor.

sexta-feira, 19 de março de 2010

Meu primeiro haikai

Tentei escrever hoje um haikai. Para quem não sabe, Haikai (em japonês: 俳句 Haiku ou Haicai?) é uma forma poética de origem japonesa, que valoriza a concisão e a objetividade. Mais informações aqui. Bem, ultimamente uma pergunta se faz presente no meu dia a dia. Tenho sido incomodado várias vezes pela dúvida: quanto do seu simples me será complexo?
Complicado?
Bom, vamos simplificar. Sempre que posso, escrevo, divago e traço considerações sobre meu convívio com o mundo tecnológico. Um assunto que no qual tenho dirigido meu foco de estudos, é sobre desenvolvimento e pragmatismo. A referencia ao haikai, é pelo fato de sua objetividade. Em três linhas, um poema inteiro, conciso e objetivo.
Porque algumas aplicações, web ou não, incistem em ser complexas? Qual a premissa utilizada no seu desenvolvimento: os óculos do Jhon com o olhar do Paul? (Engenheiros do Hawai). O que predomina, a visão do chefe, do cliente ou do desenvolvedor? Ou melhor: a visão do “é assim” ou a do “deveria ser assim”?
Este assunto é infinito, pois aplicações, sistemas não são prédios. A mutabilidade de suas razões é infinda. Uma simples brisa pode marcar o início de uma grande alteração de um software. Uma simples idéia borboleta pode bater asas e iniciar uma catastrofe em uma rede inteira. Mas as pessoas ainda querem ver prédios. Quais pessoas?
A pessoa que especifica pretende ver a materialização de uma idéia pessoal. Por mais que seja debatida, vai prevalecer a circunstância de quem idelizou. Se acaso num debate sangrento, uma especificação tiver alteração, será apenas uma outra forma de ver a mesma idéia inicial.
A pessoa que desenvolve tem o poder de acrescentar aquilo que melhor entende como certo para o momento. Se ela é obrigada a seguir um esquema a risca, ainda assim lhe sobra o código, filho querido e protegido, que nunca erra.
A pessoa que vai usar apenas espera poder encontrar a solução de algum problema que ainda não existe. Essas pessoas normalmente expressam frases assim: e se... e quando...
O mais interessante é que nenhumas delas está errada. O que claro, não significa que estão certas. O fato é que temos a tendência de deixar parte de nós naquilo que construímos. E as vezes esquecemos que parte de nós jamais compleatará o todo de um outro alguém. Assim, algo será ruim ou porquê não é a sua parte que alí está, ou porque sua visão de todo desconhece aquela parte estranha, naquele momento. Em resumo, estará ruim se não for do meu jeito.
Isto não é nenhuma novidade. É, na verdade, muito comum. Justifica, inclusive, algumas frases como: nem Jesus agradou a todos, ou: nem os dedos da mão são iguais. Mas não importa. Sempre há espaço para o novo.
Tenho testemunhado alguns equívocos, que se relacionam bem ao assunto. Por exemplo, há algum tempo conversando com amigos, disseram que sua chefia queria apostar no advento web (tarede?). Para isso, queria aplicações simples, diretas. Até aí tudo bem, não fosse o caso o time de desenvolvedores acreditar que seria necessário trabalhar menos. Apenas colocar menos campos, conversar com menos pessoas. Como resultado... bem, segundo eles ainda não há resultados.
Penso que há apenas dois caminhos a seguir: o do sucesso e o do retrabalho. Entendo que fracasso vem sempre depois de retrabalho, de muito retrabalho. Até porque não teria a menor graça um fracasso sem frustrações. No caso comentado por meus amigos, concluímos que um ponto crucial era a falta de planejamento. Sempre ouço coisas do tipo: “pai, perdoai o cliente, pois ele não sabe o que pede”. Tudo bem, vou concordar. Vou inclusive confessar que já me estressei por esta incapacidade nata de o cliente não possuir claridade ou coesão no que pede. Mas quantas vezes eu soube o que fazer?
Imagine a situação: um não sabe o que pede, mas acaba por pedir algo. O outro não sabe o que fazer, e acaba não fazendo nada. O planejamento não é tão somente um passo no desenvolvimento, mas o primeiro passo. E como sabemos, desenvolver não é como jogar amarelinha, onde se pode chegar ao céu saltando algumas casas. Não podemos jogar a malha e dizer: agora estou na casa da codificação, vamos saltar a casa do teste, parei na casa da conclusão...
Produzir uma aplicação deveria ser como produzir um haikai. Focando o objetivo para demonstar ao leitor (cliente) algo bem simple, mas que diga (faça) o necessário. Certos escritories japonezes ficavam meses pensando (modelando) seus poemas. Não havia um toque divino que lhes desse tudo de bandeija. Era necessário se esforçar. Assim, compor algo que lhe pareça simples e lhe se seja objetivo e direto, irá custar muito esforço de quem compõe. 
Assim como no haikai, devemos entregar o óbvio, não importando quão complexo tenha sido seu desenvolvimento ou atingimento. Ouso dizer que o simples é inversamente proporcional a complexidade envolvida na sua produção.
Mas a pergunta da visão de prédios ainda perdura. Porque insistimos em trazer a burocracia dos papeis para a tela do micro? Porque ainda tratamos aplicações como gestoras ou reparticições públicas, com intermináveis fluxos? Será que não queremos pagar a conta da complexidade, deixando ela para o cliente? Deixar que o cliente preencha 30 campos não será sempre melhor do que tratar 15 internamente no código, tornando-os desnecessários para o cliente?
Não vou me ater ao fato das incríveis regras de negócio, que por vezes obrigam desenvolvedores a rebolarem para conseguir o solicitado. Mas neste caso, não estaríamos hiper-valorizando a presença de uma parte estranha ao contexto, deixando que o cliente se vire com ela? As vezes penso o quanto maltratamos aquele que nos paga. O que me deixa intrigado, é que muitas vezes ele ainda fica feliz, pois vê toda uma parafernalha tecnológica fazer exetamente o que antigamente se fazia com papeis e officboys. Mesmo que esforço seja o memso e o boy agora se chama email.
No pragmatismo não há muito espaço para empatia, uma vez que o foco deve ser entendido apenas por e para ele mesmo. No entanto, no desenvolvimento sim, há espaço. Acredito que devemos ser empáticos na criação, e pragmáticos no produzir. E sempre lembrar que são coisas destintas.
Quanto ao haikai, eu bem que tentei...


meu esforço é vão
quando não posso atender
tão mero desejo


quinta-feira, 11 de fevereiro de 2010

Compila mas não roda

Como é carnaval, resolvi entrar na brincadeira e escrevi uma pequena sugestão para o bloco do #horaextra:

Compila, mas não roda


Já são seis horas da tarde,
a tal classe já esta pronta,
é hora de fatorar...

lá no teste foi tranquilo,
meu sprint em feedback,
só me falta compilar.

Executo meu comando,
gcc e coisa e tal
e eis que nada acontece.

E debugo sem sucesso
linha a linha revisada
eu recorro agora a preces.

Se esta coisa não rodar
digo adeus ao meu chefinho
vou lá para o #horaextra
repensar com meu chopinho.

Compila, compila, compila, mas não roda.
Se vira, façanha, se acerta, dá seu pulo, dá seu jeito.
Debuga, revisa, faz teste, pede ajuda no twitter.
Esqueça um pouquinho de menos wall (-wall),
vem pro #horaextra neste carnaval.

segunda-feira, 1 de fevereiro de 2010

7 Passos para imortalizar um projeto

Os passos citados para se caminhar na larga estrada do insucesso, não são fruto de nenhuma tese acadêmica ou de um livro de auto-ajuda. São situações reais, vivenciada ou assistidas por mim. Não há, nestes passos, nenhuma intenção subentendida com o propósito de espalhar um moral que possa ser a saída para os seus (ou meus) problemas de desenvolvimento de software. São apenas coisas que hoje, acho graça, mas que no passado geraram sérias consequências.
Claro, este elenco não será nenhuma novidade. É o que eu chamo de “chover no molhado”: sempre há alguém falando no assunto, a gente sempre lê algo a respeito, mas ufa... temos a tendência de ignorar. Até porque, é tudo tão repetitivo que por vezes não sentimos necessidade de refletir.

Passo 1 – Aceitabilidade inconsequente
    Sim, eu posso fazer
Se esta é a primeira resposta a uma requisição de um projeto, saiba que o primeiro passo pode simplesmente ser o único. Por inúmeras vezes, cheio de ansiedade e boa vontade, disse sim sem nenhuma análise. O fato de eu conhecer do que se tratava nunca foi suficiente para enfrentar as adversidades comuns em todos os projetos. Não há prosseguimento em projetos sem análise ou planejamento. É bom sempre estar certo nas suas respostas, positivas ou negativas, mas é bom entender que nenhuma delas se sustentará sem uma análise prévia, por mais que julgue dominar o assunto.

Passo2 – Falsas Promessas
    Você vai ter isto, e isto e mais aquilo.
Já que você respondeu sim, sem nenhuma análise, esteja certo que um destes dois pontos foram afixados num tipo de contrato consanguíneo entre as partes: ou o cliente espera que você faça exatamente o que ele esta pensando, não o que ele lhe pediu; ou você ofereceu um pouco mais do que ele esta pensando, dizendo coisas que ele ainda não compreende. Isto se chama expectativa. É bastante complicado lidar com expectativas, pois eles são muito íntimas. Tão íntimas que na maiora das vezes é difícil expressa-las. Criar expectativas nos clientes, é algo tão perigoso que causa consquências até no ramo da física: a partir daí, o contínuo-espaço-tempo não será mais como conhecemos. Para o cliente, o tempo passará mais rápido, e para você, nunca haverá espaço suficiente para implementar o prometido. Por fim, nada se continua.

Passo 3 – Ação pelo Menor Esforço
Hum, existe um exemplo na net...
Sim, existem inúmeros exemplos na internet. Eu mesmo vivo postando exemplos. Mas a finalidade é outra. São para estudos. E aliás, acaso o cliente lhe pedira uma colcha de retalhos? Imagine se você descobre que o seu sistema operacional, que é lento, cheio de mensagens de erros intraduzíveis, é feito com uma coletânea de códigos retirados de um fórum? Um projeto, em todas as suas instancias, deve começar do zero e terminar no fim. Pesquise, veja fontes, mas faça a sua própria codificação.

Passo 4 – A Não Comunicação
Eu acho que esta fórmula fica melhor assim.
Não ache, tenha certeza. Você sabia que um dos papéis do cliente e justamente o de se comunicar com você? Se você ou o seu cliente dispensam explicações, um dos dois é deus. Ou pensa ser. Ou talvez até tenha certeza. Lembre-se: o cliente acredita dominar do negócio assim como você crê dominar uma linguagem de programação. É sempre útil e aconselhável que se ouçam.


Passo 5 – O Não Planejamento
Já está quase pronto.
Qual a medida do quase? Esta nos testes finais, refatorando a página inicial, embrulhando para entrega? Muitas das vezes, o quase significa: não sei onde estou, mas imagino que estou perto. Se não consegue planejar não consegue executar. É melhor afirmar que apenas uma quinta parte está pronta, do que chutar que o todo esta quase pronto.

Passo 6 – Não Testar
Bom, na minha máquina funciona perfeitamente.
Se é assim, sempre dê sua máquina para o cliente e pronto, estará livre deste desgaste, de ter que rever código, tela, classe, função. E pensar que este desajeito pode ser evitado apenas testando. Sim, testes não são enfeites ou uma moda passageira. São necessários e protegem a sua reputação.

Passo 7 – Roteiro Improvisado
Mas eu fiz tudo certo
Não. Esta frase não seria necessária se os seis passos anteriores nunca tivessem sido dados. O caso é que não há uma forma empírica para se conduzir projetos. Se você não conhece, estude. Se conhece, estude também. Não há soluções mágicas ou receitas de bolo. A gestão de projetos é uma ciência séria, com fundamentos e métodos há muito sendo estudados. É sempre bom acompanhar o os estudos recentes, conhecer as origens, estar por dentro. Não improvise um roteiro de projeto, conheça um.

Como disse, estes passos já foram dados por mim e posso lhes assegurar o resultado: fracasso total. Como eu creio na vida após a morte, acredito que sempre que segui um ou alguns destes passos, meus projetos se tornaram imortais: morreram. É uma pena que os mortos pertencem aos mortos...  

segunda-feira, 25 de janeiro de 2010

A cláusula do menor esforço





Hoje, conversando com o #dynaum, comentei sobre minha falta de “inspiração” para compor um novo post. É engraçado, pois particularmente não creio muito neste negócio de inspiração neste modelo quase divino, muito propagado por aí. No meio de um assunto sem fim (trabalho), acabamos por falar sobre algo um tanto nada haver: a capacidade de julgamento do ser humano.
Falávamos sobre a triste realidade de, algumas pessoas, usarem de crianças para esmolar. Comentei que para a criança, aquilo pode não ser bom ou ruim, uma vez que ela não conhece outras realidades para compor uma comparação. Bom, como nenhum de nós é um sociólogo, ou antropólogo, o assunto morreu por aí mesmo.
Para minha satisfação, julguei ter encontrado inspiração para este post: como julgamos uma LP, um OS ou mesmo uma metodologia de trabalho sem conhecer outras a que comparar? Afinal, precisamos mesmo comparar para aceitar?
Costumamos acreditar que algo é bom, é melhor pelo fato de apenas ser mais simples, ou parecer mais simples. E estaríamos errados? Lembro-me dos meus primeiros passos, digo, pedaladas com a bicicleta de um amigo meu. Era uma Caloi 10 e a gente se enfiava no meio do quadro e tentava pedalar. Prestava atenção no pedal, esquecia o caminho, dava com a cara no chão.
Após alguns tombos, consegui andar. E após muitos tombos, consegui virar uma esquina. Eu havia aprendido a andar de bicicleta. Mas não dava para chegar onde eu queria, se que quisesse ir a uma cidade vizinha. No entanto, consegui isto, certa vez, com a moto de meu irmão. Não caí, mas foi bem difícil guardar como se passava as marchas, apertar a embreagem ao invés do freio, frear com o pé, regras de trânsito, tec. Pode parecer ridículo, mas o instante do aprendizado, seja ele no que for, não nada ridículo ou fácil.
A gente praticamente não se assume aprendiz, mas adora contar que é tudo muito fácil. Claro, após nos garantirmos. O caso é que andar de moto é mais complexo, porém acho melhor que andar de bicicleta. Assim, nem tudo que aparenta maior simplicidade eu julgo como o melhor. Porém, acho a moto melhor pelo fato de que ela torna o meu esforço motor mais simples. Não vou morrer de cansaço por subir um morro de moto, a não ser que eu precise subir empurrando-a.
Bom, se é assim, julgaria que algo é melhor por minimizar meus esforços. E o que eu ganharia com isto? Tempo? E o que eu faria com o tempo? Procuraria algo melhor e mais simples para fazer, do tipo, tirar um cochilo?
Ainda assim, o julgamento é subjetivo, particular a cada ser. Assim sendo, o que faz com que um grande número de programadores eleja esta ou aquela Linguagem, sendo que a mesma é a única em seus currículos? Subjetividade coletiva? Vou deixar isto para o C. G. Young.
Não é uma crítica, sério. O caso é que se torna mais e mais constante ouvir de algumas empresas: escolhemos a linguagem X porque há mais programadores no mercado. E pelo fato destes programadores serem mais baratos, não estamos abertos a novas tecnologias. Exagero meu? Imagino que cada um tenha sua história para contar. Espero não estar criando um silogismos, mas vejamos:


  • Se a linguagem X tem mais programadores, é a mais simples.
  • Se é mais simples é porque há mais códigos na net (mais gente posta)
  • Se há mais códigos tem-se menos esforço para criar, posso simplesmente juntar os códigos.
  • Se junto os códigos...


Brincadeiras a parte, isto não está relacionado a LP, mas ao programador. Infelizmente, há vários fatores que fazem com que as pessoas migrem para o ramo da programação. E como é um espaço bastante concorrido, é preciso estar pronto de imediato, o que faz a relação do menor esforço uma causa viável.
Mas até quando tal fato se perdura? Eu sei, eu sei, é mais um caso subjetivo. Porém, os danos são mensuráveis. Você se consultaria com um médico que não se recicla há mais de quatro anos? Que entende somente de polegares direitos? Se você machucou o polegar esquerdo, porque confia o seus software a quem não se recicla? Não posso, nem deveria, julgar os motivos de uma não reciclagem. No entanto, quem é capaz de desenvolver sem acesso a internete? Eu mesmo fiquei quatro anos estacionado em vb pelo simples fato de que me proporcionava dinheiro. Não mais nem menso que o suficiente para o meu momento. Ganhei quatro anos um bom salário ou perdi quatro anos de novas técnicas e tecnologias.
Como garantir que não necessitaremos desta ou daquela linguagem? Devemos lembrar que necessidades surgir surgirão que ainda nem são pensadas. Alguém senti necessidade de um iPhone em 1985?
Como desenvolvedores, estamos na contra-mão do menor esforço: somos nós quem o produzimos. Proporcionamos menor esforço para outras pessoas, os usuários, não para nós. Criar algo simples requer trabalho. Dedicação. Esforço maior.
O fato eu apenas conhecer vb impediu-me de comparar meus ganhos financeiros a outros desenvolvedores, de outras linguagens, de outras plataformas. Cheguei ao ponto de ridicularizar a web, pois sempre cria na evolução das aplicações desktop. Como resultado, entrei no mercado tarde, desatualizado e, o pior, por necessidade e não por opção.
Não digo que todos devem ser poliglotas em programação, mas é preciso conhecer para comparar. Não existe melhor ou pior em programação. Eu programo em linguagem X porque gosto, assim como gosto de vermelho. (Palavras do Henrique Bastos). E é assim mesmo que deve ser. Porém gosto de vermelho porque acho o azul chato, porque a linguagem y tem menos escalabilidade. Ou seja, sei do que gosto, porque sei comparar. Para finalizar, penso que o conhecimento é intransbordável... (Se é que esta palavra existe)


sexta-feira, 8 de janeiro de 2010

Quebrando galhos



Fui aconselhado, dia desses, a não utilizar termos como “paradigmas”, “conceitualização”, “empreendedorismo”. Que eu deveria medir palavras, olhar antes com quem estava conversando. A justificativa é que meu modo entusiasmado de conviver com o novo, por vezes assusta.
Como não pretendo ser assombração de ninguém, resolvi seguir o “conselho”. Mas para isto há um custo: deverei deixar de ser eu mesmo. É claro que ninguém solicitou tal absurdo, mas esta bem implícito, nas entrelinhas.
Lembrei-me de uma passagem bíblica que diz “quando eu era criança falava como criança”. Ou coisa parecida. Não importa. O caso é que, assustadoramente, os tais termos realmente assustam.
Também lembrei-me de um pedreiro, certa vez em minha casa, que na falta de um ferramental de esquadro, mediu 60cm de uma lado, 80cm do outro, alinhou com uma vara de 1m. Ele disse: pronto, esta esquadrado. E eu disse: isto é Pitágoras, mas ele: não, eu só esquadrei.
Ele não sabia porque, ou como, mas usou a hipotenuza, um triângulo retângulo, um teorema, elevou ao quadrado, tirou raiz, mas no fundo, apenas esquadrou, sem saber o que aquilo significava. E quantas vezes agimos da mesma forma? Quantas vezes decoramos uma sintaxe e acreditamos dominar uma linguagem de programação?
Seria hora que quebrar conceitos ou de quebrar galhos? Sejamos ecologicamente corretos: quebrar um galho é uma agressão a natureza. Assim, sejamos fieis a nossa natureza inovadora e não a agredamos com conceitos de proteção. Os conceitos de proteção são aqueles que garantem o andamento de nossa “vidinha mais ou menos”, que mantêm o status de “assim esta tudo bem” e nos mantém inertes na escalada evolutiva.
Sim, nós evoluímos sim. A cada dia, a cada código, a cada lógica reformulada. Quebrar conceitos é mais do que mudar de idéia, é mais do que mudar de rumo. Até porque, não é possível mudar de um local para lugar nenhum. Quebrar conceitos significa avaliar e experimentar o novo.
Mas o que fazer com o entusiasmo, tão presente e fascinante em nossa vida? Seria o caso de nos fazermos atores, nos aderirmos ao senso comum? Infelizmente, a resposta a estas questões pode estar ligado ao legado financeiro de cada um. Ou seja, se eu não me adequar, estarei fora. E não precisamos de mais desempregados.
Vejamos uma breve tabela de “sinônimos divergentes”:


Ousadia
Desrespeito Hierárquico
Empreendedorismo
Vai sair e abrir o próprio negócio
Dedicação
Puxa saco
Paradigma
Algo muito mal
Crítica Técnica
Agressão Pessoal


É neste cenário que muita gente trabalha, e não somente no ramo da programação, mas em qualquer esfera profissional. É um fato, não há o que fazer. Mas acredito mesmo que é possível mudar. As mudanças tecnológicas, climáticas, históricas acabam por forçar a humanidade a evoluir. E sempre há espaço na evolução.
Deixar de ser você mesmo, nem pensar. Medir palavras é um sinal de bom senso. O que não significa ter que abandonar convicções. Não devemos nos proteger de nós mesmos. Isto seria um re-trabalho. É hora parar de “esquadrar” e começar a compreender Pitágoras. Ao invés de fazer porque mandaram, compreender o como fazer. E o mais importante: saber o que se fez.
É possível fazer uma casa apenas com galhos quebrados? Há possibilidade de se aprender carpintaria exercendo o ofício de quebrar galhos com o próprio peso? Ao pensar nas questões vitais do tipo: quem somos, para onde vamos; vamos tentar pensar antes em: o que somos e como vamos.