De Sênior a Gerente

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 ?

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?

De Júnior a Sênior

Vivemos uma época transformadora no desenvolvimento de software . A partir da segunda década do século XXI só vai sobreviver quem fizer software barato (leia-se: sem “gordura”),  recheado de valor, feito com responsabilidade e entregue no prazo. É a hora de separar o trigo do joio.

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

Scrum

Um dia todos usarão Scrum e tirarão um bom sarro das metadologias obcuras e cabalisticas que se usam por ai hoje em dia.

Até lá é preciso difundir as práticas e teorias do Scrum. Desmitificar um pouco esse novo. Afinal muito se escrever por ai sem pés nem cabeça. Uns dizem que o Scrum é baseado no manifesto agil ou que é um processo de desenvolvimento de software. Ouve-se e lê-se muita coisa ridicula por aí.

A verdade é que Scrum é uma tecnica de gerenciamento de Projetos que visam entregar Produtos. Isto cai que nem uma luva para projetos de software mas muitos outros tipos de projetos podem usar esta tecnica.

Tendo isto em mente  e continuando a exploração do conceito de que criar software  é uma arte,  abro hoje uma nova secção do meu blog dedicada ao Scrum e a disseminar as simples e poderosas ideias que ele trás.

O Scrum  é ótimo para pequenas equipes e empresas que estão dandos os primeiros passos. Ao cortar a burucracia e aproximar o cliente o Scrum traz-lhe um ROI mais rápido para poder alavancar a sua empresa mais rápidamente mas fundá-la em pilares sólidos para o futuro.

Se conhece comente. Se não conhece experimente.

Sistema pequeno. Mente pequena ?

Existe uma moda de falar em sistema pequenos. “Posso fazer xxxxx ? é para um sistema pequeno.” , ” se eu fizer xxxxx tudo bem, certo? é apenas um sistema pequeno” – todos já ouvimos isto e até alguns já podem ter dito. Normalmente xxxxx é alguma gambiarra.Do tipo, posso fazer meu sistema apenas com métodos estáticos ? é um sistema pequeno.

Para mim isto é uma falácia do pensamento. Não existe sistema pequeno. O sistema pode nascer pequeno – modesto em funcionalidades – mas ele tende a evoluir. Mais cedo ou mais tarde esse sistema irá precisa de manutenção (leia-se corrigir algum problema ou aumentar as suas funcionalidades). Com a manutenção o sistema irá crescer.

Esta lógica leva-me a crer que quando alguem diz “sistema pequeno” está pensando em “sistema fast-food para enganar trouxa”, ou seja, “vou fazer esta porcaria, vender por uma nota e ganhar uma nota. Se o cara me processar depois, eu não vou estar mais aqui”. Este tipo de pensamento é triste. Mostra que ha muitos mercenários por ai que não têm qualquer honra no trabalho que fazem e tudo o que querem é dinheiro. Software, infelizmente, não dá dinheiro. Boas ideias dão dinheiro. Boas execuções dão dinheiro.

Será então que quem pensa em sistemas pequenos tem a vista curta ? Que não pensa a longo prazo ?  Este tipo pensamento pode-nos levar por um longo caminho de asneiras. Por exemplo, se o sistema é “pequeno” porquê construir camadas ? porque isolar componentes ? porquê escolher frameworks e tecnologias que trabalham bem juntas? porquê seguir boas práticas ? aliás, porquê aprender boas práticas ? porque investir aprendendo Orientação a Objetos ? porquê levantar requisitos ? porquê sequer fazer direito quando pode fazer rápido ?

Uma outra face desta moeda furada é o comum “vamos fazer só assim, e depois a gente vê como faz o resto”. Basicamente, traduzindo, significa “vamos fazer um sistema ‘pequeno’ e depois o aumentaremos”. Mas o que é pequeno aqui é a visão. Visão curta. Pensar grande corta tempo e custos porque se pensa em todas a partes. Não ha imprevisto nem surpresas. Podemos componentizar as coisas e deixar alguns componentes com implementações mais simples do que gostaríamos – mais simples, não mais “pequena”.

