Lang anhaltende, falsche Programmierannahmen [geschlossen]

Ich recherchiere nach häufigen Fehlern und schlechten Annahmen von Junior- (und vielleicht Senior-) Software-Ingenieuren.

Was war Ihre am längsten bestehende Annahme, die schließlich korrigiert wurde?

Ich habe zum Beispiel falsch verstanden, dass die Größe einer Ganzzahl kein Standard ist und stattdessen von der Sprache und dem Ziel abhängt. Ein bisschen peinlich zu sagen, aber da ist es.

Sei ehrlich; Welchen festen Glauben hatten Sie und ungefähr wie lange haben Sie die Annahme beibehalten? Es kann sich um einen Algorithmus, eine Sprache, ein Programmierkonzept, Tests oder etwas anderes handeln, das sich mit Programmierung, Programmiersprachen oder Informatik befasst.

Lange Zeit ging ich davon aus, dass alle anderen diese Programmierkonzepte beherrschen (Entwurfsmuster, die neueste neue Sprache, Komplexität der Berechnungen, Lambda-Ausdrücke, wie Sie es nennen).

Das Lesen von Blogs, Stack Overflow und Programmierbüchern schien mir immer das Gefühl zu geben, hinter den Kurven der Dinge zu stehen, die alle Programmierer nur intuitiv wissen müssen.

Ich habe im Laufe der Zeit festgestellt, dass ich mein Wissen effektiv mit dem kollektiven Wissen vieler Menschen vergleiche, nicht mit einer einzelnen Person, und das ist eine ziemlich hohe Messlatte für jeden. Die meisten Programmierer in der realen Welt verfügen über einen Wissensspeicher, der für ihre Arbeit erforderlich ist, und über mehr als einige Bereiche, die sie entweder schwach oder gar nicht kennen.

Dass die Leute wussten, was sie wollten.

Für die längste Zeit dachte ich, ich würde mit Leuten sprechen, sie würden ein Problem oder einen Workflow beschreiben und ich würde es in Code einfügen und es automatisieren. Es stellt sich jedes Mal heraus, dass das, was sie zu wollen glaubten, nicht das war, was sie wollten.

Bearbeiten: Ich stimme den meisten Kommentaren zu. Dies ist keine technische Antwort und möglicherweise nicht das, wonach der Fragesteller gesucht hat. Dies gilt nicht nur für die Programmierung. Ich bin mir sicher, dass dies auch nicht meine am längsten bestehende Annahme ist, aber es war das Auffälligste, was ich in den 10 kurzen Jahren, in denen ich dies getan habe, gelernt habe. Ich bin mir sicher, dass es meinerseits reine Naivität war, aber die Art und Weise, wie mein Gehirn verdrahtet ist / war und die Lehren und Erfahrungen, die ich vor dem Eintritt in die Geschäftswelt hatte, ließen mich glauben, dass ich tun würde, was ich antwortete; dass ich Code und Computer verwenden könnte, um die Probleme der Leute zu beheben.

Ich denke, diese Antwort ähnelt der von Robin über Nicht-Programmierer, die verstehen / sich darum kümmern, wovon ich spreche. Es geht darum, das Geschäft als agilen, iterativen und interaktiven Prozess zu lernen. Es geht darum, den Unterschied zwischen einem Programmiercode-Affen und einem Softwareentwickler zu lernen. Es geht darum zu erkennen, dass es einen Unterschied zwischen den beiden gibt und dass es nicht nur um Syntax und Schreibgeschwindigkeit geht, um auf dem Gebiet wirklich gut zu sein.

Bearbeiten: Diese Antwort ist jetzt ein Community-Wiki, um Leute zu beruhigen, die sich über diese Antwort aufregen und mir einen Repräsentanten geben.

Dass ich ohne Profilerstellung weiß, wo das Leistungsproblem liegt

Dass ich nur einen Austrittspunkt von einer Funktion / Methode haben sollte.

Dass Nichtprogrammierer verstehen, wovon ich spreche.

Diese fehlerfreie Software war möglich.

Diese privaten Mitgliedsvariablen waren für die Instanz und nicht für die Klasse privat.

