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

Eu sinto você homem. Acabei de me formar há pouco mais de um ano, na verdade, pulei na primeira oferta de emprego que veio na minha direção e tive 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 escolar com amigos, ou trabalhar sozinho, mesmo com o prazo iminente da tese ou defesa de projeto especial, não se compara ao estresse de prazos de trabalho aparentemente irracionais, problemas de comunicação (um pouco de política do escritório) e crise vezes.

Falta de melhores práticas - O mesmo que a sua experiência em profissionalismo. Antes de fazer meu primeiro trabalho e durante meu período de treinamento, saí correndo para revisar e ler sobre as melhores práticas em programação e engenharia de software. Estes não são seguidos tão bem quanto deveriam por razões práticas e, por razões justas e práticas. E, às vezes, o seu conhecimento conta muito pouco contra os outros que têm apenas medo do desconhecido e trata essas práticas com desdém.

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

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

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

Quando na Uni, eu trabalhei em rotinas de inteligência artificial para controlar robôs jogando futebol, eu construí compiladores e hackeava kernels de sistemas operacionais.

Mas no mundo real, 99% ^* de desenvolvimento de software é realmente muito chato. Sempre admirei arquitetos ou construtores que, quando perguntados "o que você faz para viver?" pode apontar para um edifício 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 para viver?" o mais próximo disso que eu já vi foi quando eu trabalhava para uma empresa que construía um software que processava mensagens SMS para estações de rádio e coisas do tipo ... Eu poderia dizer: "você sabe quando você envia um texto para uma estação de rádio para votar em uma música, bem eu escrevi o software que processa esses votos e outras coisas ". Ainda não é tão perto quanto ser capaz de apontar para um prédio e dizer "eu construí isso".

Claro, existem pessoas que podem dizer "trabalhei no Windows" ou qualquer outra coisa, mas tenho certeza de que eles não contam a ninguém por medo de que a 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

If you look at software today, through the lens of the history of engineering, it’s certainly engineering of a sort—but it’s the kind of engineering that people without the concept of the arch did. Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -Alan Kay, 2004

a entrevista completa: link

Eu não sou veterinário da indústria; Muito pelo contrário, sou um graduado recente, mas de uma das melhores escolas de ciência da computação nos EUA. Mas meu sentimento instintivo é que a maneira como estamos construindo software está errada. Ao invés de apertar o botão de pausa e reexaminar os fundamentos de como nós programamos, nós apenas corremos para a frente usando modelos datados dos anos 50, 60s continuamente adicionando um pouco de açúcar por cima. Se continuarmos assim nunca chegaremos onde estamos. Os seres humanos simplesmente não conseguem gerenciar a complexidade das coisas que são do tamanho da base de código do MS Windows. Precisamos de um novo caminho. Eu não sei o que é isso.

Eu acho que esta é a razão subjacente para a sensação de que grandes e pequenas lojas de software parecem fazer softwares de hackers, sem qualquer compreensão profunda dos princípios fundamentais.

Eu não consegui um diploma, mas peguei um pouco em bibliotecas e laboratórios de faculdades e universidades.

• Big Iron - As tecnologias que estavam ensinando eram principalmente mainframes e minicomputadores. O reitor de uma faculdade me disse que eu não seria capaz de conseguir um emprego porque eu nem sabia o que era um masterfile. Eu não tinha intenção de trabalhar em mainframes desde que eu não podia pagar um, mas eu não ia ser tão tolo a ponto de não estar um pouco preparado. O VAXen era legal, e eu estava ansioso para ser pago para codificar no meu próprio Micro VAX no meu cubículo. Que pena que esse mercado implodiu totalmente. (Acontece que eu tinha duas posições trabalhando com mainframes ... como um empreiteiro da IBM.)

• Engenharia de Software - Nos saltos da Programação Estruturada, SASD e outras metodologias de projeto, você pode ter pensado que seríamos engenheiros reais. Eu fiz. Mas os professores estavam dando muito pouca orientação sobre as técnicas de design que eu li na biblioteca. Os alunos foram deixados para se defenderem sozinhos e os micros fizeram com que fosse muito fácil manejar códigos até que eles obtivessem uma resposta com a qual estivessem satisfeitos. Eu não percebi o quão pior era no mercado de trabalho. De alguma forma eu consegui fazer 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 de funcionalidade existente e criação de novo código (sua substituição); ferramentas de escrita 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ão perfurado foi substituído no semestre anterior ao início… em 1984), mas quando você está Trabalhando em um armazém mal iluminado ou para um chefe que desliga os clientes ligando para a linha de apoio, você começa a perceber que a descrição do seu trabalho provavelmente não inclui cozinhar pipoca com um laser de 5 megawatts.

