Me explico: Alguns programadores (desenvolvedores) chegam a um ponto da vida em que não mais conseguem desenvolver (levar adiante) o trabalho que o resto da empresa que o contratou espera que ele realize. Isso é especialmente verídico quando se trata de empresas que não são da área de desenvolvimento. Ou seja, são empresas cujo propósito não é o desenvolvimento de software. Por consequência, elas não tem a obrigação de entender as nuances do processo de desenvolver software.
De qualquer forma, cada vez mais essa mesma dinâmica de frustração empresarial seguida de depressão no staff de desenvolvimento de software se começa a ver também nas softhouses já que cada vez mais estas últimas são geridas por pessoal que não tem a ver com TI e em muitos casos até aturam o departamento de desenvolvimento como um mal necessário.
Claro, que a solução obvia para o dilema é a de cada uma das partes entender a outra e assim juntos de forma regular podem vir a realizar mais e melhores projetos. Todavia, eu quero analisar um outro caminho esquecido que pode vir a melhorar e em muito o processo de desenvolvimento de um desenvolvedor: O caminho do serviço.
Servir o outro nada mais é do que abdicar do próprio desejo de ser servido e passar a fazer um esforço ímpar e unilateral de entender o que o outro quer. Isso se torna especialmente útil em empresas que não são soft-houses e tem um departamento de TI para resolver tudo internamente. O programador mor desse TI quase sempre é visto como uma pessoa negativa e de difícil trato; um ser quase inatingível com sérios problemas psicológicos se não psiquiátricos ao qual deve-se aturar já que ele é o único detentor dos oraculos necessários para manter sob controle o deus informação que está trancafiado metafisicamente nos porões do misterioso servidor local ou ascendeu a uma tal de nuvem na internet que não conseguem os simples humanos materializar.
Por sua vez, o ogro que habita a caverna de TI pensa do resto com medo e desconfiança já que lhe pediram na reunião retrasada para fazer uma coisa, na anterior para fazer o contrario e nesta estão lhe exigindo respostas de por que não fez a primeira, mesmo que ela mexesse com a estrutura básica da base de dados que não foi pensada para responder aos questionamentos que agora se planteiam na diretoria. Só pode ser uma forma moderna de inquisição, uma tentativa de derrubada da sua dificilmente conquistada posição, uma conspiração orquestrada por algum ex-concorrente que deve ser amigo íntimo do primo do vizinho do andar de baixo de um dos sub secretários de um dos colegas de bar de um membro quase sempre ausente da diretoria.
Bem, brincadeiras à parte, a verdade é que de ambas as partes há um medo e desconforto descomunal e que reuniões de interação lúdicas organizadas pelo RH da empresa podem fazer diminuir bastante. Porém, além disso acho que o TI luta internamente por ter a melhor opção de lógica, a última palavra em código escrito, e se possível, uma perfeição quase que divina nisso tudo e eis aqui que radica o problema.
A empresa (principalmente se não é uma softhouse) não está nem ai para teu código, meu chapa. Ela quer mais é que a empresa funcione e cumpra seu propósito. Se você conseguiu poupar 20ms no cálculo do custo médio de um produto sobre uma base com mais de 500mil produtos eles só vão se limitar a dizer “ahá.. que legal, como continua o projeto tal?” Tipo, não é o foco deles. Parabéns para você por ter conquistado 20ms * 500k em uma rotina que vai ser usada uma vez por ano mas sinceramente, isso não vai fazer a menor diferença para eles. Então o que? Isso mexe com seu ego? Pois é, é exatamente ai que está o problema de TI, ninguém está disposto a morrer. Serviço é morte. Claro, RH e companhia vão tentar te dourar a pílula e tal para te fazer sentir melhor, mas o que é, é. Simplesmente você, meu querido, é tão importante como são os outros departamentos. Nem mais nem menos. Isso doi. Porque você sabe que sim, é você quem detêm os oráculos para tornar esse monte de lixo eletrônico em coisa útil. Você sabe que o que te pediram na última reunião não tem chances de ser feito até terminares primeiro o que te pediram na outra semana que por sua vez nega o que vão te pedir na seguinte. Mas, meu, é esse o pensar humano. Vamos e voltamos. Somos assim. E se você não reparou, não somos máquinas.
Então o que fazer? Servir. Não há outra. Isto é, traduzir os desejos da empresa em pequenas e interconectáveis peças de software que se materializem em alguma tela, relatório, tabela, interface que a empresa consiga apalpar. Deverás abandonar um pouco (um pouco) o perfeccionismo (em especial aqueles que diz respeito aos outros departamento e às pessoas) e abraçar relaxadamente a humanidade que cerca o departamento de TI.
Claro, você vai argumentar, “mas Esteban, eles não entendem o tempo que leva fazer o que eles pediram, me dá medo só de ter que mostrar, pareço sempre o cara da negatividade“. Bem, nesse caso, meu amigo, vai ter que lembrar da galinha e da pata. A pata bota um único ovo vistoso e bem nutritivo que imagino comendo só um por semana, você estaria completo. Mas o faz em silêncio; ninguém sabe que ela botou um ovo. Já a galinha faz a maior farra com ovos menores e menos vistosos. Cacareje, meu filho, cacareje. O que te pediram vai levar 15 dias trabalhando em moto perpetuo?, bom, recalcule para mais e acrescente 20%. Divida o projeto em coisas “entregáveis” a cada 15 dias. Faça ou utilize um programinha besta que mostre aos outros o que está fazendo. Chame antes das reuniões os diretamente envolvidos na solicitação para ver o andamento. Aceite as correções dos simples mortais; ao final das contas, eles não são obrigados a saberem que justo aqueles casos que eles acham serem minoria ou ocorrerem “muito esporadicamente” são a maçã podre que te estraga o resto da caixa.
Caso não consiga servir os outros, caso para você seja uma carga muito pesada ter que aturar o pensar simplificado e muitas vezes simplista, vá percorrer a empresa para a qual trabalhas. Observa que tua função não é a mais importante de todas. Que coloques em forma de código a inteligência da empresa não te faz mais inteligente que ela. Que saibas como montar um servidor virtualizado ou um HBA redundante não te faz mais importante do que o departamento de contabilidade ou o de manutenção. És só mais uma peça que a empresa (que te sustenta por meio do salário) precisa para seguir enfrente e ter seus projetos realizados.
Então serve. Com amor, dedicação e inteligência, mas serve. Coloca o propósito e forma operacional da empresa acima dos teus próprios porque somente assim ela pode te enxergar como alguém de confiança e talvez (só talvez) algum dia tuas formas de trabalho possam ser apreciadas por outros mas lembra constantemente que o que fazes estará sempre no porão do código fonte da tua obra maestra.
]]>Lá na minha terra dizem que mais sabe o diabo por velho de que por diabo e é verdade.
A disputa era pelos direitos de propriedade intelectual nada menos que sobre as API e não sobre o Java em si mesmo. Ainda cabe apelação, mas o fato é que esta virada de opinião em cortes federais americanas traz um pano de dúvidas sobre um mundo de negócios e interdependências aos quais estamos livremente acostumados e nunca cogitamos a ideia de poder estar sujeito a esta analise.
Por trazer uma analogia simples, é como dizer que a locomotiva pode ser usada pelos vagões contanto se paguem direitos de autor sobre o engate e a forma em que este comunica-se com a locomotiva.
De qualquer forma, mais uma vez eu fico feliz pessoalmente por não ter conseguido gostar do Java há alguns anos mesmo havendo-me esforçado bastante para usa-lo.
O outro que deve de estar imensamente feliz é Miguel de Iqaz (@migueldeicaz) com sua aproximação de C# para Android. Ao final das contas, ele leva já alguns anos em utilizar um padrão aberto para desenvolver para Android e esta pode ser a oportunidade que o leve a consagrar seu projeto sob o amparo da Google.
Falando em C#, ele é patrocinado e promovido pela Microsoft, fique tranquilo que sei disso e sei das consequências disso, porém, por trás dele esteve Anders Hejlsberg que por sua vez esteve por trás de Delphi quando ainda era Borland e que agora está por trás do TypeScript da MS que é uma versão melhorada e agora opensource do Javascript desenvolvido originalmente por Brendan Eich
Ou seja, são pessoas que movimentam o mundo e não instituições. São perguntas e não respostas, desejos e não satisfações as que alavancam o desenvolvimento. Ou, como se diz comumente, a necessidade é a mãe das invenções.
Resumindo, a solução da disputa nos coloca de novo diante da necessidade de dar uma melhor plataforma aberta para os dispositivos móveis. Não acredito, claro, que C# seja a panaceia, só digo que já algum trabalho em desenvolvimento. Também não digo que TypeScript possa vir ao resgate, já que a fonte dele está contaminada e o a comunidade open-source já olha e vai continuar olhando sempre com olhos não tão legais quem tem subjugado por anos ao fio gerações inteiras de usuários havendo antes se apropriado de forma indébita ou no mínimo escusas de milhões de linhas de código alheias.
Eu acho que a solução vai vir de algum compilador em tempo real ou não que aceite Javascript no padrão asm.js o leve a binário da plataforma destino e o mantenha de forma segura no próprio dispositivo. Digo de forma segura porque o JS por ser interpretado requer que o programador exponha sua lógica, regras de negócios, acesso aos bancos de dados e segurança por só elencar alguns. Compilar e criptografar o código seria uma revitalizada nessa situação e um grande atrativos para alguns programadores que enxergam de forma negativa e ameaçante ter que disponibilizar o código.
Por que penso em JS? porque ele está presente em quase tudo o que nos interessa nos aplicativos. É diferente o desenvolvimento de sistemas operacionais, drivers, interfaces em tempo real, etc. Ai o C++ já tem o seu espaço serio bem garantido. Mas o programador comum e corrente, precisa que seu aplicativo seja fiável, estável e que rode o maior número de plataformas sem modificações. Isso JS já faz. Compilar esse mesmo código (com todas as exigências que asm.js e TypeScript impõem) já é um grande avanço.
Quem está mais perto disso? Mozilla: http://en.wikipedia.org/wiki/Mozilla_phone
]]>Serio, eu achava que todo mundo amava a leitura. Ai escrevia um mundo de embasamento teórico sobre porque fazer isto deste jeito e não daquele outro.
Claro, não que eu pensasse que o interesse na leitura chegasse ao nível de ser paixão nacional como o futebol mas que andava perto. Logo, para mim, entregar material escrito era a melhor coisa que faria por uma pessoa pois ao final de contas era uma chave para interpretar ideias alheias.
Nada mais longe da realidade. Cheguei isso sim, no enunciado fundamental da cultura atual: O interesse pela leitura é inversamente proporcional ao interesse pelo futebol e se projeta em proporção exponencial inversa ao tempo dedicado ao video game.
Bem, este blog justamente está focado no cafezinho rápido guiado por exemplo e não por abstrações. Ou seja, cada entrada é dividida em três ou quatro passos práticos que podem ser seguidos para aprender uma habilidade. Não há abstrações e quando necessário, é feita a referencia a conceitos definidos e/ou defendidos em algum outro lugar da web.
Os passos são dados em forma gradativa e se há necessidade de ter alguma outra base anterior, um atalho é fornecido para esses outros passos. A entrada está limitada em espaço ocupado, de forma que o tempo necessário para a leitura e a colocação prática dos exemplos não supere a meia hora.
Contrario então a tudo o que eu acredito que é o melhor para o pensar humano (ou seja, a abstração que resume e projeta a elaboração do próprio pensar), este é sim, um blog pragmático orientado para pessoas que almejam uma solução rápida sem por isso precisar ou querer entender como a coisa funciona.
Todavia, não é isso mesmo o que o YeAPF se propõe?
Amo vocês.
]]>Faz alguns anos me pediram para desenvolver um aplicativo para ajudar na tomada de decisão na hora da chegada do paciente ao hospital. Ou seja, baseado no menor número disponíveis ou coletáveis de variáveis o sistema devia ajudar ao profissional da saúde (médico, enfermeiro) a derivar o paciente para um ou outro serviço sabendo que muitas vezes a vida do paciente podia verse grandemente afetada por esta decisão.
Na época não haviam muitas opções que fossem acessíveis, financeiramente viáveis ou que me dessem o mínimo de suporte no que tem a ver com a segurança dos dados.
Optamos então por um aparelho da Nokia rodando uma versão modificada de Linux a 600Mhz que nos permitiu atingir certo grau de maduridade no projeto mas a uma velocidade de fazer inveja a lesmas, tartarugas e afins. Nem pensar em sonhar sequer em disseminar o que tínhamos feito para outros profissionais fora a base de testes e muito menos para a instituição como um todo.
Passou o tempo e um outro cliente, desta vez uma UTI, se nos apresentou com um problema similar porém com menos exigência sobre a velocidade de resposta -ao final das contas o paciente já estava na UTI mesmo e o propósito não era suporte à decisão e sim levantamento dos sinais vitais- mas continuava com o problema da segurança na hora de levantar os dados e enviá-los. Desta vez, nos decidimos por um Android (ou seja, mais um Linux modificado) pelo custo da plataforma e a ductilidade que ela tinha mas a experiência não foi das melhores já que os aparelhos escolhidos acabavam sendo alvo da fúria dos usuários ao apagarem de uma hora para outra ou se perderem tentando achar a WIFI a menos de 50 mts com visada direta e sem obstáculos.
Sou um ferrenho defensor do Linux. Meus servidores rodam Linux, minhas máquinas de desenvolvimento rodam Linux e dou preferencia a qualquer dispositivo com ele. De fato sou apaixonado por sistemas operacionais em geral, engoli Tanembaum quando pequeno e tá… fiquei que nem Obelix. Mas devo de reconhecer que há algumas concessões que o pinguim faz que não nos deixa a bom recaudo quando precisamos de estabilidade ou resposta em tempo real em dispositivos embarcados e tal.
Os mais chegados em sistemas lembram do QNX.
Esta plataforma em tempo real nos permite desenvolver aplicativos realmente seguros para a área hospitalar. Android e iOS ficam no chinelo. Bada e FirefoxOS nem se mencionam como possíveis concorrente.
Claro, não vou ser exagerado de dizer que devemos sair correndo para o QNX e desenvolver tudo em Ada (a não ser, claro que queiram bancar a faculdade dos meus netos) mas às vezes o programador de aplicativos está na dúvida porque um simples monitoramento de pressão arterial ou batimentos cardíacos não flui tão gostoso como ele imaginou usando C#, Java, Javascript sobre Meebo, iOS, Android, Windows.
QNX é um mundo à parte. Só por mencionar uma das características do seu microkernel, os sinais podem ser processados em tempo real e isso faz toda a diferença. Pense em um software de monitoramento de pacientes conectado a um alarme que é disparado usando lógica fuzzy, mas pense grande, não em 10, 20 pacientes, imagine uma seguradora de saúde oferecendo planos de acompanhamento para pessoas da terceira idade que moram sozinhas e/ou distante. Com certeza não vai querer isso sobre um Android/iOS/Windows Phone
Resumindo a história em três passos: 1) Desenvolva tudo o que não for essencial sobre aquela plataforma que você mais domina ou na que foi treinado na faculdade. 2) Depois de quebrar a cabeça, abandone isso tudo e migre para Linux e relaxe. 3) Quando precise desenvolver sistemas em tempo real, porque não dar uma olhada no QNX? Às vezes você pode ser surpreendido mais uma vez como quando era mais novo e programava por puro prazer.
]]>