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

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?

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.

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

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.

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.

• 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 .

• 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.

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).

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.

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.

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?