Tecnologia é um bem de consumo. Ter um carro potente é excelente, mas não faz você dirigir melhor. Ter um computador de ultima geração é muito bom, mas não permite necessariamente que você faça mais coisas em menos tempo.
Prega-se por toda a parte que programadores Ruby são mais produtivos e mais pragmáticos. Mas Ruby, assim como qualquer outra tecnologia é somente um bem de consumo. Um bom motorista, continuará sendo um bom motorista independente do carro que esteja dirigindo. Assim como um bom programador, continuará sendo um bom programador independente da linguagem de programação que estiver utilizando.
Programar não é apenas codificar. Como desenvolvedores de software precisamos entender o que estamos criando, precisamos entrar de cabeça no negócio da empresa para qual estamos trabalhando. Conheço péssimos programadores que desempenham papeis importantes nas empresas em que trabalham, não pelo seu conhecimento técnico, mas pelo seu domínio do negócio da empresa.

Não invista somente em tecnologia
Quem é mais produtivo, o cara que conhece todas as minucias da linguagem ou o cara que conhece todos os processos da empresa? Saber conversar com o seu cliente na “língua dele” é essencial. Imagine a expressão de satisfação no rosto do seu cliente se ao lhe perguntar: “Você sabe o que é um HPA456?”, você respondesse: “Sim, mas você não acha que utilizar um PDT8954 seria mais interessante para o seu negócio?”.
Para sermos produtivos precisamos ser pró-ativos. Mas para sermos pró-ativos temos de saber o que precisa ser feito.
Não leia apenas artigos técnicos, mantenha-se em dia com o negócio do seu cliente. Leia revistas especializadas. Provavelmente você não entenderá tudo que ler, mas seja persistente. Converse com seu cliente sobre a área de atuação dele, tire suas duvidas. Conhecimento nunca é desperdiçado.
Não invista tanto em ferramentas e tecnologia, invista em conhecimento.
A qualidade de um sistema não esta relacionado apenas aos recursos tecnologicos utilizados na construção, mas também e principalmente na satisfação do cliente quanto a aderência ao negócio.
Bom texto. O que vale no software são as regras de negócio do cliente bem aplicadas. Transformar regras de negócio em código funcionando é realmente uma arte.
Carlos, acho excelente seus comentários e Traduções a respeito de desenvolvimento, e acredito que o mal de buscar sempre aprender tecnologias e não adquirir conhecimento vem das faculdades e de alguns cursos que focam somente no enviar como fazer código independente se legivel ou não, isso deturba muito as pessoas, e muitas acabam se atendo somente a uma unica tecnologia.
Meus parabéns pelo post não é mais q a verdade.
[]‘s
sábias palavras garoto! ;)
Carlos, é a essência do sucesso ser brando nas decisões e ações. Que bom que recebo este artigo do meu mestre Jackson Pires, mostra que teremos uma orientação saudável, e produtiva.
Parabens,
Sérgio Moraes.
Æ!!
Você está focando bastante nisso de “Programação não é apenas código” hein? =)
Realmente é muito verdade, mas acho que o problema é que muitos programadores acham chato ter que ficar conhecendo outras coisas que não estão relacionadas a programação. = /
Ahhh…Não posse deixar de fazer a piada sem graça. O Sergio falou que precisa ser Brando, então falou com a pessoa certa. o Carlos Brando.
Há braços
Perfeito!!! “…não pelo seu conhecimento técnico, mas pelo seu domínio do negócio da empresa”. Essa é a maneira correta de “programar”!
Muito bom, software, na maioria das vezes é um meio e não o fim….
Abraço
Muito bom este artigo.
Tocou em algumas “feridas abertas”.
Quero também deixar um comentário, que como tantas outras coisas na vida que já aprendi, se prende com “no meio é que está a virtude”: um programador que vá coleccionado ferramentas e tecnologias sem as conseguir ligar à realidade com sucesso/qualidade (e sucesso/qualidade mede-se pelo grau de satisfação do utilizador final) é um “wanna be coder”. Por outro lado, um “domain knowledger” que pouco ou nada entenda (tenha pouca sensibilidade) aos conceitos e metodologias base de diversos sistemas de informação também é um “wanna be knowledge worker”.
Desde há algum tempo a esta parte que tenho tentando caminhar segundo as ideias expressas no conceito Polyglot Programming. E, generalizando, é minha actual opinião que quando se codifica um sistema com uma DSL próxima do negócio então é-se realmente um “knowledge coder”. E uma DSL próxima do negócio usa uma terminologia que o cliente/utilizador final muito bem entende, que no fim de contas é o que retiro como “mote” deste artigo.