As lojas querem que você acredite que deixarão de haver sacolas disponíveis nas lojas e tentam convencê-lo a comprar aquilo que chamam de “sacolas ecológicas” . Não vou sequer abordar o fato de muitas dessas sacolas conterem plastico, e de não serem de fato ecológicas… adiante. O ponto é : as lojas estão tentando convencer que ou você compra sacolas reutilizáveis agora, ou você vai começar a levar as compras para casa nas mãos.Mais do isso tentam você se sentir mal por usar sacolas plásticas agora responsabilizando o seu uso das suas sacolas pelos problemas ecológicos do uso do plástico e do não tratamento do lixo que são problemas mundiais.

Tudo estaria bem se as lojas realmente deixassem de usar sacolas plásticas e mudassem para o papel ou o tecido. Assim, ou você leva uma sacola reutilizável (não confundir com renovável) de qualquer material que você quiser ou você sai da loja com as compras não mão. Ora isto seria surreal. As lojas perderiam os clientes de oportunidade. Aqueles que não são clientes habituais e entram por impulso ou necessidade pontual.

A verdade é que as lojas continuarão a ter sacolas disponíveis. Mas por um preço.  A mudança não é na disponibilidade das sacolas plásticas, é no seu preço. Agora você terá que pagar por elas. Ninguém se engane achando que esta é uma atitude ecológica. É uma atitude econômica. Se o cliente tem que pagar pelas sacolas ele será mais cuidadoso a arrumar as compras nas sacolas e não usará uma sacola para cada item como muita gente faz. Além disso o custo da sacola é repassado ao cliente em vez de custar à loja. Basicamente a politica é : Quer uma sacola plástica ? Compre-a.  É bem diferente do que eles querem fazer parecer no marketing que seria “Quer uma sacola plástica ? Não temos. Porque defendemos o meio ambiente. “

Ora, se as lojas continuam tendo sacolas plásticas disponíveis, mas por um preço, então afinal como fica a ecologia ? Onde sempre fica : na carteira. A conclusão a tirar daqui é : você pode usar sacolas plásticas, desde que as compre. Se você pode poluir o mundo, desde que pague.

Mas o problemas não é apenas das lojas de produtos comestíveis. Todas as lojas estão tentando vender suas sacolas reutilizáveis com branding. Branding é uma estratégia em que se associa qualquer produto a uma marca. No caso a marca da loja. Neste espírito livrarias estão adotando a estratégia comercial de vender sacolas reutilizáveis.

Hoje entrei numa livraria cultura, com minha esposa, para comprar alguns livros. De vez em quanto dou uma olhada para ver o que ha na prateleira sobre desenvolvimento. Depois disto decidimos que queriamos comprar algumas sacolas reutilizáveis. Não pela pseudo-preocupação ecológia mas pelo simples fato de ter sacolas rutilizáveis. Pegamos duas sacolas de um modelo mais barato e outra de um modelo mais caro. Quando a moça do caixa passou os produtos o computador mostrou uma com preço diferente. A sacola custava 17 reais e o computador apontava 10 reais. Pelas regras do código do consumidor a loja é obrigada a vender pelo menor preço. Contudo a caixa não queria fazer isso nem consegui explicar porque o preço era diferente. Mas em vez de ativamente resolver o problema disse que tinhamos que falar com um vendedor. Claro que neste ponto já havia uma fila à espera. A loja em questão tem vários caixas no centro da loja em circulo. É simples para os clientes mudarem de fila, mas ninguém fazia isso.  Porque a fila tem que andar, a caixa usou a estratégia de nos mandar com um vendedor para resolver o problema. Dessa forma ela poderia continuar atendendo o resto da fila. Ora, você está sendo lesado pela loja, as pessoas têm opção de ir a outros caixas, porque cair nessa ratoeira. Eu fiquei e a minha esposa caçou um vendedor na multidão. O vendedor informou que se tratava de uma promoção. Porque eramos associados do programa de clientes e tinhamos crédito podiamos levar a sacola por dez reais. Agora o ponto era outro. Como saber se essa promoção realmente existe ou é uma desculpa para a divergência de preços ? Perguntamos então sobre onde está publicada a promoção. Toda a promoção tem que ser publica, ou seja, deve haver um cartaz um informativo qualquer e algum documento sobre as regras. Esta simples questão levou o vendedor a pedir que uma terceira pessoa – que se apresentou como a gerente – a intervir. A gerente repetiu o mesmo discurso do vendedor. Peguntamos pelo regulamento. Ela foi buscar. Esperamos. Enquanto esperávamos a fila estava travada e as pessoas começaram a mudar de fila. Claro que zangados. Connosco! Como se a culpa de falta de explicações fosse de quem faz as perguntas. Perguntamos à caixa sobre o exemplar do codigo do consumidor que a loja deve ter disponível para consulta. Queríamos mostrar do que estávamos falando. Não é questão de 7 reais de diferença. É a questão da relação fonecedor-consumidor. Para nossa surpresa ela não tinha um. Uma empresa como a Livraria Cultura, não era de esperar.

A gerente regressa. Sem o documento. Pedindo para irmos com ela a um ponto de consulta de preço. O objetivo é duplo aqui. Primeiro tirar-nos dali e fazer a fila andar. Repare que ninguém está preocupado com o que estamos dizendo, apenas em fazer a fila andar. Por outro lado queria mostrar que o preço padrão era 17. Tentei explicar para ela que eu sabia que o preço era 17 na consulta. Eu tinha feito essa consulta antes. O ponto não era esse. O ponto é que o computador do caixa, dizia um preço menor. A lei diz que tem que ser o menor preço anunciado. Não importa onde. Se é no totem de consulta ou no caixa ,ou num panfleto…

No impasse a gerente perguntou o que queriamos. Dissemos que queríamos compras todas as sacolas pelo menor preço, a menos que nos fosse apresentada a divulgação da promoção. Ela não conseguiu fazer prova da promoção e disse que nunca venderia pelo menor preço e que se não queriamos pagar pelo preço que o computador mostrava, deveriamos ir embora. Assim fizemos. Cancelando a compra. Fazendo uma reclamação por escrito. Finalmente a fila estava livre e andando. Era só esse o objetivo.

Na saida perguntámos ao segurança o nome do gerente. Queriamos aferir se era realmente a pessoa com que falámos. Ele falou para nossa surpresa que não existe um gerente. Que se tivessemos algum problema ele poderia chamar o atendimento ao cliente. Alguns detalhes. Enquanto esperávamos ligamos para dito atendimento. A pessoa estava nos vendo, mas não veio atender ou ver o que era o problema. Ambos vendedor e pseudo-gerente asseguravam que a promoção estava no site da Livraria Cultura. Ao chegar a casa verifiquei que não havia qualquer menção a qualquer promoção e o preço no site era 17 reais.

O maior choque é a falta de transparência. Ninguém sabe de nada. Só importa liberar a fila.E as pessoas afirmar ter cargos que nem existem…

Hoje mesmo na secção de desenvolvimento tinha um livro dobre HTML5. O único da loja. Em péssimo estado. Em qualquer loja competente aquele livro não estaria ali ou seria substituído por um em condições, ou um desconto seria dado. Afinal quem quer gastar dinheiro num livro completamente maltratado ? Perguntei ao vendedor se poderia aranjar outro exemplar ou dar um desconto. O que ele fez? Saiu sob a desculpa que iria ser se era possivel dar um desconto. Voltou dizendo que aquele era  o único exemplar e não havia desconto. Ok. É um direito da loja. E o meu direito é não comprar. Só não precisava de todo o teatro. Bastava dizer que não havia latitude para dar o desconto da primeira vez que perguntei.

Estão vendo o padrão ? Sair de perto do cliente sob a desculpa que vai resolver o problema e voltar sem ter feito nenhum esfoço. Qualquer esfoço. Nada. E esperar que o cliente tenha mudado de ideias ou tenha ido embora. Afinal o que faz uma livraria ? Vender livros ? Não.

É possível acreditar que empresas que nem saibem cuidar do seu negocio saibam cuidar da ecologia ou sequer saibam o que isso é ? Não. O que é muito fácil de acreditar é que as empresas e lojas de hoje em dia estão preocupadas apenas com lucrar. E lucrar significa vender mais e ter menos custos. Não importa que um cliente foi coagido a sair da loja sem o produto se um 50 outros formavam fila atrás dele.

