Programador é peão?

Acho que vc entendeu da forma errada, foi entendendo como insulto, ou na sua sala aumentaram isso seila pq, se todos estão no mesmo barco…

Nós programadores, somos sim comparados como os peão da obra, que faz o trabalho mais pesado… mas isso não quer dizer que não temos capacidade de criar startup, ter idéias inovadoras, etc, assim tb como não pode afirma que um pedreiro (o peão da obra) não vai conseguir construir uma casa para sua família sozinho (tirando o fato da regulamentação que tem na área de eng. civil)
Programador, apesar de ter um salário relativamente bom, é considerado um dos níveis mais abaixo… só ganha dos estagiários
Testadores, analista de requisitos, analista de sistemas estão todos no mesmo nível, para ai depois ser líder técnico, arquiteto, gerente de desenvolvimento etc…

Eu entendo sua revolta, também trabalho como desenvolvedor já tem alguns anos, a questão é que por mais que estudemos, e tenhamos criatividade, infelizmente no ramo de TI o programador é visto sim como um “peão”. Somos diferentes de outros profissionais de outras áreas, mas na área de TI, somos os peões, até crescermos e nos tornarmos líderes técnicos, arquitetos e gerentes de projeto.

programado n é peão, tem periodos de peão… ou seja ele tem bastante conhecimento porém as tarefas executadas com frequencia não requerem toda essa habilidade. não é td dia q vc pega algo interessante para trabalhar.

Disseram que praticamente não tem a capacidade de pensar no negócio, que recebe apenas todo o trabalho mastigado e apenas digita.

Quem cabe nessa definição é peão mesmo,o lance é que nem todos os programadores cabem.

acho que quando o pessoal da sala do worlock257 disse que programador é peão, foi se referindo ao fato de sermos a classe mais baixa na área de TI, ganhando apenas de estagiários como disse nosso nobre colega igor_ks, ganhamos bem? é relativo, mas podemos dizer que comparado a outras áreas sim, ganhamos. Porém na área de TI ainda somos os salários mais baixos, por isso somos “peão”.

Outra coisa, quando eu era estagiário, pessoas perguntavam o cargo do programador e eles sempre diziam sou “Analista de Sistemas” , não pelo fato das pessoas que não estão no ramo não conhecerem a função mas eu percebia que era vergonha msm! Triste!

Essa visão está completamente ultrapassada. Por favor, dê de presente qualquer livro de desenvolvimento ágil para seu professor.

igor_ks:

Acho que vc entendeu da forma errada, foi entendendo como insulto, ou na sua sala aumentaram isso seila pq, se todos estão no mesmo barco…

Nós programadores, somos sim comparados como os peão da obra, que faz o trabalho mais pesado… mas isso não quer dizer que não temos capacidade de criar startup, ter idéias inovadoras, etc, assim tb como não pode afirma que um pedreiro (o peão da obra) não vai conseguir construir uma casa para sua família sozinho (tirando o fato da regulamentação que tem na área de eng. civil)
Programador, apesar de ter um salário relativamente bom, é considerado um dos níveis mais abaixo… só ganha dos estagiários
Testadores, analista de requisitos, analista de sistemas estão todos no mesmo nível, para ai depois ser líder técnico, arquiteto, gerente de desenvolvimento etc…

Bom, se nós mesmos, ou pelo menos muitos de nós, acha isso correto, como podemos nos indignar quando se referem a nós como simples burros de cargas das ideias maravilhosas do superiores?

Programador é considerado um dos niveis mais baixos?? Sim, mas por idiotas. Pessoas que pensam um pouco logo reparam que contratar programador que não pensa, programador que só executa especificação é burrice enorme.

Não existe diferença entre analista e programador na prática e todas as empresas que tentam aplicar essa “hierarquização” não se dão bem. E depois ficam procurando culpados pra todo lado sem conseguir reconhecer que estão no proprio telefone sem fio de sua hierarquia e na inacreditável incompetência de seus programadores baratos as causas da maior parte do seus problemas.

+1

+1

Eu concordo, mas a maioria das empresas não, infelizmente no mercado de trabalho hoje nos vê assim, vejam bem, o fato de eu falar que é assim não significa que eu concorde, também acho um pensamento ultrapassado e também vi mtas empresas com a hierarquização indo a falência, inclusive uma em que trabalhei e sai antes do barco afundar. Mas é assim que é, pelo menos em muitas empresas aqui do Rio, praticamente todas do Paraná e uma grande maioria de Santa Catarina, que são os estados pelos quais passei. Resta a nós procurar uma empresa melhor, ou fazer de tudo para a diretoria da empresa atual entender que não é bem assim que funciona. No meu caso, eu troco de empresa até achar uma que pense mais próximo possível do ideal, que é onde estou hoje.

Bom, como esse é um fórum de programadores, com certeza haverá uma revolta de todos. rsrsrsrs.

Mas eu vejo de outra maneira.

Como em qualquer outra área, um operador de uma máquina, um pedreiro, um encanador, um programador… São as pessoas que “botam a mão na massa”. Vai sempre existir uma parcela que simplesmente faz a coisa que o pediram, sem contra-argumentar ou analisar o problema, já outra parcela sempre ira discutir o que foi pedido, já que ele sabe a realidade da coisa na pratica.

Sim, programador é peão. É você quem vai botar a mão na massa. Mas quem disse que isso é ruim? Você recebe as coisas que tem que fazer, mas não é por isso que você não vai analisar as coisas, ver se está certo ou não, discutir.

Pra falar a verdade hoje em dia essa separação só existe mesmo na cabeça de alguns professores.
Mesmo nas consultorias mais antiquadas, nos clientes mais burocráticos, o programador está sempre envolvido nas soluções tanto técnicas quanto de negócio. Só trabalha mecanicamente quem quer, ou porque é muito inexperiente (não se sente ainda seguro para dar pitaco) ou porque é acomodado mesmo (aquela velho perfil do cara que não evolui nunca, só se preocupa em reclamar do salário).

Existem empresas onde existe a figura do “analista de sistemas” superior, mas na prática ele passa o dia escrevendo documentos que não descrevem a realidade do projeto. O que é implementado e entregue ao cliente é a solução que partiu da equipe.

giovanni_dalfre:

Bom, como esse é um fórum de programadores, com certeza haverá uma revolta de todos. rsrsrsrs.

Mas eu vejo de outra maneira.

Como em qualquer outra área, um operador de uma máquina, um pedreiro, um encanador, um programador… São as pessoas que “botam a mão na massa”. Vai sempre existir uma parcela que simplesmente faz a coisa que o pediram, sem contra-argumentar ou analisar o problema, já outra parcela sempre ira discutir o que foi pedido, já que ele sabe a realidade da coisa na pratica.

Sim, programador é peão. É você quem vai botar a mão na massa. Mas quem disse que isso é ruim? Você recebe as coisas que tem que fazer, mas não é por isso que você não vai analisar as coisas, ver se está certo ou não, discutir.

encontrou as palavras que eu não consegui hehehe

worlock257:

Bom dia galera.

Estou chateado pelo q ouvi ontem em sala de aula do professor e de alunos. Naquela aula tipica que falam um pouco dos cargos em uma empresa de T.I, se referiram ao programador como um peão, simplesmente com um desprezo terrível. Disseram que praticamente não tem a capacidade de pensar no negócio, que recebe apenas todo o trabalho mastigado e apenas digita. Cara isso é revoltante! Já não basta a quantidade de assuntos que um desenvolvedor tem que aprender, o estudo e o aprendizado não para. Será que não entendem que a quantidade de assuntos que devemos aprender já é tão imenso que entender todo o negócio é tanta informação que não há como absorver tudo? Mas ser tratado como peão é uma tremenda falta de respeito! Grandes idéias, ótimas startups nascem da criatividade e conhecimento dos ‘peões’, então é um absurdo nós recebemos esse tratamento e essa visão de uma mera peça que pode ser substituída por qualquer um!
Pode ser que eu esteja viajando, afinal de contas eu sou iniciante e trabalho como desenvolvedor há um ano. mas fiquei indignado com a visão tão rancorosa do professor e alunos!
O que vc’s acham? Somos apenas um profissional que anda com uma viseira na cara? Ou nossa criatividade em criar algo que nunca é igual a outro trabalho nos diferencia de outros profissionais?

Exatamente!
Por isso você esta estudando para se analista.

Tá galera, sabia que ia gerar uma revolta em muitos desenvolvedores. Mas a grande questão é a descriminação quanto a nós, não há necessidade nenhuma de tratar nós dessa maneira. Como em outros cargos existem os acomodados e os que buscam crescer. Essa é a grande diferença! Mas em sala de aula o professor falar daquela maneira é revoltante! Falta imparcialidade!

Acho mais engraçado (ou triste) ver que ainda existem pessoas que se preocupam com o que os demais pensam. É muito mimimi para meu gosto. “Sou discriminado”, “sou minoria”, blá blá blá…
Há alguns anos (vejam bem, anos e não séculos ou décadas), as empregadas domésticas eram mão de obra farta. A maioria delas era formada por pessoas sem estudo e cujas únicas opções eram, ou ser doméstica, ou vender o corpo. Elas eram mal remuneradas e tratadas de maneira quase análoga à escravidão.
Pois bem, esses anos passaram. Atualmente você vê domésticas que ganham mais que alguns advogados e analistas de sistemas.
O que aconteceu para que esse cenário mudasse? Oganização e escassez de mão de obra (ou aumento pela demanda).
Como essa escassez aconteceu? As domésticas começaram a abandonar o barco, cansadas de maus tratos, desmandos e de baixos salários, foram atrás de outras profissões, de qualificação, etc.

