Alessandro Martins

Novo Blog

2010-04-02T18:02:00.000-07:00

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

Em Busca da Perfeição

2010-03-30T09:36:00.000-07:00

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.

Meu primeiro haikai

2010-03-19T05:07:00.000-07:00

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

Compila mas não roda

2010-02-11T02:42:00.000-08:00

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.

7 Passos para imortalizar um projeto

2010-02-01T03:54:00.001-08:00

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...

A cláusula do menor esforço

2010-01-25T16:35:00.001-08:00

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)

Quebrando galhos

2010-01-08T03:43:00.000-08:00

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.

A droga do talento

2010-01-05T09:40:00.000-08:00

Lendo um artigo do Henrique Bastos sobre programadores lentos, por sinal muito bom, fiquei tentado a divagar sobre o assunto. Como de costume, fiquei horas e copos pensando e formulando, revendo minha pobre experiência de vida e acabei por cair no tema, de cara.

O Henrique tem razão sobre a posição da atitude na qualificação de um programador, quiçá na qualificação de uma pessoa, como ser humano. Mas minhas ponderações seguiram um outro rumo, embora adjacente ao tema: até quando é possível exercer a atitude?

Tá bom, eu sei que o tema é “piegas”, “batido”, mas fazer o quê? Este tema incomoda-me profundamente. Sempre que posso, gasto lentamente meu tempo a seu favor. A que serve a atitude se ela não é vista como tal?

Este tipo de post é daqueles que não pretendem mudar o mundo ou o seu modo de pensar. Vai mais como um desabafo, um “chororô” causado pela droga do talento. Sim, talento é uma droga. Não simplesmente pelo fato de ser viciante. Todo mundo tem um talento e é viciado nele. Mas também trazer tantos transtornos.

A atitude não é uma virtude, mas uma obrigação. Porém esta relacionada ao caráter, e este é um ponto que não vale o debate: ou se tem, ou não se tem; oito ou oitenta.

Porque relacionei atitude e talento? Pelo simples fato de que considero a atitude como sendo a materialização do talento. Quando alguém trabalha minuciosamente um projeto, buscando não a perfeição, mas simples usabilidade daquilo que esta sendo produzido, é tal qual o oleiro a moldar sua obra de arte. Sim, porque programar é uma arte, um talento. E para tal, exige mais do que dedicação, exige paixão. Ou seja, a paixão é uma atitude.

Mas o talento continua sendo uma droga. Quantas pessoas você conhece que são chamadas de talentosas? Eu conheço poucas, embora chame a muitos por este “codinome”. Agora, vamos mudar a pergunta: quantas pessoas você conhece que são chamadas de “nerdes”, de “cientistas malucos”, de “inventadores de moda”?

Se o número cresceu, fique satisfeito: você conhece muita gente talentosa e, claro, também vítimas de um preconceito, como todos, infundado, de nossa sociedade moderna. Este mesmo preconceito deixa, por vezes, um certo medo de se ter talento. Não raro o mercado dispensa profissionais altamente talentosos na mesma proporção que dispensa os ruins. E a explicação é bem simples: ambos estão nas pontas, e certas empresas preferem a mediocridade que obedece, que não questiona.

Talvez, digo talvez, tudo esteja relacionado ao conceito de produtividade. O que é a produtividade? Se um programador esta lendo, ele está produzindo? E se ele desenvolve um sistema, e todo dia o monitora afim de que o mesmo siga sem problemas, ele está produzindo? E se o programador simplesmente pensa, estará ele produzindo?

O que é produção, afinal? É passar o dia inteiro digitando códigos? Ora, o programador foi contratado para produzir e isto denota que ele já sabe tudo o que precisa saber. Ou não?

Mas a culpa é do talento, dessa droga de talento. Se não fosse o talento, não haveria possibilidade de comparação. Não haveria a ponta, apenas mediocridade e coisas menos. Seríamos menos tristes sem ele, mas jamais mais felizes. Não sem a paixão.

Acho que chega de lágrimas. Essa droga do talento sempre me deixa assim, meio “jururu”. Mas isto não importa, pois tenho comigo o orgulho de ser, desde criança, o cientista maluco do colégio.

Programação Funcional?

2009-12-17T06:57:00.000-08:00

Como começar um artigo sobre a compreensão do paradigma funcional? Primeiramente é necessário entender porque eu quero deixar de ser um deus para ser um reles titã. Sim, porque programar em modelos imperativos me tornam um deus: faça isto, faça aquilo... E os erros, ah os erros, eles vêm depois. No momento, somos apenas eu e a máquina a me obedecer.

Entendamos por este exemplo:

declare mundo boolean

declare trevas boolean

declare luz boolean

inicio

trevas = true

escreva(“Criar Luz?”)

leia(luz)

se(luz == true) faça

trevas = false

mundo = true

escreval(“Houve luz”)

escreval(“O Mundo foi Criado”)

senão

escreval(“Só existe trevas”)

fimdose

fim