Aliado ao tamanho “pequeno” temos o intervalo de tempo “pequeno”. Frases como “vamos fazer um sistema pequeno para vender logo” ; leia-se : “vamos produzir um porcaria qualquer só para por no mercado sem pensar como isso afeta a nossa imagem , aumenta o risco e produz custos não estimados e altos”.

Os Romanos pensaram grande quando disseram “vamos conquistar o mundo”. E para isso criaram um estrutura social completa, infraestrutura. Infraestrutura sem a qual não seria possível conquistar nada nem ninguém. Criaram estratégias pontuais para alcançarem o objetivo maior.

Não pense pequeno. Aprenda a pensar grande. Aprenda a dividir para conquistar. Para isso nunca abra mão da qualidade do software que produz. É o seu nome, a sua dignidade, a sua honra que está nisso. Eleve a qualidade do código/software que lhe chega em mãos. Não tenha medo se defender a bandeira da qualidade. Se alguem não gostar, tenha a certeza que são eles que estão errados.

E sei que temos que comer e para isso precisamos trabalhar. E para trabalhar precisamos engolir alguns sapos de vez em quando. Mas existe um limite moral até onde você pode ir. A partir daí é trabalho intelectual forçado, é escravatura intelectual, é prostituição intelectual.

Mercenários pensam pequeno e ganham dinheiro, mas são infelizes e mal vistos pela sua falta de moral. Ninguém confia neles.  Artistas pensam grande e são normalmente felizes e as pessoas tendem a confiar neles.  Tudo bem que ha artistas que nada ganham e outros que ganham muito. Isso depende do talento de cada um. Não apenas do talento artístico como do comercial, interpessoal, etc..

Embora possa parecer que pensar pequeno pode ser uma vantagem a curto prazo, nunca é uma vantagem a longo prazo. E sendo que sistemas sempre duram além da sua vida útil, o longo prazo mal planejado tende a ser um problema.

Você pode pensar grande e dar passos simples , um de cada vez e chegar no que pensou. Mas ao pensar pequeno por muito que corra nunca vai chegar onde deveria. Isso porque você não sabe onde deveria chegar. Porque não pensou nisso antes ?

Nosso novo blog

Já era hora, eu achei, de criar um novo blog para falar do MiddleHeaven.

Tenho dedicado meu muito escasso tempo livre a este projeto durantes os últimos anos e está na hora de o mostrar ao mundo (e ser criticado por isso …).

O blog em inglês não deslanchou e o site feito pelo maven é pesado para atualizar. A ideias são muito mais fluidas e, contando que a minha equipe jornalística sou eu mesmo é bem mais facil utilizar um blog. A volta ao blog do WordPress em deterimento do Blogstop é que o Wrodpress apresenta a muito útil capacidade de criar páginas estáticas além do blog.

Convido a todos a conhecerem o nosso novo blog para entender e desenvolver o MiddleHeaven.

A seu tempo vou colocar nele os textos já apresentados, em inglês, no blog antigo.
Espero que acabe havendo algum cross-siting entre os dois blogs especialmente em referências a padrões e coisas relacionadas ao Java em si. Isso não era possível com o blog antigo devido à diferença da língua. Espero que isso, também, seja uma vantagem.

Aproveito para informar o estado do projeto. Embora já seja possível criar telas swing e sites jsp ainda falta um pouco para que as peças principais estejam no lugar.  Recentemente integrei o NeoDatis e parece bastante promissor, contudo, leva a uma revisao do modelo de dominio baseado em anotações (sem ORM , não ha necessidade das anotações). Por outro lado, revisei o mecanismo de wiring (injeção automática) para ser possível encontrar pontos de injeção por outras vias que não annotações. Desta forma é possível análises mais dinâmicas. O mecanismo de persistência é o próximo a ser revisto. Espero que após isso uma versão do framework possa ser usada para aplicações web simples (a la Spring / Struts / Vraptor / Mentawai) .

Claro que, para isso, você precisa estar preparado para não usar o Hibernate… será que aguenta ?