Então e portanto, parem de reclamar, de sentir-se discriminados e comecem a buscar qualificação, a organizar-se e a buscar essa mudança de visão. Chega desse mimimi, parem de implorar atenção e passem a olhar as possibilidades.

drsmachado:

Acho mais engraçado (ou triste) ver que ainda existem pessoas que se preocupam com o que os demais pensam. É muito mimimi para meu gosto. “Sou discriminado”, “sou minoria”, blá blá blá…
Há alguns anos (vejam bem, anos e não séculos ou décadas), as empregadas domésticas eram mão de obra farta. A maioria delas era formada por pessoas sem estudo e cujas únicas opções eram, ou ser doméstica, ou vender o corpo. Elas eram mal remuneradas e tratadas de maneira quase análoga à escravidão.
Pois bem, esses anos passaram. Atualmente você vê domésticas que ganham mais que alguns advogados e analistas de sistemas.
O que aconteceu para que esse cenário mudasse? Oganização e escassez de mão de obra (ou aumento pela demanda).
Como essa escassez aconteceu? As domésticas começaram a abandonar o barco, cansadas de maus tratos, desmandos e de baixos salários, foram atrás de outras profissões, de qualificação, etc.

Então e portanto, parem de reclamar, de sentir-se discriminados e comecem a buscar qualificação, a organizar-se e a buscar essa mudança de visão. Chega desse mimimi, parem de implorar atenção e passem a olhar as possibilidades.

Concordo com vc! Existe muita faculdade a cada esquina, o que vai nos diferenciar é a qualificação! Ficar chorando realmente não adianta, mas um professor ter uma visão daquelas é terrível.

drsmachado:

Acho mais engraçado (ou triste) ver que ainda existem pessoas que se preocupam com o que os demais pensam. É muito mimimi para meu gosto. “Sou discriminado”, “sou minoria”, blá blá blá…
Há alguns anos (vejam bem, anos e não séculos ou décadas), as empregadas domésticas eram mão de obra farta. A maioria delas era formada por pessoas sem estudo e cujas únicas opções eram, ou ser doméstica, ou vender o corpo. Elas eram mal remuneradas e tratadas de maneira quase análoga à escravidão.
Pois bem, esses anos passaram. Atualmente você vê domésticas que ganham mais que alguns advogados e analistas de sistemas.
O que aconteceu para que esse cenário mudasse? Oganização e escassez de mão de obra (ou aumento pela demanda).
Como essa escassez aconteceu? As domésticas começaram a abandonar o barco, cansadas de maus tratos, desmandos e de baixos salários, foram atrás de outras profissões, de qualificação, etc.

Então e portanto, parem de reclamar, de sentir-se discriminados e comecem a buscar qualificação, a organizar-se e a buscar essa mudança de visão. Chega desse mimimi, parem de implorar atenção e passem a olhar as possibilidades.

Onde eu assino?

giovanni_dalfre:

Bom, como esse é um fórum de programadores, com certeza haverá uma revolta de todos. rsrsrsrs.

Mas eu vejo de outra maneira.

Como em qualquer outra área, um operador de uma máquina, um pedreiro, um encanador, um programador… São as pessoas que “botam a mão na massa”. Vai sempre existir uma parcela que simplesmente faz a coisa que o pediram, sem contra-argumentar ou analisar o problema, já outra parcela sempre ira discutir o que foi pedido, já que ele sabe a realidade da coisa na pratica.

Sim, programador é peão. É você quem vai botar a mão na massa. Mas quem disse que isso é ruim? Você recebe as coisas que tem que fazer, mas não é por isso que você não vai analisar as coisas, ver se está certo ou não, discutir.

Sim, esse papo de programador-peão realmente me revolta. Mas não por ideologia barata não, nem por orgulho ferido.

Mas sim porque normalmente somos nós, aqueles que não pensamos assim, que temos que arrumar toda a M… feita por programadores inexperientes porque havia na empresa alguém que achava que programador é quem põe a mão na massa de soluções pensadas por superiores.

Somos os otários aqui que arrumamos a bagunça deixadas quando se tenta por linha de produção em software.

drsmachado:

Acho mais engraçado (ou triste) ver que ainda existem pessoas que se preocupam com o que os demais pensam. É muito mimimi para meu gosto. “Sou discriminado”, “sou minoria”, blá blá blá…
Há alguns anos (vejam bem, anos e não séculos ou décadas), as empregadas domésticas eram mão de obra farta. A maioria delas era formada por pessoas sem estudo e cujas únicas opções eram, ou ser doméstica, ou vender o corpo. Elas eram mal remuneradas e tratadas de maneira quase análoga à escravidão.
Pois bem, esses anos passaram. Atualmente você vê domésticas que ganham mais que alguns advogados e analistas de sistemas.
O que aconteceu para que esse cenário mudasse? Oganização e escassez de mão de obra (ou aumento pela demanda).
Como essa escassez aconteceu? As domésticas começaram a abandonar o barco, cansadas de maus tratos, desmandos e de baixos salários, foram atrás de outras profissões, de qualificação, etc.

Então e portanto, parem de reclamar, de sentir-se discriminados e comecem a buscar qualificação, a organizar-se e a buscar essa mudança de visão. Chega desse mimimi, parem de implorar atenção e passem a olhar as possibilidades.

Até concordo contigo, mas é bem fácil se indignar quando se tem nas mãos a consequencia dessa visão. Tem a prova viva de quanto isso é falho e ter que ler e ouvir dizer de quem a defenda como verdade.

worlock257:

Bom dia galera.

Estou chateado pelo q ouvi ontem em sala de aula do professor e de alunos. Naquela aula tipica que falam um pouco dos cargos em uma empresa de T.I, se referiram ao programador como um peão, simplesmente com um desprezo terrível. Disseram que praticamente não tem a capacidade de pensar no negócio, que recebe apenas todo o trabalho mastigado e apenas digita. Cara isso é revoltante! Já não basta a quantidade de assuntos que um desenvolvedor tem que aprender, o estudo e o aprendizado não para. Será que não entendem que a quantidade de assuntos que devemos aprender já é tão imenso que entender todo o negócio é tanta informação que não há como absorver tudo? Mas ser tratado como peão é uma tremenda falta de respeito! Grandes idéias, ótimas startups nascem da criatividade e conhecimento dos ‘peões’, então é um absurdo nós recebemos esse tratamento e essa visão de uma mera peça que pode ser substituída por qualquer um!
Pode ser que eu esteja viajando, afinal de contas eu sou iniciante e trabalho como desenvolvedor há um ano. mas fiquei indignado com a visão tão rancorosa do professor e alunos!
O que vc’s acham? Somos apenas um profissional que anda com uma viseira na cara? Ou nossa criatividade em criar algo que nunca é igual a outro trabalho nos diferencia de outros profissionais?

Existe uma diferença entre o que deveria ser e o que é. Essa diferença advém de motivos culturais , educacionais, econômicos e profissionais.

A definição abstrata de programador é uma pessoa que é eximia em escrever código. Essa é a sua especialidade. Esta pessoa escreve código como quem escreve um livro. Quanquer um sabe escrever, mas escrever um livro é preciso talento. É preciso cuidado com detalhes de forma e estilo. É preciso escolher as palavras com cuidado porque embora sinónimos, nenhuma palavra é igual à outra. Ha nuances. Um programador sabe todas as nuances da linaugem que usa. Sabe toda a API de cor , sabe manipulá-la à sua vontade como o escrito manipula as palavras. Trata Threads por tu e consegue ver nos arquivos estáticos de código o funcionamento dinâmico do sistema. Sabe boas práticas de escrita. Escolher bons nomes. Organiza o código de forma tipograficamente correta. Um código escrito bem vale mais que mil palavras.

Mas para alcançar este nivel e poder se designar “programador” a pessoa que que evoluir muito. Então, como existem pessoas que sabem escrever e existem autores, existem programadores que escrevem e programadores que sabem escrever. E entenda que o talento do programador não é saber porque a classe X e Y existem ,ou qual é o seu papel para o usuário. Descobrir essas coisas não é o seu papel. Seu papel é simplesmente traduzir esses conceitos em código da forma mais fidedigna possível. Então, neste sentido ele é um escriba sem pretensão de conhecer do negócio ou tomar decisões de arquitetura, escolher frameworks , etc… seu único propósito é escrever bom código.

Muitas poucas pessoas são “autores de código” no nível que deveriam. Isso é uma pena. E isso advém desse preconceito contra quem é “só programador”. Não ha nada de errado em ser “só programador”, desde que seja um programador de verdade.
Então o que temos são muitas pessoas que sabem escrever e poucos autores. E ai se banaliza dizendo que se qualquer um pode escrever, então é uma função menor. Nos ultimos anos temos vindo a assistir a movimentos contra isso e em favor de escrever bom código. Mas ainda existem mutias pessoas em pontos do fluxo ( como os professores) que não estão nessa onda e ainda pensam como pessoas nos anos 50 ( talvez porque nasceram nos anos 50)