É isso que me custou tentar comprar uma maldita sacola reutilizável …

Mas a historia não acaba aí. No caminho de casa passei num supermecado da rede Pão de Açucar onde comprei 3 sacolas de melhor qualidade por menor preço (13 reais). Um lugar onde todas as perguntas sobre o evento do dia 25 foram respondidas competentemente pelos funcionários.

Não é esperar muito que sejamos bem tratados como consumidores. Afinal damos um duro danado para ter esse dinheiro para gastar nas lojas. O minimo é que nos tratem bem.

Podem até enganar-nos com um papo ecologista que nos obriga a comprar sacolas reutilizáveis, mas querer fazer de nós estúpidos é pedir de mais. Eles estão se ajudando a si mesmos. A lei só torna isso oficial.

Respeito. É pedir muito ?

Hoje em dia, é quotidiano ouvir falar sobre “verde”. Empresas verdes, produtos verdes, etc… Todos querendo salvar o mundo e natureza dos maus tratos que a humanidade lhe causa.

Sendo educado em ciências isto só por si me causa grande náusea, porque demonstra como a população mundial pode ser tão facilmente enganada pela mídia. Não ha realmente provas que exista realmente um aquecimento global, tal como não havia das causas do buraco do ozônio que todos já esqueceram  mas que ainda permanece lá. Quem existe para dizer que aquele buraco não é natural e sempre esteve ali. As “estatisticas” dizem que o globo está aquecendo cerca de 1ºC por século. Sendo que o termômetro foi inventado 1592 mas apenas no final do seculo XVIII se começaram a fazer medições periódicas na Inglaterra sendo que medição periódica em todo o mundo apenas foi conseguida no seculo XX.  Ou seja, um único século para medir o aumento de um grau por século. É como olhar o termometro durante uma hora e vê-lo subir 1ºC e concluir que a temperatura irá aumentar 1ºC por hora. O que realmente não leva em consideração o fato que essa mesma temperatura poderá não aumentar no período seguinte.

Muita gente ainda acredita que o nível das águas do mar irá aumentar quando os glaciares dos polos derreterem. Como uma experiência bem simples lhe mostrará , o gelo ocupa mais espaço que água liquida, o que significa que quando o gelo se transforma em água, o nível da água diminui. O que significa que o argumento é furado.  O nível da água do mar aumenta devido à dilatação da água e não ao descongelamento dos gelo. Faça a experiência. coloque gelo num copo e encha com água. Marque o nível da água. Espere o gelo derreter e marque de novo. Observe que o nível marcado no final é menor que o anterior.

Pois bem, no meio de toda este manbo-jambo feito para enganar a população a pagar mais pelos produtos , serviços e marcas “verdes” achando que estão salvando o mundo, mas que no fim, estão sendo apenas enganadas do seu dinheiro ha um problema mais grave.

Quantas dessas marcas, produtos ou serviços são manchados pelo trabalho escravo que é utilizado na sua fabricação. Não é  segredo para ninguem que não existem leis trabalhistas em muitos dos países asiáticos e que é exatamente lá que os produtos de marcas famosas são fabricados. Desde marcas de roupa e calçado e marcas de produtos de informática e aparelhos domésticos são fabricados por pessoas em condições de trabalho deploráveis e até por crianças e até de escravidão.

Então , quando você compra um produto e se pergunta se ele é verde e se os seus produtores se procuram com a Natureza , você também se pergunta como aquele produto foi feito e quantas crianças ou escravos o produziram ?

Você se preocupa que o produto é verde, mas não se ele é manchado pelo vermelho do sangue destes injustiçados ?

Porque você acha que o mundo está em uma crise econômica ? Porque milhões de pessoas não têm poder aquisitivo. Pode este que perderam quando as suas funções foram transferidas para pessoas na Ásia que recebem menos, ou mesmo nada e até crianças. E esses mesmos produtos são vendidos mais caro aqui do que antes. As marcas irão negar que empregam crianças ou escravos, mas todos nós sabemos que isso é mentira. Negabilidade significa que se pode negar, não que é mentira.

Os países  do chamado primeiro mundo não podem competir com isto. Não ha como competir com produção de custo zero. A não ser que as pessoas deixem de comprar os produtos produzidos dessa forma. Da mesma forma que se pede o boicote a produtos não-verdes porque ferem o ambiente e o legado que você irá deixar aos seus filhos, também os produtos vermelhos afetam o legado que você irá deixar aos seus filhos. Um mundo onde é licito alguns se aproveitarem da fragilidade dos governos para se utilizarem das pessoas a um nível criminosos, mas o outro lado do mundo não sabe, não enxerga e não quer saber sobre o problema.

Comparativamente queimar pretróleo é muito menos perigoso do que comprar estes produtos de marca manchada.

Você vai ler este texto e até poderá concordar com ele e falar dele aos seus amigos e tentar conscientizará-los do problema que a probreza do terceiro mundo se deve ao consumismo do primeiro e que a crise do primeiro se deve à falta de evolução do terceiro. Ou seja, a desigualdade é o motor para mais desigualdade.

Pessoas se procuram com o ambiente, com o uso de peles de animais roupas, como o uso de animais em testes de laboratório. Tudo isto é licito e importante porque abusar da natureza e de nossos companheiros animais. Mas da mesma forma não podemos abusar dos outros seres humanos. Não o fazemos diretamente  e por isso funciona para eles – os que ganham com isto.

Em vez de se preocupar com um problema “verde” que não existe e que foi desenhado para levar você a gastar mais dinheiro, preocupe-se com um problema real, documentado e existente de não ajudar a criar mais escravos e por mais crianças a trabalhar.

Sim, é possivel doar dinheiro para entidades que se ocupam com estas coisas, tal como é poissivel doar para organizações que se preocupam com o uso de animais para experiencias e vestuário e salvar as baleias. Mas as melhor forma de você ajudar tudo isto é consumir com consciência.

O ser humano consome por natureza é impossivel pará-lo de consumir. Mas consumir com responsabilidade não se limita a proteger os recuros naturais. Incluir em se responsabilizar por proteger vidas e valores morais numa sociedade cada vez mais globalizada. Cada vez menos importa a lingua, o pais e o seu credo e muito mais quais são so seus valores humanos. Esses são internacionalmente entendidos e aceites.

Protega o seu futuro e o de seus filhos e netos se procupando o mal que está fazendo ao mundo comprando produtos que são fabricados em condições precárias de um sub-mundo que só quer seu dinheiro custe a quem custar, desde que não seja a eles.

Se ha criminosos no mundo é apenas porque ha quem compre deles.

O conceito de que o trabalhador “pertence” à empresa leva ao conceito de que se a empresa protege seus bens, então deve proteger seus trabalhadores. Especialmente deve manter os seus salários altos. Por outro lado, leva ao conceito de que a empresa é o conjunto dos seus trabalhadores. Tudo isto são ilusões.

Na realidade o trabalhador é livre para mudar de emprego para outra empresa a qualquer momento, e a empresa é livre de mudar de empregados a qualquer momento. Não existe vinculo exceto aquele condicionado pelo horário de trabalho que, na prática, causa um vinculo de exclusividade, embora na teoria a pessoa é livre de ter quantos trabalhos quiser.

O trabalho é um fator produtivo como qualquer outro. Se uma matéria prima escasseia a empresa irá antever formas de substituir essa matéria prima por outra. O mesmo se aumentar de preço. Se a matéria prima abunda o seu preço é menor porque a concorrência assim o força. O mesmo com o trabalho. Se ha muitos trabalhadores de uma certa especialidade a empresa contrata os mais baratos, se ha poucos, ela tem que competir pelos poucos que ha aumentando o salário. Claro que ao falar em salário me refiro inclusivamente a todos os benefícios que são pagos.

Não existe ponto de equilíbrio. É um processo cíclico constantemente em rotação.

Neste cenário não faz sentido pensar que a pessoa tem alguma chance de permanecer na mesma empresa por muito tempo. É simples. Quando ela acumular um valor que se equiparar ao do mercado ela será substituída. O truque, portanto, é nunca deixar que a massa do mercado chegue nos seus calcanhares. A pessoa tem que se manter acima da média, bem acima, para se manter na posição que ocupa. Por outro lado, em outra empresa, essa mesma posição pode pagar melhor ou ser de alguma forma mais vantajosa. E ai é tempo da pessoa mudar de empresa.