• O desenvolvimento é principalmente o trabalho em equipe. Isso significa que a comunicação (falada e lida), a leitura do código do outro e a reutilização de módulos anteriores (internos e externos) é 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 eu pensei que a parte principal do trabalho era codificar sozinha, no deserto. Não é.
• Explicar coisas para não-desenvolvedores é difícil (também coberto pelo primeiro ponto), e é sua responsabilidade fazer seus pontos (não dos outros 99% do mundo).
• O bom teste é o teste que falha. (pela primeira vez, pelo menos) E, claro, não existe código livre de erros. Você não é um mau programador se tiver erros. Bugs são apenas uma parte (muito importante e demorada) do seu trabalho.
• Não há marcadores de prata. Cada tecnologia tem suas vantagens e desvantagens.
• A faculdade não ensina tecnologias de ponta. Mas também, 90% das obras usam tecnologias 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 motivos esotéricos, como manutenção, parceria, disponibilidade do trabalhador ...
• Você está apenas começando , jovem padawan .

Eu comecei a perceber desde então o fato de que codificar é 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 noventa), eu estava convencido de que eu estaria fazendo as coisas do zero e nunca olhando para o código do outro ou tendo que coordenar com os outros ...

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

• A programação de computadores é não-física e não intuitiva.
  • Quando um construtor de casa termina seu trabalho, ele / ela pode andar por aí e imediatamente ver / sentir se há algo errado. Um bug de programação de computador não pode ser descoberto da mesma maneira, e pode se esconder no sistema por meses, ou mesmo décadas.
  • Embora um programador possa parecer / sentir um código-fonte por meio de revisão de código, não é garantido que ele localize todos os erros contidos no código. Um computador, no entanto, seria capaz de reproduzir exatamente o erro toda vez, executando o programa com alguma entrada. Assim, a compreensão humana de uma parte do 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 não consegue lidar com os casos de borda.
  • 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 de borda que o código deve manipular.
  • Adicionado Por outro lado, certas metodologias de desenvolvimento de software parecem sugerir que podemos extrair valor de negócio (menor tempo para comercializar, etc.) escolhendo conscientemente não lidar com casos de borda, e 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 provedores de software não estão muito preocupados com o tratamento dos 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 só vêem a elegância da interface do usuário e as 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 tempo suficiente para começar a apreciar um design de software elegante.
  • Porque nem os clientes nem os programadores valorizam a elegância do código-fonte, nem serão valorizados pelas empresas.

Adicionado

Meus dois centavos: acostume-se.

Imagens de processos ISO, resmas de documentação técnica, todos os recursos e erros sendo estritamente documentados e um ambiente geralmente profissional descreve a minha empresa razoavelmente bem. No entanto, fazemos produtos críticos de software / hardware de infraestrutura, então, a pressão está em em termos de qualidade (temos a certificação ISO 9001, por exemplo).

Eu pensei, depois de me formar, que as pessoas responsáveis seriam capazes de reconhecer o bom trabalho do trabalho ruim. Depois de receber a milionésima cópia do "código realmente ótimo criado pelo nosso codificador superior" e ter 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
    .
    .
    .

Eu quase desisti de tentar entender o que se passa entre as orelhas do chefe de cabelos pontudos. "Ótimo" significa pesadelo de manutenção, "bom" significa acidentes em uma brisa suave e "bagunça horrível" significa tanto isso quanto uma base de código bem estruturada cujos engenheiros se recusaram a cumprir prazos obscenos apenas para manter sua sanidade.

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

Eu acho que você pode encontrar equipes de engenharia divididas que desenvolvem e seguem processos strongs 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 convolute isso com grandes quantidades de documentação) . Eu acredito que eu trabalho em um time como esse no momento. Embora eu certamente tenha experimentado o outro tipo de desenvolvimento.

Muitos softwares não chegam ao ponto de serem usados / comprados o suficiente. Quando alguém faz isso, ele tende a ficar por perto e está apenas "bagunçado" em manutenção.

As expectativas dos usuários estão aumentando a cada dia para recursos, mas em muitas áreas, elas são menores em á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 de volume é uma maravilha moderna, mas o que atrapalha 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 parecido com os pequenos sacos de plástico na mercearia. Eles fazem bilhões deles, eles rasgam e rasgam e são jogados fora. A maioria das pessoas não se importa o suficiente para exigir uma bolsa melhor.

Eu acho que um software de qualidade é feito, eventualmente. Parte disso chega ao mercado mais cedo do que a maioria dos produtos comemorativos. Quem consegue dirigir um carro em Beta?