Por outro lado, um escrito de código meia boca, também não pode achar que é o salvador da pátria só que porque ele escreve um código mixuruca e faz o sistema funcionar. Ele é responsável pela maior parte do trabalho “físico”, mas ignoar sua responsabilidade na equipe é um erro fatal. O peão só é peão porque se contenta com isso. Mas peões ha muitos e um jogador experiente não tem medo se realizar o gambito do peão.

Profissionalmente as pessoas não enxergam que é necessário bons programadores autores da mesma forma que não enxergam que são necessários bons pedreiros. Acham que é só por um bom capataz (aka lider de equipe) e pronto. Isto é mau gerenciamento. É gerenciamento meia boca, porque também os gerentes que temos são como os programadores : meia boca. E assim vai até os diretores. É uma questão de cultura. Vc vai ver em outros lugares do mundo e as pessoas pensam diferente. Não se acomodam com a mediocridade. Aqui, nem sabem que são mediocres e ainda se acham os super-master.

Tudo isso começa na faculdade, nos professores que são muito acadêmicos sem experiencia real em sistemas reais. até os gerentes que - ironicamente - não têm fundamento académico para as decisões que tomam. No mundo real do dia a dia, parece que nunca ninguém leu um livro sobre gerencia de equipes de software (que é diferente de outros tipos de equipes), ninguem sabe o que é um cone de incerteza ou que quanto mais pessoas num projeto pior. Coisas simples. Claras. Que todos sabem, mas ninguém assume.

É como se a empresa mandasse escrever sua autobiografia e escolhe o primo do sobrinho do padrão porque ele tem jeito com o word. Escrever uma biografia é muito mais complexo que isso. Então, pessoas que pensam pequeno (porque não foram educadas de outra forma e sequer conhecem o mundo ) têm a ajuda de pessoas pequenas. E o engraçado é que eles são felizes assim. Até que o livro sai e ninguem gosta e ninguem compra e a culpa é do cara que escreveu e não do cara que o contratou.

Então, se está indignado em que se associe o programador ao peão, o jeito é ser um excelente programador, um autor de código, treinar seus pares para serem o mesmo, e talvez um dia, haja respeito. Porque antes de pedirmos respeito da sociedade, temos que ganhar respeito dentro da nossa própria profissão. E hoje tem muito gentio sem os valores necessários para trabalhar com software.

Cara, essa visão, como diz o Godoy, é de quem vive realidades de fábricas de software fordistas.
De fato não podemos negar que alguns cargos de programadores são imensamente subvalorizados.

Mas isso se encaixa apenas nas minorias, a grande maioria das empresas está absorvendo mais dos programadores do que só código, a eles é repassado o entendimento do que deve ser feito, e a partir dele são obtidas consultorias de como fazer melhor e mais eficiente.

igor_henrique:

Eu concordo, mas a maioria das empresas não, infelizmente no mercado de trabalho hoje nos vê assim, vejam bem, o fato de eu falar que é assim não significa que eu concorde, também acho um pensamento ultrapassado e também vi mtas empresas com a hierarquização indo a falência, inclusive uma em que trabalhei e sai antes do barco afundar. Mas é assim que é, pelo menos em muitas empresas aqui do Rio, praticamente todas do Paraná e uma grande maioria de Santa Catarina, que são os estados pelos quais passei. Resta a nós procurar uma empresa melhor, ou fazer de tudo para a diretoria da empresa atual entender que não é bem assim que funciona. No meu caso, eu troco de empresa até achar uma que pense mais próximo possível do ideal, que é onde estou hoje.

O mercado de TI é uma prostituição só (e cuidado com essas empresas que se dizem ágeis, são as piores) e não adianta mudar de cidade ou região porque é algo universal e inerente a profissão.

doravan:

Cara, essa visão, como diz o Godoy, é de quem vive realidades de fábricas de software fordistas.
De fato não podemos negar que alguns cargos de programadores são imensamente subvalorizados.

Mas isso se encaixa apenas nas minorias, a grande maioria das empresas está absorvendo mais dos programadores do que só código,

É… tá absorvendo a vida também …

a eles é repassado o entendimento do que deve ser feito, e a partir dele são obtidas consultorias de como fazer melhor e mais eficiente.

As pessoas inventam estatisticas para provar o que querem , 14 % da pessoas sabe disso.
(people can come up with statistics to prove anything. 14% of people know that. - Homer Simpson)

Esse negocio de “maioria”/ “minoria” é muito subjetivo. número. Tem números para apoiar sua afirmação ?
Num pais onde vemos serem eleitas as melhores empresas de TI as empresas que mais exploram as pessoas e/ou que têm a maior rotatividade, não é sério dizer que as “maioria” das empresas respeita as pessoas.

Sabe quanto um “peão” tá ganhando hoje em dia?
No mínimo uns 5 mil reais, e ainda escolhe trabalho. Com essa nova geração não se importando mais como as coisas funcionam e simplesmente querendo usar, quem sabe vai ficando cada vez mais escasso.
Se quiser um exemplo prático é só ir tentar achar um bom eletricista hoje em dia, o cara tem a agenda mais cheia do que médico.

sergiotaborda:

Existe uma diferença entre o que deveria ser e o que é. Essa diferença advém de motivos culturais , educacionais, econômicos e profissionais.

A definição abstrata de programador é uma pessoa que é eximia em escrever código. Essa é a sua especialidade. Esta pessoa escreve código como quem escreve um livro. Quanquer um sabe escrever, mas escrever um livro é preciso talento. É preciso cuidado com detalhes de forma e estilo. É preciso escolher as palavras com cuidado porque embora sinónimos, nenhuma palavra é igual à outra. Ha nuances. Um programador sabe todas as nuances da linaugem que usa. Sabe toda a API de cor , sabe manipulá-la à sua vontade como o escrito manipula as palavras. Trata Threads por tu e consegue ver nos arquivos estáticos de código o funcionamento dinâmico do sistema. Sabe boas práticas de escrita. Escolher bons nomes. Organiza o código de forma tipograficamente correta. Um código escrito bem vale mais que mil palavras.

Mas para alcançar este nivel e poder se designar “programador” a pessoa que que evoluir muito. Então, como existem pessoas que sabem escrever e existem autores, existem programadores que escrevem e programadores que sabem escrever. E entenda que o talento do programador não é saber porque a classe X e Y existem ,ou qual é o seu papel para o usuário. Descobrir essas coisas não é o seu papel. Seu papel é simplesmente traduzir esses conceitos em código da forma mais fidedigna possível. Então, neste sentido ele é um escriba sem pretensão de conhecer do negócio ou tomar decisões de arquitetura, escolher frameworks , etc… seu único propósito é escrever bom código.

Muitas poucas pessoas são “autores de código” no nível que deveriam. Isso é uma pena. E isso advém desse preconceito contra quem é “só programador”. Não ha nada de errado em ser “só programador”, desde que seja um programador de verdade.
Então o que temos são muitas pessoas que sabem escrever e poucos autores. E ai se banaliza dizendo que se qualquer um pode escrever, então é uma função menor. Nos ultimos anos temos vindo a assistir a movimentos contra isso e em favor de escrever bom código. Mas ainda existem mutias pessoas em pontos do fluxo ( como os professores) que não estão nessa onda e ainda pensam como pessoas nos anos 50 ( talvez porque nasceram nos anos 50)

Por outro lado, um escrito de código meia boca, também não pode achar que é o salvador da pátria só que porque ele escreve um código mixuruca e faz o sistema funcionar. Ele é responsável pela maior parte do trabalho “físico”, mas ignoar sua responsabilidade na equipe é um erro fatal. O peão só é peão porque se contenta com isso. Mas peões ha muitos e um jogador experiente não tem medo se realizar o gambito do peão.

Profissionalmente as pessoas não enxergam que é necessário bons programadores autores da mesma forma que não enxergam que são necessários bons pedreiros. Acham que é só por um bom capataz (aka lider de equipe) e pronto. Isto é mau gerenciamento. É gerenciamento meia boca, porque também os gerentes que temos são como os programadores : meia boca. E assim vai até os diretores. É uma questão de cultura. Vc vai ver em outros lugares do mundo e as pessoas pensam diferente. Não se acomodam com a mediocridade. Aqui, nem sabem que são mediocres e ainda se acham os super-master.

Tudo isso começa na faculdade, nos professores que são muito acadêmicos sem experiencia real em sistemas reais. até os gerentes que - ironicamente - não têm fundamento académico para as decisões que tomam. No mundo real do dia a dia, parece que nunca ninguém leu um livro sobre gerencia de equipes de software (que é diferente de outros tipos de equipes), ninguem sabe o que é um cone de incerteza ou que quanto mais pessoas num projeto pior. Coisas simples. Claras. Que todos sabem, mas ninguém assume.

É como se a empresa mandasse escrever sua autobiografia e escolhe o primo do sobrinho do padrão porque ele tem jeito com o word. Escrever uma biografia é muito mais complexo que isso. Então, pessoas que pensam pequeno (porque não foram educadas de outra forma e sequer conhecem o mundo ) têm a ajuda de pessoas pequenas. E o engraçado é que eles são felizes assim. Até que o livro sai e ninguem gosta e ninguem compra e a culpa é do cara que escreveu e não do cara que o contratou.