Da mesma forma que as empresas procuram constantemente revitalizar seu quadro, também os trabalhadores  precisam se mover entre as empresas. A idéia de que a pessoa entra no departamento de entregas e depois de um tempo acaba na presidência não advém de um mecanismo interno da empresa, mas sim da constante busca dessa pessoa em se destacar da massa que o rodeia.

Neste sentido, a Carreira Profissional é o conjunto de operações, estudos, e extensões que a pessoa adquire ao longo da vida que lhe permitem se manter acima da massa regular  e não o conjunto de cargos que ocupou numa mesma empresa.

É um erro entrar numa empresa e esperar ficar nela para sempre. Igualmente é um erro sair dela antes de aprender o suficiente. Do ponto de vista da empresa é um erro manter pessoas que não evoluem, mas igualmente é um erro não lhes dar espaço para evoluir.

Acho que a conclusão é : não existe segurança no emprego, então parta do principio que você vai mudar mais cedo ou mais tarde e não que vai ficar ai para sempre.

Sabe-se bem quantos dias tem um determinado ano. Do ponto de vista estrictamente cientifico e fenomenológico o periodo de um ano é o intervalo de tempo  entre duas passagens consecutivas do sol por um determinado ponto pre-defenido da sua órbita aparente. Como o Sol no seu moviemento de revolução aparente em torno da Terra , transcreve uma órbita eliptica, esta é, logo, fechada e periodica.

Este tempo iguala 365.26 dias ( despresando termos de ordem inferior a 0.01) Mas como os humanos nunca se deram bem a tratar de numeros não inteiros achou-se por bem tornar o ano um periodo inteiro de dias ( assim como o mesmo se fez para as horas , pois o periodo de rotação também não é de 24h certas) Assim o ano passou a ter 365 dias exactos e a chamar-se ano civil , pelo facto de ser adequado às contas temporais das pessoas no dia a dia.

Mas para manter uma relação com o tempo verdadeiro da viajem da terra em torno do sol ou o que vai dar ao mesmo ; e naquela época era assim que se considerava ; do sol em torno da terra – achou-se também por bem de 4 em 4 anos civis o ano conter um ano suplementar. Desta forma 0.26 x 4=1.04 onde 0.04 se despresou completamente. Isto explica porquê os anos não são todos iguais. Mas imagine-se a si a fazer todas estas contas à um bom tempo atraz. Onde acrescentaria esse dia ?

Temos 3 hipoteses. No inicio do ano , no meio do ano ou no fim do ano. É nesta altura sensato relembrar que antigamente  o que dava de comer às gentes era a agricultura e toda a sua vida se baseava na fertalização, sementeira , crescimemto e recolha dos produtos. Ora , onde colocariamos esse dia a mais ? Seria um dia para nos divertirmos ou para trabalharmos ? Suponho que um dia de 4 em 4 anos seria suficientemente invulgar para ser de festa. Aceitando isto, se você vivesse no hemisfério norte naquele tempo onde colocaria esse dia  suplememtar?  Provávelmente seria colocado no inicio da primavera ou pelo menos quando o tempo fosse o suficientemente bom para festejar. Mas porquê não no verão ? Bom no verão faz mais calor , e se o frio a mais não é bom para festejar o calor de mais também não é. Portanto seria colocado no inico da primavera. Mas em relação ao ano  seria onde ?

Segundo o calendário de hoje seria no inico , bom mais ou menos , fim do 1º trimestre.E naquela altura ? Faria sentido colocar um dia destes no interior do ano , quebrando o ritmo para “festejar” um dia suplementar ? Acho que não, ainda para mais conhecendo o rigor com que estas coisas do cultivo era seguido. Este aspecto remete-nos para uma descrepância entre o calendário actual e o que parece ter tido lugar antes. Mas não é o unico.

Os dias do mês de fevereiro são ondulantes , ou seja , são 28 ou 29 conforme o ano. Porquê colocar este mês como segundo mês ? Era muito mais logico colocá-lo no fim , ou no inicio. Ainda para mais não é um mês que respeita a regra do 31-30. Supondo que o dia é acrescentado , parece evidente que seria acrescentado no fim dos 28 dias normais. Ou seja Fevereiro ao ser variável por exesso não faria sentido colocá-lo no inicio do ano, mas sim no fim do ano , onde se pode acrescentar. Acrescentar implica , que me lembre , sempre , fazê-lo no fim. Ora sendo assim como é que temos fevereiro como 2º mês do nosso ano ?

Além disso temos mais., existem 2 meses consecutivos com 31 dias; Julho e Agosto. Mas estes meses são consecutivamente o mês 7 e 8 dos 12 do ano. Ora se o ano tem 12 meses e se temos 2 iguais consecutivos não seria mais logico colocá-los como os meses 5 e 6, ou seja, no meio do ano? Uma ultima curiosidade. Os prefixos devem servir para alguma coisa ou não os usariamos , certo ? Supondo que isto é verdade e atendendo aos prefixos comuns como , bi , di ,tri ,hexa , sept , oct , nov, dex reparamos que temos meses que têm estes prefixos :  Se(p)tembro , Ou(c)tubro ,Novembro, Dezembro. Parece então que estes meses deveriam ser os meses 7 ,8 ,9 e 10  e não os 9,10,11 e 12. Em todas esta questões deparamos com sempre 2 meses de diferença ou seja Fevereiro é o 2º em vez do ultimo ( 12=0 ) , julho e agosto são so 7 , 8 em vez de 5 e 6 e por fim os ultimos meses do ano. Como explicar isto ?

A resposta é muito simples. Antes o ano começava, no Equinócio da primavera , o tempo era contado pelas colheitas ( por ciclos de rotação das colheitas , se quiser). Ora o Equinocio de primavera dá-se em Março , 21 de Março. Se fizermos Março como o mês 1 então fevereiro seria o mês 12 ( sendo agora compreensivel ) , julho seria o mês 5 e agosto o mes 6 , sendo também agora possivel estabelecer a relação entre os prefixos e os meses. Se(p)tembro =7 , Ou(c)tubro=8 ,Novembro =9 e Dezembro =10. Esta simples hipotese parece arrumar tudo nos sitios certos. Então porquê a descrepância com o calendário actual ?

Quando se soube que existia uma ordem no movimento aparente de revolução do sol, soube-se que era por esta orbita ser uma elipse e logo se soube também que a Terra estaria num desses focos ( lembre-se que analizamos o movimento do sol , embora aparente , era o usado pelos antigos agricultores. do ponto de vista da seguinte discusão é irrelevante esse promenor , “que o quê gira sobre o quê” ) Assim haveria uma altura em que a distancia Terra-Sol fosse minima ( perigeu) e outra em que fosse máxima (apogeu). Como o Homem sempre gostou do minimo então decidiu-se que o ano seria contado a partir do perigeu e não do equinócio. Esta convenção faz o ano civil começar a 1 de janeiro e não a 21 de março. [ nota: estes dias são assim contados segundo o calendário actual , na realidade os proprios numeros dos dias seriam "renomeados" de 1 de Março para 21 de Março e X de janeiro( 285 dias depois de dia 21 de março ) para 1 de janeiro. ]

Conclusão , foi a mente humana e a sua procura/gosto pela ordem que fez o calendário ser tão anti-natural como o que temos hoje. Compare-se com o antigo e repare-se que o antigo também era ordenado , e bem ordenado. Mais do que ordenado era natural. Correspondia com o calendário de trabalho da maioria das pessoas.   Os meses eram de 31 ou 30 dias com o ultimo mes a variar entre 28 e 29. Os meses do meio tinham os mesmos dias e o ano seguia o ciclo das estações. O de hoje em dia não tem nada disto mas está de acordo com a consideração astronómica do perigeu. Este é o preço do Raciocinio. Se por um lado deixa de ser natural e ter a ver com as nossas vidas, por outro é regido pela ordem que se pode provar e contar e refazer as vezes que forem necessárias.

Quando criei este blog lá em 2007 era para ser apenas um lugar onde pudesse escrever sobre os meus gostos – que são muitos e variados. O “problema“ é que rapidamente o gosto maior tomou conta: o Java.

