Tá bom, tá bom. Estava tudo muito parádo por aqui. Parado não, a melhor definição é coma. Isso, o coding4food estava em coma. Mas era um coma induzido. Estive um tempo envolvido com alguns projetos muito importantes (jogando video-game, vendo TV, lendo alguns livros, engordando, … ).

Mas hoje o coding4food saiu do coma graças a um e-mail que perambulou entre os departamentos da empresa onde trabalho. O texto falava sobre a regulamentação da área de TI. E mais uma vez, o famigerado projeto de lei 7109/06 era alvo de novas discussões. O projeto já é antigo, porém vem a tona de tempos em tempos, como um span-highlander que insiste em renascer entre fóruns e afins.

O Sr. Bonifácio Andrada já foi responsável por longas threads no guj e as opniões sobre o assunto são as mais diversas: a SBC sempre foi contra, porém o CCT aprovou o projeto em março de 2008. Tem gente que não pode nem ouvir no assunto, outros acham que um sindicato pode significar um aumento de salário rápido e fácil, quase que milagroso, como sugerido pelo e-mail abaixo:

Pessoal, até que enfim, ao que tudo parece agora sai a lei que regulamenta nossa profissão. Isso significa um sindicato próprio (não esses fantasmas que cobram de nós sem nem sabermos ao menos quem são), piso salarial, garantias e deveres definidos, etc.

O link para a notificação de entrada na pauta de Senado é, acompanhem o andamento do projeto através do cadastro no site:
http://www.senado.gov.br/sf/ atividade/Materia/Detalhes. asp?p_cod_mate=82918

Por favor, perdi alguma coisa ou tem gente achando que vai ganhar um aumento de salário com a simples criação de um conselho ou sindicato ? Provavelmente o Sr. Bonifácio Andrada conhece do mercado de TI o mesmo que o Sr. Expedíto Júnior: ABSOLUTAMENTE NÁDA.

Sério. Por vezes procurei argumentos ou justificativas que me fizessem acreditar que este projeto de lei não fosse mais uma “politicagem” sem pé nem cabeça. Não acredito mais em analistas de sistemas, porque iria acreditar nisso ?! Então vamos lá, como nem a ACM, nem a SBC encontrou motivos para impor alguma regulamentação em nossa área, vamos deixar que os profissionais lá de Brasília o façam.

O que posso dizer sobre isso é apenas repetir o Akita:

Será que um músico diplomado é melhor que um Villa Lobos? Será que um pintor diplomado é melhor do que uma Tarsila do Amaral? Será que um escritor formado será melhor do que Machado de Assis? Será que o Washington Olivetto é um grande publicitário porque é formado? Ah, não, ele nunca concluiu o curso de publicidade da FAAP.

Grandes programadores não são formados. Grandes programadores se formam.

Não entendo porque algumas pessoas tem uma necessidade de proteção de algum órgão, sindicato ou conselho para se sentirem mais seguras. Pra mim, a competência é o que prevalece e não o diploma. Não sou contra o curso superior. Ir a faculdade foi umas das melhores escolhas que já fiz na minha vida. Mas conheço ótimos profissionais hoje, que não foram alunos tão brilhantes assim. Isso porque os bons profissionais não param apenas com o canudo. Estão sempre estudando, se aperfeiçoando, lendo, indo um pouco mais além. Para estes profissionais, o mercado sempre terá espaço. Tenho a impressão de quem é a favor da regulamentação, precisa de uma “garantia legal” para manter o seu emprego. Se este for o caso, acho que o funcionarismo público, seria o mais indicado.

Como daqui pra frente apenas os analistas de sistemas poderão desenvolver software, vamos excluir todos os engenheiros, matemáticos, físicos, administradores, filósofos que estão fazendo programas de computador por esse país a fóra. Afinal, eles não tem competência para fazer isso.
Sendo assim, alguém que é a favor dessa lei poderia me dizer se também está disposto a apenas comprar software desenvolvido por analistas de sistemas “licenciados” ? (… porque aposto que seu computador está infestado de “programinhas” desenvolvidos por adolescentes.)
Aliás, excluir engenheiros da área de TI seria no mínimo, cômico. As ciências da computação por anos vem tentando (sem muito sucesso, diga-se de passagem) aplicar técnicas de engenharia no desenvolvimento de software. Na verdade, a maioria das metodologias utilizadas hoje estão com um pé na engenheria. Mas isso não importa, vamos mandar todo esse pessoal para faculdade, porque eles não conhecem náda de computação.