Então, se está indignado em que se associe o programador ao peão, o jeito é ser um excelente programador, um autor de código, treinar seus pares para serem o mesmo, e talvez um dia, haja respeito. Porque antes de pedirmos respeito da sociedade, temos que ganhar respeito dentro da nossa própria profissão. E hoje tem muito gentio sem os valores necessários para trabalhar com software.

Que comentário fantástico!!!

Só acrescento ao que você disse, e é o que mais me deixa indignado, é que muitas vezes, na maioria, a opção por um programador-peão acontecer por questões financeiras. Pra economizar com mão de obra. Então traz-se um analista (normalmente um ex-programador “promovido”) e um exército de programadores a preço de banana.

O que me irrita não é chamar programador de peão, porque programadores-peões realmente existem, o que me irrita é ainda se achar que eles servem para alguma coisa. É achar que pessoas que se limitam a pegar uma especificação sem questionar e escrever código com aquilo é capaz de construir um software aceitável, pelo menos. Não é.

Irritante é um analista de sistemas colocar-se num pedestal e achar que ele tem o direito de não programar. E a junção dessas duas caricaturas do mercado resulta em softwares com a qualidade que conhecemos.

Eu sou muito azarado.
Trabalhei em duas empresas seguidas com este pensamento.
Pra mim acho que mais do que conhecimento e experiência devesse primeiro se valorizar a honestidade e o respeito.

Eu sempre fui um cara que vestiu a camisa, em qualquer empresa que trabalhei, mas conforme as dúvidas vão surgindo a quem se deve perguntar?
Pois é pessoal, eu trabalhei com um analista que não se podia perguntar nada.
Após 1 ano de trabalho, olha a pérola que o ultimo infeliz soltou na metade de um projeto:
Faça como eu to mandando seu porra! Ninguém é insubstituível.
Resultado: Pedi demissão na hora e ele teve continuar sozinho (Pelo que sei ele não deu conta).

Criar um ambiente com este pensamento pra mim é gostar de jogar dinheiro fora.
Um time de softwares é como um comando. Se o comandante perde o respetio dos soldados, ele pode morrer no campo de batalha. É de se admirar que uma faculdade esteja difundindo este pensamento. Uma burrice estratégica.

Não dá pra enumerar os riscos de se contratar qualquer um. Estes são só alguns que lembro de ter visto:
http://www.guj.com.br/java/291483-desenvolvedor-e-demitido-por-terceirizar-seu-trabalho-inteiro-para-a-china
http://tecnologia.terra.com.br/noticias/0,,OI761698-EI15607,00.html

Concordo com o viny. Essa visão é ultrapassada mas ainda é ensinada como foi colocado por nosso colega worlock257! Um livro muito utilizado nas cadeiras de engenharia de software e análise de software é o “Engenharia de Software” do Roger S. Pressman e olhem o que ele diz:

Por causa do esforço aplicado no projeto o código se desenvolverá com pouca dificuldade. Uma margem de 15 a 20% do esforço global pode ser conseguido pag. 146

A Engenharia de software considera a boa codificação como consequencia de um bom projeto. O código é revisado para que possa ter estilo e clareza, mas deve, por outro lado, ser diretamente relacionado ao projeto detalhado. pag. 194

Acredito que essa visão equivocada vai levar muitos anos para ser mudada, até porque os métodos ágeis não são compreendidos da maneira correta (a maioria das vezes que se usa scrum ou qualquer outra coisa o que se esta fazendo é um mini waterfall). Me lembro agora até de uma conversa com um professor meu sobre XP, onde ele afirmava que com XP não era possivel projetar uma casa!

Eu falo bastante sobre isso em um post do meu Blog: E o programador virou pedreiro!

Todas as pessoas que já vi depreciarem a profissão de programador desta forma, eram justamente as que nunca conseguiram aprender a programar, passavam raspando na base da cola e do decoreba. Então quando não aprendem, denigrem para aquilo perder a relevância.

Qualquer profissional consciente sabe que programadores, analistas de negócio, arquitetos, o cliente, e todos os outros papéis são cruciais para o sucesso dos projetos.

Todas as pessoas que já vi depreciarem a profissão de programador desta forma, eram justamente as que nunca conseguiram aprender a programar, passavam raspando na base da cola e do decoreba. Então quando não aprendem, denigrem para aquilo perder a relevância.

Qualquer profissional consciente sabe que programadores, analistas de negócio, arquitetos, o cliente, e todos os outros papéis são cruciais para o sucesso dos projetos.

mas ninguém disse que não são necessários. Quando foi dito ‘peão’, foi com o intuito de dizer que são a base.

Sobre eletricista ganhar 5000. Meu primo vive de agenda cheia, mas tem vezes que não tem nada. Não sei se chega a 5 mil, mas acho que os engenheiros elétricos e de outras áreas realmente ganham MUITO mais que área de T.I

YvGa:

Só acrescento ao que você disse, e é o que mais me deixa indignado, é que muitas vezes, na maioria, a opção por um programador-peão acontecer por questões financeiras. Pra economizar com mão de obra. Então traz-se um analista (normalmente um ex-programador “promovido”) e um exército de programadores a preço de banana.

O que me irrita não é chamar programador de peão, porque programadores-peões realmente existem, o que me irrita é ainda se achar que eles servem para alguma coisa. É achar que pessoas que se limitam a pegar uma especificação sem questionar e escrever código com aquilo é capaz de construir um software aceitável, pelo menos. Não é.

Demanda x Oferta.

A maioria dos programadores também não têm conhecimento de negócio pra criar sua própria história e preferem a segurança de escrever biografias dos outros em troca de um contra-cheque no fim do mês.

Todas as pessoas que já vi depreciarem a profissão de programador desta forma, eram justamente as que nunca conseguiram aprender a programar, passavam raspando na base da cola e do decoreba. Então quando não aprendem, denigrem para aquilo perder a relevância.

Qualquer profissional consciente sabe que programadores, analistas de negócio, arquitetos, o cliente, e todos os outros papéis são cruciais para o sucesso dos projetos.

mas ninguém disse que não são necessários. Quando foi dito ‘peão’, foi com o intuito de dizer que são a base.

Sobre eletricista ganhar 5000. Meu primo vive de agenda cheia, mas tem vezes que não tem nada. Não sei se chega a 5 mil, mas acho que os engenheiros elétricos e de outras áreas realmente ganham MUITO mais que área de T.I

Elizeu, foi por isso que eu frisei exatamente a parte onde o usuário relatou desprezo, ou o “peão” de forma depreciativa. Quando a entonação gira da forma como você mencionou (são a base), aí não há problema algum.

Nenhum emprego digno merece desprezo.

Talvez seu professor pense que programadores são assim:

as vezes me pergunto como deixam um cara desse dar aula, sem falar que ele é um ótimo motivador de alunos em.

Eh proibido postar o nome da instituição?

Lembrando que independente de pública/privada, açougueiro tem em todo lugar, com todo respeito aos camaradas que vendem a minha mistura.

[]'s

msato:

YvGa:

Só acrescento ao que você disse, e é o que mais me deixa indignado, é que muitas vezes, na maioria, a opção por um programador-peão acontecer por questões financeiras. Pra economizar com mão de obra. Então traz-se um analista (normalmente um ex-programador “promovido”) e um exército de programadores a preço de banana.

O que me irrita não é chamar programador de peão, porque programadores-peões realmente existem, o que me irrita é ainda se achar que eles servem para alguma coisa. É achar que pessoas que se limitam a pegar uma especificação sem questionar e escrever código com aquilo é capaz de construir um software aceitável, pelo menos. Não é.

Demanda x Oferta.

A maioria dos programadores também não têm conhecimento de negócio pra criar sua própria história e preferem a segurança de escrever biografias dos outros em troca de um contra-cheque no fim do mês.

Eu sei que isso existe e eu sei que as empresas procuram programadores com pouca experiência acreditando que a experiência do analista-que-não-programa será suficiente e o resultado disso é catastrófico, invariavelmente. Stress, reuniões intermináveis, bate-boca, finais de semana e noites em claro tentando resolver problemas. E assim vai até que chegue um programador experiente pra baixar a poeira e por as coisas no lugar.

Isso acontece sempre, mas o problema é a incapacidade de muitos de reconhecer que a causa disso são os programadores inexperientes (programador junior é util e um dia pode virar um grande programador, mas enquanto junior ele deve ser assistido por outro programador mais experiente, não por um analista-que-não-programa).

E alguns, além da incapacidade de reconhecer um problema recorrente, ainda bradam aos quatro ventos que ela é a melhor solução.

raf4ever:

Disseram que praticamente não tem a capacidade de pensar no negócio, que recebe apenas todo o trabalho mastigado e apenas digita.

Quem cabe nessa definição é peão mesmo,o lance é que nem todos os programadores cabem.

A minha resposta é simples: Vai do salário do cabra. Peao na minha concepção é o q kra q enfrenta busão, trem etc d meio d condução ida/vinda trabalho; ganha salário baixo; tem d cumprir kda mldt* minuto das 8h pq é monitorado por olhos d todos os ângulos e por aí vai.

worlock257:

Bom dia galera.