Os 10 Mandamentos do Programador Java

Programar em Java pode ser uma experiencia muito rica e gratificante, sobretudo quando construímos programas elegantes – que com poucas linhas fazem muitas coisas.

Nem sempre é fácil manter qualidade no código, sobretudo quando muitas mãos mexem nele.

Uma forma de obter qualidade é que toda a equipe siga um padrão de codificação comum, mas isso não é suficiente se nem todos seguem as regras básicas para a programação em Java.

A nova página “Os 10 Mandamentos do Programador Java” pode ajudar a ter algum nível de coerência no código da sua equipe.

Para mais controle considere utilizar uma ferramenta como o CheckStyle ou o PMD. Para saber mais sobre o assunto leia “Effective Java” , especialmente a segunda edição que dá dicas para o uso dos novos recursos do java 1.5 e 1.6

Gâmbito do Peão

Gâmbito é uma palavra utilizada no Xadrez para designar um sacrifício de uma peça em troca de vantagem no tabuleiro.  Normalmente é uma armadilha porque quando o adversário toma a peça é quando ele perde vantagem. Então, normalmente o Gâmbito ou é disfarçado ou muito óbvio. Ambas as formas tentam tomar o adversário desprevenido e forçá-lo a tomar uma decisão “a quente”.

O peão é a peça menos valiosa no tabuleiro (em termos de pontos) e com movimentação limitada, mas são muito uteis para atrapalhar a movimentação das outras peças.  Por outro lado, os peões podem ser promovidos. A Promoção acontece quando um peão chega na extremidade do tabuleiro  oposta àquele em que começou a partida. Nesse caso o peão é substituído por uma outra peça à escolha do jogador. Normalmente a Rainha – a peça mais poderosa do tabuleiro, mas qualquer uma é possível. É por isso que o jogador faz alguns gâmbitos no inicio da partida: para abrir caminho à promoção do máximo de peões. Por causa da promoção,  o adversário normalmente morde a isca e toma o peão sempre que tem oportunidade para evitar ficar em desvantagem mais perto do fim do jogo. Essa é armadinha, ele vai ficar mais vulnerável quando interessa: agora!

“Peão” é também o nome dado às pessoas que trabalham no chão de fábrica. Talvez por analogia  com o peão do Xadrez, já que ambos gozam de certas propriedades semelhantes, como o valor a movimentação o “atrapalhamento” que causam e a “promoção”.

Ao contrário do jogador de xadrez que valoriza seus peões, o dono de fábrica  normalmente não. À semelhança do jogador de Xadrez ambos acham que o peão é dispensável; que não há vantagem em tê-lo por perto e muitas vezes é vantajoso livrar-se dele. O Gâmbito do Peão acaba sendo uma estratégia de donos de fábrica. O que eles esquecem é que o jogador de Xadrez oferece o gâmbito em troca da possibilidade de promover outros peões. Normalmente o dono da fábrica não sabe o que significa “promover”, como um jogador iniciante.

Mas ao contrário dos peões de Xadrez que são peças de madeira sem alma, o peão de fábrica é um ser humano.  Certo que talvez um ser humano com pouca educação e oportunidades, mas normalmente uma pessoa honesta e de caráter que não se importa de sacrificar a sua força física e a sua força emocional e intelectual para o bem da empresa, em troca de salário fixo e constante.

Em épocas de crise (ou pseudo-crise) as fábricas despedem os peões que contrataram a mais anos atrás quando as coisas “iam bem”. A mídia interpreta isso como “corte de custos” e automaticamente como “crise na empresa”. Quando muitas empresas fazem o mesmo a mídia fala em “crise do mercado”, cega ao fato do problema ser da empresa que faz isso, nunca do mercado. Isto nada mais é do que o Gâmbito do Peão sendo executado em massa.

Agora, você que trabalha com desenvolvimento de software em uma empresa que se auto-denomina “fábrica de software” deve estar pensando se você é um peão ou se seus superiores teriam escrúpulos em oferecê-lo em gâmbito.  Está?