Como iríamos tratar os projetos open-source? Com certeza não poderíamos mais utilizar muitos desses softwares, porque esses projetos são desenvolvidos por profissionais de todo o mundo, de todas as idades, todas as áreas e formações. Não, não poderíamos utilizar um software desse. Quem iria nos garantir que foi desenvolvido apenas por analistas de sistemas formados ? Com certeza, não poderíamos correr esse risco.

“Mas tem muita gente sem formação, roubando a vaga de profissional com curso superior!!!”

Essa é a maior das falácias. Seria hilário se não fosse triste. Se o profissional não for competente, não são seus diplomas ou certificados que irão lhe salvar. A competencia é o que prevalece. Ninguém rouba vága de ninguém. Apenas alguns profissioanis são mais competentes no que fazem, do que os outros, simples assim.

Alguém já conheceu algum engenheiro que se sentisse mais seguro pelo CREA ?!
Alguém já viu a OAB, CREA, CRA ou algum outro conselho convocar uma greve ? Fico me perguntando por que não ?
O MEC já existe a muito tempo… mas impediu a abertura indiscriminada de pseudo-faculdades e o comércio de diplomas pela internet ? Porque que será ?

A reserva de mercado, como proposto por esse projeto, é andar para trás, e a ACM já vem falando nisso a muito tempo:

ACM is opposed to the licensing of software engineers at this time
because ACM believes it is premature and would not be effective at
addressing the problems of software quality and reliability.
ACM is, however, committed to solving the software quality problem
by promoting research and development, by developing a core body of
knowledge for software engineering, and by identifying standards of
practice.

Is ACM against licensing software engineers?
Yes. For legal reasons, the only way to be a licensed software
engineer is to become a PE. As described in the Safety-Critical
report (see www.acm.org/serving/ se_policy/safety_critical.pdf), several
topics on which all prospective PEs are tested, such as fluid mechanics
and thermodynamics, are beyond the scope of software engineering.
Mastering these topics could detract from the study of more relevant
areas.
In addition, a software engineering license would be interpreted as an
authoritative statement that the licensed engineer is capable of producing
software systems of consistent reliability, dependability, and
usability. The ACM Council concluded that our state of knowledge and
practice is too immature to give such assurances.

Is ACM against software engineering being viewed as a profession?
No. ACM believes it is important to foster the emergence of a true IT profession,
not just software engineering. A field does not need licensing to be a
profession.

A área de TI já não sofre o suficiente com escassez de profissionais no mercado ?!
A CLT já não impõe burocracia e carga tributária suficientes sobre empregadores e empregados nesse país ?!
O mercado de TI no Brasil já não tem problemas o suficiente ?!
Afinal, quem serão os verdadeiros beneficiados com esta regulamentação ?

Esse mês deixei a DTS Consulting, empresa pela qual prestava serviços ao HSBC Bank Brasil desde o ano passado. Não, não …. não vou me aposentar. Aliás, a tão sonhada aposentadoria está cada vez mais longe, e na verdade, todo ano precisa ser postergada … hehe…

Gostaria de agradecer à todo o pessoal da DTS e do HSBC que aguentaram bravamente as minhas lamúrias por todos esses meses à fio, e que apesar de toda minha chatice, nunca desistiram de mim!!!
Para vocês todos , apenas posso desejar muito sucesso !!!… hehe…

Desde a semana passada faço parte da equipe de integração da Global Village Telecom – GVT, através da eWave do Brasil. Tenho muito ainda para apreender, e vi na GVT uma oportunidade para trabalhar com tecnologias e ferramentas ainda desconhecidas para mim. Em alguns projetos, estão sendo desenvolvidas algumas idéias do SCRUM, o que deixa o trabalho um pouco mais dinâmico. E nem preciso dizer, que tenho uma certa simpatia por metodologias ágeis !!!

Acho que muita coisa está por vir, nos próximos sprints, vamos ver o que acontece… hehe…

Apenas pense, se você já não passou por uma situação parecida:

programador jr: estou fazendo uma alteração nesta classe, o que você acha de…
programador ego senior: Eeiiii.. eu implementei esta classe !!!  Porque você está mexendo nisso agora ?!?!?!”

