Pressupostos de programação incorretos e antigos [fechados]

Estou pesquisando erros comuns e suposições ruins feitas por engenheiros de software júnior (e talvez sênior).

Qual foi sua suposição mais antiga que acabou sendo corrigida?

Por exemplo, eu entendi errado que o tamanho de um número inteiro não é um padrão e, em vez disso, depende do idioma e do destino. Um pouco embaraçoso para afirmar, mas está aí.

Seja franco; que firme crença você tinha e aproximadamente quanto tempo manteve a suposição? Pode ser sobre um algoritmo, uma linguagem, um conceito de programação, teste ou qualquer outra coisa sobre programação, linguagens de programação ou ciência da computação.

Por um longo tempo, presumi que todos os demais tinham esse domínio de todos os conceitos de programação (padrões de design, a nova linguagem mais recente, complexidade computacional, expressões lambda, etc.).

Ler blogs, Stack Overflow e livros de programação sempre pareceu me fazer sentir que estava por trás das coisas que todos os programadores precisam saber intuitivamente.

Ao longo do tempo, percebi que estou comparando efetivamente meu conhecimento ao conhecimento coletivo de muitas pessoas, não de um único indivíduo, e isso é um nível bastante alto para qualquer pessoa. A maioria dos programadores no mundo real possui um cache de conhecimento necessário para realizar seu trabalho e possui mais de algumas áreas das quais são fracos ou completamente ignorantes.

Que as pessoas sabiam o que queriam.

Durante muito tempo, pensei em conversar com as pessoas, elas descreveriam um problema ou fluxo de trabalho e eu as codificaria e automatizaria. Acontece que toda vez que isso acontece, o que eles pensavam que queriam não era realmente o que queriam.

Edit: Eu concordo com a maioria dos comentários. Esta não é uma resposta técnica e pode não ser o que o interlocutor estava procurando. Não se aplica apenas à programação. Tenho certeza de que também não é minha suposição mais antiga, mas foi a coisa mais impressionante que aprendi nos 10 anos em que venho fazendo isso. Tenho certeza de que foi pura ingenuidade de minha parte, mas a maneira como meu cérebro está / foi ligado e os ensinamentos e experiências que tive antes de entrar no mundo dos negócios me levaram a acreditar que estaria fazendo o que respondi; que eu seria capaz de usar código e computadores para corrigir os problemas das pessoas.

Eu acho que essa resposta é semelhante à de Robin, que não programadores entende / se preocupa com o que estou falando. Trata-se de aprender os negócios como um processo ágil, interativo e interativo. É sobre aprender a diferença entre ser um macaco de código de programação e ser desenvolvedor de software. Trata-se de perceber que há uma diferença entre os dois e que, para ser realmente bom em campo, não se trata apenas de sintaxe e velocidade de digitação.

Edit: Esta resposta é agora wiki da comunidade para apaziguar as pessoas chateadas com esta resposta, dando-me representante.

Que eu sei onde está o problema de desempenho sem criar perfil

Que eu deveria ter apenas um ponto de saída de uma função / método.

Que os não programadores entendem do que estou falando.

Esse software livre de erros era possível.

As variáveis ​​de membro privadas eram privadas para a instância e não para a classe.

Eu pensei que a digitação estática estava muito quieta no seu teclado.

Que você possa entender completamente um problema antes de começar a desenvolver.

Pessoas inteligentes são sempre mais inteligentes que eu.

Eu realmente posso me derrotar quando cometo erros e, muitas vezes, sou criticado por me depreciar. Eu costumava olhar com admiração para muitos desenvolvedores e geralmente assumia que, como eles sabiam mais do que eu no X , eles sabiam mais do que eu.

Como continuei a ganhar experiência e conhecer mais pessoas, comecei a perceber que, muitas vezes, embora elas saibam mais do que eu sobre um assunto específico, não são necessariamente mais inteligentes que eu / você.

Moral da história: nunca subestime o que você pode trazer para a mesa.

Durante muito tempo, pensei que a programação ruim era algo que acontecia à margem ... que fazer as coisas corretamente era a norma. Não sou tão ingênuo hoje em dia.

Eu pensei que deveria avançar para abstrair o máximo possível. Fui atingido na cabeça por isso, por causa de muito pouco entrelaçado de funcionalidades.

Agora, tento manter as coisas o mais simples e dissociadas possível. Refatorar para tornar algo abstrato é muito mais fácil do que prever como preciso abstrair algo.

Assim, mudei de desenvolver a estrutura que rege todos eles, para trechos de funcionalidade que fazem o trabalho. Nunca olhei para trás, exceto quando penso na hora em que ingênuo pensei que seria o único a desenvolver a próxima grande novidade.

Que as mulheres acham os programadores sexy ...

Que a qualidade do software levará a maiores vendas. Às vezes acontece, mas nem sempre.

Que todos os idiomas são (principalmente) criados iguais.

