Uma manifestação não resolve o problema!... mas pode ser o início

Estava em conversa com uma amiga minha sobre a manifestação de ontem e as palavras que trocámos inspiraram-na a escrever o seguinte texto:

200 mil, 300 mil, não sei quantos foram, mas juntaram-se a mim na Avenida da Liberdade e no Rossio e juntos manifestámo-nos contra este futuro de precariedade que nos oferecem. “Precariedade” é um grande chavão! Não basta dizê-lo, é preciso entender o que significa e, em especial, que impacto tem no nosso futuro. No futuro desta geração que dizem ser a «mais qualificada de sempre» mas que se vê a trabalhar em call-centers , etc.

Pior do que ter empregos que não correspondem às expectativas e não fazem uso daquilo que aprendemos nas faculdades, é que, nem aí, conseguimos ter a segurança de um emprego que nos permita fazer planos para o futuro, porque não sabemos se estaremos ali daqui a uns meses. E se isto não parece muito grave quanto se tem vinte e tal anos, vai começar a ter menos graça quando tivermos trinta e tal, quarenta e tal e percebermos que a nossa vida está muito longe daquilo que idealizámos, muito longe daquilo que os nossos pais idealizaram para nós.

Sobretudo, vamos perceber que desperdiçámos décadas de luta por melhores condições laborais ao aceitar trabalhar a recibos verdes, contratos a prazo, horários de trabalho demasiado extensos, etc. Sim, porque não se iludam! A culpa desta situação não é só dos políticos, não é só das empresas, é de nós todos que nos sujeitamos a estas condições. Se não formos nós a lutar por melhores condições de trabalho, não serão as empresas a fazê-lo por nós! Os fins-de-semana não foram criados porque os patrões decidiram ser bonzinhos, foram criados pela luta dos trabalhadores e pelo seu espírito de sacrifício conjunto. E é este espírito que eu acho que se perdeu nesta sociedade individualista, e nesta época em que ser sindicalista está fora de moda e ser comunista é, muitas vezes, motivo de piadas. Esquecemo-nos do que nos ensinaram as gerações anteriores: juntos podemos dizer NÃO. Juntos temos força!

Não acredito na atitude do “se não aceitar estas condições de trabalho, fico sem emprego e alguém as aceitará em vez de mim”. Se começarmos a nossa vida profissional com este espírito, agora que nem sequer temos responsabilidades (a maior parte não tem casa para pagar nem filhos para criar) quando é que vamos começar a lutar por melhores condições? Vamos ficar à espera que esta “crise” passe e que as condições melhorem espontaneamente nessa altura? ISSO NÃO VAI ACONTECER!

Mas se todos dissermos que não, terão de criar melhores condições. Lembrem-se: somos uma geração bastante qualificada, não nos vão substituir por imigrantes brasileiros e, sobretudo, AGORA não temos nada a perder, AGORA é o momento para dizer Não! NÃO não vamos aceitar trabalhar nessas condições nem vamos andar a saltar de estágio em estágio! Somos competentes e podemos ajudar as empresas a crescer e a melhorar, não vamos aceitar que só alguns ganhem com isso! Caso contrário, aquilo que se ouviu ontem na manifestação «à rasca estamos nós, só eles é que não!» continuará a ser verdade por muitos e muitos anos.

Uma manifestação não resolve o problema, mas pode ser o início. Digamos não! Denunciemos a empresas que promovem esta precariedade! E, sobretudo, tenhamos esperança num futuro melhor e na nossa capacidade de o construir. Ontem saímos à rua aos milhares, isso quer dizer que somos muitos a pensar o mesmo, passemos à acção!

Deixo aqui as palavras dela salientando o facto de que se ficarmos à espera que o governo ou as empresas tomem a iniciativa de melhorar as nossas condições de trabalho, bem podemos esperar sentados. Não é do interesse das empresas providenciar melhores condições de trabalho (porque normalmente custam mais), nem é muito do interesse do governo contradizer as empresas. Se queremos que alguém lute pelos nossos direitos não basta sairmos à rua e gritar em plenos pulmões que os temos e que queremos que sejam respeitados... temos de os fazer respeitar.

Se não queremos trabalhar em condições precárias, o que temos de fazer é não aceitar trabalhar em condições precárias. Temos de rejeitar quando nos oferecem essas condições. Se ninguém aceitar estas condições, as condições oferecidas têm de mudar para um conjunto de condições que sejam aceitáveis.

