Como é o trabalho de um programador?

A resposta é um grande DEPENDE. Isso pode variar de empresa para empresa. Você pode tanto trabalhar em migração de enormes sistemas legados em COBOL ou desenvolver app’s para smartphones.

Os dois.

Os dois.

Os dois.

Pegar problemas pra resolver, implementando algo novo ou corrigindo algo que já existe.
Aprender sempre.

[voz do Sergio Chapelin mode: on]
O trabalho de um programador, suas atividades, seus momentos bons, suas horas ruins. Quem são eles? Onde eles vivem? São seres solitários? Eles dormem? Vão para a balada? Não perca, sexta, no guj repórter
[voz do Sergio Chapelin mode: off]
A função de um programador é desenvolver códigos com base em especificações e normas definidas. Este desenvolvimento deve abranger o conhecimento próprio do mesmo e pesquisas, para agregar novas informações. Será regrada por todo o conjunto de normas e leis que possam recair sobre a atividade e sobre o produto final desenvolvido.
Esta função poderá ser direcionada para criar novos sistemas ou manter os que já existem.

Nossa vida seria bem mais fácil se isso fosse verdade. Na maioria dos caso, nós mesmo temos que ir atrás das especificações do sistema.

rmendes08:

A função de um programador é desenvolver códigos com base em especificações e normas definidas (…)

Nossa vida seria bem mais fácil se isso fosse verdade. Na maioria dos caso, nós mesmo temos que ir atrás das especificações do sistema.

Sei bem o que você está falando, já trabalhei em lugares onde nós precisávamos ser canivetes suíços, desde web designer até DBA, passando por analista de negócios, de sistemas e de testes. De vez em quando, até fazer café e controlar estoque…

rmendes08:

A função de um programador é desenvolver códigos com base em especificações e normas definidas (…)

Nossa vida seria bem mais fácil se isso fosse verdade. Na maioria dos caso, nós mesmo temos que ir atrás das especificações do sistema.

Neste caso, na verdade, o correto seria definir-se como desenvolvedor. O programador desenvolve à partir das normas. Só faz o código e mais nada. O desenvolvedor, reiterando este, também cuida das especificações, como propriamente dito. A grande diferença entre programador e desenvolvedor é essa.

Cara, alguém aqui realmente acha graça em pegar um UML pronto e transcrever para código ? Alguém acha que fazer esse tipo de serviço vale + q R$ 800,00 no mês ?

Depende, como já fora dito. Respondendo suas perguntas de acordo com a empresa onde trabalho:

Tipo, tem que criar programas do zero com seu próprio conhecimento ou já pega códigos prontos para consertar ou modificar?
às vezes. Mas, na maioria das vezes, tenho que começar do zero.

Fica pesquisando APIs durante muito tempo ou a maior parte do tempo utiliza o q já sabe?
quando não sei algo, ou pesquiso ou consulto o nosso analista, que é veterano na área.

Normalmente os projetos são fáceis de desenvolver ou tem que matar um leão por dia?
Isso depende. Não há como dar uma resposta concreta.

Como é mais ou menos a rotina de trabalho de um programador?
depende também. Há dias em que rende, há dias em que você fica agarrado em um problema, e esses últimos são horríveis, chatos e cansativos. Em empresas mais flexíveis, que lhe permitem “descansar” de tempo em tempo, para não ficar algo muito massante, as coisas correm melhores. Dores de cabeça no fim do dia são frequentes, muito estresse e tudo mais, mas o salário é bom.

Eu, por exemplo, tenho livre árbitro de decidir o que acontecerá ou não no aplicativo que desenvolvo. É melhor assim, rende mais e é menos cansativo. Tive que desenvolver uma solução PAF-ECF, seguindo um roteiro do governo, coisa de mais de cem páginas. Foi horrível. Muito estresse, muita dor de cabeça e dificuldade de interpretação. O roteiro é muito mal escrito.

rmendes08

cara, pode até ser fácil assim, até a hora que vc pegar uma alteração de 10 linhas de análise, e entrar em um código com 5 mil linhas de cálculo de imposto e o carai*** a 4, e demorar 1 dia só pra entender e mais uns 3 dias pra fazer e testar tudo, dai vc muda de opnião, e vai querer muito mais que 800 por mês, senão não vai valer os cabelos brancos…

eduJava:

rmendes08

cara, pode até ser fácil assim, até a hora que vc pegar uma alteração de 10 linhas de análise, e entrar em um código com 5 mil linhas de cálculo de imposto e o carai*** a 4, e demorar 1 dia só pra entender e mais uns 3 dias pra fazer e testar tudo, dai vc muda de opnião, e vai querer muito mais que 800 por mês, senão não vai valer os cabelos brancos…

e os bugs do nosso browser preferido? kkkk

Eu geralmente tenho que matar vários leões por semana.
E não trabalharia numa empresa que não fosse assim.

Quer coisa fácil? Depois não reclame de ganhar pouco.

