Expectativas de pós-graduação versus realidade [fechada]

50

Ao escolher o que queremos estudar e fazer com nossas carreiras e vidas, todos temos algumas expectativas de como será. Agora que estou no setor há quase uma década, tenho refletido um pouco sobre o que eu pensava (quando eu estudava Ciência da Computação) como seria a vida profissional de programação e como está realmente se saindo. estar.

Meus dois maiores choques (ou melhor, expectativas quebradas) são, de longe, a grande quantidade de trabalhos de manutenção envolvidos no software e a falta geral de profissionalismo:

  1. Manutenção : na uni, todos nos disseram que a maioria do trabalho de software é a manutenção de sistemas existentes. Então, eu sabia esperar isso em abstrato. Mas nunca imaginei exatamente como isso seria esmagador. Talvez seja algo em que eu olhei mentalmente, e esperava que estivesse construindo coisas novas e legais do zero muito mais. Mas, na verdade, a maioria dos trabalhos é predominantemente orientada para manutenção, correção de bugs e suporte.

  2. Falta de profissionalismo : Na uni, sempre tive a impressão de que o trabalho de software comercial é muito orientado a processos e rigorosamente projetado. Eu tinha imagens de processos ISO, resmas de documentação técnica, todos os recursos e bugs sendo rigorosamente documentados e um ambiente geralmente profissional. Foi um choque enorme perceber que a maioria das empresas de software não opera de maneira diferente para uma equipe de estudantes trabalhando em um grande projeto de semestre. E eu trabalhei na pequena loja ágil de hackers e na empresa corporativa de tamanho médio. Embora eu não diga que sempre foi totalmente "não profissional", parece definitivamente que a indústria de software (em geral) está longe da forte disciplina de engenharia que eu esperava que fosse.

Alguém já teve experiências semelhantes a isso? Quais são as maneiras pelas quais suas expectativas sobre como seria nossa profissão eram diferentes da realidade?

Bobby Tables
fonte
4
Como um estudante quase fora da universidade, essa é uma pergunta muito interessante!
Mal
8
O que você está vendo agora é a realidade. Outros fatos engraçados que também pertencem à realidade são: bilhões de pessoas sem comida, analfabetos, sob a constante ameaça de guerra, mercado financeiro próximo ao colapso, etc. Em outras palavras, a faculdade é um maravilhoso campo de distorção da realidade, e as pessoas podem aprenda muito conhecimento em livros didáticos dentro da proteção desse campo.
rwong
Você deve esperar o que quiser. Se for algo menos do que você esperava, não aceite isso como realidade. Seja um pioneiro e torne suas expectativas realidade!
Atomix
11
Eu amo programação. Eu odeio a realidade de como o software está sendo desenvolvido no mundo "real". O que você descreve é ​​uma descrição bastante precisa do estado das coisas na indústria de software.
Capitão Sensible
Como Fresh Jr.Engenheiro de software, também estou experimentando isso, pensei que fosse apenas no meu país, agora estou recebendo o recurso Não-escrito de Desenvolvimento de software.
Parmanand 20/11

Respostas:

27

Eu sinto você cara. Acabei de me formar há pouco mais de um ano, de fato, pulei na primeira oferta de emprego que apareceu no meu caminho e teve o maior choque da minha vida.

Coisas que eu não esperava:

O estresse escolar e o estresse no trabalho não são os mesmos - o estresse de trabalhar em um projeto da escola com os amigos ou trabalhar sozinho, mesmo com o prazo final da tese ou a defesa do projeto especial, não se compara ao estresse de prazos de trabalho aparentemente irracionais, problemas de comunicação , (um pouco da política do escritório) e tempos difíceis.

Falta de melhores práticas - Igual à sua experiência em profissionalismo. Antes de assumir meu primeiro emprego e durante meu período de treinamento, comecei a revisar e ler sobre as melhores práticas em programação e engenharia de software. Elas não são seguidas tão bem quanto deveriam por razões práticas e, para ser justas, práticas. E, às vezes, seu conhecimento conta muito pouco contra outros que têm apenas medo do desconhecido e tratam essas práticas com desdém.

O que eles ensinaram na escola era apenas a ponta do iceberg - pensando que o que eu aprendi estudando sozinho e nas aulas foi suficiente para me fazer passar, fiquei chocado ao dizer o mínimo, enquanto olhava estupefato para o primeiro pedaço de código que eu era. deveria manter. Muitas das habilidades que uso agora foram aprendidas no trabalho ou durante o meu trabalho, que continuo me perguntando se eu poderia ter conseguido sem um diploma universitário. XD

