Longue durée, hypothèses de programmation incorrectes

Je fais des recherches sur les erreurs communes et les mauvaises suppositions faites par les ingénieurs logiciels juniors (et peut-être supérieurs).

Quelle a été 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 du langage et de la cible. Un peu gênant à dire, mais ça y est.

Soyez franc Quelle croyance ferme avez-vous et approximativement combien de temps avez-vous maintenu cette hypothèse? Il peut s’agir d’un algorithme, d’un langage, d’un concept de programmation, de tests ou de tout autre élément relatif à la programmation, aux langages de programmation ou à l’informatique.

Pendant longtemps, j’ai supposé que tout le monde avait cette super-maîsortingse de tous les concepts de programmation (modèles de conception, langage le plus récent, complexité informatique, expressions lambda, etc.).

La lecture de blogs, de Stack Overflow et de livres de programmation a toujours semblé me ​​faire penser que j’étais derrière la courbe des choses que tous les programmeurs doivent savoir intuitivement.

Au fil du temps, j’ai réalisé que je compare effectivement mes connaissances aux connaissances collectives de nombreuses personnes, et non à un seul individu, ce qui constitue un obstacle pour quiconque. La plupart des programmeurs dans le monde réel ont un cache de connaissances nécessaire pour faire leur travail et ont plus que quelques domaines dans lesquels ils sont soit faibles, soit totalement ignorants.

Que les gens savaient ce qu’ils voulaient.

Pendant longtemps, je pensais parler avec des gens, ils décriraient un problème ou un workflow et je le mettrais dans un code pour l’automatiser. À chaque fois que cela se produit, il s’agit de ce qu’ils pensaient être ce qu’ils voulaient.

Edit: Je suis d’accord avec la plupart des commentaires. Ce n’est pas une réponse technique et peut-être pas ce que le questionneur recherchait. Cela ne s’applique pas uniquement à la programmation. Je suis sûr que ce n’est pas mon hypothèse la plus ancienne, mais c’est la chose la plus frappante que j’ai apprise au cours des 10 dernières années. Je suis sûr que c’était une pure naïveté de ma part, mais la façon dont mon cerveau est / a été câblé et l’enseignement et les expériences que j’ai vécus avant d’entrer dans le monde des affaires m’ont amené à croire que je ferais ce que j’ai répondu. que je pourrais 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 / prennent soin 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-programmation et être un développeur de logiciels. Il s’agit de réaliser qu’il existe une différence entre les deux et que pour être vraiment performant sur le terrain, il n’ya pas que la syntaxe et la vitesse de frappe.

Edit: Cette réponse est maintenant wiki-communauté pour apaiser les gens contrariés par cette réponse en me donnant un représentant.

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

Que je ne devrais avoir qu’un seul sharepoint sortie d’une fonction / méthode.

Que les non-programmeurs comprennent de quoi je parle.

Ce logiciel sans bogue était possible.

Les variables de membre privé étaient privées de l’instance et non de la classe.

Je pensais que le typage statique était immobile sur votre clavier.

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

Les gens intelligents sont toujours plus intelligents que moi.

Je peux vraiment me battre quand je fais des erreurs et que je me fais souvent reprocher par moi-même. J’avais l’habitude de regarder avec admiration beaucoup de développeurs et je pensais souvent que, comme 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, même s’ils en savent plus que moi sur un sujet particulier, ils ne sont pas nécessairement plus intelligents que moi.

Morale de l’histoire: Ne jamais sous-estimer ce que vous pouvez apporter à la table.

Pendant très longtemps, je pensais que la mauvaise programmation était quelque chose qui se passait en marge. Que faire correctement les choses était la norme. Je ne suis pas si naïf ces jours-ci.

Je pensais que je devrais aller vers l’abstraction autant que possible. J’ai été touché à la tête avec ceci, à cause de trop peu 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 framework qui les régit tous aux fragments de fonctionnalités qui font le travail. Je n’ai jamais regardé en arrière, sauf quand je pensais au temps 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é des logiciels conduise à de meilleures ventes. Parfois, c’est le cas mais pas toujours.

Que toutes les langues soient (principalement) créées égales.

Pendant un bon bout de temps, j’ai pensé que le langage choisi ne faisait pas vraiment la différence dans la difficulté du processus de développement et le potentiel de réussite du projet. Ce n’est certainement pas vrai.