Na maioria dos projetos que participei, enfrentei muitos problemas técnicos. Mas nenhum destes problemas,  foram tão desgastantes, como os conflitos de relacionamento dentro das equipes. As vezes, os égos das pessoas se tornam maiores do que o próprio projeto, e isso, definitivamente não é bom.
Sobre o esse tema, não posso deixar de citar um artigo bem interessante que havia encontrado já fazia algum tempo no builder.com. O texto nos remete a psicologia da programação e descreve os 10 mandamentos da programação colaborativa, para que você não se prenda ao seu égo. Abaixo, segue a minha tradução/interpretação do artigo:

1. Aceite que você irá cometer erros. A questão aqui é encontrá-los cedo, antes que estes sejam enviados para produção. Contudo, com exceção de alguns poucos programadores que desenvolvem sistemas para guiar mísseis na JPL, erros de programação raramente são fatais. Por isso nós, programadores, devemos rir e apreender com nossos erros.
2. Você não é o seu código. Lembre-se que o objetivo da revisão de código é encontrar problemas, e pode ter certeza, que problemas serão encontrados. Não leve para o lado pessoal, quando um erro for apontado por alguém. Isso é normal, acredite.
3. Não importa o quanto você sabe de “karate”, alguém sempre vai saber mais. Alguém sempre vai poder ensinar à você alguns “movimentos especiais” se você souber pedir e der o mínimo de espaço. Procure aceitar feedbacks dos outros, especialmente, quando você “tem certeza” que nenhum feedback é necessário.
4. Não reescreva código sem consultar alguém. É tênue a linha entre “corrigir código” e “reescrever código”. Saiba a diferença e conseguirá realizar avanços na revisão e melhoria de código fonte.
5. Trate as pessoas menos experientes com respeito e paciência. A maioria das pessoas não técnicas que trabalham com programadores geralmente tem a mesma opnião sobre nós: somos metidos, irritantes e egoístas. Não queira piorar ainda mais este estereótipo, tratando mal as pessoas que apenas querem apreender com você.
6. A única constante nesse mundo é a mudança. Esteja aberto as mudanças e aceite-as com um sorriso. Veja cada mudança de requisitos, plataformas e ferramentas como um novo desafio e não como mais um problema que precisa ser combatido.
7. A verdadeira autoridade nasce do conhecimento, não da posição ou cargo. Conhecimento é o que promove autoridade, e autoridade é o que gera respeito. Portanto, se você quiser ser respeitado, dessimine o conhecimento entre a sua equipe.
8. Lute pelo que você acredita, mas aprenda a aceitar uma derrota. Aceite que muitas vezes suas melhores ideias não serão aceitas pelos outros. E mesmo que depois, você consiga prova que estava certo, não tenha pensamentos vingativos, nem faça comentários do tipo “Viu, eu te disse”. Muito menos faça a recusa de uma opnião sua, uma oportunidade para se tornar um mártir ou um inconformado que só reclama.
9. Não se isole, mantenha contato. Não seja aquele cara incomunicável programando numa sala escura, que só é visto quando saí para comprar pizza ou coca-cola. Mantenha contato com as pessoas, fale com elas, apareça e esteja presente quando necessário. Num ambiente colaborativo, é fundamental que as outras pessoas saibam que podem contar com você.
10. Faça críticas ao código fonte e não às pessoas. Seja gentil com o programador, não com o código. Sempre que possível, faça com que todos os seus comentários sejam positivos e direcionados para melhoria do código fonte. De feedbacks sobre padrões, especificações ou performance. Critique o que foi implementado, mas nunca, quem implementou.

Sinceramente, nunca havia encontrado algo que definisse tão acertadamente o comportamento humano na programação. Algumas pontos parecem clichês de tão óbvios, mas diariamente eu vejo problemas relacionados à eles. Particularmente, estou trabalhando exaustivamente nos itens 2 e 8 dessa lista a algum tempo, mas devo confessar, não é fácil. Reconhecer um erro, aceitar uma crítica e apreender com ela, é algo que vai se apreendendo com o passar dos anos.

O artigo está baseado no livro de  Gerald M. Weinberg: The Psychology of Computer Programming. O que mais me impressiona, é como um livro escrito em 1971 descreve com tamanha precisão os problemas que ainda enfrentamos hoje em dia. Sem dúvida, este merece estar entre as minhas “pendências” bibliográficas.

Por enquanto, toda manhã, ao sentar à frente de meu computador, repito em mantra:
“Eu não sou o meu código.. eu não sou o meu código… eu não sou o meu código… ”