Se está, então deixe-me lhe dizer o que já é sabido há muito tempo:  sem peões não há jogo.
Por muito descartáveis que sejam não é possivel ter um jogo sem eles. Durante a partida, você pode até sacrificar alguns, mas se você deixar alguns até ao fim, normalmente acontece alguma promoção que lhe dá a vitória do jogo.

Donos de fábrica inteligentes tentam promover seus peões da mesma forma que o jogador de Xadrez. Isso envolve treinamento e custo, mas principalmente envolve respeito e profissionalismo.

Então, não é porque você trabalha em uma “fábrica de software” que automaticamente você está no páreo para o sacrifício.

Se você não quer sacrificado seja aquele peão que tem mais chance de ser promovido. Mas  se os donos da fábrica não tiverem uma política de promoção (ou pelo menos reconhecimento), então é hora de procurar outro emprego. É o processo de seleção natural. Quem sabe fazer software vai trabalhar para empresas que respeitam esse talento. Quem não respeita, acaba com meia duzia de autômatos que escrevem código (que é algo diferente de desenvolver software). A longo prazo essas empresas morrem.

Essas empreas que estão voltadas a morrer são simples de identificar. Normalmente têm muita gente  pouco qualificada programando (quer dizer, escrevendo código) e essas pessoas são encaradas como dispensáveis. Aliás, alguns tipos de contratação já meio que signfiicam isso (aka estagiário).  Têm sempre algum tipo de hierarquia como no exército. Isto é necessário quando a força ativa do grupo precisa cumprir ordens sem pensar, ou quando os superiores acham que a força ativa não pensa ou não pode ter esse direito. Além disso a hierarquia é essencial para ordenar o sacrifício e ter certeza que será cumprido. Em uma real empresa de software não há hierarquia, ha responsabilidades e colaboração.  Finalmente, empresas voltadas a definhar não fazem nenhum investimento na educação ou re-educação da força ativa (já que eles não pensam, como iriam aprender ?). Quando qualquer novidade é encarada com desdem e até como sacrilégio é porque a empresa não preza pela capacitação de seus membros. Esse é o sinal para você dar o fora. Você aprendeu a ser profissional em um nível superior ao que a empresa onde trabalha admite. Se você não for embora por sua conta, acabará sendo enviado para fora mais tarde já que a sua necessidade de evolução e a mentalidade mentecapta da empresa nunca poderão funcionar juntas. Encare isso como um processo natural em que você seleciona parceiros mais aptos e não como um castigo.

MiddleHeaven Pré-Alfa

Uma versão utilizável do MiddleHeaven já está disponivel. A versão é a 0.0.1 o que significa que é pre-alfa.

Este release não é de produção, nem muito menos está em estado de completo, mas isso é porque estou tomando em consideração todos os toolboxes.  Alguns toolboxes estão 90% terminados e alguns já são utilizáveis mesmo sem estarem completos.

O objetivo é deixar um jar disponível para que as pessoas possam experimentar o MiddleHeaven sem o esforço de baixar tudo do SVN e compilar em casa. Note-se que o MiddleHeaven tem muitas dependências externas. É bom dar uma olhada no arquivo POM dentro do jar.

É claro que nem todos os bugs foram corrigidos, mas tentei deixar corrigidos todos os que encontrei.

O blog de desenvolvimento do MiddleHeaven está aberto aos comentários de todos assim como os foruns.

O que é, e onde está a Física

Como formado no ramo da Física ainda hoje não posso escapar do seu encanto. Mesmo não praticando uma profissão relacionada à Física, ser físico é algo que está na alma e não é possível deixar de se  ser.

Para mim a Física é a ciência básica que alimenta todas as outras ciências naturais. É tão vasto o poder de explicação atual da Física que outros ramos da ciência existem apenas para tomar conta deles. A Química de hoje em dia não está mais preocupada em explicar por que o átomo existe ou como se formam moléculas, mas interessada em construir ferramentas para domar essa formação. A Física Quântica explica toda a tabela periódica sem margem de dúvida e com uma exatidão incomum. Não restam dúvidas que a Física Quântica é suficiente para explica toda a base da química – o átomo. Contudo ainda restam alguns detalhes sobre as reações químicas em si. Embora o poder de predição tenha aumentado ainda é difícil conceber uma reação artificial para construir algum composto com propriedades pré-definidas. A tentativa e o erro ainda são instrumentos nesse campo.

