Hypothèses de programmation erronées de longue date [clôturé]

Je fais des recherches sur les erreurs courantes et les mauvaises hypothèses faites par les ingénieurs logiciels juniors (et peut-être seniors).

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

Par exemple, j'ai mal compris que la taille d'un entier n'est pas une norme et dépend plutôt de la langue et de la cible. Un peu gênant à dire, mais ça y est.

Soyez franc; Quelle croyance ferme aviez-vous et approximativement pendant combien de temps avez-vous maintenu l'hypothèse? 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.

Pendant longtemps, j'ai supposé que tout le monde avait cette super-maîtrise de tous les concepts de programmation (modèles de conception, le dernier nouveau langage, complexité de calcul, expressions lambda, vous l'appelez).

La lecture de blogs, de Stack Overflow et de livres de programmation m'a toujours fait sentir que j'étais derrière la courbe des choses que tous les programmeurs doivent savoir intuitivement.

J'ai réalisé au fil du temps que je compare efficacement mes connaissances à la connaissance collective de nombreuses personnes, pas d'un seul individu et c'est une barre assez élevée pour quiconque. La plupart des programmeurs dans le monde réel ont un cache de connaissances nécessaires pour faire leur travail et ont plus de quelques domaines dont ils sont faibles ou complètement ignorants.

Que les gens savaient ce qu'ils voulaient.

Pendant très longtemps, j'ai pensé que je parlerais avec des gens, ils décriraient un problème ou un flux de travail et je le mettrais dans le code et l'automatiserais. Il s'avère que chaque fois que cela se produit, ce qu'ils pensaient vouloir n'était 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 peut ne pas être ce que l'interrogateur recherchait. Cela ne s'applique pas seulement à 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 10 courtes années que j'ai faites. 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'avais avant d'entrer dans le monde des affaires m'ont amené à croire que je ferais ce que je répondais; que je serais en mesure d'utiliser du code et des ordinateurs pour résoudre les problèmes des gens.

Je suppose que cette réponse est similaire à celle de Robin à propos des non-programmeurs qui comprennent / se soucient de ce dont je parle. Il s'agit d'apprendre l'entreprise comme un processus agile, itératif et interactif. Il s'agit d'apprendre la différence entre être un singe-code 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 le domaine, ce n'est pas seulement la syntaxe et la vitesse de frappe.

Edit: Cette réponse est maintenant wiki communautaire pour apaiser les gens à cette réponse me donnant rep.

Que je sais où est le problème de performances sans profilage

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

Que les non-programmeurs comprennent de quoi je parle.

Ce logiciel sans bug était possible.

Ces variables de membre privé étaient privées pour l'instance et non pour la classe.

Je pensais que la saisie statique était immobile sur votre clavier.

Que vous pouvez bien comprendre un problème avant de commencer à développer.

Les gens intelligents sont toujours plus intelligents que moi.

Je peux vraiment me battre lorsque je fais des erreurs et que je me fais souvent dénoncer pour auto-dépréciation. J'avais l'habitude de regarder avec admiration beaucoup de développeurs et je supposais souvent qu'étant donné qu'ils en savaient plus que moi sur X , ils en savaient plus que moi.

Comme j'ai continué à acquérir de l'expérience et à rencontrer plus de gens, j'ai commencé à réaliser que souvent, alors qu'ils en savent plus que moi sur un sujet particulier, ils ne sont pas nécessairement plus intelligents que moi / vous.

Morale de l'histoire: ne sous-estimez jamais ce que vous pouvez apporter à la table.

Pendant très longtemps, j'ai pensé que la mauvaise programmation était quelque chose qui se passait en marge .. que faire les choses correctement était la norme. Je ne suis pas si naïf de nos jours.

J'ai pensé que je devrais autant que possible m'abstraire. J'ai été touché à la tête avec cela, à cause de trop de fonctionnalités entrelacées.

Maintenant, j'essaie de garder les choses aussi simples et découplées que possible. Refactoriser pour faire quelque chose d'abstrait est beaucoup plus facile que de prédire comment j'ai besoin d'abstraire quelque chose.

Ainsi, je suis passé du développement du cadre qui les régit tous à des extraits de fonctionnalités qui font le travail. Je n'ai jamais regardé en arrière, sauf quand je pense au moment où je pensais naïvement que je serais celui qui développerait la prochaine grande chose.

Que les femmes trouvent les programmeurs informatiques sexy ...

Que la qualité du logiciel entraînera une augmentation des ventes. Parfois, mais pas toujours.

Que toutes les langues sont (pour la plupart) créées égales.

Pendant longtemps, j'ai pensé que la langue de choix ne faisait pas vraiment une grande différence dans la difficulté du processus de développement et le potentiel de réussite du projet. Ce n'est certainement pas vrai.

Le choix de la bonne langue pour le poste est aussi important / critique que toute autre décision de projet prise.

Qu'un grand rapport commentaire / code soit une bonne chose.