Ich dachte, dass statisches Tippen sehr still an Ihrer Tastatur sitzt.

Dass Sie ein Problem vollständig verstehen können, bevor Sie mit der Entwicklung beginnen.

Kluge Leute sind immer schlauer als ich.

Ich kann mich wirklich verprügeln, wenn ich Fehler mache und oft wegen Selbstironie angeklagt werde. Ich habe viele Entwickler ehrfürchtig angesehen und oft angenommen, dass sie, da sie auf X mehr wussten als ich , mehr wussten als ich.

Da ich immer mehr Erfahrungen gesammelt und mehr Menschen getroffen habe, wurde mir klar, dass sie in einem bestimmten Fach zwar mehr wissen als ich, aber nicht unbedingt schlauer als ich / Sie.

Moral der Geschichte: Unterschätzen Sie niemals, was Sie auf den Tisch bringen können.

Am längsten dachte ich, dass schlechtes Programmieren etwas ist, das am Rande passiert ist. Dass es die Norm ist, Dinge richtig zu machen. Ich bin heutzutage nicht so naiv.

Ich dachte, ich sollte so viel wie möglich abstrahieren. Ich wurde dabei im Hauptfach getroffen, weil zu viele kleine Funktionen miteinander verflochten waren.

Jetzt versuche ich, die Dinge so einfach und entkoppelt wie möglich zu halten. Refactoring, um etwas abstrakt zu machen, ist viel einfacher als vorherzusagen, wie ich etwas abstrahieren muss.

Daher bin ich von der Entwicklung des Frameworks, das sie alle regiert, zu Funktionsausschnitten übergegangen, mit denen die Aufgabe erledigt werden kann. Ich habe nie zurückgeschaut, außer wenn ich an die Zeit denke, in der ich naiv dachte, ich wäre derjenige, der das nächste große Ding entwickelt.

Dass Frauen Computerprogrammierer sexy finden ...

Dass die Qualität der Software zu mehr Umsatz führen wird. Manchmal schon, aber nicht immer.

Dass alle Sprachen (meistens) gleich sind.

Lange Zeit stellte ich fest, dass die Sprache der Wahl keinen großen Unterschied in der Schwierigkeit des Entwicklungsprozesses und dem Potenzial für den Projekterfolg machte. Das ist definitiv nicht wahr.

Die Auswahl der richtigen Sprache für den Job ist genauso wichtig / kritisch wie jede andere einzelne Projektentscheidung, die getroffen wird.

Dass ein großes Kommentar / Code-Verhältnis eine gute Sache ist.

Es dauerte eine Weile, bis mir klar wurde, dass Code sich selbst dokumentieren sollte. Klar, ein Kommentar hier und da ist hilfreich, wenn der Code nicht klarer gemacht werden kann oder wenn es einen wichtigen Grund gibt, warum etwas getan wird. Im Allgemeinen ist es jedoch besser, diese Kommentarzeit damit zu verbringen, Variablen umzubenennen. Es ist sauberer, klarer und die Kommentare sind nicht "nicht synchron" mit dem Code.

Diese Programmierung ist unmöglich.

Kein Scherz, ich dachte immer, Programmieren sei unmöglich zu lernen, und ich hielt mich immer davon fern. Und als ich mich dem Code näherte, konnte ich ihn nie verstehen.

Dann setzte ich mich eines Tages einfach hin und las einige grundlegende Anfänger-Tutorials und arbeitete mich von dort aus vor. Und heute arbeite ich als Programmierer und ich liebe jede Minute davon.

Außerdem denke ich nicht, dass das Programmieren einfach ist, es ist eine Herausforderung und ich liebe es, mehr zu lernen, und es gibt nichts Schöneres, als ein Programmierproblem zu lösen.

"On Error Resume Next" war eine Art Fehlerbehandlung

Diese Programmiersoftware erfordert eine solide Grundlage in der höheren Mathematik.

Jahrelang, bevor ich mit dem Codieren anfing, wurde mir immer gesagt, dass man in fortgeschrittener Algebra, Geometrie, Analysis, Trigger usw. gut sein muss, um ein guter Programmierer zu sein.