Estou chateado pelo q ouvi ontem em sala de aula do professor e de alunos. Naquela aula tipica que falam um pouco dos cargos em uma empresa de T.I, se referiram ao programador como um peão, simplesmente com um desprezo terrível. Disseram que praticamente não tem a capacidade de pensar no negócio, que recebe apenas todo o trabalho mastigado e apenas digita. Cara isso é revoltante! Já não basta a quantidade de assuntos que um desenvolvedor tem que aprender, o estudo e o aprendizado não para. Será que não entendem que a quantidade de assuntos que devemos aprender já é tão imenso que entender todo o negócio é tanta informação que não há como absorver tudo? Mas ser tratado como peão é uma tremenda falta de respeito! Grandes idéias, ótimas startups nascem da criatividade e conhecimento dos ‘peões’, então é um absurdo nós recebemos esse tratamento e essa visão de uma mera peça que pode ser substituída por qualquer um!
Pode ser que eu esteja viajando, afinal de contas eu sou iniciante e trabalho como desenvolvedor há um ano. mas fiquei indignado com a visão tão rancorosa do professor e alunos!
O que vc’s acham? Somos apenas um profissional que anda com uma viseira na cara? Ou nossa criatividade em criar algo que nunca é igual a outro trabalho nos diferencia de outros profissionais?

Sabe, é complicado…

Qdo. eu estava na faculdade, assim como vc… Escutava coisas como: Programadores são bitolados no q fazem, no geral sao tímidos, nao se comunicam bem e etc etc e etc… Meu primeiro estagio, contrariou tudo o q eu escutva dizer… Em outras palavras, com base em suas experiências e expectativas vao formando suas opiniões/pontos de vista/maneiras de como encaram as coisas… Talvez seu professor já tenha avançado alguns níveis acima do cargo Programador e por isso ele coloca como ele enxerga as coisas da forma como ele disse… Quer um exemplo… Eu tinha um professor q na minha opiniao era o melhor da faculdade, e sabe o q ele dizia d quem trabalhava com Suporte Técnico/conserteva computador nas empresas? Ele falava algo como “pessoas infelizes, q andam de um lugar pro outro na empresa, tudo suado, bagunçado e com uma chave de fenda no bolso todos extressados c/ salários mediocres…”… Talvez isso me impulsionou a deixar essa área rs… E confesso, hj, tenho a mesma visao dele, daquele professor, o Marcelo…

YvGa:

msato:

YvGa:

Só acrescento ao que você disse, e é o que mais me deixa indignado, é que muitas vezes, na maioria, a opção por um programador-peão acontecer por questões financeiras. Pra economizar com mão de obra. Então traz-se um analista (normalmente um ex-programador “promovido”) e um exército de programadores a preço de banana.

O que me irrita não é chamar programador de peão, porque programadores-peões realmente existem, o que me irrita é ainda se achar que eles servem para alguma coisa. É achar que pessoas que se limitam a pegar uma especificação sem questionar e escrever código com aquilo é capaz de construir um software aceitável, pelo menos. Não é.

Demanda x Oferta.

A maioria dos programadores também não têm conhecimento de negócio pra criar sua própria história e preferem a segurança de escrever biografias dos outros em troca de um contra-cheque no fim do mês.

Eu sei que isso existe e eu sei que as empresas procuram programadores com pouca experiência acreditando que a experiência do analista-que-não-programa será suficiente e o resultado disso é catastrófico, invariavelmente. Stress, reuniões intermináveis, bate-boca, finais de semana e noites em claro tentando resolver problemas. E assim vai até que chegue um programador experiente pra baixar a poeira e por as coisas no lugar.

Isso acontece sempre, mas o problema é a incapacidade de muitos de reconhecer que a causa disso são os programadores inexperientes (programador junior é util e um dia pode virar um grande programador, mas enquanto junior ele deve ser assistido por outro programador mais experiente, não por um analista-que-não-programa).

E alguns, além da incapacidade de reconhecer um problema recorrente, ainda bradam aos quatro ventos que ela é a melhor solução.

O pior é que muitas vezes nem se busca um profissional experiente. Já vi muito sistema horrível que atende empresas grandes com erro de memória o tempo todo, travamentos, lentidão excessiva e o cliente, normalmente amarrado num contrato que privilegia só a empresa que vendeu o software, não tem muito do que reclamar. Tem que aprender a usar o sistema de modo que não de pau (se é que tem como). :shock:

Isso acontece também porque muitas vezes os clientes não buscam qualidade na hora de fechar o contrato. Aquela estória de “precisamos de um sisteminha”, aí contrata uma empresa por ter afinidade com o dono, que faz um preço camarada. Começam com o pé-esquerdo justamente por não valorizar o software.

Essa história de “peão” é uma típica visão herdada do famoso “gerente” das décadas passadas, que não produzia nada e não decidia nada, servia apenas para cobrar dos inferiores e apresentar resultados (relatórios) ao dono do negócio. Atualmente, empresas modernas (e inteligentes) estão trabalhando com uma estrutura mais horizontalizada/colaborativa. Dê uma assistida na palestra abaixo que você vai entender, vale a pena, o palestrante é muito bom:

Para avaliar a atual situação dos programadores, penso que devemos considerar o seguinte:

1. Um BOM programador (não um mero programador de framework), capaz de entender recursividade, OOP, ponteiros e outras estruturas e problemas complexos, deve ser no mínimo capaz de resolver um teste de Einstem, que segundo ele próprio, somente 2% da população é capaz. Este percentual proposto por Einstem pode não ser preciso, mas é no mínimo aproximado, basta percebermos os seguintes fatos: a aversão à matemática desde o ensino fundamental; a evasão nas faculdades de computação; a razão do número de formandos entre os cursos de graduação em computação e qualquer outro (ADM, Direito, etc.).

2. A maioria das empresas (pequenas) ainda enxerga o profissional de informática como um cargo burocrático (auxiliar administrativo, por exemplo), e, apesar da crescente falta de profissionais, há uma forte insistência em “não dão o braço a torcer” em relação à equiparação, mesmo sofrendo por atraso de projetos e recusa de demanda.

3. O senso comum ainda enxerga uma pessoa que faz computação como um “mecânico de computador” (Daí a falta de interesse pelos cursos). Qual analista de sistemas que já não ouviu: “Minha impressora está com problema…”.

4. QI não dá dinheiro! O que dá dinheiro é a gestão do QI. É aí que os experts em matemática muitas vezes se perdem. A grande maioria dos milionários não fez fortuna sabendo resolver uma equação da “NASA”, mas sabendo coordenar pessoas que o fizessem. Cabe, aí, citar a velha máxima: “Quem trabalha não tem tempo para ganhar dinheiro”.

Considerando isto, enxergo o seguinte “byte” de opções para um pretenso programador:

+1 Sei coordenar/gerir
+2 Sou criativo
+4 Estou entre os 2%

Resultado:

0 - Procure um emprego;

1, 3, 5 ou 7 - Monte sua empresa;

2 ou 6 - Procure uma sociedade;

4 - Procure um bom emprego.

[]s

James.

bombasar:

Essa história de “peão” é uma típica visão herdada do famoso “gerente” das décadas passadas, que não produzia nada e não decidia nada, servia apenas para cobrar dos inferiores e apresentar resultados (relatórios) ao dono do negócio. Atualmente, empresas modernas (e inteligentes) estão trabalhando com uma estrutura mais horizontalizada/colaborativa. Dê uma assistida na palestra abaixo que você vai entender, vale a pena, o palestrante é muito bom:

http://www.youtube.com/watch?v=uyMY2uo-iqQ

Waldez Ludwig. Realmente o cara é muito bom.
http://www.youtube.com/watch?v=uyMY2uo-iqQ
http://www.youtube.com/watch?v=_ixT4MSxjmE
http://www.youtube.com/watch?v=IjZjOamODFo

Pra mim, uma das piores coisas que tem acontecido dentro do mundo do desenvolvimento de softwares é a esse pensamento ultrapassado (é o que passei aqui no centro-oeste que me deixou pessimista). Infelizmente ainda existem pessoas que pensam como capatazes.
Max Horkheimer chama esse pensamento de razão instrumental, que é o pensamento que objetiza tudo. Incluindo as pessoas.
Isso é inviável dentro de uma empresa por vários motivos citatos pelo Waldez Ludwig. Principalmente no mundo da T.I., porque as coisas e ferramentas voluem muito rápido. Um funcionário que é “treinado” em um framework logo se torna ultrapassado. Diante deste pensamento ultrapassado a ferramenta passa a ser mais importante que o funcionário.

Infelizmente alguns gerentes escolhem as ferramentas sem consultar seus funcionários por obrigação de uma parceria (ultima empresa onde trabelhei). Sabem onde isso vai parar? Em empresas escravas de incontaveis inutilidades que não conseguem ver as qualidades das pessoas. Estas empresas passam meses tentando selecionar 10 curriculos entre 5000 sem ter nenhum sucesso. Ai recorrem as emissoras relatando a falta de profissionais “treinados” em frameworks, IDEs…

Hoje eu sou adepto da simplicidade. Vejam bem, simplicidade não significa ignorância.
Segundo Mario Sérgio Cortella onde há concorrência não há tempo a perder

Gozado um professor falando mau de alguma profissao , se ele ta dando aula e sinal que nao é la essas coisas. Queria ver ele trabalhar de verdade.

Meu professor de Programação básica sempre me dizia,“Quanto mais longe você estiver do computador,mais dinheiro você ganhará.”
Isso não quer dizer que você sendo um otimo programador não se torne futuramente um Eng. de Software,né?

