Des hypothèses de programmation erronées et ancrées depuis longtemps

Question

Je fais des recherches sur les erreurs courantes et les mauvaises suppositions faites par les ingénieurs logiciels débutants (et peut-être seniors).

Quelle est votre hypothèse la plus ancienne qui a finalement été corrigée ?

Par exemple, j'ai mal compris que la taille d'un nombre entier n'est pas une norme et dépend plutôt de la langue et de la cible. C'est un peu embarrassant à dire, mais c'est ainsi.

Soyez franc : quelle croyance ferme aviez-vous, et pendant combien de temps environ avez-vous maintenu cette supposition ? Il peut s'agir d'un algorithme, d'un langage, d'un concept de programmation, de tests ou de toute autre chose concernant la programmation, les langages de programmation ou l'informatique.

Answer 1

Pendant longtemps, j'ai supposé que tout le monde maîtrisait parfaitement tous les concepts de programmation (modèles de conception, dernier nouveau langage, complexité informatique, expressions lambda, etc.)

La lecture des blogs, de Stack Overflow et des livres de programmation me donnait toujours l'impression d'être en retard sur les choses que tous les programmeurs doivent savoir intuitivement.

J'ai réalisé au fil du temps que je comparais effectivement mes connaissances à celles de la collectivité, et non à celles d'un seul individu, et c'est un critère assez élevé pour quiconque. Dans le monde réel, la plupart des programmeurs ont un bagage de connaissances nécessaires pour faire leur travail et ont plus d'un domaine dans lequel ils sont faibles ou complètement ignorants.

Answer 2

Que les gens savaient ce qu'ils voulaient.

Pendant longtemps, j'ai pensé que je parlerais avec les gens, qu'ils décriraient un problème ou un flux de travail et que je le traduirais en code et l'automatiserais. Il s'avère qu'à chaque fois que cela arrive, ce qu'ils pensaient vouloir n'est pas vraiment ce qu'ils voulaient.

Edit : Je suis d'accord avec la plupart des commentaires. Ce n'est pas une réponse technique et ce n'est peut-être pas ce que l'auteur de la question recherchait. Elle ne s'applique pas uniquement à la programmation. Je suis sûr que ce n'est pas non plus mon hypothèse la plus ancienne, mais c'est la chose la plus frappante que j'ai apprise au cours des dix petites années où j'ai fait ce métier. Je suis sûr que c'était de la pure naïveté de ma part, mais la façon dont mon cerveau est/était câblé et l'enseignement et les expériences que j'ai eus avant d'entrer dans le monde des affaires m'ont amené à croire que je ferais ce à quoi j'ai répondu ; que je serais capable d'utiliser le code et les ordinateurs pour résoudre les problèmes des gens.

Je pense que cette réponse est similaire à celle de Robin concernant les non-programmeurs qui comprennent ou se soucient de ce dont je parle. Il s'agit d'apprendre le métier comme un processus agile, itératif et interactif. Il s'agit d'apprendre la différence entre être un singe de programmation et être un développeur de logiciels. Il s'agit de réaliser qu'il y a une différence entre les deux et que pour être vraiment bon dans ce domaine, il ne s'agit pas seulement de syntaxe et de vitesse de frappe.

Edit : Cette réponse est maintenant community-wiki pour apaiser les gens qui sont contrariés par le fait que cette réponse me donne du crédit.

Answer 3

Que je sache où se trouve le problème de performance sans profilage

Answer 4

Que je ne dois avoir qu'un seul point de sortie d'une fonction/méthode.

Answer 5

Que les non-programmeurs comprennent ce dont je parle.