Eu escolhi me especializar em Java, em tudo o que diz respeito a Java, por razões profissionais, mas se tornou um hobby muito interessante ao ponto de me fazer criar o MiddleHeaven. Através do Java aprendi sobre Orientação a Objetos e mesmo sem os purismos de Smalltak o estreito mapeamento entre a linguagem Java e os conceito de Orientação a Objetos concorrem para que quanto mais se conheça um, mais se aprecie o outro.

Hoje, o meu blog é visitado por milhares de pessoas todos os meses que procuram se educar um pouco mais nestas coisas e aprender a criar aplicações Java melhores, fugir de más práticas e aprender melhores formas de codificar e mapear o mundo real para objetos. Muitos defendem a visão empirista em que através de tentativa e erro se chega a um modelo bom e uma aplicação robusta. O experimentalista em mim  entende essa visão, mas o arquiteto em mim prefere ter menos trabalho criando um modelo mais duradouro. O desafio é grande, mas a recompensa será maior.

Só que, há um problema com esta visão. Os consumidores de software coorporativo, ao contrário dos consumidores caseiros, não sabem o que procurar em um software, não sabem avaliar a sua qualidade. E o pior é que nem os desenvolvedores sabem avaliar essa qualidade. Ela é intangível, imensurável. Contudo, ela não é subjetiva. Existe sim o bom e o mau. O Padrão e o Anti-Padrão, o crédito e o débito técnico.  O problema que eu vejo é que tanto desenvolvedores, quanto os donos de empresas que produzem software, quanto os consumidores desse software adoram gastar rios de dinheiro e ampulhetas de tempo em gambiarra, mas não dão o braço a torcer para procurar qualidade, diminuição de custo, mais-valia. A culpa do débito técnico sobre a recompensa do crédito técnico. Sentimento de utilidade para quem compra e sentimento de orgulho para quem vende.

É por isso que no ultimo mês coloquei na prática os alicerces de uma idéia que há muito estava na minha cabeça. São os primeiros tijolos para um espaço que levará as pessoas a produzir melhor software de forma mais barata, sem gambiarra, sem prejuízo para a saúde mental, emocional ou moral de ninguém e que os cliente sintam vontade de usar e evoluir.  Um portal que ajude a explicar o que é um produto software, como se faz e por que se faz assim. Tecnologias, Práticas, Regras, Teorias, Tutoriais e, espero, muitos exemplos rodando no seu navegador e no seu desktop que comprovem  que isto é possível e ajudem a enterrar as velhas práticas da Era da Pedra ( do cartão ? ) da produção de software como um bem.

Este empreendimento é maior que eu. É maior que um só blog. É necessário um lugar  com mais recuros e menos limitativo que estas fronteiras, onde esta ideia possa ser discutida, aperfeiçoada, exemplificada. É um novo edifício. Hoje ainda com poucos cômodos, mas que logo crescerá. O céu é o limite. A nova casa para o desenvolvimento de aplicações com Java: www.javabuilding.com

Ora, esta ideia, em si mesma é que é a grande fantochada. Alguns objetos são simplesmente um saco de propriedades e não há nada que possamos fazer contra isso. Embutir artificialmente métodos nesses objetos só para que pareça que eles fazem alguma coisa é simplesmente errado. Ao tentar fugir dos fantoches criam-se monstros piores.

O Principio de Separação de Responsabilidade pede que cada objeto tenha apenas uma responsabilidade. Se a responsabilidade do objeto é apenas ser um saco de propriedades, então que seja. Exigir dele mais do que isso é violar o Principio de Separação de Responsabilidade por querer colocar no objeto coisas que ele não sabe fazer ou não pode fazer.

Um  exemplo clássico do que estou falando é o objeto Usuario. Muitos gostam de colocar um mudarSenha(String senhaAntiga,  String senhaNova). Já vi isto várias vezes. Dois erros:

1. Porque precisa da senha antiga? O usuário já tem um getSenha que é esse valor. O argumento é que o usuário real tem que saber a senha atual e portanto senhaAntiga tem que bater com o valor em getSenha(). E o que acontece quando não base certo? Lança exception? E se eu não quiser fazer isso?
   Conclusão: é uma decisão que pode ter várias estratégias conforme quem decide, quando e onde. Não ha uma resposta possivel única. Logo, isso deve ser isolado em outro objeto.
2. Quem muda a senha do usuário? A aplicação. Certo? Não é o próprio usuário que realmente muda a senha. É sempre alguém que o faz por ele. Esse alguem não é o usuário, logo, isso não é responsabilidade da classe usuário. É responsabilidade de um outro agente do sistema, outro objeto.

Outro é o uso do pseudo-ActiveRecord. Por alguma razão que me escapa ao entendimento muitos acham que  ter um método save() no proprio objeto que está sendo guardado, é  uma excelente ideia.  Pode até ser, se for bem implementado. Isso é a essência do padrão ActiveRecord. Só que o ActiveRecord tem contra indicações. Ele não é recomendado para sistemas grandes. Certo. Agora vai dizer que o seu sistema não é grande e portanto você pode usar o ActiveRecord. O sistema pode parecer pequeno agora, mas deixe passar um tempo e verá. ActiveRecord é bom para protótipos que vão – com certeza – ser jogados no lixo. Mas aceitemos que para o seu caso ActiveRecord é uma boa ideia; ai ,muita gente faz assim :


public class ObjectQualquer {

DAO daoObjectoQqualquer;

public void save(){
daoObjectoQualquer.save(this);
}
}

Não vou nem entrar no mérito se deve usar DAO ou Repositorio (para ActiveRecord é DAO mesmo) mas esse código é o exemplo de como é fácil associar responsabilidades aos objetos que eles não têm. Como sei isso? Porque o objeto simplesmente delega a outro. Sem alterar nada, sem produzir nenhum outro efeito. Depois vêm perguntar: “Como injeto o DAO neste objeto?” a resposta é “Porque raios você tem esse objeto ai para começo de conversa?!” É muito difícil chama o DAO apenas quando ele é necessário? Que raio de preguiça é essa?

Não é perguiça. É a falsa noção de que os objetos têm que ter métodos diferentes de get/set. E ai as coisas mais absurdas são feitas para atingir esse objetivo.

Um objecto é composto por três coisas: estado, comportamento e responsabilidade. Responsabilidade é o que os outros objetos esperam que ele faça. Comportamento é como esses objetos pedem que isso seja feito e estado é a forma que o objeto tem de “memorizar” o que fez.

A responsabilidade deve ser apenas uma. Isso é obvio. Quanto mesmos responsabilidade mais simples é o objeto. Lembre-se disto. O comportamento é um contrato publico. É algo do tipo : “quando chamarem por  desta maneira farei este trabalho, desta forma.” Isto não necessariamente significa que existe um método especifico que traduz o comportamento, mas sim que ha um contrato que é acessível por meio de um método. Por exemplo, ArrayList e CopyOnWriteArrayList têm comportamentos diferentes, embora as sua interface (o conjunto de métodos) seja a mesma.

Ao definir um objeto primeiro você define a sua responsabilidade: “Este é o objeto que é responsável por … “, depois como ele vai possibilitar essa responsabildiade. Só quando você o implementa é que você precisa de pensar no estado do objeto.

Mas e os objetos cuja responsabilidade é apenas portar dados? O comportamento deles é dar acesso aos dados e o estado deles são os dados (ou representações dos dados).

Tomemos como exemplo o objeto String. Ele porta dados (caracteres) e tem estado (um array de char) que representa esses dados.  Pronto. Preciso colocar um save() nele só porque ele vai ser gravado em banco de dados? Não. A responsabilidade de String é muito simples: portar caracteres. String é talvez o objeto mais manipulado em Java. Isso, com certeza, não faz dele um objeto fantoche. Então porque o meu TipoProduto que só contém uma String com o nome do tipo e um inteiro com um código para o tipo é um fantoche ? Não é.

Todo este delirio quixotesco de ver objetos fantoche onde só existem objetos simples e incólumes advém de um má interpretação daquilo que significa “comportamento” em um objeto. A mensagem original é muito simples e se prende com outra caracteristica do design orientado a objetos : inversão de controle.  A ideia é o seguinte : não deixe para os outros o que você pode fazer. Um objeto string pode informar quantos caracteres guarda. Isso é trivial, porquê delegar isso a outro objeto? Um objeto String pode informar qual é o caracter que está na posição n da cadeia. Por que delegar isso a outro objeto?