A Física é a ciência que estuda as ações que corpos e campos impõem sobre outros campos e corpos.  A Física está presente em quase tudo o que temos hoje em dia. Qualquer aparelho alimentado com energia elétrica funciona com base em alguma conhecimento físico. A produção de energia, per se está baseada em algum conhecimento físico; é o ramo da Termodinâmica.

O clima é talvez o campo de estudo da física que mais a ilude. A meteorologia tem uma capacidade de previsão limitada e seus modelos são complexos e empíricos – ou seja, não são totalmente  deduzidos de Princípios ou Leis e se baseiam muito em analise de dados reais. Outros campos como a Oceanografia e a Geologia estão ligados ao planeta e sofrem o mesmo problema da falta de uma teoria unificadora. Ramos como o Eletromagnetismo e a Óptica (é quase a mesma coisa, realmente…)  estão ligados às telecomunicações. O eletromagnetismo está relacionado ainda à produção de energia e à produção de movimento – motores elétricos que alimentam desde brinquedos a elevadores e trens e alternadores instalados em hidrelétricas ou na sua bicicleta que produzem energia elétrica a partir do movimento. A aerodinâmica e a mecânica também estão ligados a este ramo da atividade.

Ainda relacionado à produção de energia está a Física Nuclear que estuda também as partículas subatómicas, suas reações e sua composição.

A física está presente na sua cozinha, desde do mais simples formo (a lenha, gás ou eletricidade) até ao moderno microondas, passando pelo refiregerador e qualquer coisa que tenha a haver com frio ou quente. A física está presente na sua sala de estar, desde do vídeo em DVD (que funciona graças a um laser , devido à fisica quantica e à otica e à fisica de materiais para consturir o próprio DVD) passando pelo televisor, aparelho de som (Acustica) e qualquer item eletrônico. Eletrônica que está em todo o lugar devido ao estudo de materiais e suas propriedades (Física de Materiais). No caso o silicio e todos os semicondutores. A Eletrônica está por sua vez na base dos computadores e é o braço prático da Informática ( que não é uma ciência física mas tem muitas relações práticas)

A física está até presente nos seus moveis, nas estruturas dos prédios e até nas molas do seu colchão. Seres vivos à parte é dificil encontral algo na natureza ou no que o homem frabrica que não esteja relacionado à fisica.

Embora a biologia tenha começado apenas como uma catalogação dos seres vivos, hoje em dia, ela é marcada pela Teoria Da Evolução e a identificação do DNA. O DNA nada é mais que uma molécula – quimicamente falando – mas os processos que rodeiam essa molecula são aqueles que diferencia a vida da “não vida”.  A biologia ocupa um campo além da quimica e da fisica que lida com um conceito que é dificil colocar em formulas e reaçõs quimicas :a vida. Enquanto não é mistério como particulas subatómicas formam átomos ainda somos ignorantes de porquê elas formam átomos e como e porquê esses atómos formam DNA e vida.

A Física Moderna ( ou seja, a dos últimos 100 anos) virou sua atenção para o cosmos e desenvolveu a Cosmologia que usa parte da Fisica Quantica e parte da Relatividade Geral da Mecânica para explicar os objetos que observamos nos cosmos : estrelas, planetas, quasares, pulsares, buracos negros, etc…  A cosmológica vai mais longe e tenta explicar a aparição do Universo ( que é uma parte do Cosmos) com o famoso, e polêmico, Big Bang.

Escala. Esse é primeiro conceito necessário em física. A diferentes escalas diferentes formas da fisica são usadas conforme os fenômenos que queremos explicar.  Desde a Física Quantica do muito pequeno até á Cosmologia do muito grande.