Quando estiverem à procura de emprego lembrem-se que há duas entidades em necessidade: vocês que precisam do emprego, e os empregadores que precisam do empregado. Não são só os empregadores que têm algo para vos dar, os empregados também têm algo a dar aos empregadores. E quando as pessoas se inteirarem disto, vão estar mais confortáveis em dizer "não" a condições de trabalho pouco dignas.

Ouve-se bastante o argumento "se eu não aceitar este emprego, outra pessoa aceitará". À pessoa que aceita o emprego resta consciencializar-se que ao aceitá-lo está não só a prejudicar-se a si mesma, como a prejudicar todos os que estão à procura de emprego. A verdade é que se ninguém aceitar as más condições, a mudança terá de vir do outro lado, de quem faz a proposta de emprego. E neste caso estamos a subir a qualidade de vida, em vez de a baixar.

O que esta manifestação mostra é que há pessoas suficientes que estão insatisfeitas com esta situação para fazer uma mossa. O que agora falta é essas pessoas fazerem algo que faça realmente mossa. Todos nós trabalhadores temos de lutar pelos nossos direitos, não podemos ficar de braços cruzados à espera que alguém lute por nós.

A sério que não quero saber

Hoje queria usar uma folha de cálculo e como a licença temporária do Microsoft Office que vinha com o meu portátil deve estar quase a acabar*, decidi sacar o Libre Office, uma versão bastarda do Open Office feita por alguns tipos que não gostaram muito da passagem de mãos para a Oracle.

A página de download é engraçada. Não sei porquê alguém achou que sacar o código fonte para criar o próprio instalador é um caso de uso suficientemente importante para estar (quase) logo abaixo do download da versão que quero. Mais importante ainda do sacar o SDK para fazer as minhas alterações (já que está por cima desse). Acho que alguém tem de lhes dizer que não há aí muitas pessoas a quererem sacar o código fonte só para compilar e fazer um instalador personalizado quando, em princípio, o resultado final é igualzinho a usar o instalador dos binários. Talvez o caso de uso seja um pouco diferente do que a ligação dá a sugerir, mas prontos.

Também nessa página (e isto só reparei agora que a estou a revisitar) os temos a pedir desculpa se a "combo-box" não tiver logo o sistema operativo certo. Que idiotas... mais valia ficarem caladinhos. Imagino que aquele texto seja precisamente o contrário: o que eles estão a fazer é a gabarem-se que têm um sistema automático para detectar o sistema operativo e querem salientar essa funcionalidade. Mas como às vezes falha já se estão a desculpar. Se não quisessem ser chico-espertos não precisavam de dar a saber que a funcionalidade às vezes falhava. Se não dissessem nada, silenciosamente melhoravam a experiência do utilizador sem darem mau aspecto. Detecção do sistema operativo não é nada de tão difícil que se valha a pena gabar-se, e se não se conseguir detectar deixa-se o valor escolhido no sistema operativo mais usado que também ninguém havia de refilar se afinal falhassem.

Mas a cena mais espectacular da experiência toda ainda foi durante a instalação:

Lendo com atenção, não me estão a perguntar onde quero que o Libre Office vá parar, estão a perguntar onde quero que ponham os ficheiros temporários de instalação. Ora aí está algo que nem sequer quero saber, não percebo por que raio me estão a perguntar isto. Ponham-nos onde quiserem, num canto refundido qualquer que nunca mais vou visitar e que normalmente é apagado automaticamente, como o directório de ficheiros temporários do Windows. Se for, sem perguntar nada a ninguém, para um sítio desses como tantos outros programas fazem ao se instalarem, não me chocava nada. A única razão válida para me perguntarem uma coisa destas seria eu ter o controlo de onde os ficheiros vão parar para se tiver falta de espaço em disco saber onde estão. Há soluções melhores para este problema (que em princípio nem sequer é assim tão problemático) e nenhuma envolve perguntar-me onde quero que descompactem os ficheiros do instalador: podiam, como já disse, meter os ficheiros automaticamente numa directoria de ficheiros temporários. Podiam, se se preocupam assim tanto com o espaço que ocupam, simplesmente apagar os ficheiros como passo final do instalador.

