Por que é tão dificil encontrar bons programadores?
[atualização]Incrível, mas o artigo foi removido da base do Web Insider. Não sei se foi a administração do site ou o próprio autor, mas acho que não poderia ter sido feito nada pior.[/atualização]
Em artigo publicado no Web Insider, Marcelo Okano (já citado aqui anteriormente) nos dá a visão das agências na contratação de programadores, fazendo a pergunta: Por que é tão difícil encontrar bons programadores?
O artigo começa muito bem, falando sobre as complexas questões do mercado de trabalho na área de desenvolvimento, porém, depois o autor inicia uma série de generalizações, indicando uma marginalização dos profissionais da área.
Não vou me aprofundar nos trechos que dizem coisas como: passou pela cabeça do programador limpar as bases de dados e apagar os arquivos. Se passou pela cabeça do programador, poderia ter passado na cabeça do médico, do eletricista, do mecânico e de qualquer profissional picareta que existe por aí. É preciso lembrar que esse tipo de atitude não está relacionada à área profissional, e sim à pessoa.
Eu credito essa "dificuldade" de se encontrar bons programadores, ao próprio mercado, que atravessa uma fase de carência por profissionais, gerando uma enorme quantidade de oportunidades. Quem oferece as melhores condições de trabalho, fica com os melhores profissionais, e é aí que as agências podem estar encontrando tal dificuldade. Olhando de fora (nunca trabalhei em agência), eu acredito que o profissional disputado entre as agências sejam os publicitários.
Sendo assim, as agências, ao invés de contratar estagiários ou programadores inexperientes acreditando que eles conseguirão gerenciar um projeto de desenvolvimento do dia pra noite sem cometer erros, deveriam buscar outros caminhos, como terceirização ou até mesmo investir na área, montando uma pequena fábrica de desenvolvimento própria. Depende do custo/benefício de cada solução.
Artigos Relacionados:
PHP, Ruby on Rails ou Java?
Uma das palestras realizadas no International PHP Conference, realizada em Frankfurt esse ano, causou uma chuva de posts revoltados lá fora. O motivo? O palestrante Tim Bray, apresentou gráficos comparativos onde o PHP perde, por muito, em facilidade de manutenção de código para o Ruby on Rails (que na verdade é uma framework) e Java.
Infelizmente eu não estava lá para saber o real contexto da palestra, apesar do próprio Tim Bray ter postado no seu blog mais informações, mas curiosamente na sexta-feira, comentei sobre isso com alguns de meus novos colegas de trabalho, e pelo que vi, eles estavam comentendo, o mesmo erro que o palestrante: culpar a linguagem por seus desenvolvedores.
Dizer que a linguagem PHP é difícil de manter, simplesmente por que muitas das aplicações são desenvolvidas com macarronada de HTML e SQL, é esquecer de se informar sobre quem desenvolveu este código. O código está ruim, por que o programador era inexperiente, ou a aplicação, geralmente opensource, foi desenvolvida por um grupo enorme de pessoas.
Assim como não podemos comparar códigos desenvolvidos por novatos do Java com gurus do PHP, também não podemos fazer o inverso, ou lá seja qual for a linguagem.
É preciso acabar com essa visão de que o PHP foi feito para construir sites e formulários para a web. Hoje existem muitas ferramentas e grandes aplicações muito bem desenvolvidas, e já é verdade que o mercado abriu os olhos para isso, pois está crescendo o número de oportunidades para bons desenvolvedores de PHP, com conhecimentos de Orientação à Objetos, design patterns e tudo mais que um bom programador deve saber. 
.
Pra quem sabe inglês, alguns posts lá de fora sobre o assunto:
- Tim Bray compared Java, Ruby and PHP - Tobias Schlitt
- Keynote of Tim Bray: some interesting comparison between PHP, Rails and Java - Think PHP
- An update on Tim Bray's keynote - Think PHP
- Tim Bray's keynote, misinterpreted? No, really not. - Pierre
Artigos Relacionados:
Expandindo horizontes: Linguagem Ruby
Não sou daqueles fanáticos por programação, que estão sempre em busca da linguagem mais nova para aprender e passar horas se divertindo com novas regras de sintaxe. 
. Ta bom, exagerei um pouco, mas a verdade é que, desde que comecei a trabalhar profissionalmente com PHP, não tenho tido muito interesse em estudar outras linguagens. Não tinha.
Hoje resolvi dar uma olhada rápida nas queridinhas dos desenvolvedores web: Ruby e Python. Resolvi começar pelo Ruby.
Na wikipedia dei uma revisada geral sobre a linguagem, e, no site oficial, achei o link Ruby em vinte minutos.
Um amigo da faculdade já havia me falado da interessante Orientação a Objetos da linguagem, e comprovei isso nos meus pouco mais de 20 minutos com Ruby. Instalei no meu Linux (simples como sempre: apt-get install ruby) e comecei a fazer algumas experiências via linha de comando mesmo.
Não tive problemas para me adaptar à sintaxe, apesar de sentir falta dos delimitadores de bloco, e acredito que para os já iniciados, é uma linguagem fácil de se acostumar e com potencial para tornar o trabalho do programador mais produtivo. O próximo passo agora é testar o Ruby com um nível de complexidade mais alto, rodando sobre a framework Rails, que foi o responsável por tornar a linguagem de fato conhecida.
Para os fãs de PHP como eu, que ainda não conhecem, existe uma framework que promete oferecer a mesma produtividade que o Ruby on Rails, é o CakePHP. Será?
Artigos Relacionados:
Expressões Regulares
Quem ainda não conhece, expressões regulares são muito úteis para trabalharmos com padrões de strings, utilizadas para validar, encontrar ou substituir o trecho da string que se encaixa no padrão definido.
Linguagens como PHP, Ruby, Python e JavaScript, além de softwares como o MS Word, (isso mesmo, o Word), nos permitem trabalhar com eregs.
Para conhecer o poder dessa ferramenta, visite a versão on-line do livro Expressões Regulares, escrito pelo Aurélio Marinho Jargas (conhecido como verde), publicado pela Novatec em formato pocket, como um de seus guias de consulta rápida.
Artigos Relacionados:
Cadê o AJAX no Palm?
Nessa última semana, no trabalho, tivemos a oportunidade de testar nosso sistema web em um Palm. Confesso que era a primeira vez que via alguém navegar na internet com um dispositivo móvel, utilizando um navegador "normal", que era o IE.
Depois de testar rapidamente uma folha de estilos CSS, definindo o atributo media como handheld, me descepcionei ao observar que os componentes criados com AJAX não funcionaram, além de que o suporte a JavaScript, em geral, não é muito bom.
Uma pena, pois estes componentes foram desenvolvidos para melhorar a experiência do usuário na utilização do sistema, mas, por outro lado, não consigo imaginar alguém digitando, por exemplo, dezenas de entradas e saídas de notas fiscais utilizando um palm ou um celular.
Essa experiência serviu também para que eu valorizasse ainda mais o uso de JavaScript não-obstrusivo, ou seja, mesmo quando o usuário utilizar um navegador sem suporte a javascript, o site deve funcionar.
Artigos Relacionados:
Siga-me
Tags
Posts Recentes
- O Reaproveitamento de… tudo
- TEDx Asa Sul – Evento e Talks
- 3 razões pra organizar projetos usando um Quadro (kanban)
- Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software
- O papel da Análise de Requisitos e a Taquigrafia/Digitação