A importância da comunicação - me fez perceber o que eram todas aquelas aulas de inglês. Antes do mundo real, eu não conseguia ver a relevância de ter três a quatro aulas de inglês diferentes na faculdade quando isso é ensinado desde que estávamos na primeira série. Você não adianta em seu trabalho quando pode conversar com um computador, mas falha em conversar com as pessoas.

Jonn
fonte
5
+1 A importância da comunicação. Quanto ao número 2, não é a falta de boas práticas; é (i) muitas melhores práticas, e (ii) prevalece a falta de interesse em seguir qualquer.
Rwong 18/10/10
11
+1 para a ponta do iceberg! Tantos graduados pensam que sabem tudo, agora sinto que sei menos do que nunca!
billy.bob
+1 Alguns bons pontos aqui. Freqüentemente, o motivo da falta de práticas recomendadas / sistemas / procedimentos é o 'custo' inicial (ou seja, requer gastos de capital para compra) - mas o preço por não tê-los é maior manutenção ou, pior ainda, falha do produto por meio de listas de erros descontrolados ou que não satisfaçam os requisitos .. que uma boa comunicação pode ajudar a evitar :-)
JBRWilkinson
2
Eu gosto desta resposta. É um bom. E isso me faz pensar: por que não existe algum tipo de "estágio" como todos os médicos precisam passar? Uma zona de transição profissional longa e séria, onde alguém pode estar envolvido, mas não no caminho crítico de qualquer projeto. Algumas grandes empresas podem ter isso, mas simplesmente não é um padrão universal nessa profissão. No entanto, o trabalho de muitos programadores / desenvolvedores de SW / engenheiros de SW é tão perigoso e crítico para organizações de todos os tipos, quanto o que os médicos fazem por indivíduos.
darenw
11
Se possível, eu daria um +1 extra para a ponta do ponto de iceberg!
darenw
18

A maior parte do trabalho que você faz não é inovadora

Na Uni, trabalhei em rotinas de IA para controlar robôs que jogavam futebol, construí compiladores e hackeava os kernels do sistema operacional.

Mas no mundo real, 99% * do desenvolvimento de software é realmente muito chato. Sempre admirei arquitetos ou construtores que, quando perguntados "o que você faz da vida?" pode apontar para um prédio ou qualquer outra coisa e dizer "eu fiz isso ". Mas a maioria dos desenvolvedores de software não pode fazer isso. Quando perguntado "o que você faz da vida?" o mais próximo do que eu já pude chegar é quando eu trabalhava para uma empresa que construía software que processava mensagens SMS para estações de rádio e coisas assim ... eu poderia dizer: "você sabe quando envia uma mensagem para uma estação de rádio para votar em uma música, eu escrevi o software que processa esses votos e outras coisas ". Ainda não é tão legal quanto apontar para um prédio e dizer "eu construí isso".

É claro que existem pessoas que podem dizer "trabalhei no Windows" ou o que quer que seja, mas tenho certeza de que não dizem a ninguém que, por medo da próxima pergunta, seja "não consigo fazer minha impressora funcionar, você pode consertar isso para mim? "


* e 62% de todas as estatísticas são feitas no local

Dean Harding
fonte
11
isso é verdade, mas não inovar não significa que não seja crucial ou importante. Existem muitos aplicativos que não são inovadores que, sem suporte e correções, podem falhar, diz a nossa economia (no lado extremo ...) ... mais sempre haverá inovações dependendo do projeto de tempos em tempos ...
aggietech
3
Muitos de nós abrem novos caminhos todos os dias. Pode não ser a cura para o câncer, mas celebramos os pequenos triunfos com cinco em toda a volta, uma rodada de bolos / muffins / rosquinhas, etc., para marcar o momento. Muitos trabalhos, não apenas de programação, não têm uma saída que você possa mostrar aos seus amigos / familiares, mas isso é uma questão de enquadramento: você pode dizer "Eu configuro comutadores de rede, servidores DNS e firewalls" ou pode refazer esta frase como "Você conhece a internet - Facebook, YouTube, Twitter e tudo isso? Bem, eu ajudo a fazê-lo funcionar".
JBRWilkinson
11
@JBRWilkinson: +1. O melhor caso de "re-enquadramento" que tive foi em um trabalho anterior, onde trabalhei no software de bip de hospital NurseCall. Você poderia dizer algo genérico sobre isso, como "escrevi programas que executam bipes". OTOH, você também pode dizer "Eu escrevi um software que ajudou os hospitais a funcionarem melhor e provavelmente salvou vidas !!". Não tinha pensado nisso até agora ... mas estatisticamente é provavelmente verdade. Na verdade, me sinto muito melhor com esse trabalho agora. ou seja, esse software entrou em produção mais cedo, graças ao meu esforço, etc. Pode realmente ter salvado vidas. :)
Bobby Tables
11
@ Guzica: Que você pode ser / contribuir para salvar vidas diariamente é provavelmente a melhor satisfação no trabalho que alguém pode ter - bem feito!
JBRWilkinson
11
Haha, resposta excelente e +1 por ter senso de humor!
Captain Sensible
17