Podemos observar a Física em acção em todo o lugar , a qualquer momento, em qualquer escala.

Aceleração

O conceito cinemático de aceleração é muito simples. A aceleração representa a alteração de velocidade. E isto significa não apenas a alteração da magnitude da velocidade mas também da sua direção.

O conceito mecânico de aceleração é mais complexo. Está ligado ao conceito de força através do conceito de massa inercial. A força, por sua vez, está ligada ao conceito de trabalho e este ao de energia. Basicamente: a transferência de energia entre dois corpos físicos provoca a produção de  trabalho em um e a realização de trabalho pelo outro. A energia do corpo sobre o qual é a realizado o trabalho aumenta e isso leva a velocidade a aumentar, produzindo aceleração.  Ou seja, força provoca a aceleração que é a alteração da velocidade.

Contudo o inverso é também verdade. Alteração da velocidade produz força.

Estou certo que os condutores de ônibus de São Paulo são sabem disto, mas cada vez que eles pisão o freio ou o acelerador eles provocam um movimento dos passageiros. E quanto mais brusco o pisar, mas brusca a alteração do movimento. Tanto que o passageiro pode ser projetado além da sua vontade … isso é verdade, já vi acontecer, e prova que a física não é nenhuma mentira.

O ser humano está submetido constantemente à aceleração da força de gravidade, embora ele não note, pois é “construído” para não se dar conta que é submetido à aceleração da gravidade constantemente. Digamos que ele é sensível à mudança de aceleração e porque a aceleração da gravidade é sempre a mesma, não damos por ela, ou estamos, de alguma forma preparados para não nos darmos conta disso (outros seres vivos estão, como as plantas, que crescem para cima porque é o sentido oposto ao da aceleração).

Felizmente o que Deus não nos deu em sentidos nos deu em inteligência e somos capazes de criar aparelhos que medem a aceleração, os acelerômetros.  Acelerômetros, hoje em dia são corriqueiros. São eles que lhe permitem jogar no seu console apenas com movimentos , ou que a tela do seu handlet ou laptop se reposicione conforme a inclinação que dá ao aparelho.  Simples e divertido. Só possível porque tudo na Terra está submetido a uma aceleração constante todo o tempo, em todo o lugar.

A aceleração tem ainda uma outra relação com o seu humano. Quando um ser humano é submetido a acelerações muito diferentes que a da gravidade ( 9,8 m/s²) ele sente-se mal. Tão mal ao ponto de vomitar, desmaiar e até morrer.  É por isso que a aceleração está intimamente ligada ao conforto dos passageiros em qualquer transporte. Aviões têm que ganhar muita velocidade para poderem levantar voo, mas não a podem ganhar muito depressa porque isso seria equivalente a uma aceleração forte demais para um ser humano comum (por isso que a lista é longa e ha regras para quanto um avião pode acelerar). Pilotos e Astronautas são treinados para serem capazes de suportar acelerações maiores que um ser humano comum, sem passarem mal.

É claro que, alheios à qualidade do transporte urbano, as empresas de ônibus de São Paulo não instruem os seus condutores a terem cuidado com o nível de aceleração do veículo, já que isso é diretamente proporcional ao conforto do passageiro, e este ao nível de satisfação. Em uma sociedade civilizada não seria necessário dizer, mas em uma em que os condutores dirigem descalços é bom lembrar que o passageiro é um ser humano que sofre com a aceleração extrema do veículo. São pessoas que estão sendo transportadas, não plantas.

Talvez a prefeitura queira instalar acelerômetros nos ônibus e não repassar o valor da passagem por infrações à qualidade, tal como acontece na aviação. Acelerômetros são baratos, até os celulares os têm hoje em dia, então não há desculpa para esta falta de cuidado.

Hum… já agora, é por causa da aceleração que é preciso usar cinto de segurança. É porque se o veículo travar de repente (e quanto mais de repente, maior a aceleração) uma aceleração do seu corpo irá acontecer e você será projetado para fora do veículo através do parabrisa.

Tome cuidado, não acelere.