Existem comportamentos que são naturalmente associáveis com a responsabilidade do objeto e por isso o objeto ganha essas sub-responsabilidades. Isto é feito , não porque o Principio de Separação de Responsabilidade é fraco, mas sim porque ele é forte. Se deixassemos outro objeto nos informar de, por exemplo, o tamanho da String, teriamos um objeto com um metodo  objectoX.length(String s). Quando um objeto Y precisasses saber o tamnho da String ele teria que chamar X. Isso cria um acomplamento artificial entre X e Y. Então , atribuindo a responsabilidade ao String esse acoplamento não existe mais. Contudo, isto não significa que os métodos sempre devem ser transportados para o objeto que contém os dados.  O comportamento do método têm que ser natural à responsabilidade principal do objeto.

Um contra exemplo para mostrar isto é o objeto Date. Ele contém uma data. Se eu quiser saber a idade de uma pessoa eu preciso saber a data do seu nascimento. A primeira aproximação seria fazer calculaIdade(Date dataPessoa) e seguindo o exemplo atrás você poderia ser tentado a fazer dataPessoa.calculaIdade(). Ai você bateria de frente com o fato do Java não lhe permitir criar métodos novos em classes existentes e a sua conclusão seria que java é uma porcaria de linguagem e você migraria para ruby onde isso é possível.  Coitado do Java. Na realidade é você que é um péssimo designer. A idade é da Pessoa e não da data de nascimento. O método seria calculaIdade(Pessoa pessoa). E pessoa tem um atributo público que informa a data de nascimento. Claro que a idade é algo que depende de quando fazemos a pergunta. Então precisamos de mais uma informação que é a data atual: calculaIdade(Pessoa pessoa, Date atual)

Utilizando o método acima poderiamos pensar em fazer Pessoa.calculaIdade(Date atual). Seria isso certo? Pessoas podem calcular as suas idades?  Podem.

Animais não sabem calcular as suas idades. Significa isso que Cao.calculaIdade(Date atual) é errado? Não.
Por muito que você goste de abstrair o mundo em objetos e o princípio de separação de reponsabilidade tenha que ser cumprido, ele se aplica a Objectos e não a coisas do mundo. Então, embora um cão não saiba calcular a sua idade, o objecto Cao não É o cão. Ele é uma abstração humana daquilo que um cão É. Portanto, o objeto pode conter responsabilidades que um humano entenderia para o objeto e não as responsabilidades que o ente real, realmente tem. Ou seja, em termos simples: um objeto pode ter mais responsabilidades/comportamentos  que a sua contraparte real.

A mensagem é que diminua ao máximo o acoplamento atribuindo comportamentos naturais aos objetos que já tem no seu modelo. Sim, poderiamos pensar que um comportamento como “capitalize” (coloca todos os caracteres do principio das palavras em maiuscula) é um comportamento natural de um String. E ai você irá xingar o Java de novo por não lhe permitir adicionar esse comportamento. Mas será mesmo que é isso?

Não será que na realidade isso seria o comportamento esperado para um Texto? Ou mais especificamente ainda, para um Titulo? Qual é a diferença entre formatar um data para um String com certo padrão e formater um String para outra String com um certo padrão. Não será que na realidade Capitalize é a responsabilidade de um objeto de formatação?

Não existe uma única resposta para um design. É por isso que se chama design (desenho). Cada um descreve de uma forma. E sim, existe a corrente do Realismos (os objetos são as coisas), do Impressionismo (os objetos parecem as coisas) e até do Cubismo (todos os objetos são cúbicos). Da designer tem o seu estilo, e se funciona não está muito mal. Só que um design não “corre”. Ele funciona abstratamente e não no CPU. Um design que funciona (que é funcional) é aquele com baixa manutenção. E baixa manutenção envolve várias coisas além de gosto artistico por um estilo. Envolve decidir e fazer trade-off de muitas coisas simultaneamente. Se você não tem um estilo artistico de design, pelo menos conheça e use as tecnicas dos designers profissionais.

A proliferação de objetos do tipo bean (apenas como get/set) não é uma questão  derivada de mau design. Ela acontece porque esta é a forma padronizada que criar objectos que são sacos de propriedades (PropertyBag). Muitas outras formas existiriam: como usar Map ou criar uma classe PropertyBag. Contudo, classes genéricas como essas tirariam poder de abstração que é tão importante e pior que isso, tirariam tipagem forte. Repare que fazer bean.getNome() é muito mais forte e refactorável que propertyBag.get(“nome”). O uso de Strings é desaconselhado e por isso o uso de beans é tão comum. Contudo, sempre que o bean puder provêr comportamente extra que lhe seja natural, deve fazê-lo e não delegar isso para outro objeto (normalmente apenas com métodos estáticos). A palavra chave é puder. Às vezes ele quer, e até parece natural, mas ele não pode.

Não há problema nenhum em que um objeto só seja um bean com os seus get/set se isso é realmente o que ele deve ser. O problema real é você ter objetos (classes) apenas com métodos estáticos que fazem operações sobre objetos que um deles poderia fazer sozinho. Essa delegação excessiva é que é realmente o problema, ou colocar sempre os get/set sem pensar se é esse o comportamento esperado/necessário daquele objeto.

Não lutemos então contra fantoches  ou fantasmas anoréxicos que só existem na nossa cabeça.  Alguns objetos são realmente simples e com uma só responsabilidade e poucos comportamentos. Tão poucos que a única grande responsabilidade é guardar dados e prover acesso a essa memória.

Acho que muita gente não entendeu que o J em JVM significa Java. O que quero dizer com isto é que a JVM foi feita para correr Java. Ok, ela foi feita para correr Java Bytecode, mas no fim existe uma estreita relação entre a linguagem Java, o bytecode e a JVM.

Muitos dos avanços da plataforma desde a versão 1.5 vieram da generalidade do bytecode face à linguagem que por exemplo, aceita coisas como herança múltipla que a linguagem não aceita. Mas muitos outros vieram de truques de compilação em que o compilador aceita sintaxes diferentes e as compila para o mesmo bytecode de sempre.

As novas linguagens da JVM como Groovy e Scala desenvolveram compiladores que compilam para o mesmo bytecode mas devido à falta de alguns construtos na JVM estas linguagens precisam usar de alguma magia para que tudo funcione perfeitamente.

Pois bem, a solução óbvia é incrementar a JVM e o bytecode com novos construtos necessários a estas linguagens : invocação dinâmica, tail call, continuations, etc..

O ponto é que, devido à estreita relação entre a JVM e a linguagem Java , o Java tem a oportunidade de absorver estas novas capacidades. É claro que mesmo a JVM as tendo a linguagem não é obrigada a ter, mas não há razão para que não possa. Tudo parece se resumir a gostos políticos e a indecisão às interjeições que estão acontecendo com a venda da Sun à Oracle.

O futuro da JVM é bem claro. Ela tem que evoluir para suportar mais linguagens que Java. É o mesmo tipo de evolução da VM .NET cuja tecnologia não está nem perto da JVM mas suporta várias linguagens.

O futuro da linguagem Java pode não incluir modificações a curto prazo, mas não há razão para não o fazer e várias para fazer. A razão principal para as fazer é tornar a linguagem Java a como a linguagem base para JVM da mesma forma que o C é a base para as máquinas não-virtuais.  Da mesma forma que o Java e outras linguagens utilizam o C para comunicar com máquina real, linguagens na plataforma java utilizarão o Java para comunicar com a JVM.  Tudo isto de forma tão encapsulada quanto a comunicação do Java com a JVM.

O Java 7 pode conter um monte de pequenos acertos na linguagem escrita que se compilarão para o mesmo bytecode. Açucar sintático (sintax sugar) é como se chama a isto. Coisas como inferência de tipos genéricos em declarações ou acesso a listas como a sintaxe de arrays. Tudo isto interessante e desenhado para minimizar a escrita pelo programador. Contudo acertos no nivem baixo serão poucos. A invocação dinâmica que estará presente – ao que tudo indica – não será suficiente a longo prazo, mas já quebra o galho de muitas as linguagens da JVM como Groovy.

O precisamos entender é que Java sempre estará presente mesmo quando outras linguagens tomarem o pódio na JVM. Se, por exemplo, Scala, se tornar a linguagem mais utilizada sobre a JVM, ainda assim o pessoal que implementa,  e especialmente que estende essa linguagem, terá que o fazer usando Java. Java passa assim a ser a linguagem de baixo nível que a JVM aceita como par. É como a Common Language Runtime do .NET ou o C da programação para máquinas físicas. É o esperanto da JVM que todas as novas linguagens terão que saber falar.