Se você olhar o software hoje, através das lentes da história da engenharia, certamente é um tipo de engenharia - mas é o tipo de engenharia que as pessoas sem o conceito do arco fizeram. Atualmente, a maioria dos softwares é muito parecida com uma pirâmide egípcia com milhões de tijolos empilhados uns sobre os outros, sem integridade estrutural, mas apenas executados pela força bruta e milhares de escravos. -Alan Kay, 2004

a entrevista completa: http://queue.acm.org/detail.cfm?id=1039523

Eu não sou veterinário da indústria; Muito pelo contrário, sou recém-formado, mas de uma das melhores escolas de CS dos EUA. Mas meu sentimento instintivo é que a maneira como construímos software está errada. Em vez de pressionar o botão de pausa e reexaminar os fundamentos de como programamos, acabamos avançando usando modelos datados dos anos 50 e 60, adicionando continuamente um pouco de açúcar por cima. Se continuarmos assim, nunca passaremos de onde estamos. Os seres humanos simplesmente não conseguem gerenciar a complexidade de coisas do tamanho da base de código do MS Windows. Precisamos de um novo caminho. Não sei o que é isso

Penso que esta é a razão subjacente para o sentimento de que grandes e pequenas lojas de software parecem produzir software cortando tudo juntos, sem nenhum entendimento profundo dos princípios fundamentais.

maharishi
fonte
Como um graduado relativamente recente, tenho a impressão de que a maneira como muitos lugares desenvolvem software está errada, mas que meu local de trabalho atual é ... não perfeito, mas eles tentam, e funciona muito melhor . Certamente parece haver muitos lugares que adotam uma abordagem horrível de "força bruta" ... mas se você estiver em um desses lugares, considere procurar outro lugar.
11
O desenvolvimento de software como um todo é um processo evolutivo, não revolucionário. Claro, você poderia construir uma estrutura de pirâmide a partir de nanotubos de carbono em teoria, que é mais forte, mais durável e mais leve do que as pirâmides egípcias em teoria. Mas não é prático ou viável fazê-lo. Se o local em que você está trabalhando é muito ruim, encontre um novo emprego. Caso contrário, não fique muito envolvido com a perfeição, porque trabalhos de programação reais têm restrições reais (como tempo / financiamento). Lembre-se de que "na teoria, teoria e prática são iguais. Na prática, não são".
quer
>>> Precisamos de um novo caminho. Não sei o que é isso - Nem mais ninguém, assim continua!
Gary Willoughby
5

Não me formei, mas peguei um pouco nas bibliotecas e laboratórios de faculdades e universidades.

  • Big Iron - As tecnologias que eles estavam ensinando eram principalmente mainframes e minicomputadores. O reitor de uma faculdade me disse que eu não conseguiria um emprego porque nem sabia o que era um arquivo mestre. Eu não tinha intenção de trabalhar em mainframes, já que não podia pagar um, mas não seria tão tolo a ponto de não estar um pouco preparado. O VAXen foi legal e eu estava ansioso para receber o código do meu próprio Micro VAX no meu cubículo. Que pena que o mercado tenha implodido totalmente. (Como se viu, eu tinha dois cargos trabalhando com mainframes ... como contratada pela IBM.)

  • Engenharia de software - Na esteira da programação estruturada, SASD e outras metodologias de design, você pode ter pensado que seríamos engenheiros de verdade. Eu fiz. Mas os professores estavam dando muito pouca orientação sobre as técnicas de design que li na biblioteca. Os alunos foram deixados para cuidar de si mesmos e os micros tornaram muito fácil a codificação até obterem uma resposta com a qual estavam satisfeitos. Não percebi o quanto era pior no mercado de trabalho. De alguma forma, eu pude criar um pouco de código novo, então não era tão chato. Mas eu também assumi muito, e eles eram ruins o suficiente, era como um novo projeto, porque eu tinha que consertar muito código. Foi uma combinação de pesquisa da funcionalidade existente e criação de novo código (sua substituição); ferramentas de redação para simplificar o processo e instituir um melhor gerenciamento de projetos.

  • Carreira de alta tecnologia - Uma coisa é quando as escolas têm prédios e equipamentos antigos (o equipamento de cartões perfurados foi substituído no semestre antes de eu começar ... em 1984), mas quando você está trabalhando em um armazém mal iluminado ou para um chefe que desliga nos clientes que ligam para a linha de suporte, você começa a perceber que a descrição de seu trabalho provavelmente não inclui pipocas de cozinha com um laser de 5 megawatts.