Agora você conseguiu ser pior do que o professor do cara.

Agora você conseguiu ser pior do que o professor do cara.

+1.

Verdade!

Verdade!
++

Agora você conseguiu ser pior do que o professor do cara.

Irony_1.jpg442×533

Meu Deus.

Este problema todo na realidade é linguístico. Já escrevi a respeito inclusive no meu blog: http://www.itexto.net/devkico/?p=1230

O grande problema é este negócio de comparar a nossa área com outras completamente diferentes, como por exemplo construção civíl.

Se nós nos limitarmos ao modo de pensar das fábricas de software, desenvolvedor é peão mesmo e essa é uma associação que tenta desqualificar o profissional da nossa área. Acontece que “fábrica de software” já é uma ideia que, por si só, é péssima. Partindo disso, não tem como esperar coisa muito boa de uma fábrica.

Se formos comparar nosso mercado de TI ao dos EUA, por exemplo, veremos uma diferença básica: lá um programador consegue fazer uma carreira de 10, 20 anos como programador. Ou seja, o cara é valorizado, a sua experiência, conhecimento, discernimento. Não é um zé mané, é um cara que dá solução para problemas de desenvolvimento de sistemas. Aqui no Brasil isso não existe, em 8 anos um cara já é programador sênior/arquiteto e não tem mais para onde ir. Tem que virar gerente ou analista de requisitos, caso contrário corre o risco de ser “peão” pelo resto da vida.

Além do mais, essa questão de peão ou não torna-se irrelevante na medida em que pensamos como nós temos que desenvolver nosso trabalho: de forma global, completa. Como programador eu preciso ter habilidades para conversar com meu cliente, entender sua demanda, procurar me envolver com o seu domínio, escrever o código, testar, implantar, escrever manual. Ou seja, um programador não é um mico adestrado que transforma especificação de requisitos em código-fonte. Ele é um cara que resolve problemas e usa toda a sua habilidade para isso. Empresas como Google não classificam seus colaboradores com diferentes títulos, todos são “Engenheiros de software”. É o que somos, profissionais polivalentes que entregam uma solução para problemas.

Só para fazer mais um paralelo, um dia fui à faculdade de Arquitetura com a minha irmã para assistir à apresentação de um arquiteto que atuou por um tempo no Japão. Ele disse que a construção civil lá é bacana porque um pedreiro conversa em pé de igualdade com um engenheiro, porque os dois têm que garantir que a obra que está sendo feita atenderá aos critérios estabelecidos pelo contratante. Não é a classificação (pedreiro/engenheiro) que importa, é a colaboração do time, a experiência e o conhecimento de cada um que contam no resultado final.

Independente de nos chamarmos de programadores, analistas de sistemas ou o que quer que seja, nós somos profissionais completos e especializados em dar soluções tecnológicas para problemas de tudo quanto é área.

kicolobo:

Este problema todo na realidade é linguístico. Já escrevi a respeito inclusive no meu blog: http://www.itexto.net/devkico/?p=1230

O grande problema é este negócio de comparar a nossa área com outras completamente diferentes, como por exemplo construção civíl.

A meu ver o grande problema está na separação da codificação da análise. A análise é tratada como uma atividade de engenheria, responsável por modelar o projeto, e a codificação é uma atividade braçal, simplesmente implementa o que foi decidido no projeto.

Acredito que isso se deva muito aos projetos realizados em Assembly onde um minucioso processo de análise era fundamental para codificação e a linguagem quase não te dava um feedback do que estava sendo feito. Porém com a evolução da linguagem essa separação se tornou problemática. A codificação é um processo que faz parte do projeto e não uma atividade manufatureira.
A codificação é uma atividade de engenharia, deve ser realizada em parelo com a análise e não a parte. O problema é que muita gente acha que uma bom código depende exclusivamente de uma boa análise e isso é besteira.

A nossa aréa até pode ser comparada a outras, desde que corretamente. A análise e a codifição fazem parte do projeto de um sistema e não devem ser tratatas separadamente. Em um projeto de software não existe execução de um projeto, como na cívil ou mecânica, por exemplo. A tarefa de excução é automatizada e acontece no build (não é a toa que ele tem esse nome).

Digo isso pois transitei entre os dois mundos. Na verdade vim da engenharia para aréa de software e foi um choque imenso. Apreendi a desenvolver software na engenharia e isso era feito como qualquer outro projeto deles. Quando vim para as fabricas de software eu não entendia esse modelo e ainda escutava que era um modelo como de outras áreas, o que uma grande besteira!

se fosse possível dar CTRL+C, CTRL+V em uma Obra, os engenheiros civis seriam os analistas, os cadistas os peões, e os pedreiros fariam parte do sistema.

Lá um pedreiro também consegue.

…a minha irmã para assistir à apresentação de um arquiteto que atuou por um tempo no Japão.
Ele disse que a construção civil lá é bacana porque um pedreiro conversa em pé de igualdade com um engenheiro, porque os dois têm que garantir que a obra que está sendo feita atenderá aos critérios estabelecidos pelo contratante. Não é a classificação (pedreiro/engenheiro) que importa, é a colaboração do time, a experiência e o conhecimento de cada um que contam no resultado final.

Algumas empresas de construção civil no Brasil já trabalham assim também.

Pelas mensagens do post acho que o problema vai muito da forma que cada um vê o peão.

douglaskd:

se fosse possível dar CTRL+C, CTRL+V em uma Obra, os engenheiros civis seriam os analistas, os cadistas os peões, e os pedreiros fariam parte do sistema.

Cadista é coisa rara hoje em dia, só vejo para detalhamento de projeto elétrico e olha lá. Isso vem do tempo em que AutoCad era coisa rara e quase ninguém sabia mexer. Hoje um projetista é obrigado a utilizar o Auto Cad, o que praticamente acabou com os cadistas!

A função do Cadista é de detalhar ou desenhar o projeto, mas sem conhecimento do projeto e sem altera-lo. É um desenhista, pura e simplesmente, alguém que recebe ume esboço e passa para o Autocad.

No contexto do projeto de um software ele não faria parte ou estaria na mesma situação do pedreiro que o certo é ser o compilador e não programador!

kicolobo:

Este problema todo na realidade é linguístico. Já escrevi a respeito inclusive no meu blog: http://www.itexto.net/devkico/?p=1230

O grande problema é este negócio de comparar a nossa área com outras completamente diferentes, como por exemplo construção civíl.

x___________

Sabem o que eu acho que alimenta demais o problema (além da causa linguística)?

O fato de muitas vezes empresas de TI serem geridas por pessoas que não fazem a MENOR idéia do que seja produção de software.
E é um problema que vai se prolongando ad eternum, porque funciona da seguinte forma:

• Um idiota que não faz a menor idéia sobre o que é desenvolvimento abre uma “fábrica de software”.
• O mesmo idiota contrata pessoas que estão começando a carreira, normalmente no primeiro emprego, e que vão ser formadas com base nas idéias do idiota que abriu a empresa.
• O fulano vai pra faculdade e, descrente, começa a ver o professor como um perdido (vide o comentário tosco acima a respeito dos professores como evidência disto) e o idiota que abriu a sua “fantástica fábrica de softwares” como o correto, porque afinal de contas, é o chefe do cara e está fazendo dinheiro.

Interessante observar que estes mesmos idiotas sem noção que tentam entrar no mercado raríssimas vezes contratam pra abrir a empresa profissionais gabaritados (salvo se for um sócio ou outro). Na maior parte das vezes são estagiários sem a menor experiência, por serem fáceis de moldar.

E aí o estagiário que poderia ser alguém, vira outro idiota sem a menor idéia do que é desenvolvimento (mesmo tendo cursado uma faculdade). E o ciclo se repete de novo.

olha, infelizmente pode ganhar 5,10,15 mil, ele receberá por suas habilidades mentais e manuais, um programador não “comanda” um processo que gera dinheiro, esse processo que teria peões gerando dinheiro não existe. ele só vê e tem retorno do que ele mesmo faz.

na minha conclusão, um jogador de futebol também é um peão, ele pode ganhar mais que um técnico de futebol, porém ele é peão, quando suas habilidades começarem a falhar, fisícamente e psicológicamente, o R$ arrecadado durante os anos servirá para ele não ser mais peão.

o mesmo ocorre com o programador, se ele diz não vou trabalhar hoje, o processo NÃO continua, se um gerente diz o mesmo, o processo continua.

a evolução de um programador, levando em consideração o fator “perda de motivação” para programar/implementar o tempo todo, seria o de um Lider de Programação/Arquiteto, a pessoa que só faz código que o resto da empresa(peões) não conseguem fazer. talves ele se torne um Bispo, Cavalo, Torre ou até mesmo Rainha, mas Rei será o lugar dedicado para o Gerente ou Dono =)

OBS: estou falando de programadores contratados, trabalhando em empresas de outras pessoas.

• os programadores que criam um software que gera renda, ex: Android, IOs, (Softwares Fechados com venda ou pagamento mensal sem necessidade da interferência do programador) esses absolutamente não são Peões.

kicolobo:

Sabem o que eu acho que alimenta demais o problema (além da causa linguística)?