Já deu para perceber quem é que manda aqui, não é? Eu disse haja luz e houve, e o mundo foi criado, e as trevas deixaram de existir. Se não der “pau” no programa, claro. Isto é linguagem imperativa: faça isto, faça aquilo. Sou eu quem determina o que deve ser feito, sou o próprio manda-chuva, senhor de meu universo. Tenho o poder de dar vida ao criar uma variável, interfiro em seu destino simplesmente alterando o seu valor, e posso gerar consequências, caso queira, definindo estruturas de decisão. E o melhor, posso dar fim em tudo, afinal, eu sou deus.

Como pode-se perceber, neste meu “creation of the world”, como um bom deus, indiquei sequencialmente minhas ordens de como fazer. O que haveria de ser feito dependeria de um fator variante, ou seja, daquilo que recebi como entrada. Se eu lesse false em minha entrada de luz, de acordo com minha condição, as trevas permaneceriam, e se a entrada fosse banana, não haveria cosmos, e sim caos, pois não fiz um tratamento de exceção.

Quando falamos em um modelo imperativo de programação, estamos entendendo (compreendendo?), como algo muito próximo de nossa linguagem. E isto está correto. Lembram dos verbos no modo imperativo?

Fazei, vós!

Graças a um outro deus , Von Neumann, de forma imperativa utilizamos um modelo matemático que busca processar uma única instrução de cada vez, procurando manter a integridade dos dados executados. Nem é preciso dizer que este paradigma é dominante que está estabelecido.

Aliás, o que vem a ser paradigma?

De acordo com o Priberam,

paradigma
(grego parádeigma, -atos)

s. m.

1. Algo que serve de exemplo geral ou de modelo. = padrão

2. Gram. Conjunto das formas que servem de modelo de derivação ou de flexão. = padrão

3. Ling. Conjunto dos termos ou elementos que podem ocorrer na mesma posição ou contexto de uma estrutura.

Bom, podemos entender como ponto de vista. Porque não? É bem mais simples do que parece. Os paradigmas: orientado a objetos, a funções, a exceções, etc, nada mais são do que pontos de vista sobre melhores formas de se programar em dadas situações, determinados problemas. Ao menos não deveriam ser: um único paradigma, a solução de todos os problemas. Isto tem um nome que não me lembro. Ah, sim, isto é fundamentalismo.

Bom, no ponto de vista utilizado na interpretação da minha criação do mundo, como disse, é claramente definido o como fazer, e as nuances derivadas são diretamente ligadas ao o que fazer. Isto pode ser uma desvantagem, uma vez que o como fazer não garante o que deve ser feito e nem se foi feito. Estas garantias estão ligadas a mais comandos, mais códigos.

Mas apesar de tudo, ainda sou um deus. E se olhar mais à diante, posso criar santos a que chamarei de classes, que intercederão a mim. Sim, estou falando de orientação a objetos, que em suma, seria uma forma de organizar o modo de como fazer. Ou seja, um nível de organização e não um paradigma de fato. Algo como:

Inicio campeonato

se(Vitoria(Galo) ==true) faça

escreva(“Galo campeão!!!”)

fimdose

fim campeonato

Onde:

Vitoria(time) {

ganha = true

}

Que executaria:

Inicio campeonato

se(

Vitoria(time) {

ganha = true

}

==true) faça

escreva(“Galo campeão!!!”)

fimdose

fim campeonato

Embora eu tenha sido o deus do como fazer, botaram o Flamengo no “o que fazer” e o meu galo ficou a deus dará. E mesmo sendo um deus, me frustrei. Isto por que, por mais que possa controlar o destino de uma variável, alterando o seu valor, ela ainda será uma variável, variante...

Depois de uma breve e singela pincelada sobre paradigmas e linguagem imperativa, vamos passar à orientação funcional, onde passamos a ser titãs, o melhores amigos, também deuses, do homem.

Vamos à nossa teogonia!

Como esta analogia poderia ficar extensa com a infinidades de titãs gregos, brinquemos apenas com Prometeu, um dos titãs mais conhecidos. O que o cara fez, e o porque do castigo? Se ele foi castigado, eu deixando de ser deus também serei? Estou saindo do contexto, voltemos.

Prometeu, segundo uma das lendas, foi dado a ele e seu irmão Epimeteu a tarefa de criar os homens e todos os animais. Epimeteu encarregou-se da obra e Prometeu encarregou-se de supervisioná-la. Na obra, Epimeteu atribuiu a cada animal os dons variados de coragem, força, rapidez, sagacidade; asas a um, garras outro, uma carapaça protegendo um terceiro, etc. Porém, quando chegou a vez do homem, formou-o do barro. Mas como Epimeteu gastara todos os recursos nos outros animais, recorreu a seu irmão Prometeu. Este então roubou o fogo dos deuses e o deu aos homens. Isto assegurou a superioridade dos homens sobre os outros animais. Todavia o fogo era exclusivo dos deuses. Como castigo a Prometeu, Zeus ordenou a Hefesto que o acorrentasse no cume do monte Cáucaso, onde todos os dias uma águia (ou corvo) dilacerava seu fígado que, todos os dias, regenerava-se. Esse castigo devia durar 30.000 anos.