Huperniketes
fonte
5
  • Desenvolvimento é principalmente trabalho em equipe. Isso significa que a comunicação (falada e lida), a leitura do código de outras pessoas e a reutilização dos módulos anteriores (internos e externos) são algo a ser enfrentado quase todos os dias. Na minha faculdade, pelo menos eu tive que codificar com mais pessoas em poucas ocasiões, então pensei que a parte principal do trabalho era codificar sozinha, no deserto. Não é.
  • Explicar as coisas para os não desenvolvedores é difícil (também abordado no primeiro ponto) e é sua responsabilidade apresentar seus argumentos (não nos outros 99% do mundo).
  • O bom teste é o teste que falha. (pela primeira vez, pelo menos) E, é claro, não existe um código sem erros. Você não é um programador ruim se tiver bugs. Os erros são apenas uma parte (muito importante e demorada) do seu trabalho.
  • Não há balas de prata. Cada tecnologia tem suas vantagens e desvantagens.
  • A faculdade não ensina tecnologias de ponta. Mas também 90% das obras utilizam tecnologias bastante antigas. Que, a propósito, às vezes é o que é necessário.
  • Pessoas não técnicas tomam decisões sobre soluções técnicas , principalmente por razões esotéricas, como manutenção, parceria, disponibilidade do trabalhador ...
  • Você está apenas começando , jovem padawan .

Desde então, comecei a perceber o fato de que a codificação é um trabalho que você faz em conjunto com mais pessoas, especialmente agora que o código aberto é mais proeminente. Mas quando eu estava na faculdade (final dos anos 90), eu estava convencido de que iria fazer as coisas do zero e nunca procurar no código dos outros ou ter que me coordenar com os outros ...

Olhando para trás, para mim, uma das melhores partes é aprender e ensinar aos outros .

Khelben
fonte
"A faculdade não ensina tecnologias de ponta.": Sim e não. Em alguns campos, a academia está 20 a 30 anos à frente da indústria, e você aprende um pouco disso na faculdade.
Giorgio
3
  • A programação de computadores não é física nem intuitiva.
    • Quando um construtor de casas termina seu trabalho, ele pode passear e ver / sentir imediatamente se há algo errado. Um erro de programação de computador não pode ser descoberto da mesma maneira e pode estar oculto no sistema por meses ou até décadas.
    • Enquanto um programador pode parecer / sentir um pedaço de código-fonte através da revisão de código, não é garantido detectar todos os erros contidos no código. Um computador, no entanto, seria capaz de reproduzir exatamente o erro todas as vezes executando o programa com determinadas entradas. Assim, a compreensão humana de um pedaço de código-fonte é sempre um modelo imperfeito da essência de ser as instruções para um computador.
  • É muito fácil codificar um programa que lida com os casos mais comuns, mas falha completamente com os casos extremos.
    • Em outras disciplinas, é relativamente fácil aplicar uma ação corretiva após o fato. Pode até haver um corpo de conhecimento especificamente dedicado a ações corretivas. Não existe tal coisa no desenvolvimento de software.
    • Felizmente, o desenvolvimento orientado a testes ajuda a codificar os casos extremos que o código deve tratar.
    • Adicionado Por outro lado, certas metodologias de desenvolvimento de software parecem sugerir que podemos extrair valor de negócios (tempo mais rápido ao mercado, etc.) por escolher conscientemente para não casos de ponta punho, e para comunicar essas decisões para os clientes.
  • Os clientes podem encontrar valores de negócios em um software que lida apenas com os casos mais comuns; portanto, os fornecedores de software não estão muito preocupados em lidar com casos raros.
    • Os clientes simplesmente aprendem a evitar as arestas.

Adicionado

  • A elegância do código fonte não é valorizada.
    • Os clientes não veem a elegância do código fonte. Eles vêem apenas a elegância da interface do usuário e das interações.
    • Os programadores, por outro lado, geralmente não valorizam a elegância da interface do usuário e geralmente não permanecem em um único projeto por um tempo suficiente para começar a apreciar um design de software elegante.
    • Como nem clientes nem programadores valorizam a elegância do código-fonte, nem serão valorizados pelas empresas.