O fato de muitas vezes empresas de TI serem geridas por pessoas que não fazem a MENOR idéia do que seja produção de software.
E é um problema que vai se prolongando ad eternum, porque funciona da seguinte forma:

• Um idiota que não faz a menor idéia sobre o que é desenvolvimento abre uma “fábrica de software”.
• O mesmo idiota contrata pessoas que estão começando a carreira, normalmente no primeiro emprego, e que vão ser formadas com base nas idéias do idiota que abriu a empresa.
• O fulano vai pra faculdade e, descrente, começa a ver o professor como um perdido (vide o comentário tosco acima a respeito dos professores como evidência disto) e o idiota que abriu a sua “fantástica fábrica de softwares” como o correto, porque afinal de contas, é o chefe do cara e está fazendo dinheiro.

Interessante observar que estes mesmos idiotas sem noção que tentam entrar no mercado raríssimas vezes contratam pra abrir a empresa profissionais gabaritados (salvo se for um sócio ou outro). Na maior parte das vezes são estagiários sem a menor experiência, por serem fáceis de moldar.

E aí o estagiário que poderia ser alguém, vira outro idiota sem a menor idéia do que é desenvolvimento (mesmo tendo cursado uma faculdade). E o ciclo se repete de novo.

Cara, voce foi preciso nesse comentário.

Um exemplo claro de como essa ideia de “fabrica”, de “linha de montagem” ou de “engenharia civil like” está enraizada nas pessoas é quando os próprios que não aceitam o termo peão, não aceitam mais porque o termo é depreciativo do que pelo que o termo representa dentro do processo.

Voce lê muita gente se referindo a “cargos mais altos”, mesmo quando não gostam do termo peão, o que demonstra que a noção realmente é esta, independente do termo, de que o programador é um mero executor das ideias de superiores.

Mas o problema não está no termo, está no conceito, eles gostam de tratar programador como peão (ou qualquer outro termo) porque assim se acham no direito de pagar pouco. Só que com o tempo isso mostra os efeitos e as coisas começam a ir pro buraco. E enquanto não chegar alguém experiente pra por ordem na casa, nada se arruma. E mesmo assim insistem nesse modelo.

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

Alexandre Saudate:

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

concordo, apesar de prefirir estar no estratégico =), porém não é pra qualquer um && não depende só de querer.

Alexandre Saudate:

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

Excelente explicação, eu ia postar o mesmo mais a preguiça não deixou rsrs, o problema é que muita gente não entende esse contexto de como uma empresa funciona, são as aulas de teoria geral de sistemas fazendo falta rsrs.

Boa Tarde a todos… trabalho numa empresa de São Paulo… e na minha modesta opnião Programador não é peão não… é um cara inteligente que sabe o que faz, mesmo que esteja no começo… com certeza a grande maioria não é só programador e sim Analistas programadores, pois o mercado hoje exige isto, então chamar de peão é um comentario muito infeliz, pelo menos aqui em são paulo as pessoas não pensam assim de programadores. Pelo menos por onde passei. Abraço !!!

Então, por isso mesmo eu disse que seria uma boa você refletir no que isso significa pra você. Entenda o que o kico colocou no post dele: isso é um problema linguístico. Quem está achando isso depreciativo é você. Isso porque você associa o termo “peão” a algo inferior (algo que você deu a entender com a frase “então chamar de peão é um comentario muito infeliz”).

Eu sou arquiteto SOA, em São Paulo. E, mesmo assim, me considero peão. Posso até ser “peão de luxo” :lol: , mas isso não muda o que sou.

[]'s

acabei de chamar jogador de futebol de peão!

Nunca vi o termo peão ser usado de uma forma que não seja pejorativa fora desta discussão.
O que observo é uma tentativa muito frustrada de se tentar trazer para o desenvolvimento de software as idéias do Fordismo quando o termo aparece.
E numa boa? Já passei pela experiência e não foi nem um pouco positiva.

Alexandre Saudate:

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

Concordo com o que vc está dizendo, mas não com a denotação que é utilizada para o termo “peão” neste post.

kicolobo:

Nunca vi o termo peão ser usado de uma forma que não seja pejorativa fora desta discussão.
O que observo é uma tentativa muito frustrada de se tentar trazer para o desenvolvimento de software as idéias do Fordismo quando o termo aparece.
E numa boa? Já passei pela experiência e não foi nem um pouco positiva.

A crítica é à idéia de que:

As vezes precisamos ver pra crer e por a mão na massa para perceber o que pode ser:
reformulado
corrigido
melhorado
abandonado
evitado
…
[youtube]http://www.youtube.com/watch?v=f0z56D5qCO0[/youtube]

Alexandre Saudate:

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

Errou feio na definição do peão. O operacional trabalha com a mesma coisa sempre, repetindo seja lá o que ele precise fazer, porém programação não funciona dessa maneira. Existe uma visão de que programador é peão por aqui que condiz com o conceito de operário: o programador em tese receberia tudo mastigado, não precisando usar nenhum conhecimento fora da repetição padrão. Isso acontece pois existe um cargo intermediário entre programador e arquiteto, o que faz com que o programador pareça um cara meio que inútil em termos de pensamento nos projetos.

marcio_gs:

Alexandre Saudate:

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

Errou feio na definição do peão. O operacional trabalha com a mesma coisa sempre, repetindo seja lá o que ele precise fazer, porém programação não funciona dessa maneira. Existe uma visão de que programador é peão por aqui que condiz com o conceito de operário: o programador em tese receberia tudo mastigado, não precisando usar nenhum conhecimento fora da repetição padrão. Isso acontece pois existe um cargo intermediário entre programador e arquiteto, o que faz com que o programador pareça um cara meio que inútil em termos de pensamento nos projetos.

OK, mas nesse caso, você está dizendo que programador não é operacional, é isso? É tático ou estratégico, então?

[]'s

Alexandre Saudate:

marcio_gs:

Alexandre Saudate:

Meus dois centavos:

Todos, absolutamente todos em uma empresa, se encaixam em três níveis: estratégico, tático e operacional. Diferenças entre os três:

• O operacional faz “a roda girar”. Se ele se ausenta um dia da empresa (ou faz uma besteira nesse um dia), os resultados são visíveis no mesmo dia.
• O tático coordena o trabalho do operacional. Se ele se ausenta ou faz besteira, os resultados podem ser vistos no mesmo dia ou podem demorar mais uma semana, ou um mês, até serem vistos.
• O estratégico coordena o trabalho dos táticos. Se ele se ausenta da empresa um dia… costuma não fazer diferença. Se ele faz besteira, os resultados demorarão para serem vistos, mas terão uma evidência maior do que de qualquer um dos outros.

Nesse contexto, o programador é operacional (sim, peão). O arquiteto / analista / líder técnico / whatever são tático-operacionais. O gerente de projetos é tático. O dono (ou o PMO ou qualquer um que esteja acima do gerente de projetos) é estratégico.

Posto isso, digo o seguinte: sou peão? Sim, sou. Me importo? Não. Prefiro que meu trabalho tenha mobilidade suficiente para que eu possa reparar meus erros em um único dia do que eu ter que passar vários e vários meses pra resolver um problema que levei apenas um dia pra criar. Mas isso vai da opinião de cada um. Se você se ofende com o termo “peão”, sugiro que passe mais tempo refletindo sobre o que isso significa para você.

[]'s

Errou feio na definição do peão. O operacional trabalha com a mesma coisa sempre, repetindo seja lá o que ele precise fazer, porém programação não funciona dessa maneira. Existe uma visão de que programador é peão por aqui que condiz com o conceito de operário: o programador em tese receberia tudo mastigado, não precisando usar nenhum conhecimento fora da repetição padrão. Isso acontece pois existe um cargo intermediário entre programador e arquiteto, o que faz com que o programador pareça um cara meio que inútil em termos de pensamento nos projetos.

OK, mas nesse caso, você está dizendo que programador não é operacional, é isso? É tático ou estratégico, então?

[]'s

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford. A princípio em uma equipe, o cargo de arquiteto ou engenheiro deve ser cíclico. Dependendo do projeto quem assume esse papel é quem possui o maior know how no negócio envolvido.

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford.

Bom… não consigo pensar dessa forma (sim, mentalidade fordista). Fale mais, o que muda no contexto da sua empresa?

[]'s

Alexandre Saudate:

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford.

Bom… não consigo pensar dessa forma (sim, mentalidade fordista). Fale mais, o que muda no contexto da sua empresa?

[]'s

Olha mais acima, editei o post para adicionar mais alguma coisa.

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford. A princípio em uma equipe, o cargo de arquiteto ou engenheiro deve ser cíclico. Dependendo do projeto quem assume esse papel é quem possui o maior know how no negócio envolvido.

Tudo bem. Mesmo assim, acredito que o conhecimento que o pessoal operacional tem a respeito do negócio não faz variar a posição deles na “cadeia alimentar”. É como alguém disse antes: o jogador de futebol conhece bem o negócio em que está envolvido (vide Ronaldo e outros). Mesmo assim, enquanto jogador de futebol, é peão (pela idéia que expús lá em cima).

[]'s

Alexandre Saudate:

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford.

Bom… não consigo pensar dessa forma (sim, mentalidade fordista). Fale mais, o que muda no contexto da sua empresa?

[]'s