Esta realidade não apenas significa que o Java não está morto, como o seu uso será cada vez mais especializado. Enquanto a maioria dos mortais usa Scala, Groovy , Fortress ou outra linguagem sobre a JVM, extensões serão feitas nessas linguagens por uma minoria programando em Java. Além disso novas linguagens serão criadas com Java sobre a JVM.

O uso do Java pelas massas poderá diminuir  tal como C diminuiu, e outras linguagens mais produtivas virão. Mas Java continuará lá sendo o C da JVM , sendo o C para das novas linguagens. Você poderá fugir de utilizar java no dia a dia, mas não poderá dizer que java morreu da mesma forma que hoje a JVM existe porque é construída com C.

Dito de outra forma, você pode escolher outra linguagem e abandonar a linguagem Java, mas não poderá fugir de usar a JVM e toda a plataforma que já existe.

Uma ótima apresentação pelo Niel Gafter chega , eu acho, nesta mesma conclusão.

Como epílogo podemos concluir que utilizar alguma plataforma fora JVM é um risco. As grandes apostas e os grandes apostadores  estão sobre o Java. Se a Oracle não pisar na bola, continuará assim. Do outro lado, temos cada um apostando no seu cavalo e isso não poderá chegar perto da evolução da JVM a curto prazo. Utilizar linguagens fora da JVM  é um risco e até linguagens como PHP , Pytohn e Ruby estão vindo para a JVM. É uma questão de tempo até que as funcionalidades dessas linguagem vazem para a linguagem Java.

Para resolver isso, vários paradigmas foram criados buscando transmitir à máquina as intenções do ser humano. O mais vantajoso até hoje é o paradigma da linguagem de programação.

Programar significa utilizar uma certa linguagem para transmitir uma série de instruções ao computador. O ser humano escreve com símbolos que ele entende – palavras e símbolos textuais – e isso é transformado para o símbolos que a máquina entende através de um programa chamado compilador. Sim, você pensou certo. Se o compilador é um software, e um software é criado com um compilador, como se criou o primeiro compilador?

Parece uma charada mas não é. Acontece que existem diferentes níveis de linguagem. Linguagens de alto nível e de nível máquina ( “baixo nível” não se diz porque é feio). Os primeiros compiladores eram escritos em linguagens de nível máquina com os quais se criaram compiladores de nível mais alto e assim sucessivamente até linguagens de alto nivel como Java, C++ ou C#. O paradigma orientado a objetos é atualmente o paradigma das linguagens mais flexível e difundido, já que nele é possivel montar linguagens com outros paradigmas (procedural, funcional, etc) sem perda de generalidade.

Bom, temos uma linguagem. Toda a linguagem escrita tem um semântica e uma sintaxe. As de programação também têm. E toda a escrita é redigida por alguém.  No mundo editorial quem escreve é redator, mas no mundo do software, quem escreve para máquinas é programador. O texto que o programador escreve é chamado “código” (alguns chamam de código fonte, do inglês “source code“) para transmitir a ideia que é meio críptico e muito “secreto”.

Mas então qualquer um que escreve código é um programador? Tecnicamente sim, mas na realidade isso não diz muito sobre o que a pessoa faz ou sabe fazer. É como dizer que todos os autores de best sellers sabem escrever. Isso é verdade, mas não significa nada de útil. É uma tautologia se pensarmos bem.

O que é interessante para o mundo do software não é que a pessoa saiba escreve código,  o interessante é que a pessoa escreva bom código. Da mesma forma que autores escrevem bons livros. Para isso é preciso uma capacidade técnica maior que simplesmente escrever palavras. O programador é para o código o que um autor é para um livro e não apenas um redator. Bom, pelo menos um (bom) programador aspira a ser um autor e não um redator.

Da mesma forma que na língua portuguesa também nas linguagens de programação uma instrução pode ser escrita de várias formas. Umas mais claras que outras. E enquanto qualquer frase minimamente representativa da ideia basta para a pessoa comum, não basta para o autor que quer tirar o maior partido das palavras que pode usar para escrever em menos espaço o maior número de ideias. Mas também existe um limite. Ser conciso demais pode levar à confusão do leitor médio. Um autor não escreve para si, escreve para  os demais, para ser lido, já que o objetivo ultimo é vender livros difundir as suas ideias.

O programador sofre do mesmo problema. A linguagem até pode permitir que ele escreva mais em menos palavras, mas nem sempre isso é a melhor forma para quem lê. A variedade C de linguagens é conhecida por permitir uma ampla gama de formas de escrita – bastante crípticas, por sinal. E Java permite que tudo seja escrito usando códigos Unicode como \u0002 … Lá porque você escreve dessa forma, não significa que o deva. Essa é a diferença entre um autor e um redator. Essa é a diferença entre um escritor de código e um programador.

Mas saber escrever não é apenas colocar palavras juntas. Existe mais. Existe conhecer as palavras em si mesmas, as regras da linguagem (como escrever corretamente) e  conhecer a semântica da linguagem (o que as palavras significam). Para programadores isso significa saber o que cada palavra reservada faz, assim como as bibliotecas padrão que acompanham a linguagem.  Estas bibliotecas são como dicionários de palavras novas que podem ser (re)utilizadas a cada momento para enriquecer o texto.

Muitas linguagens, poucas palavras

Quando você aprende a falar e a escrever, normalmente, você aprende a língua de seus educadores, que por extensão é a língua do seu país. A sua língua natural. Também quando você programa você começa por aprender uma linguagem. A diferença é que essa, ainda não é, a sua linguagem natural.

Durante a vida do programador ele aprende muitas linguagens da mesma forma que aprendemos muita línguas. Afinal, traduções são limitadas, em si mesmas, na riqueza de transmitir o pensamento (as instruções) do autor, e ler o original, na lingua originalmente pensada para transmitir a mensagem, é sempre uma experiência mais rica. O programador passa por um tempo de busca da sua linguagem natural. Aquela que ele entende e é proficiente sem esforço. Imagine um prêmio nobel da literatura escrevendo em outra língua que não a sua.  Não é simples atingir o mesmo nível de intimidade com todas a linguagens. O programador descobre isso com o tempo.

Pensemos que você decide aprender todas as línguas faladas na Europa. Parece simples. Você até é capaz de agradecer e perguntar as horas em todas elas, mas você consegue manter uma conversa longa em todas elas. sem parecer um idiota?

Parecer um nativo é impossível. Você tem que ser um nativo para falar e escrever nativamente.  É um erro a pessoa pensar que pode aprender uma lingua/gem por tradução daquela que já conhece. Isso dá para o básico, não para o avançado, muito menos para o extraordinário.

Assim, quantas mais linguagens, menos palavras. Em termos de software, você pode conhecer muitas linguagens e fazer o básico em todas elas, mas só será proficiente em algumas e só será intimo com uma ou duas. É uma regra natural, seu cérebro não aguenta saber tudo todo o tempo.

O programador tem então três caminhos. Ser um autor memorável em uma linguagem, ser um “zé-ninguém” em todas ou ser um “meia-boca” em meia dúzia.

Profissionalmente você não ganhará bom dinheiro sendo autor memorável em uma linguagem nem “zé-ninguém” em todas. Você ganhará dinheiro sendo proeficiente em uma ou duas e se desenvolver com uma ou duas (o que é desenvolver é assunto para outro post). Ou seja, você acaba deixando de ser autor no meio do caminho para passar a ser editor, revisor,  professor ou dono de uma editora. É uma mudança de carreira, mas uma necessária nos dias de hoje (um pequeno segredo: ninguém quer realmente pagar para alguém escrever código bem. O mercado, hoje, está preocupado em escrever depressa. Não bem.)

O programador pode evoluir em amplitude ou em profundidade, mas não em ambos. É demasiado extenuante. O “problema” é que para evoluir ele precisa aprender pelo menos uma linguagem em profundidade.

Bom, então se o caminho profissional natural do programador é deixar de ser programador,  se ele se dispersa em várias linguagens, nunca será ninguem no mundo do software ?  Sim. Se você ficar perseguindo linguagens novas todos os dias acabará acordando – tarde – para o fato que não está em lugar algum. Como o andarilho que percorre e conhece todos os caminhos, mas  não onde voltar depois da caminhada. Pelo contrário, se você seguir uma ou duas linguagens, você atingirá o nível necessário para passar ao próximo nivel: desenvolvedor.