Zehn Jahre später musste ich nur einmal etwas tun, was ein Achtklässler nicht konnte.

Das Optimieren == Umschreiben in Assemblersprache.

Als ich Assembly (von BASIC) zum ersten Mal wirklich verstand, schien es, dass die einzige Möglichkeit, Code schneller auszuführen, darin bestand, ihn in Assembly neu zu schreiben. Es hat einige Jahre gedauert, bis klar wurde, dass Compiler sehr gut optimieren können, und insbesondere mit CPUs mit Verzweigungsvorhersage usw. können sie wahrscheinlich einen besseren Job machen als ein Mensch in angemessener Zeit. Wenn Sie Zeit für die Optimierung des Algorithmus aufwenden, erzielen Sie wahrscheinlich einen besseren Gewinn als wenn Sie Zeit für die Konvertierung von einer Sprache in eine Sprache auf hohem Niveau aufwenden. Auch diese vorzeitige Optimierung ist die Wurzel allen Übels ...

• Dass sich die Führungskräfte des Unternehmens um die Qualität des Codes kümmern.
• Dass weniger Zeilen besser sind.

Ich würde sagen, dass das Speichern des Jahreselements eines Datums als zweistellige Zahl eine Annahme war, von der eine ganze Generation von Entwicklern betroffen war. Das Geld, das auf Y2K geblasen wurde, war ziemlich schrecklich.

Dass alles andere als das Einfügen / Blasen-Sortieren ganz einfach dunkle Magie war.

Dieses XML wäre ein wirklich interoperables und für Menschen lesbares Datenformat.

Das C ++ war an sich irgendwie besser als alle anderen Sprachen.

Dies erhielt ich von einem Freund ein paar Jahre vor mir im College. Ich habe es für eine peinlich lange Zeit bei mir behalten (ich werde gerade rot). Erst nachdem ich ungefähr 2 Jahre damit gearbeitet hatte, konnte ich die Risse für das sehen, was sie waren.

Niemand - und nichts - ist perfekt, es gibt immer Raum für Verbesserungen.

Ich glaubte, dass das Erstellen von Programmen genau dem entsprechen würde, was im Unterricht gelehrt wurde ... Sie setzen sich mit einer Gruppe von Menschen zusammen, gehen ein Problem durch, finden eine Lösung usw. usw. Stattdessen lautet die reale Welt "Hier ist" Mein Problem, ich muss es lösen, los "und zehn Minuten später erhalten Sie ein weiteres, sodass Sie keine Zeit mehr haben, Ihre Lösung effizient zu planen.

Ich fand Mainstream- Designmuster großartig, als sie in einer CS-Klasse eingeführt wurden. Ich hatte vorher ungefähr 8 Jahre als Hobby programmiert und hatte wirklich kein solides Verständnis dafür, wie man gute Abstraktionen erstellt.

Designmuster fühlten sich wie Magie an; Sie könnten wirklich ordentliche Sachen machen. Später entdeckte ich funktionale Programmierung (über Mozart / Oz, OCaml, später Scala, Haskell und Clojure), und dann verstand ich, dass viele der Muster nur Boilerplate oder zusätzliche Komplexität waren, weil die Sprache nicht ausdrucksstark genug war.

Natürlich gibt es fast immer Muster, aber sie sind in Ausdruckssprachen auf einem höheren Niveau. Jetzt habe ich einige professionelle Codierungen in Java durchgeführt, und ich fühle wirklich den Schmerz, wenn ich eine Konvention wie Besucher- oder Befehlsmuster anstelle von Mustervergleich und Funktionen höherer Ordnung verwenden muss.

In den ersten Jahren, in denen ich programmierte, habe ich nicht verstanden, dass 1 KByte technisch gesehen 1024 Bytes und nicht 1000 Bytes sind. Ich war immer ein wenig ratlos darüber, dass die Größe meiner Datendateien etwas von meinen Erwartungen abwich Sein.

Dieser Zustand prüft wie folgt:

if (condition1 && condition2 && condition3)

werden in einer nicht festgelegten Reihenfolge durchgeführt ...

Dass meine Programmierung schneller und besser wäre, wenn ich sie alleine ausführen würde.