Reparem a utilização do verbo atribuir, ou o que fazer. Tentando traduzir:

function atribuirdom(bicho,[dons]){

bicho → dom + atribuidom(dons - 1)

}

Por questões obvias, esta expressão não pertence a nenhuma linguagem de programação específica. Esta função atribui um do ao bicho, recursivamente, de acordo com a quantidade de dons que foram disponibilizados. O fato é: foi claramente indicado o que fazer, que no caso seria atribuir dom ou dons a um bicho qualquer.

Isto é o paradigma funcional, um tratamento por avaliação de funções matemáticas. As funções podem ou não possuir parâmetros, assim como podem ser parâmetros de outras funções. A definição da função descreve de que forma ela será avaliada por outra função. Por exemplo, Epimeteu tem a função de f{atribuirdons, sob a função f{supervisão de Prometeu.

Como a função f{supervisão retornou algo estranho à função f{ordem, de Zeus, este procedeu a função f{dilarecafigado.

Brincadeiras à parte, o modo de compreensão à orientação funcional não é diferente do modo que funciona nosso pensamento. É bem provável que pouca gente pensa orientado a objetos. É mais fácil pensar orientado a função, uma vez agir (o que fazer), nos é sempre mais natural que pensar(como fazer).

Não tenho a intenção de ensinar esta ou aquela linguagem funcional. No momento, estou me dedicando a erlang. Este esboço foi originado na tentativa de compreender os princípios de uma linguagem. O mais importante e compreender onde e quando utilizar. Parafraseando o pessoal da 37signals, se uma linguagem não for boa para você, não a use. Vou continuar postando minhas análises de compreensão dos paradigmas, especificamente o funcional. Para terminar, alguns paradigmas a não seguir:

POG - Programação Orientada a Gambiarra
POF - Programação Orientada a Falácias
POMEE - Programação Orientada ao Menor Esforço Educacional.

Sugiram outras a não se seguir.

Abstração

2009-12-10T02:02:00.000-08:00

O problema não podia estar mais claro. Era algo tão trivial, cotidiano. Fomos logo codificar. Afinal, porque perder tempo analisando algo que se vive no dia a dia? Era melhor aplicar a força intelectual na resolução.

Mas a análise não seria a premissa da solução? Bem, é sabido que todos analisam tudo antes de codificar (?), mas será que esta verdade se repete quando o problema é trivial? Quando desconhecemos o problema, tomamos um de dois caminhos: ou estudamos ou encontramos “o cara” que sabe das coisas, o analista de negócios, de processos, o expert no assunto. Tempo para nós mesmos decifrarmos a correção? Difícil...

Mas o caso era outro: era muito simples.

De imediato, surge a abstração, a forma com que esperamos levar a solução/problema para a máquina e virtualizar a resposta. Pensamos em objetos, nos orientamos a soluções e por fim materializamos uma idéia na forma de códigos e telas. Tudo pronto, uma formulação matemática pode resumir todo um pensamento. No entanto, orientamos o nosso pensamento proporcionalmente a complexidade do fato.

Isto significa que imaginamos soluções simples para problemas simples.

Eureka! Isto é maravilhoso.

Mas como julgamos a simplicidade de um problema? É possível imaginar uma solução simples para um problema que acaso imaginamos ser simples. Mas se o problema não era tão simples assim, nossa solução poderá ser falha, ou seja, haverá re-trabalho.

Vamos partir do ponto que, o bom seria soluções simples para qualquer tipo de problema. Pronto, desta forma nos orientamos que a resolução deverá caminhar para uma única estrada. Agora vamos nos ater ao julgamento do problema.

Sem querer pensar em Hume ou Descartes, o caso é que, constantemente, alternamos nossas decisões com base em conhecimentos adquiridos, ora empiricamente, ora racionalmente. Nossas decisões oriundas do pensamento racional, são aquelas em que agimos segundo um conceito adquirido num processo de busca intencional. Por exemplo, deverei usar o lambda para resolver isto porque, num dado momento, me houve uma necessidade parecida, precisei aprender lambda e, a partir daí, julgo ou sei os casos em que posso utiliza-lo. Este julgamento depende do quanto aprendi sobre lambda.

Quando algo é natural ao meu desenvolvimento, sem custo de aprendizado, julgo sua utilização conforme meu aprendizado ambiental, não necessariamente advindo de um fator externo ao meu meio.

Semana passada, no Coding Dojo Niteroi, foi levada uma proposta de problema bastante interessante: o caso do mijão. O problema era, quando um homem adentrasse em em banheiro público, ele procuraria o banheiro mais distante da porta; o próximo cara, ficaria o mais distante deste homem; e o próximo, so utilizaria um mictório caso houvesse a distancia de pelo menos um mictório entre os caras da direita e da esquerda.

Simples assim.

Pelo menos eu faço isto todo os dias, chego e se o banheiro está vazio, vou logo para o mais longe da porta. Onde trabalho tem três mictórios. Se já tem alguém, vou para longe dele, respeitando a “zona de respingo”. Se tem alguém no meio, espero.

É muito natural, tanto que eu nem saberia explicar quem ou mesmo se alguém me ensinou. É parte do meu meio de criação.

Assim, fomos direto ao código e, pessoalmente preocupei-me mais com a Linguagem de Programação aplicada do que com o problema em si. Intimamente já sabia que o primeiro ia para o ultimo, o segundo para o primeiro e o terceiro esperava. Sim, eu sabia. Dificuldade mesmo era na declaração de um array específico que quería-mos usar.

Até que uma boa alma pergunta: e se forem quatro ou cinco mictórios?

É preciso confessar que somente neste instante me deparei que o trivial não era tão simples quanto se mostrava. Divaguei em minhas reflexos, conversei com meus botões, tentei formulações matemáticas, e apenas descobri que um problema é sempre um problema. Nem difícil e nem fácil, apenas problema.

Em meus pensamentos pude notar um certo remorso, pois fui logo pensando em algumas soluções antigas que utilizei no passado, o quanto eu desrespeitei o problema em si. Sim, foi mesmo desrespeito e, claro, tive re-trabalho.

Sempre acreditei que, nestes casos, a análise era incompleta, mas na verdade era falha mesmo. O problema foi considerado simples e a análise foi apenas simples. Logo, no lugar de uma solução simples, produzi algo imaturo, que nem era solução.

Como julgar se o problema é simples ou complexo? Não julgue, problemas são problemas. Aliás, em termos de programação, não julgue nunca, tenha sempre certeza. E isto possível? Bom, encerro com uma outra questão: acaso duvida que 2 + 2 = 4?

O velho novo projeto

2009-11-30T12:44:00.000-08:00

E então, somos chamados a mais uma daquelas intermináveis reuniões para debatermos qual a melhor forma de se apagar um incêndio no sistema xpto. Claro, há uma eminente determinação de todos os presentes, o problema tem que ser resolvido e rápido. O departamento z não pode ficar sem o sistema xpto.

Em meio a tantas soluções, tantas boas ideias, o que fazer? Assim, um novo debate surge e, agora, o foco é descobrir qual é a melhor ideia. Mas afinal, como se mede uma ideia? O que faz dela boa ou má? O testes, talvez, mas temos tempo e dinheiro para testar todas?

Neste momento fica claro o objetivo, o foco: resolver o problema. Mas o ideal não seria focar em não se ter problema? Toda e qualquer decisão tomada em momentos de tensão, ambientes de stress, têm a tendência de partirem para o caminho mais rápido, não o melhor. As decisões, nesses momentos, fluem como a água, buscando o caminho mais rápido. O que não significa que é o melhor caminho.

Incêndio significa fogo sem controle. Assim, é ilusória a máxima “apagar incêndio” do sistema. Tal como há tantas ideias para solucionar consequências, inúmeros podem ser os focos de problemas. O que somos: bombeiros, programadores ou paramédicos?

Finda a reunião, um novo projeto vai surgir para tentar resolver velhos problemas. É incrível o apego de um desenvolvedor com uma aplicação, ao ponto de invocar emoções que o impeçam de ver que a hora do sistema xpto chegou.

Que ele vá com Deus!

Embora triste, há momentos em que é chegada a hora de se tomar a decisão da morte de um sistema. Até porque, se o desenvolvedor assim não o fizer, o cliente pode declarar a morte de quem o fez. Claro, não devemos defender a certeza do que julgamos conhecer contra a incerteza do novo. É um fanatismo.

Quanto tempo se perde re-projetando? Em relação a algo pronto, nem sempre utilizamos a liberdade que a tecnologia nos propões: a da simplicidade. Fazer um projeto para corrigir algo de um projeto que não foi terminado. Isto não é reinventar a roda, é o equivalente a estar sempre comprando uma mesma roda.

De posse bom e velho novo projeto, somos fadados a querer produzir, aumentar. O termo “projeto” nos induz a isto. São raros os projetos de “limpeza de funcionalidades”, “eliminação de comandos”. Ora, queremos evoluir, e por vezes entendemos (compreendemos?) evoluir como sendo a algo (físico) a agregar. Mas deveria ser mais simples, evoluir deveria ser “adaptar-se”, no nosso entendimento. É preciso adaptar a forma de pensar ao invés de pensar em formas de se adaptar.

Por que é tão difícil recomeçar? Porque somos treinados a crer que se deve recomeçar somente após uma queda. “levanta, sacode a poeira e dá a volta por cima!”. No entanto, a decisão de se recomeçar um projeto falho, significa a maturidade de ver que crescemos. É como olhar o código e se espantar: fui eu quem fiz isto? Sim. Fui eu mesmo. É hora de evoluir meu produto, hora de substituí-lo, hora de encerrá-lo. Não há tombo, não há derrota, apenas crescimento.

Apagar incêndios é cíclico e consequencial. Nunca termina. E o pior: sempre sobram cinzas impossíveis de se limpar. E quando acredita estar tudo limpo, ainda resta o cheiro de fumaça.

É hora de olhar para o cliente sob o olhar dele, e não do nosso. Quando deveríamos negar funcionalidades fantasmas, as agregamos, pois somos treinados a produzir funcionalidades e não a interpretá-las. Quando devemos ouvir o cliente sobre o seu negócio, seu domínio, o negamos, pois somos treinados a crer que conhecemos o produto melhor que o cliente e não a produzir em conjunto.

Somos mal treinados? Seguimos uma tendência? Somos egoístas? Não deve haver uma resposta plausível para tal questão, no entanto, sempre há lugar para pensar diferente, agir diferente. Projeto novo, que seja mesmo novo.

De quem é o seu conhecimento?

2009-11-15T12:45:00.000-08:00

Por vezes sou tentado a questionar-me sobre a quem pertence o meu conhecimento. Não a informação, pois esta é deveras transitória em minha mente, mas o conhecimento. Aquela coisa que nos faz interagir com a linguagem, a informação, o ambiente e o raciocínio. Sim, pois creio raciocinar de acordo com um certo conhecimento que define as diretrizes do meu pensar.

Dia desses, lendo o livro Getting real, escrito pelo pessoal da 37signals, percebi a necessidade de compreender o pragmatismo americano. Entendi que era necessário, ao menos para mim, compreender o pensamento de quem escreveu o livro, se é que isto é possível.

Logo de cara, percebi que, pelo momento pessoal em que vivo, o livro foi bastante claro, entendi de cara. Mas depois, conversando com meus botões, imaginei estar caindo numa armadilha: entendimento versus compreensão.

Segundo o dicionário online priberam (http://www.priberam.pt/DLPO/), entendimento significa

entender (ê) - Conjugar

(latim intendo, -ere, estender, pretender, estar atento)

v. tr.

1. Apossar-se do sentido de (o que ouvimos ou lemos).

2. Ser de opinião; julgar.

v. intr.

3. Ser entendedor.

4. Superintender.

5. Infrm. Contender, armar rixas.

v. pron.

6. Compreender-se (a si mesmo).

7. Referir-se; ser concernente.

8. Estar de acordo (duas ou mais pessoas).

9. Combinar.

s. m.

Maneira de pensar ou de ver. = entendimento, juízo, parecer, opinião

e compreender

compreender (ê) - Conjugar

v. tr.

1. Abranger.

2. Encerrar.

3. Conter.

4. Entender.

5. Alcançar com a inteligência.

6. Perceber.

7. Notar.

8. Depreender.

9. Saber apreciar.

10. Ant. Achar (alguém) incurso em, ou culpado de.

Estar incluído ou contido.

Achei bastante interessante “entender”, como apossar-se dos sentidos e “compreender”, estar incluído, ou contido. Claro, não é possível compreender sem antes entender. Compreender é tal qual uma tarefa dependente de entender. Porem, percebe-se que é possível apenas entender.

Assim, fico a imaginar o quanto somos obrigados a apenas entender. Imagine um trabalho onde as tarefas são passadas como certas, e você até tem a liberdade de questionar, mas a premissa já fora definida e é irrevogável, ou seja: questione, mas tera que obedecer.

Sem nenhum incentivo ao anarquismo, mas de que vale o entendimento neste caso? A simples base para a sequência de um roteiro? E o pior: cremos na falsa liberdade do questionar. Esta liberdade, falsa, nos ilude no aspecto de que fazemos parte de um conhecimento que não é nosso e que pode jamais ser, uma vez que somos obrigados a encerrar nosso exercício mental na fase do entendimento.

Por fim, seremos responsabilizados pelo resultado do produto e não somente pela resolução do mesmo. Algo como: empregado, faça “A”. E o pobre até questiona: “A” com acento ou sem acento? Empregado, faça “A” com trema. E dá-lhe esforço, trabalho, dedicação. Tudo tem que ser rápido, pois o chefe que solicitou não possui todas as noções necessárias de como produzir “A”, ainda mais com trema.

Trabalho realizado, vem a surpresa: “A” com trema não é capaz de realizar o que se necessita.

Um momento. Quando foi questionado o que “A” deveria fazer? Apenas se entendeu que produto seria realizado, mas o que o produto faz? Para que serve? Compreendo bem a necessidade? Consigo conversar com o produto? Compreendo sua linguagem.

Já dizia o Bituca (Milton Nascimento): “minha casa não é minha, nem é meu este lugar.” Este fragmento deveria ser o hino da frustração. É qual entender onde estou, como estou, mas não compreender quem eu sou.

Quando somos forçados a apenas entender, cumprimos o imediatismo das corporações e apresentamos resultados rápidos. Mas nem sempre satisfatórios a estas corporações e sempre infelizes para nós mesmos. O que é um resultado? É simplesmente entregar o que se pede? Na forma que se pede? O que é pedido afinal? Quem o sabe?

Não vamos atravessar a linha filosófica do Cogito, ergo sum ("penso, logo existo") – Rene Descartes. Mas nos estacionemos por hora no Dubito, ergo cogito, ergo sum, ("Eu duvido, logo penso, logo existo"). Quando realizamos algo que simplesmente entendemos, significa que alguém compreendeu este algo anteriormente a nós. E se não compreendermos este algo doravante, ou nos contentamos a simplesmente entender ou somos impelidos a tal.

Desta forma, chegamos na questão do título: a quem pertence o nosso conhecimento? No caso citado acima, sequer chegamos na esfera do conhecer. Então, não nos há conhecimento. Mas e quando podemos adentrar o espaço do conhecer enquanto produzimos? De quem será o conhecer?

Nosso!

Meu, seu, do chefe, da corporação, nosso. Caso compartilhado, digo, encerrado. No entanto, sabemos, as coisas não são bem assim. Há hierarquias, segmentos, regras incompreensíveis que todos os dias enfrentamos. Porém, se o conhecer é algo que podemos personificar em nossa centelha intelectual, não há impedimento para o alcançarmos. Ou melhor, é uma tarefa que depende unicamente de nós mesmos.

É preciso duvidar para entender, entender para conhecer, conhecer para se satisfazer, estar satisfeito para duvidar. Sim, porque, do que adiantaria duvidar num momento em que não há satisfação? Nada. É preciso estar cheio para duvidar do que possui e assim começar e/ou recomeçar o eterno ciclo do conhecer, do amadurecer. E este conhecimento é somente seu. Não há corporação, regra, modo ou situação que o tire de você. É a sua conquista.

Esperança

2009-11-09T06:24:00.001-08:00

Tenho esperança que este texto fique bom.
Bom, ainda continua medíocre, poucas palavras, objetivo obscuro. Mas ainda tenho esperanças. E aguardo...
Continua na mesma. Talvez o tenha piorado. Acho que vou partir para um plano “B”. Porém não há plano “B” e o meu texto continua ruim. Porque eu não fiz um plano “B”? Será que esperei demais?
Nestas minhas andanças pelo vale da programação, sempre me deparei com a tentação de esperar que tudo se ajeitasse. Com isto, acabava por desconsiderar questões básicas como planejamento, estratégias de exceção, análises, saídas alternativas. Excesso de confiança? Com toda certeza.
Não que eu não merecesse tal confiança, mas o caso é que por inúmeras vezes acreditei que era capaz de realizar o impossível e esperava, como sempre, de fato conseguir. E esperava, esperava e apenas confiava, sem nenhum trabalho extra.
Uma ilusão, pois sempre trabalhei mais para não realizar absolutamente nada. Um exemplo, um certo cliente pediu-me que desenvolvesse toda uma aplicação de gestão de Planos de Ação, mas havia um problema: como haveria uma auditoria, era necessário que o sistema estivesse disponível em duas semanas. Fora isto, o cliente ficava 80% do tempo indisponível para levantamento de informações e havia uma distância geográfica considerável. Estava em Minas e ele no Mato Grosso.
Não é necessário estender a história ou detalhar fatos. O sistema não ficou pronto a tempo. Precisei ir ao MT e lá trabalhar por cerca de 15 horas por dia e, não entregar um sistema funcional, mas um amontoado de protótipos que iam do nada a lugar nenhum. Atendeu à auditoria, mas corroeu-me por dentro. Senti-me frustrado. O tempo todo tinha esperanças que terminaria, mas isto não aconteceu. E eu não tinha um planejamento, uma plano de contingência, nada. Apenas esperança.
Não posso entrar no mérito da fé, isto muito íntimo de cada um. Porém, no mundo da responsabilidade, a ação é o que vale. Você pode até esperar ser um programador melhor, uma pessoa melhor, ter mais grana. Espere o quanto quiser. Se não agir, será apenas mais um a esperar.
Hoje, reconheço que precisarei reescrever este texto inúmeras vezes até que o mesmo possa ter um mínimo de aceitabilidade pelo leitor. Hoje reconheço e assumo o compromisso de agir em função daquilo que produzo, e não o contrário. Por todo o tempo que esperei minha produção agir a meu favor ela sequer foi produzida. Sim, porque algo mal feito não se difere de algo não feito.
Para que um coisa, um programa exista, é necessário que ele saia do mundo das ideias. É preciso se esforçar, limpar a forma, manuseá-la com cuidado, agradar Platão. Não se deve esperar que fique pronto. Um programa não é um bolo. É a sua ideia, a sua produção.
Mas o que diferencia o trabalho que realizo enquanto espero e confio, de um trabalho de ação que atinja o objetivo esperado? Ora, não estou trabalhando da mesma forma? A resposta é não. Manipular conhecimento é diferente de produzi-lo. Ajuntar códigos com o objetivo de simplesmente entregar algo pronto, é muito diferente escrever um login pensando em quem vai utilizá-lo.
Vou revelar um medo que guardo comigo: de que os programadores se tornem digitadores. Não possuo fontes sobre esta vertente, nem posso provar que ela ocorra. Mas guardo um medo de que isto possa acontecer. Sempre me pergunto quanto de mim está presente num programa, numa análise. Não é uma questão de uma assinatura, mas simplesmente de personalidade.
Assim como eu, minhas produções possuem defeitos, qualidades. Mas quanto destes defeitos são meus? E as qualidades? Não que seja errado aplicar algo de bom encontrado na net, mas o que qualifica este algo como algo bom? A minha análise, o meu conhecimento conversando com o conhecimento do outro e formando um novo conhecimento.
Para isto, algumas horas de leitura sempre ajudam. Debates em foruns, com colegas de trabalho sempre acrescentam. Por isto não posso apenas esperar que algo dê certo, é preciso compreender o que é o certo para este algo e suas implicações.
Mas não vou conseguir saber tudo. E isto é o que há de melhor. Sempre há oportunidade para um novo conhecer. Trazer uma ideia do mundo das formas para o mundo real é um processo. Fazer o mundo real compreender esta ideia é um progresso. Levar esta compreensão à origem, ao mundo das ideias para que as novas formas já a tenham impressa, é partilhar conhecimento.
Hoje, sempre que penso em esperar, em ter esperança sobre algo, começo logo a planejar; boto o meu conhecer para “papear” com o conhecimento de outros. E você, o que espera para si? Ou já está agindo?

Próximo!

2009-10-30T17:15:00.000-07:00

Às vezes fico imaginando a satisfação de um médico, quando a secretária, sem sequer levantar o olhar atendo à sua sua agenda, grita: próximo! Um cliente atendido, outro a caminho, mais uma experiência ganha e mais um desafio a caminho. Bom, assim imagino.
No mundo de desenvolvimento não deveria ser diferente. Devería-mos constantemente gritar: próximo. Mas isto não acontece. Porque? Vou tentar elencar algumas razões com base na minha própria dificuldade em gritar “próximo”.
Num primeiro momento, é preciso entender a concepção que se tem de realização profissional. O que é estar-se realizado profissionalmente? Um bom salário? Poucas horas de trabalho? Dinheiro na conta? Fazer o que gosta?
É de cunho muito pessoal, portanto, acredito que seja uma questão sem importância. Sim, sem importância mesmo. O que a realização pessoal tem haver com um produto desenvolvido para outrem? É justamente este o ponto. E acredito que ele possa estar naquela máxima “não há mérito no cumprimento do dever”.
Bom, se isto é natural para o leitor, sugiro que passe para uma outra leitura. Próxima!
Se não, vamos continuar: que mérito há no cumprimento do dever? Se o dever é seu, pessoal, a realização do mesmo diz respeito a você mesmo. O empenho e desempenho na sua produção não seguem com o produto pronto, ficam com você. A qualidade o segue, mas o desenvolvimento da mesma permanece com o criador. Este é o mérito que se herda no dever cumprido.
Quando se valoriza aquilo que agrega o desenvolvimento, o mérito esta na vitória de se aplicar aquilo em que se acredita. E como prêmio: conhecimento. Um exemplo: qual programador não se sentiu satisfeito no seu primeiro “Hello World”. Independente da linguagem, do código, do paradigma. Falo daquela satisfação, do monólogo: eu consegui! E que todos dizer depois? Hora de fazer o “próximo” passo.
Houve um tempo em que minha maior preocupação estava na segmentação de um software, na sua continuidade como programa e na minha como empregado. Hoje fico agradecido que esta preocupação se foi com meu primeiro emprego na área de informática. Neste tempo, conheci muita gente que aplicava técnicas de “defeito previsto”. Situações que obrigariam a intervenção do programador e consequentemente a geração de um custo para o cliente.
Também convivi com as chamadas licenças de uso. Um valor pago mensalmente para o programador não fazer nada. Muitos, acreditem, diziam que era o pagamento da propriedade intelectual. Era uma coisa mais ou menos assim: o cliente dizia ao programador o que fazer, o cara fazia o que o cliente queria menos um (defeito previsto) e depois cobrava a patente para o idealizador do programa. Eram vendidos programas e não soluções.
Devo admitir que parti para soluções parametrizáveis como um diferencial no mercado. E sendo novo, não tive retorno financeiro, mas tive a satisfação de aprender métodos que pude aplicar em soluções duráveis. E estas sim, são as que interessam no mercado.
Entregar uma solução que se auto-gerencie não é o fim de um trabalho, mas o início de vários outros. O cliente prefere conhecer que fez a solução ao programa que resolve. Porque? Porque não existe apenas um problema no mundo.
Nem é preciso dizer que meu trabalho era solitário. Assim, entregar algo que estivesse bem ao meu ponto de vista e ao mesmo tempo que atendesse às expectativas do cliente era penoso e demorado. Foi então que eu percebi que o problema maior estava na expectativa causada no cliente. Vejamos um cálculo não oficial:

quebra de expectativa = ((frustração) ^ dias de espera ) * 2

Onde 2 representa você mais o cliente.

Assim, quanto mais fazer esperar, maior a probabilidade de decepcionar. O que fazer então? Causar menos expectativa? Pode ser. Mas também se pode causar expectativa à prestação. Quando desenvolvi um software para a área de segurança do trabalho, prometi um gráfico em que o técnico seria capaz de fazer mais de 1000 análises que o ajudariam no seu dia a dia. Entreguei, com atraso, claro. E onde ficou a decepção? Esta estava no fato de o técnico não usar mais do que três análises do gráfico. A que que fazia mais de mil... A expectativa que eu havia causado não estava no software, mas na alteração de um modelo de trabalho que não ocorreu. A frustração ficou lá, no dia a dia do técnico. Depois deste episódio entendi o que significavam as frases “canhão para matar formiga” e “máquina de fazer sombra”.
Por outro lado, posso elencar as expectativas que quero causar (entenda por ideias, inovações) e as distribuir mediante a entrega. Podemos descobrir que algumas são apenas inúteis, outras perigosas, a maioria inatingível. Devemos atuar como num jogo de xadrez, imaginando no mínimo uns cinco movimentos à diante. E sempre atentos aos movimentos que não devemos fazer. A expectativa deve ser compartilhada e moderada. Jamais deixe que o cliente tenha mais expectativas do que você. A expectativa causa uma cobrança de resultados às vezes até incompreensíveis. Se você, por sua própria expectativa se cobra, imagine também sendo cobrado por seus clientes por algo que eles nem sequer lhe pediram.
Aliás, quem são seus clientes? Se esta pergunta é difícil resolução, ou pior, se for uma resposta curta, então é hora de repensar no assunto. Mas podemos resumir: todos são meus clientes. Num processo comunicativo, todos, por uma razão ou outra sugerem oferecer uma satisfação, um feedback.

--- E aí, cara, tudo bem?
--- Beleza e você?
--- Bem também.

Neste diálogo curto, houve uma satisfação de fatos (estado) dos dois lados. Agimos assim, é natural da comunicação. É preciso entender somente que tipo de satisfação dar e cobrar de seus clientes.
O conflito de egos também é um grande vilão na história do “próximo”. O cliente sempre tem certeza do que está pedindo e o programador sempre sabe o que está entregando. Assim, caímos nos três lado de uma mesma moeda: a sua versão, a minha versão e a versão correta. Se enfileirarmos um monte de moedas deitadas, ora cara, ora coroa, consumiremos um grande espaço físico e a última moeda, a palavra final, será de quem tiver mais poder de se impor, ou cara ou coroa.. Se as enfileirarmos de pé, todas os lados que vão aparecer são as laterais, sempre iguais e com um espaço muito reduzido.
O que quero dizer é que o esforço deve estar direcionado à comunicação, à análise e ao consenso.

Próximo = !retrabalho

Retrabalhar aquilo que já foi solicitado causa frustração, não gera conhecimento, gera custos e causa decepção no cliente. Assim, a ortografia de uma aplicação solicitada deve falar a linguagem do cliente e não a sua. A não ser, claro, que você mesmo seja o cliente. Quando não se tem retrabalho, se tem oportunidade de resolver outros problemas. No entanto, uma coisa fique bem clara: os outros problemas não podem, jamais, ser novos problemas causados por sua aplicação. Lembre-se, produzir soluções é diferente de produzir programas.
A diferença está justamente no fato de que programas independem de interpretações humanas. Por mais protegido com alertas que um programa esteja, o usuário pode simplesmente ignorar e executar.
Solução significa entender se o usuário poderia ou não executar tal programa, se este mesmo programa é de fato necessário. É falar a mesma língua, deixar claro o que se está executando. É a comunhão do conhecimento.
Relembrando Paulo Freire: “Ninguém educa ninguém, ninguém se educa a si mesmo, os homens se educam entre si, mediatizados pelo mundo”. Ou seja, é preciso partilhar e compartilhar conhecimento.
Tenha uma equipe, mesmo que trabalhe sozinho. A quem você recorre nas suas dificuldades? Ou acredita não tê-las? Faça testes, conheça novas modalidades de testes, abandone preconceitos de linguagens e paradigmas. Já acreditei que visual basic resolveria até meus problemas sexuais. O que aprendi com isto? Que ao invés de ser expert nesta linguagem, era um nada nas outras linguagens.
Todas as linguagens possuem defeitos e qualidades Mas antes de tudo, todas possuem aplicabilidade. Estude cada uma, as velhas, as novas, entenda antes suas aplicabilidades. Acredite, isto é fundamental para se dizer: próximo.
Faça tentativas, invista no conhecimento. Ele não tem valor se não for aplicado. “Não enterre seus talentos”. Neste momento, vou adotar com minha equipe um grito de guerra: próximo! Com apenas uma certeza: será mais uma experiência ganha. Qual é o seu grito de guerra?