Não há vergonha nenhuma em você ser um bom programador em duas linguagens e excelente em uma delas.  Aliás, deveria se sentir dignificado com isso, já que é raro.  Mas é como o cara que saber fazer contas de cabeça com 1000 algarismos e de trás para frente: assombroso, mas ninguém pagará você para fazer isso. (Bom, quase ninguém. Se você for louco talentoso o suficiente para fazer isso, alguem pagará.)

Quando uma pessoa é inciada no mundo do software espera-se que saiba programar. O famoso “programador júnior”. O que ele sabe é escrever código. Não programar. Porque normalmente ele não entende o que escreve e não escreve coisa intelegível. Mesmo que funcione, ele não sabe por onde começar na hora de alterar ou re-escrever em outro lugar. É natural. Afinal todos tivemos que saber o alfabeto antes de saber escrever o nosso nome. O problema é que com tantas linguagens por aí é fácil a pessoa se frustrar e constantemente mudar de rumo. Saberá muitas linguagens, mas saberá dizer pouco.

Se você se apresenta como programador,  pergunte-se: eu sei realmente escrever bem? Os outros entendem meu código sem eu explicar? Estou seguindo as regras? Sei escolher as instruções e API certas ?

Sem saber , você pode ser um “zé-ninguém” em todas as linguagens ou um “meia-boca” na meia duzia com que se cruzou até hoje. E você, ainda, acha que é programador?

]]> http://sergiotaborda.wordpress.com/2009/07/23/e-voce-acha-que-e-programador/feed/ 20 sergiotaborda http://sergiotaborda.wordpress.com/2009/07/04/de-senior-a-gerente/ http://sergiotaborda.wordpress.com/2009/07/04/de-senior-a-gerente/#comments Sat, 04 Jul 2009 12:55:06 +0000 sergiotaborda http://sergiotaborda.wordpress.com/?p=614 ]]> Se você é desenvolvedor a algum tempo com certeza já se deparou com a questão da promoção de sênior a gerente. Por algumas razões que iremos analisar as pessoas não só aceitam este fato como esperam por ele.

Não é incomum durante uma entrevista perguntar para o candidato a uma vaga de desenvolvedor onde ele se vê daqui a 5 – 10 anos, e a resposta costuma ser “como gerente”. A razão para isso é simples: dinheiro. Historicamente a pessoa na posição de Gerente ganha mais que a pessoa na posição de desenvolvedor, seja qual for a sua classificação ou maturidade. Mas esse, espante-se, não é o único fator. A chamada da sereia do poder é prazerosa.

As empresas acham que promover a pessoa de desenvolvedor sênior para gerente é uma coisa boa. Não é. E as pessoas na sua extrema visão curta só enxergam essa opção.  Não é segredo que todos queremos ganhar mais, então quando a pessoa diz que quer ser gerente o que ele está dizendo, na verdade, é que quer mais dinheiro. Nesse ponto eu desclassifico o candidato já que ele ainda não deixou de ser júnior e já quer ficar mandando nos outros.

Por razões que o tempo conhece as empresas se habituaram a pensar que criar software é dificil e que a probabilidade do projeto de software dar errado é grande. Portanto, os diretores que não querem ver o seu na reta adotam a política de: 1) por um lado criar bodes expiatórios na pessoa do gerente. Se o projeto der errado eles serão culpabilizados e o diretor manterá o seu emprego; 2) é preciso microcontrolar tudo o que os desenvolvedores fazem para que assim não existam imprevistos e não existam atrasos.

O curioso é que são exatamente essas medidas de “contingência” que fazem o projeto atrasar.

O resultado é que em uma hierarquia de um diretor de produção de software é comum existirem vários “gerentes”, os quais tentam microcontrolar a equipe de desenvolvimento. A pessoa no papel de gerente  rapidamente  sacrifica os membros  da equipe para manter um salário um pouco melhor que eles sendo que ele seria incapaz de realizar o mesmo trabalho. A imagem do feitor de escravos me vem à mente.  O pior de tudo nem sequer é isso. O pior de tudo é que, normalmente, a pessoa na posição de gerente não tem capacidade técnica nem política para desempenhar esse papel. Sim, a pessoa foi desenvolvedor sênior 20 anos atrás. Isso não lhe dá conhecimento nenhum sobre como o software é feito hoje.  Não apenas a linguagem e o paradigma utilizado hoje são diferentes, como também as técnicas e ferramentas em volta (uso de repositório de código, por exemplo). Quanto mais cedo a pessoa passou de sênior a gerente mais óbvio é este fato, no limite absurdo de comparar, por exemplo, a plataforma Java com linguagens como Clipper, Delphi ou VisualBasic. Você já reparou como o seu gerente reduz tudo a operações no banco de dados e desconhece o conceito de “Servidor de Aplicação” ou o confunde com “servidor web” ?

Quanto à parte política, a pessoa na posição de gerente não tem qualquer escruplo ou vergonha em pedir ao desenvolvedor para trabalhar extra para manter o (famoso) cronograma. Mas  peraí! Não é o gerente que criou o cronograma? Se houver atraso não é responsabilidade dele? Infelizmente no mundo atual não. Nada nunca é responsabilidade do gerente e ele faz de tudo para que assim não seja. O clássico é pedir que os desenvolvedores estimem o cronograma. Ele pede que “estimem” mas o que ele quer dizer é “assinem com sangue um chute de quanto tempo vai ser necessário”. Depois o gerente faz a seguinte conta: se a “estimativa” é X então como temos N desenvolvedores vai demorar X/N tempo. A estimativa … quer dizer, a corda no pescoço da equipe de escra… desenvolvedores ficou ainda mais apertada. Nestas condições totalmente indecentes a equipa tem zero motivação , zero ajuda, zero autoridade, total responsabilidade e lá para quando faltarem dois meses para o final do prazo do cronograma fajuto a equipa ainda passa a ser chicoteada diariamente com a pergunta “Quantos porcento falta para estar pronto?”. O que revela que a pessoa no lugar de gerente não sabe o estado das coisas, ou seja, ela esteve fazendo o quê enquanto os desenvolvedores criavam o software? Esperaria-se que estivesse exatamente calculando quanto tempo falta. Certo ?

O diretor (a pessoa hierarquicamente acima do gerente e que o contratou como bode expiatório profissional) não se preocupa com a performance do gerente. Apenas com a da equipe. Afinal todos os males advém da equipe de desenvolvedores. Esses seres abjetos que o diretor é obrigado a tolerar para poder vender alguma coisa a alguém. Ao diretor tanto lhe faz se o gerente explora os desenvolvedores da mesma forma que o senhor lhe importa um pepino que o feitor chicoteie os seus escravos. Não só isso, como o diretor espera que o gerente aja assim.  Tanto isso é verdade que em empresas maiores (leia-se “com mais níveis de isolamento dos seres abjetos da equipe”) existem uma camada de gerentes. O diretor delega para N gerentes, cada um deles delega para M outros gerentes, que delegam a outros … em um cadeia até que se chega no gerente que controla a equipe. Vejam bem o estado da coisa. O gerente não serve para gerenciar o projeto. Não. Isso é fácil, qualquer excel ou project pode fazer isso. O gerente serve para controlar a equipe em uma mistura de babysiter com capataz e a empresa é tanto maior quanto mais gerentes forem controlados por outros gerentes.

Quantos “gerentes” estão acima de si na sua empresa? Dito de outra forma, quantas pessoas podem vir chateá-lo na sua mesa com exigências para ontem ?

Take Our Poll

Parece então óbvio porque um desenvolvedor quer virar gerente: 1) mais dinheiro no fim do mês; 2) menor ou nenhuma responsabilidade sobre o projeto ou o software; 3) direitos de fustigar a equipe como e quanto quiser; 4) receber todos os louros dos superiores quando o projeto dá certo; e 5) nunca ser “castigado” por nada.