Il m'a fallu un certain temps pour réaliser que le code devrait être auto-documenté. Bien sûr, un commentaire ici et là est utile si le code ne peut pas être rendu plus clair ou s'il y a une raison importante pour laquelle quelque chose est fait. Mais, en général, il vaut mieux passer ce temps de commentaire à renommer les variables. C'est plus propre, plus clair et les commentaires ne sont pas «désynchronisés» avec le code.

Cette programmation est impossible.

Sans blague, j'ai toujours pensé que la programmation était quelque chose d'impossible à apprendre, et je m'en suis toujours éloigné. Et quand je me suis approché du code, je n'ai jamais pu le comprendre.

Puis un jour, je me suis assis et j'ai lu quelques didacticiels de base pour débutants, et j'ai travaillé à partir de là. Et aujourd'hui, je travaille en tant que programmeur et j'aime chaque minute.

Pour ajouter, je ne pense pas que la programmation soit facile, c'est un défi et j'aime apprendre plus et il n'y a rien de plus amusant que de résoudre un problème de programmation.

"On Error Resume Next" était une sorte de gestion des erreurs

Ce logiciel de programmation nécessite une base solide en mathématiques supérieures.

Pendant des années avant de commencer à coder, on m'a toujours dit que pour être un bon programmeur, il fallait être bon en algèbre avancée, en géométrie, en calcul, en trigonométrie, etc.

Dix ans plus tard, je n'ai dû faire qu'une seule fois ce qu'un élève de huitième ne pouvait pas faire.

Cette optimisation == réécriture en langage assembleur.

Quand j'ai vraiment compris l'assembly (venant de BASIC), il semblait que la seule façon d'accélérer l'exécution du code était de le réécrire dans l'assembly. Il a fallu plusieurs années pour se rendre compte que les compilateurs peuvent être très bons pour l'optimisation et en particulier avec les processeurs avec prédiction de branche, etc., ils peuvent probablement faire un meilleur travail qu'un humain ne peut le faire dans un délai raisonnable. De plus, passer du temps à optimiser l'algorithme est susceptible de vous donner une meilleure victoire que de passer du temps à passer d'un langage de haut en bas. Aussi cette optimisation prématurée est la racine de tout mal ...

• Que les dirigeants d'entreprise se soucient de la qualité du code.
• Que moins de lignes, c'est mieux.

Je dirais que le stockage de l'élément année d'une date sous forme de 2 chiffres était une hypothèse qui a affligé toute une génération de développeurs. L'argent dépensé sur Y2K était assez horrible.

Que tout autre chose que le type insertion / bulle était tout simplement de la magie noire.

Ce XML serait un format de données véritablement interopérable et lisible par l'homme.

Ce C ++ était intrinsèquement meilleur que tous les autres langages.

C'est ce que j'ai reçu d'un ami quelques années avant moi au collège. Je l'ai gardé avec moi pendant une période embarrassante (je rougis en ce moment). Ce n'est qu'après avoir travaillé avec elle pendant environ 2 ans avant que je puisse voir les fissures pour ce qu'elles étaient.

Personne - et rien - n'est parfait, il y a toujours place à amélioration.

Je pensais que la création de programmes serait exactement comme ce qui était enseigné en classe ... vous vous asseyez avec un groupe de personnes, passez un problème en revue, trouvez une solution, etc. etc. Au lieu de cela, le monde réel est "Voici mon problème, j'ai besoin qu'il soit résolu, allez-y "et dix minutes plus tard, vous en obtenez un autre, ne vous laissant pas de temps réel pour planifier efficacement votre solution.

Je pensais que les modèles de conception traditionnels étaient géniaux lorsqu'ils ont été introduits dans une classe CS. J'avais programmé environ 8 ans comme passe-temps avant cela, et je ne comprenais vraiment pas comment créer de bonnes abstractions.

Les motifs de conception ressemblaient à de la magie; vous pourriez faire des trucs vraiment soignés. Plus tard, j'ai découvert la programmation fonctionnelle (via Mozart / Oz, OCaml, plus tard Scala, Haskell et Clojure), puis j'ai compris que de nombreux modèles n'étaient que passe-partout, ou complexité supplémentaire, car le langage n'était pas assez expressif.

Bien sûr, il y a presque toujours une sorte de modèles, mais ils sont à un niveau supérieur dans les langues expressives. Maintenant, je fais du codage professionnel en Java, et je ressens vraiment la douleur quand je dois utiliser une convention telle que visiteur ou modèle de commande, au lieu de la correspondance de modèle et de fonctions d'ordre supérieur.

Pendant les premières années de programmation, je n'ai pas compris que 1 kilo-octet correspond techniquement à 1024 octets, pas à 1000. J'ai toujours été un peu perplexe par le fait que la taille de mes fichiers de données semblait légèrement différente de ce à quoi je m'attendais. être.

Cette condition vérifie comme:

if (condition1 && condition2 && condition3)

sont effectuées dans un ordre non spécifié ...

Que ma programmation serait plus rapide et meilleure si je la faisais seule.