Programador é peão?

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.

[quote=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
[/quote]

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.[/quote]

+1.

Verdade!

Verdade![/quote]
++

Agora você conseguiu ser pior do que o professor do cara.[/quote]

Meu Deus.
:stuck_out_tongue:

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.

[quote=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.[/quote]
Gostei da sua abordagem, também falo disso aqui: http://tekhton.blogspot.com.br/2013/02/e-o-programador-virou-pedreiro.html

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.

[quote]…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. [/quote]

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.

[quote=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.
[/quote]

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!

[quote=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.[/quote]

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.

[quote=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.[/quote]

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