Mas não. Escolheram perguntar-me onde quero descompactar os ficheiros do instalador. Já tinha ouvido falar no termo "smart defaults" para melhor agradar o utilizador e ele ter de mexer o menos possível nas configurações obrigatórias, mas a sugestão que eles dão como localização dos ficheiros de instalação é do melhor. Então quem é que não quereria ficheiros temporários no seu ambiente de trabalho? Isto já está tão limpinho e arrumadinho, só faltava mesmo era um directório chamado "Libre Office 3.3 (letras aleatórias) Instalation Files". Está-se mesmo a ver que é um directório que iria usar com uma frequência desgraçada depois de instalar o Libre Office.

Bem ... ao menos ficou num sítio onde é relativamente fácil seleccionar e apagar.

Na tab de "Get Involved", um dos perfis de programadores que precisam é de User Experience e Visual Designer. Têm razão. E precisam tão desesperadamente que fazem coisas completamente idióticas para chamar a atenção a esse facto.

Quando encontrar o botão de "Submit Feedback", podem crer que farei uso dele.

* Para além de ser profundamente irritante aparecer uma janela enorme para me dizer que só posso abrir o Office mais uma dúzia de vezes e a perguntar se não quero dar um balúrdio do dinheiro pelo privilégio de o poder abrir as vezes que quiser.

O que distingue um bom programador?

Esta semana estou a fazer o Developer Boot Camp da OutSystems. A ideia é aprofundar os meus conhecimentos na óptica de Developer para a Agile Platform para que possa estar mais à vontade a desenvolver as ferramentas que se usam internamente na OutSystems (a grande maioria é desenvolvida com a própria plataforma da OutSystems), mas também para saber o que é que se anda a ensinar a quem usa a plataforma de forma a melhor compreender os erros que nos aparecem na Manutenção.

Uma das vantagens destes boot camps é conhecer outros profissionais da área de informática, particularmente com outra história e sensibilidades. Ontem gerou-se uma discussão que eu achei bastante interessante. Estava o formador a explicar as "Simple Queries" e como funcionavam e não é que aparece nos slides um "SELECT * FROM tabela ...". Visto isto há um dos colegas que pergunta se é possível seleccionar especificamente os campos em vez de se usar *. Ele claramente preocupado com aderir às boas práticas de SQL de seleccionar apenas os campos que interessam e obtê-los numa ordem previsível. "Não é preciso, a plataforma faz isso por si. Não só o '*' conceptual é expandido nos campos concretos da tabela, como os campos que não são usados também não são obtidos." é a resposta à preocupação dele. Devia chegar, mas não chegou.

É então que surge outra preocupação pelo mesmo colega: "Ora. Se a plataforma faz isso, como é que distingo quem sabe o que está a fazer de quem não sabe o que está a fazer quando faz perguntas à base de dados?". Aqui o argumento é bastante diferente: ao estar a tirar um fardo do programador, a plataforma está a retirar uma das características que o senhor usava para avaliar a competência dos seus programadores.

A minha opinião sobre o assunto é que se o que distingue um bom programador de um mau programador é algo que pode ser automatizado, então eu proponho que não é uma boa medida para avaliar o trabalho de um ser humano. Automatize-se o que se puder ao máximo e avaliem-se as capacidades cognitivas do programador, não as suas capacidades mecânicas.

Esta boa prática em particular tem como principal objectivo que as perguntas à base de dados sejam mais eficientes e menos propensas a erros. Com o "*", conceptualmente, os campos podem vir numa qualquer ordem, e poder-se-ia estar a introduzir um erro difícil de detectar se os campos viessem numa ordem diferente da esperada, ou pior ainda, se por alguma razão deixarem de vir pela ordem que vinham quando se definiu a pergunta. Por isso é boa prática enumerar os campos em vez de usar '*'. Por outro lado, se só precisarmos de dois ou três dos campos das tabelas usadas para realizar a pergunta, também é boa prática listar apenas os campos que vamos usar na selecção. Isto vai fazer com que hajam menos dados a passar na ligação (usualmente remota) à base de dados, melhorando o desempenho da aplicação.

Estas boas práticas são particularmente chatinhas de manter: se de repente deixo de precisar ou passo a precisar de um certo campo, posso ter de ir à definição da variável que guarda os valores adicionar/remover o campo, ter a certeza que na pergunta está lá ou deixa de estar. Enfim, pode ser preciso estar a alterar várias partes do código para fazer alterações rotineiras, das quais é fácil esquecer uma ou outra. Alterações do modelo de dados que se queiram utilizar podem também necessitar ir a uma série de perguntas alterar a lista de atributos obtidos, noutra operação rotineira e propensa a erros.