Parece muito melhor que a vida de um desenvolvedor que 1) ganha pouco para aquilo que faz e a responsabilidade que tem; 2) tem toda a responsabilidade sobre o resultado mas nenhum autoridade para guiar o processo; 3) é interrompido a todo o momento com perguntas idiotas que não são da sua responsabilidade responder como “Quantos porcento do projeto já está completo?” 4) nunca recebe o agradecimento real de ninguém nem o reconhecimento real do esforço (eu disse real e não aquele tapinha nas costas ou aquele e-mail de agradecimento modelo B) e 5) é sempre “castigado” por tudo no limite de ser despedido por justa causa por erros cometidos pelo gerente, pelo diretor ou até pelo erro estratégico da empresa como um todo.

Se você teve estômago para ler até aqui, parabéns. Vejamos agora um pouco do outro lado. Afinal, nem todo o mundo é mentecapto e alguma pessoas querem realmente ganhar dinheiro a sério e não apenas para pagar as contas. Qualquer economista, por muito ruim que seja, sabe que uma forma de ganhar mais é gastar menos. É fácil gastar menos com desenvolvimento de software.

Primeiro, foque no que dá dinheiro. No caso do software o que dá dinheiro é o software, funcional e entregue. Muito importante o entregue. Segundo, desenvolvedores são pessoas com educação superior e qualificadas a resolver problemas lógicos e matemáticos complexos. Não os trate como animais de curral. Converse com eles e ouça o que eles dizem. Melhor que ninguém eles sabem quais são os problemas com o software. E ninguém melhor que ele sabe como traduzir o que é esperado pelo mercado em código. Eles podem ajudá-lo não apenas a resolver problemas técnicos mas até problemas que impactaram na venda do software ou na aceitação pelo público. O seu foco é fazer software, então dê recursos aos desenvolvedores para o fazerem. O foco da empresa é o software e todos devem ajudar a conseguir que ele seja feito nas melhores condições de mercado possíveis.  Simplifique os processos. Coloque no lixo a hierarquia militar de passar ordens entre níveis.  Muita informação se perde dessa forma quando o assunto é complexo como um software. Pode até funcionar para a guerra onde as ordens são simples, mas não numa empresa de software.  Uma muito boa forma de conseguir isto com facilidade, sem gastar dinheiro e com um retorno imediato é substituir todos os que se dizem gerentes por desenvolvedores sênior (realmente sênior e não apenas júniors disfarçados). Implementar Scrum também não é má ideia, mas se você tem um outro processo que realmente funciona para a sua empresa (eu disse, realmente - o que significa que todo o mundo na empresa acha que funciona) então mantenha esse.

Implemente um mecanismo de carreira. Não separe os desenvolvedores por anos de trabalho  e sim preveja que todos têm mais do que uma habilidade. Não é desmérito para ninguém só saber programar bem. Saber escrever código limpo, bem estruturado, que aproveita ao máximo as funcionalidades da linguagem não é pecado. Nem todos têm  de ser arquitetos. Não é desmérito para ninguém ser um bom tester que sabe escrever testes automáticos com boa cobertura.

A vida de um desenvolvedor têm várias partes e não são: júnior , sênior, gerente. São: programador, engenheiro,  tester, designer, analista e arquiteto. E isto não é uma sequência. Cada um pode ser mais do que uma coisa. Aliás tem que ser mais do que uma. Existe o básico que é ser programador (saber programar não é suficiente) e existe o complexo: analise é uma tarefa ao mesmo tempo técnica, interpessoal e até política onde poucos engenheiros e arquitetos se sentem bem. Moral da história, monte uma equipe multidisciplinar sem gerentes fustigadores mas com pessoas que ajudem a resolver os problemas políticos, burocráticos e administrativos e deixe o desenvolvimento com quem entende.

A próxima década não terá pena de quem não se ajustar à nova ordem. Quem ainda quiser ficar fuçando no código como se fazia à 20 ou 30 anos atrás não vai chegar a lado nenhum diferente da falência. A concorrência é maior que nunca e o mercado de tecnologia é maior do que nunca. Quem não primar pela qualidade não vai vingar.

A escravatura das fábricas de software tem que acabar. O primeiro passo é que você, desenvolvedor,  não aceite esses termos.  Aspire a ter capacidades de análise, conhecimento de arquitetura, design ou teste, e não a ser um gerente mentecapto e escravocrata.  Afinal, você gostaria que pensassem de si o que você pensa do seu gerente?

Os sufixos júnior e sênior me aborrecem enormemente desde sempre. Especialmente quando utilizados fora de contexto ou como sinônimos de “tempo de serviço”. Mas o que realmente faz de você um júnior ou um sênior?

A resposta a esta pergunta pode não ser o que você esperava ouvir. Mas se quiser trabalhar com software nos próximos decênios é bom que a aceite.

A diferença entre júnior e sênior não está na idade, nem no tempo de serviço. Está na maturidade técnica e na maturidade profissional.

Para um júnior, trabalhar muito é sinônimo de “bom”. Trabalhar até altas horas e acumular um monte de horas extra é um sinal de dignidade. Para um sênior só de isso ser sugerido, é um insulto. O sênior sabe que se algo der errado não é com horas a mais ou fins de semana longe da família que o problema se resolve. Bem pelo contrário. Se agrava. Então a posição do sênior é não ter problemas. Para isso ele usa todos os seus skills técnicos para que problemas não aconteçam ou sejam facilmente mitigados. Um bom design, uma bateria de testes automatizados e muito refactoring são ferramentas básicas do sênior para não deixar “a vaca ir p’ro brejo”.

Para um júnior, boas práticas são subjetivas e discutíveis e gambiarra é um martelinho de ouro que resolve todos os problemas com uma pancada só. Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoniaco intolerável que tem ser exorcizado a qualquer custo de todo aquele de quem se apodera. O sênior sabe que seguir bons princípios e boas práticas fazem as coisas fluirem mais facilmente e responder mais eficazmente a imprevistos enquanto o júnior ignora que as suas gambiarras são aquilo que está fazendo seus fins de semana serem perdidos na empresa ao invés de poder estar em casa ou em passeio com os amigos ou a namorada.

O júnior acha que o objetivo de construir um software é fazer o programa funcionar. O sênior sabe que o objetivo de criar um software é fazer uma aplicação de fácil manutenção. Pois é na manutenção que está o custo e não na criação.

O júnior acha que com 3 anos de serviço pode ser um pleno. Um pleno tapado será se pensa que o tempo traz experiencia. O trabalho é que traz experiencia. O sênior sabe que desenvolver software é uma arte e uma arte não se aprende com o tempo e sim com a prática.

O júnior tende a usar pouco a cabeça, tentando seguir ao máximo “receitas de bolo”, sem se ater ao contexto. O sênior racionaliza o problema e encontra a solução mais flexível até à solução. Normalmente esta solução só é possível com o uso de alguma técnica avançada de desenvolvimento de software como o uso de  objetos  em vez de rotinas. Como para o júnior boas práticas são piadas que se contam aos amigos este tipo de técnica passa longe.

O júnior fica feliz quando o dinheiro entra na conta todo o mês, o sênior dorme tranquilo quando sabe que o código que a sua equipe fez tem qualidade e pode ser mostrado a qualquer um.  Bom, nisso o junior é muito semelhante. Ele também não tem nenhuma vergonha do código que escreve. Acontece apenas que ele não a tem porque não enxerga as tremendas burrices que o seu código exclama.

Maturidade profissional não se ganha com o tempo. É preciso que a pessoa tenha orgulho no que faz e prime pela qualidade do que faz. Só isso a fará se aprefeiçoar.

Se você acha que ainda é júnior, não se desespere, aprimore-se. Acredite que as boas práticas são realmente boas e apreenda-as. Use-as. Tenha orgulho do que faz e vergonha dos seus erros. Procure qualidade e não quantidade. Procure terminar antes do prazo e com mais funcionalidades e não se faça de preguiçoso para poder arrecadar algumas horas extra. Seja profissional. Desconfie de qualquer um que o tentar levar pelo mau caminho.

Se você conhece alguém nas condições descritas aqui como júnior que ocupa um cargo sênior não tenha medo nem vergonha em o desafiar. Tanto tecnica como profissionalmente. Teste-o. Ele pode estar enganando você. E se você é diretor de gerentes de TI, a probabilidade de estar sendo enganado por um júnior se passando por gerente é quadriplicada. Cuidado, abra os olhos.

Se você é um sênior, tal como descrito aqui, meus parabéns. Agora é hora de elevar a qualidade exigindo mais dos que estão à sua volta. Ou dobra ou parte. Não há meio termo. O seculo XXI não terá pena de quem for conivente com a mediocridade.