A mentalidade fordista não funciona com desenvolvimento de software justamente porque o trabalho do programador não é operacional. Nessa metodologia o desgaste com o tratamento do programador como “peão” leva a empresa a perder produtividade.

Aqui tem um artigo sobre:

http://xprogramming.com/articles/jatsustainablepace/

Alexandre Saudate:

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford. A princípio em uma equipe, o cargo de arquiteto ou engenheiro deve ser cíclico. Dependendo do projeto quem assume esse papel é quem possui o maior know how no negócio envolvido.

Tudo bem. Mesmo assim, acredito que o conhecimento que o pessoal operacional tem a respeito do negócio não faz variar a posição deles na “cadeia alimentar”. É como alguém disse antes: o jogador de futebol conhece bem o negócio em que está envolvido (vide Ronaldo e outros). Mesmo assim, enquanto jogador de futebol, é peão (pela idéia que expús lá em cima).

[]'s

No caso do programador não porque no meio de uma equipe existem divergências no conhecimento. Veja que me refiro ao profissional que realmente tem know how em determinado negócio ou tema e não um profissional que foi treinado para digitar código. Aliás imagino o segundo como “digitador” e não programador.

juliocbq:

Alexandre Saudate:

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford.

Bom… não consigo pensar dessa forma (sim, mentalidade fordista). Fale mais, o que muda no contexto da sua empresa?

[]'s

A mentalidade fordista não funciona com desenvolvimento de software justamente porque o trabalho do programador não é operacional. Nessa metodologia o desgaste com o tratamento do programador como “peão” leva a empresa a perder produtividade.

Aqui tem um artigo sobre:

http://xprogramming.com/articles/jatsustainablepace/

Julio, eu não enxergo dessa maneira, até porque, não é ofensa chamar um membro operacional da empresa de membro operacional. “Peão” é um termo pra isso. Pode ser considerado pejorativo? Com certeza. Mas qualquer outro nome que você der vai continuar caracterizando a pessoa como membro operacional da empresa (a não ser, é claro, que seja uma pessoa de papéis flutuantes).

Mas calma que eu ainda vou ler o texto

[]'s

Alexandre Saudate:

juliocbq:

Alexandre Saudate:

juliocbq:

Numa boa? na empresa de engenharia que trabalho são táticos e estratégicos. É como o kiko falou, esse tipo de trabalho não dá certo com a metodologia de ford.

Bom… não consigo pensar dessa forma (sim, mentalidade fordista). Fale mais, o que muda no contexto da sua empresa?

[]'s

A mentalidade fordista não funciona com desenvolvimento de software justamente porque o trabalho do programador não é operacional. Nessa metodologia o desgaste com o tratamento do programador como “peão” leva a empresa a perder produtividade.

Aqui tem um artigo sobre:

http://xprogramming.com/articles/jatsustainablepace/

Julio, eu não enxergo dessa maneira, até porque, não é ofensa chamar um membro operacional da empresa de membro operacional. “Peão” é um termo pra isso. Pode ser considerado pejorativo? Com certeza. Mas qualquer outro nome que você der vai continuar caracterizando a pessoa como membro operacional da empresa (a não ser, é claro, que seja uma pessoa de papéis flutuantes).

Mas calma que eu ainda vou ler o texto

[]'s

juliocbq:

Mas é justamente isso que coloco em xeque. “Digitador” ou “programador”?

Pra mim, nenhum dos dois, na verdade. Profissional de software (por causa da história de papéis flutuantes, que quase todos temos).

[]'s

Alexandre Saudate:

juliocbq:

Mas é justamente isso que coloco em xeque. “Digitador” ou “programador”?

Pra mim, nenhum dos dois, na verdade. Profissional de software (por causa da história de papéis flutuantes, que quase todos temos).

[]'s

Mas então, de acordo com Ford o “programador” nesse caso está mais para “digitador” se for encarado como recurso operacional. Dessa maneira se perde uns 40% da do potencial do profissional envolvido.

juliocbq:

Alexandre Saudate:

juliocbq:

Mas é justamente isso que coloco em xeque. “Digitador” ou “programador”?

Pra mim, nenhum dos dois, na verdade. Profissional de software (por causa da história de papéis flutuantes, que quase todos temos).

[]'s

Mas então, de acordo com Ford o “programador” nesse caso está mais para “digitador” se for encarado como recurso operacional. Dessa maneira se perde uns 40% da do potencial do profissional envolvido.

Bom… como eu disse, eu encaro mais como o reflexo produzido pelo trabalho dele do que pura e simplesmente como um cara que faz atividades repetitivas ou não.

Acho que o Alexandre mudou um pouco o foco da discussão.

Entendi o que ele disse e até concordo. Supomos que haja uma empresa de arquitetura (arquitetura mesmo), que vende os seus projetos às empresas que irão executar a obra. Nesse caso o operacional são os arquitetos, logo os arquitetos são os peões. Enquanto marketing, diretoria etc… formam as outras áreas que o Alexandre citou.

Ok, sem problemas, nesse caso nós programadores somos os peões mesmo e não há o menor problema nisso.

Mas, como eu disse, o foco da discussão foi mudado. O que estamos discutindo é especificamente no ambiente de desenvolvimento, tira-se de discussão qualquer outra parte da empresa, marketing, direção, administração, nada disso vem ao caso no nosso contexto.

E é nesse contexto específico de desenvolvimento de software que o termo peão para o programador é péssimo. Péssimo porque é usado para demonstrar a hierarquia que vai do peão ao gerente de projeto, passando pelo analista de sistemas, analista de negócios e qualquer outro papel que se ponha no meio.

E dessa hierarquia vem a ideia de que se pode contratar programador a preço de banana, guardando o “grosso” do salário para “aqueles que pensam”. E esse é um caminho curto pro fracasso, invariavelmente. Os analistas não conhecem a fundo a infra-estrutura na qual a sua solução maravilhosa será implementada, e nem se importam. Enquanto o programador não tem ideia de para que aquele código que ele está escrevendo vai servir, e nem se importa.

Isso resulta num telefone sem fio que destrói o projeto, gera stress, acusações de um lado e de outro, funcionalidades mal implementadas porque foram planejadas sem levar em conta a ferramenta com a qual vai se trabalhar ou porque foram desenvolvidas sem a ideia clara de para que vão servir. Infelizmente isso ainda é regra e não exceção hoje em dia.

E é nessas circunstâncias que o termo peão é terrível, porque serve para sustentar esse modelo fracassado. Tão fracassado que nunca funcionou, embora insistam nele pelo desconhecimento de outro. E mesmo insistindo a coisa só começa a andar quando o caos toma conta e chega um programador com experiência pra assentar a poeira e fazer a coisa andar.

Mas quando se começa outro projeto lá está o Ford de novo, e aquele programador que salvou o projeto, agora foi promovido a analista, e feliz com a promoção não põe mais a mão no código porque mexer em código é coisa de peão. E assim o ciclo se repete.

Então o problema não é o termo, mas o modelo que ele representa dentro do contexto específico de desenvolvimento de software.

sim, este é um modelo que aparece bastante em fábricas de software. Essas empresas vendem projetos de software e não produtos com valor agregado. Por isso citei o termo “digitador”.

– Os comentários deste fórum devem conter algo construtivo para o aprimoramento do conhecimento. By Lina –

– Os comentários deste fórum devem conter algo construtivo para o aprimoramento do conhecimento. By Lina –

– Os comentários deste fórum devem conter algo construtivo para o aprimoramento do conhecimento. By Lina –

– Os comentários deste fórum devem conter algo construtivo para o aprimoramento do conhecimento. By Lina –

Na verdade temos que ter o conhecimento das regras para aplicá-las no código, mesmo que programadores implementem as regras, também podemos elaborar idéias ou sistemas da mesma forma e não só implementar.

SE VOCE TRABALHAR PELO MODELO DO RUP ESTÁ 100% CORRETO. :lol:

po até que é legal a comparação.
Quem nunca se imagino cavalgando no eclipse se preparando para laçar e derrubar bug assim que acha-lo.
Organizando as paginas JSF no curral para dar um trato nela passando Ivomec em cima para tirar os parasitas que impedem da pagina de crescer.
Ou ainda melhor, ver se o software aguenta ficar 8 segundos em pé assim que sobe para produção, pura emoção.

Enfim, so falei isso pq não me incomodo com terminologia, afinal dependendo do ponto de vista todos trabalhos podem parecer como peão.

Programador é peão sim. Veja a descrição do cargo no wikipedia…

Em informática, todas as atividades são infelizes, mas programador é uma das mais tristes, pois é difícil e pouco gratificante. Programador é igual a um operário da época revolução industrial, pois é tratado como um apertador de parafusos e não tem voz nenhuma nos negócios da empresa, só faz, obedece, deprimente!

Qualquer um que passou por programador vomita ou chora por estar numa posição tão humilhante, só não chora porque nunca esteve em posições melhores e portanto não sabe o quão lá embaixo estava, na minha empresa, até vendedores mandam no programador… deprimente demais.

Honestamente, de que importa se alguem acha que vc e um peao, programador, analista, faxineiro, cavaleiro jedi? Eu acho que o que importa e vc estar satisfeito com seu trabalho e o seu contra-cheque. Todo o resto e mimimi.
Alem disso, como ja foi dito, as pessoas que pensam da forma descrita por vc, estao pelo menos uns 10 anos atrasados.

[]'s