Em certas áreas o valor do salário é proporcional ao esforço desprendido para realizar a tarefa.
Digo determinadas por que profissões como futebol e “político” não é assim.
Já com engenharia, direito, medicina, análise e desenvolvimento de sistemas pode ser, mas nem sempre é.
Tem muita gente que trabalha demais e recebe de menos.

" se nao ganho pelo que faço posso fazer pelo que ganho?"

nao tenho reclamação nenhuma da empresa onde eu trabalho… Graças ao pessoal do GUJ e os cursos que eu fiz na Caelum consegui uma vaga bem interessante de analista. Trabalhamos com PHP, Java e Javascript.

Aprender é quase rotina constante. E como o ViniGodoy disse, “varios leoes por dia”.

Meu professor de algoritmos 1 dizia: “enquanto nao estiver sonhando com isso, estude mais pq ainda esta muito pouco! quer algo facil? curso x é na sala ao lado”

obs. ele gritava na parte de falar o nome do curso x kkkk

Meu primeiro chefe me disse que a recompensa por um bom trabalho, é mais trabalho, então acho que fica a critério de cada um.
Se quer ser reconhecido, e principalmente se gosta do que faz, provavelmente vai gostar de ter que encarar desafios semanalmente.

Não falei pelo volume, mas pela complexidade do trabalho.

Se você só quer fazer CRUD simples, ou sistemas que todos sabem fazer, provavelmente vai estar num mercado com mais ofertas de programadores (dependendo do quão simples forem esses sistemas, pode estar até num mercado onde um “sobrinho” é um concorrente em potencial).

E quando a oferta é grande, o preço (do seu salário) cai.

E, claro, empresas de programadores “operacionais” os tratam como tal. Então não se impressione também se em pouco tempo te entupirem de trabalho.
Não haverá nenhum desafio técnico significativo, exceto o de entregar muita coisa em pouco tempo.

Não é pra ser divertido mas sim para facilitar a substituição do recurso por outro igual, caso este venha faltar.

É mais fácil encontrar programadores que sabem framework x, y e z, do que digamos, alguém com habilidade para se relacionar com clientes da empresa.

Não é pra ser divertido mas sim para facilitar a substituição do recurso por outro igual, caso este venha faltar.

É mais fácil encontrar programadores que sabem framework x, y e z, do que digamos, alguém com habilidade para se relacionar com clientes da empresa.

Não é questão de ser divertido, é questão de sentir-se motivado. Além do mais, essa história de que basta ter diagramas UML que um novo programador será 100% produtivo assim que pisar na empresa é papo pra boi dormir. Pessoas são mais importantes que processos, e esse é um paradigma que vem sendo adotado não só por empresas que adotam Agile, mas por qualquer corporação moderna. Uma rápida pesquisa sobre a expressiva valorização dos departamentos de RH e sobre a valorização dos gerentes e executivos de RH é mais do que suficiente.

Sobre a separação analista X programador, isso também é pura bobagem. É coisa de alguém que fumou um baseado muito forte e comparou desenv. de software com engenharia civil. Desenvolv. de software tem que ter seu próprio manual de boas práticas, e entre elas está a aproximação de cliente e programador, melhor ainda é a comunicação direta entre eles. Isso é tão verdade que muitos empresários de hoje começaram justamente como programadores, indo a campo, conversando com clientes e construindo o sistema ao gosto do freguês.

rmendes08:

Não é questão de ser divertido, é questão de sentir-se motivado. Além do mais, essa história de que basta ter diagramas UML que um novo programador será 100% produtivo assim que pisar na empresa é papo pra boi dormir. Pessoas são mais importantes que processos, e esse é um paradigma que vem sendo adotado não só por empresas que adotam Agile, mas por qualquer corporação moderna. Uma rápida pesquisa sobre a expressiva valorização dos departamentos de RH e sobre a valorização dos gerentes e executivos de RH é mais do que suficiente.

Nem todas pessoas são mais importantes que todos os processos da empresa. Na verdade, pessoas importantes para empresa não são contratadas pelo RH, que é o departamento de RECURSOS humanos.

rmendes08:

Sobre a separação analista X programador, isso também é pura bobagem. É coisa de alguém que fumou um baseado muito forte e comparou desenv. de software com engenharia civil. Desenvolv. de software tem que ter seu próprio manual de boas práticas, e entre elas está a aproximação de cliente e programador, melhor ainda é a comunicação direta entre eles. Isso é tão verdade que muitos empresários de hoje começaram justamente como programadores, indo a campo, conversando com clientes e construindo o sistema ao gosto do freguês.

Não. É coisa de alguém que chegou a conclusão que TI é mais sobre lustrar as bolas do cliente do que desenvolver software complicado. Como programador concordo que é uma merda, mas é a realidade. Hoje em dia qualquer adolescente que nem saiu de casa consegue, com as ferramentas corretas, realizar o serviço típico exigido em TI.