Choisir la bonne langue pour le travail est aussi important / critique que toute autre décision de projet unique prise.

Qu’un grand ratio commentaire / code est une bonne chose.

Il m’a fallu du temps pour réaliser que le code devait être auto documenté. Bien sûr, un commentaire ici et là est utile si le code ne peut être clarifié ou s’il existe une raison importante pour laquelle quelque chose est fait. Mais, en général, il est préférable de dépenser ce temps pour 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 plaisanter, j’ai toujours pensé que la programmation était une chose impossible à apprendre et je me suis toujours éloigné de ça. Et quand je me suis approché du code, je ne pouvais jamais le comprendre.

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

Pour append, 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, en géomésortinge, en calcul, en sortingg, etc.

Dix ans plus tard, je n’ai eu à faire qu’une seule fois qu’un huitième élève ne pouvait pas.

Cela optimisant la réécriture == en langage assembleur.

Lorsque j’ai compris pour la première fois l’assemblage (venant de BASIC), il semblait que le seul moyen de faire tourner le code plus rapidement était de le réécrire en assembleur. Il a fallu plusieurs années pour comprendre que les compilateurs peuvent être très efficaces en optimisation, en particulier avec les processeurs avec prédiction de twig, etc. Ils peuvent probablement faire un meilleur travail que ce que l’homme peut faire en un temps raisonnable. En outre, le fait de consacrer du temps à l’optimisation de l’algorithme vous donnera probablement de meilleurs résultats que de passer du temps à convertir un langage de haut niveau en langage de bas niveau. Aussi, l’optimisation prématurée est la racine de tout mal …

  • Que les dirigeants de l’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 à 2 chiffres était une hypothèse qui affectait toute une génération de développeurs. L’argent qui a été soufflé sur l’ an 2000 était assez horrible.

Que tout autre chose que le sorting par insertion / bulle était tout simplement une magie noire.

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

Ce C ++ était en quelque sorte insortingnsèquement meilleur que tous les autres langages.

Ce que j’ai reçu d’un ami quelques années devant moi au collège. Je l’ai gardé avec moi pendant un temps embarrassant (je rougis tout de suite). Ce n’est qu’après avoir travaillé avec elle pendant environ deux ans avant que je puisse voir les fissures de ce qu’elles étaient.

Personne – et rien – n’est parfait, il y a toujours place à l’amélioration.

Je pensais que la création de programmes serait exactement comme ce qui a été enseigné en classe… vous vous assoyez avec un groupe de personnes, examinez un problème, proposez une solution, etc. Au lieu de cela, le monde réel est «Voici mon problème, j’ai besoin de le résoudre, allez “et dix minutes plus tard, vous en obtenez un autre, ne vous laissant aucun temps réel pour planifier efficacement votre solution.

Je pensais que les modèles de conception traditionnels étaient géniaux, quand ils ont été introduits dans une classe CS. J’avais programmé environ 8 ans comme passe-temps avant, et je n’avais vraiment pas une bonne compréhension de la manière de créer de bonnes abstractions.

Les motifs de conception étaient comme de la magie; vous pourriez faire des trucs vraiment chouettes. Plus tard, j’ai découvert la functional programming (via Mozart / Oz, OCaml, plus tard Scala, Haskell et Clojure), puis j’ai compris que beaucoup de motifs étaient simplement complexes ou complexes, car le langage n’était pas assez expressif.

Bien sûr, il existe presque toujours des modèles, mais ils se situent à un niveau plus élevé dans les langues expressives. Maintenant, je fais du codage professionnel en Java, et je ressens vraiment la douleur lorsque je dois utiliser une convention telle que le modèle visiteur ou commande, plutôt que la correspondance de modèle et les fonctions d’ordre supérieur.

Au cours des premières années, je programmais que je n’avais pas compris que 1 Ko correspondait techniquement à 1024 octets, pas à 1000. J’ai toujours été un peu perplexe devant le fait que la taille de mes fichiers de données semblait légèrement inférieure à ce que je pensais. être.

Cette condition vérifie comme:

if (condition1 && condition2 && condition3) 

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

Que ma programmation soit plus rapide et meilleure si je la jouais seule.