Adicionado

Meus dois centavos: apenas se acostume.

rwong
fonte
8
construção de casas em comparação com a correção de bugs, hmm? "Ei, acabei de virar a maçaneta da porta na direção errada e a casa desapareceu!"
xor_eq
3

Imagens de processos ISO, resmas de documentação técnica, todos os recursos e bugs sendo rigorosamente documentados e um ambiente geralmente profissional descreve minha empresa bastante bem. Fazemos produtos críticos de infra-estrutura de software / hardware, porém, assim, bem, a pressão é sobre para a qualidade (estamos ISO 9001, por exemplo).

Paul Nathan
fonte
11
@Guzica: Uma das empresas em que trabalhei era bastante orientada para a engenharia. Não possui certificação ISO9001, mas segue processos internos bastante rigorosos. Os outros eram, como já disse - não mais organizados do que um grupo de estudantes de CS fazendo um projeto final do ano juntos.
Bobby Tables
2

Depois de me formar, pensei que os responsáveis ​​seriam capazes de reconhecer o bom trabalho do mau trabalho. Depois de receber a milionésima cópia de "realmente ótimo código, nosso codificador de topo", e com a seguinte aparência:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Quase desisti de tentar entender o que se passa entre os ouvidos do chefe de cabelos pontudos. "Ótimo" significa pesadelo de manutenção, "bom" significa colisões com uma brisa suave e "bagunça horrível" significa isso ou uma base de código bem estruturada cujos engenheiros se recusaram a cumprir prazos obscenos para manter sua sanidade.

wheaties
fonte
1

Ouvi dizer que toda a engenharia de software após a primeira linha de código é de manutenção. E isso certamente parece coincidir com a minha experiência. O único código que escrevi que não acabou tendo a maior parte de seu custo sendo manutenção foi um código tão mal sucedido que nunca foi ou apenas usado brevemente.

Eu acho que você pode encontrar equipes de engenharia divergentes que desenvolvem e seguem processos fortes que levam ao lançamento de código robusto, no qual a equipe pode ter um alto nível de confiança (embora eu não o tenha envolvido com grandes quantidades de documentação). Acredito que trabalho em uma equipe como essa no momento. Embora eu tenha experimentado certamente outro tipo de desenvolvimento.

Porém, o que eu pude apreciar é que o desafio nem sempre é encontrar o algoritmo perfeito ou a solução mais limpa para o problema. Mas, muitas vezes, negociando todos os tipos de restrições (recursos, conhecimento, dinheiro, tempo, habilidades, risco, treinamento pré-existente do usuário etc.) para obter o maior retorno do investimento disponível. Isso é construir um sistema que seja mais adequado a todos esses fatores e não apenas às influências técnicas.

flamingpenguin
fonte
Muito bons pontos. Duas das médias / grandes empresas em que trabalhei mostraram um forte contraste entre esses dois casos. Um deles era fortemente orientado para a engenharia, e o outro funciona mais como um grupo de equipes de estudantes do CompSci fazendo projetos separados do último ano em suas próprias bolhas - e, de alguma forma, tendo que integrar o material mais tarde. (Nota: Gestão realmente suporta essas "bolhas" - nome real - pensando que é mais eficiente para as equipes a trabalhar separadamente do que se preocupar com a integração durante o desenvolvimento Eu não estou brincando..)
Tabelas de Bobby
1

Muitos softwares simplesmente não chegam ao ponto em que são usados ​​/ comprados o suficiente. Quando alguém faz isso, ele tende a permanecer e só é "bagunçado" com a manutenção.

As expectativas do usuário estão aumentando todos os dias para os recursos, mas em muitas áreas, elas são mais baixas nas áreas de engenharia. Vamos supor que o software de transações bancárias seja tão sólido e profissionalmente projetado quanto um automóvel moderno. O manuseio do volume é uma maravilha moderna, mas qual é a confiabilidade de cada transação? Não muito. Seu post sobre a primeira porcaria do seu cachorro no tapete foi descartado, e daí. É mais como os saquinhos de plástico do supermercado. Eles fazem bilhões deles, rasgam e rasgam e são jogados fora. A maioria das pessoas não se importa o suficiente para exigir uma bolsa melhor.

Acho que software de qualidade é feito, eventualmente. Parte disso chega ao mercado mais cedo do que a maioria dos produtos comemorativos. Quem dirige um carro na versão Beta?

JeffO
fonte