Por um bom tempo, achei que a linguagem de escolha não fazia muita diferença na dificuldade do processo de desenvolvimento e no potencial de sucesso do projeto. Isto definitivamente não é verdade.

A escolha do idioma certo para o trabalho é tão importante / crítica quanto qualquer outra decisão do projeto que seja tomada.

Que uma grande proporção de comentário / código é uma coisa boa.

Demorei um pouco para perceber que o código deveria ser auto-documentado. Claro, um comentário aqui e ali é útil se o código não puder ser esclarecido ou se houver um motivo importante para que algo esteja sendo feito. Mas, em geral, é melhor gastar esse tempo de comentários renomeando variáveis. É mais limpo, mais claro e os comentários não ficam "fora de sincronia" com o código.

Essa programação é impossível.

Sem brincadeira, sempre achei que a programação era algo impossível de aprender e sempre me afastei dela. E quando cheguei perto do código, nunca consegui entender.

Então, um dia, sentei-me e li alguns tutoriais básicos para iniciantes, e trabalhei a partir daí. E hoje eu trabalho como programador e adoro cada minuto.

Para adicionar, não acho que a programação seja fácil, é um desafio e adoro aprender mais e não há nada mais divertido do que resolver algum problema de programação.

"On Error Resume Next" era algum tipo de manipulação de erro

Esse software de programação requer uma base sólida em matemática superior.

Durante anos antes de começar a codificar, sempre me disseram que, para ser um bom programador, você tinha que ser bom em álgebra avançada, geometria, cálculo, trigonometria, etc.

Dez anos depois, e apenas uma vez tive que fazer algo que um aluno da oitava série não conseguiu.

Essa otimização == reescrita na linguagem assembly.

Quando eu realmente entendi assembly (vindo do BASIC), parecia que a única maneira de acelerar o código era reescrevê-lo no assembly. Demorou alguns anos para perceber que os compiladores podem ser muito bons em otimização e, especialmente com CPUs com previsão de ramificação, etc. eles provavelmente podem fazer um trabalho melhor do que um humano pode fazer em um período de tempo razoável. Além disso, é provável que gastar tempo otimizando o algoritmo proporcione uma vitória melhor do que gastar tempo convertendo de um idioma de alto para baixo nível. Também que a otimização prematura é a raiz de todo mal ...

• Que os executivos da empresa se preocupem com a qualidade do código.
• Que menos linhas é melhor.

Eu diria que armazenar o elemento year de uma data como 2 dígitos foi uma suposição que afligiu toda uma geração de desenvolvedores. O dinheiro investido no Y2K foi horrível.

Que qualquer coisa que não fosse o tipo inserção / bolha era simplesmente magia negra.

Esse XML seria um formato de dados legível verdadeiramente interoperável e humano.

Esse C ++ era intrinsecamente melhor do que todas as outras linguagens.

Recebi isso de um amigo alguns anos antes de mim na faculdade. Fiquei comigo por um tempo embaraçosamente longo (estou corando agora). Foi só depois de trabalhar com ele por 2 anos ou mais antes que eu pudesse ver as rachaduras do que eram.

Ninguém - e nada - é perfeito, sempre há espaço para melhorias.

Eu acreditava que a criação de programas seria exatamente como o que foi ensinado em sala de aula ... você senta com um grupo de pessoas, analisa um problema, apresenta uma solução etc. etc. Em vez disso, o mundo real é "Aqui está meu problema, preciso resolvê-lo, vá "e dez minutos depois você recebe outro, sem tempo real para planejar sua solução com eficiência.

Eu pensei que os padrões de design convencionais eram impressionantes quando foram introduzidos em uma classe de CS. Eu tinha programado cerca de 8 anos como hobby antes disso, e realmente não tinha uma sólida compreensão de como criar boas abstrações.

Padrões de design pareciam mágicos; você poderia fazer coisas realmente legais. Mais tarde, descobri a programação funcional (via Mozart / Oz, OCaml, mais tarde Scala, Haskell e Clojure) e depois entendi que muitos dos padrões eram apenas clichê, ou complexidade adicional, porque a linguagem não era expressiva o suficiente.

É claro que quase sempre há algum tipo de padrão, mas eles estão em um nível superior nas linguagens expressivas. Agora, eu tenho feito alguma codificação profissional em Java, e sinto muita dor quando preciso usar uma convenção como visitante ou padrão de comando, em vez de correspondência de padrões e funções de ordem superior.

Nos primeiros anos em que estava programando, não entendi que 1 Kbyte é tecnicamente de 1024 bytes, e não 1000. Sempre fiquei um pouco perplexo com o fato de os tamanhos dos meus arquivos de dados parecerem um pouco diferentes do que eu esperava que eles fizessem. estar.

Essa condição verifica como:

if (condition1 && condition2 && condition3)

são executados em uma ordem não especificada ...

Que minha programação seria mais rápida e melhor se eu a realizasse sozinha.