Como todas as operações rotineiras e monótonas, quanto mais automático isto for melhor. Na Agile Platform da OutSystems é exactamente isso que acontece. Os programadores que usem "Simple Queries" (servem perfeitamente para a vasta maioria das perguntas) beneficiam de borla destas boas práticas sem terem de se preocupar com isso. É maravilhoso poder fazer perguntas optimizadas a um nível de abstracção tão alto como o possível na Agile Platform.

Revisitando a preocupação do meu colega de formação: quando a plataforma faz tanto por nós pode parecer mais difícil distinguir um bom programador de um mau programador. Não me parece que seja um problema, principalmente porque o que interessa é ter bom código. Se ele foi feito por um bom programador, um mau programador ou por um gerador de código, não é tão relevante quanto isso. E nem sequer é um problema novo.

Quando surgiram compiladores de linguagem máquina para linguagens sequenciais simples, os programadores deixaram de se preocupar com (por exemplo) meter variáveis a 0 usando xor com ela própria (poupa algumas instruções) para se passarem a preocupar com problemas de mais alto nível. O mesmo se observou quando surgiram linguagens "managed" que (entre outras coisas) gerem grande parte da alocação da memória pelo programador. Em ambas estas instâncias o que distingue um bom programador da linguagem "antes" e o que distingue um bom programador na linguagem "depois" são quase sempre pormenores diferentes. Claro que também há características distintivas de bons programadores em geral que não estão ligadas a tecnologias especificas.

Mas esta subida da parada é algo positivo. Mesmo que os novos programadores Java (ou C#) não saibam nada de alocação de memória, e não se fossem lembrar de fazer os free's para todos os malloc's, eles agora vão ser avaliados pelo quão bem conhecem e usam as bibliotecas da linguagem, por exemplo. E é bom que não se tenham de preocupar com as coisinhas de baixo nível para virarem a sua atenção para a organização do programa e em ter mais e melhores funcionalidades no produto final.

Quando "programamos em OutSystems" a linguagem que usamos é gráfica: arrastamos bolinhas e outros bonequinhos para fluxos, editamos (visualmente) como a informação é apresentada, e definimos o modelo de dados das nossas aplicações usando o modelo Entidade-Relação. Por trás a plataforma vai gerar o SQL, o código aspx (ou jsp), e o código C# ou Java que implementa a nossa aplicação. Não temos de nos preocupar em fazer x = 0 com XOR em vez de usando uma constante (é o compilador de baixo nível que faz isso), nem com fazer um free por cada malloc (a linguagem "managed" é quem tem essa preocupação), e agora nem temos de nos preocupar com o código aspx/html ou sequer com as perguntas SQL (é a Agile Platform quem faz isso). Isto é mais do que bom, é óptimo.

Não termos de nos preocupar com estes pormenores (e eles serem feitas pelas camadas mais abaixo) quer dizer que as nossas preocupações vão para outros pormenores. Já não conseguir distinguir o "bom" programador que sabe o básico de optimizar perguntas SQL é uma vantagem já que mesmo o tipo que não sabe optimizar perguntas SQL vai gerar perguntas SQL optimizadas. Tal como o tipo que não sabe onde deve fazer free, vai ter os free's no sítio certo. O código por baixo é portanto de melhor qualidade. Remover estas preocupações propencia a uma melhor qualidade geral do programa, e é isso que todos queremos fazer: programas de qualidade.

Com a Agile Platform, o nível onde estão as distinções entre programadores fica cada vez mais próximo do nível que quem utiliza a aplicação vai ver. A não ser quando o programa estoura por falta de memória, quem usa um programa não quer saber se os free's estão todos feitos. A não ser que o programa demore um tempo alarvo a ir buscar dados à base de dados, o utilizador quer lá saber se o SELECT tem * ou não. O foco da qualidade da aplicação passa para cada vez mais perto de onde interessa, para quem o utiliza. E esta aproximação do utilizador final só pode ser positiva. Temos de nos lembrar que não fazemos aplicações por fazer aplicações (por mais tecnicamente bem feitas que estejam), mas sim que fazemos aplicações para serem usadas por alguém.

Um bom programador OutSystems vai ser aquele que melhor constrói  o modelo de dados adequado ao problema em mãos. É também aquele que melhor desenha a funcionalidade desejada sobre esses dados, com cada vez mais atenção que o cliente quer (quer ele o expresse ou não). Um bom programador OutSystems vai fazer aplicações fantásticas para quem as utiliza.