Wann würde jemand als schlechter Programmierer gelten? [geschlossen]

Wie würden Sie denken, dass ein Programmierer schlecht in dem ist, was er oder sie tut?

Wenn möglich ... Wie soll er / sie sich verbessern?

Wenn sie nicht aus ihren Fehlern und Peer Reviews lernen.

Irgendwann sind wir alle grün; Wenn Sie jedoch nicht besser werden oder versuchen, besser zu werden, sind Sie ein schlechter Programmierer.

Ein Programmierer, der nicht weiß, was er nicht weiß und überhaupt nicht interessiert ist, es herauszufinden.

Ein großes Warnsignal ist, wenn sie ein "Frachtkult" -Programmierer sind - was bedeutet, dass sie Dinge tun, aber nicht wissen, warum sie diese Dinge tun (es ist nur "Magie"). Toller Beitrag von Eric Lippert hier .

Aus dem Artikel:

Programmierer, die verstehen, was der Code tut, aber nicht, wie er es tut.

Ein großer Tipp für mich ist, wenn sie Ihnen oder den anderen Programmierern Entwicklungsfragen stellen, die deutlich zeigen, dass sie absolut keine Anstrengungen unternommen haben, um es selbst herauszufinden.

Eine Konsequenz ist, wenn sie dieselbe Programmierfrage mehrmals stellen und angeben, dass sie die Informationen nicht internalisieren.

Wenn sie lange brauchen, um das FizzBuzz-Problem zu lösen.

Programmierer, die sich weigern, neue Technologien / Sprachen zu lernen, und darauf bestehen, sich an das zu halten, was sie bereits kennen.

Nachtrag: (Hinzufügen des Gedankenstrichs in den Kommentaren)

Eine Erweiterung davon sind Leute, die eine Teilmenge der Funktionalität einer Technologie kennen, aber keine Lust haben, mehr darüber zu erfahren. Programmiersprache, Editor, andere Tools ...

Wenn ein Teammitglied der negativ produzierende Entwickler ist .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Das heißt, der Rest Ihres Teams muss wegen des schlechten Entwicklers mehr Arbeit leisten. NNPP

Wenn sie Dinge produzieren, die regelmäßig auf The Daily WTF laufen .

Wenn sie wissen, dass es bessere Möglichkeiten gibt, die Dinge zu tun, sich aber weigern, sie zu tun, selbst wenn es die Zeit erlaubt.

Persönlich denke ich, dass jeder Programmierer, der sich seinen eigenen Code ansehen kann, den er vor einiger Zeit geschrieben hat, und keinen Fehler findet, kein guter ist. "Eine Weile" kann mit der Erfahrung mithalten ... Ich würde sagen zwischen ein paar Wochen bis zu einem Jahr oder so.

Diejenigen, die Warnungen in ihren Codes ignorieren und sich nur um Fehler kümmern.

Als ich ein Teamleiter in einem kleinen Laden war, gab es einige Leute, die ich neu zuweisen musste (weder ich noch mein direkter Vorgesetzter hatten eine Kündigungsmöglichkeit ohne jede Menge Bürokratie und Unterlagen.) Oder keine Vertragsverlängerung am Ende des aktuellen Engagements. Einige der aufgezählten Typen arbeiteten auch für andere Teamleiter, und sie waren fast der gleichen Ansicht. Dinge, die Leute in die Kategorie "Bad Programmer" in meinem Buch geführt haben:

1. In der Vergangenheit untrainierbar oder ohnmächtig
   Wenn der Programmierer das neue System, das neue Tool oder was auch immer eingesetzt wird, nicht aufnehmen kann, unabhängig davon, wie die Schulung / Ausbildung durchgeführt wird. Muss das Training regelmäßig wiederholen.
   Wenn der Programmierer nur die Technologie oder das Codierungsparadigma kennt, die er vor 10 oder 15 Jahren verwendet hat. Es war dann gut genug, also warum sollten sie sich ändern?
2. Cowboy-Codierer
   Die Person, die zuerst codiert, ohne einen Plan. Der 'Programmierer', der ungetestete Änderungen am Produktionscode und / oder den Daten vornimmt, "weil wir sie jetzt reparieren müssen", ist dann überrascht, wenn die "Korrektur" fehlschlägt.
   Der Cowboy ist auch definitiv kein Teamplayer. Benötigt kein stinkendes Team.
3. Die Wetterfahne
   Dieser "Programmierer" ist verliebt in die "technology du jour " und sieht jedes neue Framework, jede neue Sprache, Methodik oder was auch immer neu und aktuell ist wie die
4. Das "große Gehirn"
   Dieser "Programmierer" ist sich seines Talents und seiner Fähigkeiten so sicher, dass Dinge getan werden, die für das Projekt wenig sinnvoll sind. zB Umschreiben einer Standardbibliothek "weil sie für unser System ineffizient ist" oder Einführung von Tools und Techniken, die für das jeweilige Problem nicht geeignet sind. zB Einführung von Lisp oder Forth in einer Mainframe-Umgebung.
5. LOC ^a. Sandbagger
   Dieser 'Programmierer' verwendet Verschleierung und falsche Richtung, um das ^a zu erhöhen ^. LOC: Codezeilen, für die bezahlt wird. Ich habe in dieser Situation Code gesehen, der Seite für Seite war, Bildschirm für Bildschirm mit doppelter Struktur und Logik, wobei nur die Namen der Absätze oder Steuervariablen geändert wurden, um die Zeilenanzahl zu erhöhen.
6. Unverzichtbarer Experte
   Der "Programmierer", der das Fachwissen besitzt, um die vorliegenden Probleme zu lösen, aber seitdem alles darüber "weiß". Tatsächlich würde die gesamte Organisation zusammenbrechen, wenn sie von einem Bus angefahren würden. { Beobachtung: Diejenigen, die denken, dass sie in der Regel unverzichtbar sind, sind. (Hat jemand die Quelle für diesen Aphorismus?)}
7. Der Pasta-Chef
   Dieser "Programmierer" ist auf Spaghetti-Code spezialisiert, gewürzt mit Bezeichnern, die ohne eine syntaktisch implementierte IDE einfach zu schwer nachzuvollziehen sind. zB IndexI1O0, Index1I0O usw.
8. Sommerpraktikant - Speziell für den Subtyp "Walking Disaster"
   Früher stellte ich in meinem alten Laden einige Praktikanten im späten Abitur- oder College-Alter ein. Einmal benötigte eine Abteilung eine kleine Datenbank, um die Auslastung der Geräte zu verfolgen (jetzt war dies eine Verzögerung, und es wurde dBase III verwendet). Der Typ hat den ganzen Sommer mitgeschrieben, war aber noch nicht fertig, als das College im Herbst begann. Er bekam eine einwöchige Verlängerung, dann eine zweite Woche. Am Ende der zweiten Woche wurde ich ausgesandt, um sein Projekt zu übernehmen und es zum Abschluss wieder in die Systementwicklung zu bringen. Er zeigte mir die Sachen, die er gemacht hatte, und dann den unvollendeten Teil. Was funktionierte hatte eine schöne Augenweide, aber die Anwendung warunvollständig. Als ich die neue Schachtel mit den formatierten Disketten öffnete, um Kopien zu erhalten, sagte er: "Nur eine Sekunde, lassen Sie mich meine Testdateien löschen ..." und bevor ich etwas sagen konnte, hatte er eine Reihe von Dateien gelöscht.
   Ich war misstrauisch und stellte fest, dass seine Bewerbung fast nichts anderes als eine Augenweide war, als ich in meinen Laden zurückkehrte. Dann ging ich zurück in die Abteilung und holte Norton heraus und löschte die gelöschten Dateien wieder, um eine zusätzliche Logik zu finden. auch wenn unvollständig.
   Ich fand keine schlechte Logik, sondern schlechtes Benehmen. Der Drucker, der an den von ihm verwendeten PC angeschlossen war, war ein Raddrucker. Der normalerweise eingebaute Zeichensatz war eine Schweizer Variante. Die Ausgabe der gelöschten Programme enthält einen Namen, eine Adresse, ein DOB, einige Buchstabencodes und eine Art ID-Nummer. Das Format und Layout hat mich gestört. Alle Geburtsdaten für mehrere Personen waren kaum trinkberechtigt. Die meisten Adressen waren nicht da, als ich sie in unserem Kreuzverzeichnis nachschlug. Als ich seinem Vorgesetzten die Ausdrucke zeigte, sah er mich an und sagte: "Führerschein, meinst du nicht?" Ich sagte, ich tat es. Er sagte, deshalb habe er das Transparentmaterial im Papierkorb neben dem Xerox gefunden. Unser böser Junge hatte Overlays gemacht, um sein Alter und das seiner Freunde auf ihren Führerscheinen abzustimmen. Wir haben es den Behörden gemeldet.nicht für seine letzten zwei Wochen bezahlt.

Dies sind nur einige der schlechten Charaktere, mit denen ich arbeiten musste ...

/ s / BezantSoft

Kann sich nicht an neue Technologien anpassen

Abgesehen von dem offensichtlichen Mangel an Kenntnissen / Fähigkeiten ist ein Programmierer ein schlechter, wenn sein Code schwerer zu lesen und / oder zu warten ist, als er sein sollte.

Wenn sonst niemand seinen Code lesen kann. Es ist egal, wie hell du bist; Kein Programmierer ist eine Insel.

Jemand, der nicht auf die Details achtet und immer im Modus "Es funktioniert, also lasse ich es in Ruhe. Alle diese Ausnahmen in den Protokollen spielen keine Rolle" ist.

Es gibt zwei Kategorien für Programmierer für mich - Solo und Team.

Schlechte Solo-Programmierer sind

• Diejenigen, die zu lange gebraucht haben, um die einfache Aufgabe zu erledigen.
• Diejenigen, die nicht selbst recherchieren können, was sie tun.
• Diejenigen, die innerhalb weniger Tage vergessen werden, was heute codiert wurde, und ihre eigene Codebasis nicht gut pflegen können.
• Diejenigen, die sich nicht an die Anforderungen anpassen können, ändern sich.

Schlechte Team-Programmierer sind diejenigen, die in die Kategorie der schlechten Solo-Programmierer fallen, einschließlich

• Diejenigen, die sich nicht mit anderen Teammitgliedern abstimmen können.
• Diejenigen, die Kritik nicht begrüßen.
• Diejenigen, die nicht wissen, wie sie anderen nützlich sein und wie sie von anderen Teammitgliedern profitieren können.
• Diejenigen, die keinen lesbaren Code schreiben können.
• Diejenigen, die aus Gründen der Lesbarkeit für die anderen nicht kommentieren.

Nicht bereit zuzugeben, dass sie die Antwort nicht kennen und / oder nicht bereit sind, nachzuschlagen.

Wenn Sie es nicht wissen, geben Sie nicht auf - finden Sie es heraus und erledigen Sie es.

Meiner Erfahrung nach ist es ein großes Warnsignal, wenn sie ihre Hacks nicht kommentieren ...

Sie wissen, was ich meine: wenn Sie gezwungen sind, etwas sehr Hackiges zu tun, weil es einfach keinen besseren Weg gibt, es zu tun.

Gute Programmierer werden es hassen, dies tun zu müssen, und Inline-Kommentare einfügen, in denen steht, wie sehr sie es hassen, diese Art von Hack einzusetzen, aber es gibt keine andere Wahl. Schlechte Programmierer werden nur den Hack einbauen und ihn nicht kommentieren.

Ganz offensichtlich ruhig, wenn ein Programmierer VIEL Code schreibt. Sehr große Funktionen, z. B. das Kopieren / Einfügen von Zeilen oder Codeblöcken, bei weitem mehr, als erforderlich ist. Dies kann daran liegen, dass der Programmierer keine Standardfunktion kennt, mit der er das tun kann, was er will, dies jedoch in den meisten Fällen nicht.

Wiederholt den richtigen Weg gezeigt zu bekommen und es immer wieder einfach zu machen.

Ich verlagere meine Antwort hierher von einem geschlossenen Duplikat mit der Frage Können Sie erkennen, ob Sie ein schlechter Programmierer sind? Das andere Thema wurde geschlossen, als ich meine Antwort verfasste. Meine Antwort geht direkter auf die Frage ein, wie sie vom anderen Fragesteller formuliert wurde, und wird besser gelesen, wenn Sie das verstehen.

Seufzer! Ein Teil von mir wollte diesem bereits beschäftigten Thema nichts hinzufügen, aber der andere Teil von mir hat gewonnen! Warum hat es gewonnen? Warum mache ich mir die Mühe, diesem speziellen Multilog noch mehr Worte hinzuzufügen? Na ja, weil ich das bis zu einem gewissen Grad ein wenig anders einschätzen kann als die vielen vorherigen Kommentatoren.

Binär funktioniert hervorragend in Computern: Es ist "1" oder "0", "Ein" oder "Aus". Mit diesen beiden berühmten Staaten können wir viele Informationen abstrahieren und kodieren. Aber es funktioniert nicht so gut für menschliche Angelegenheiten: "gut" oder "schlecht", "gesund" oder "verrückt", "gut" oder "böse", "klug" oder "dumm", "fett" oder "dünn", "lebendig" oder "tot?" Diese Art von polarisierten Bewertungen hat den fürsorglichen Menschen, der ein Teil von mir ist, immer schrecklich unzufrieden gemacht. Unabhängig davon, welche Messschemata ich wähle, stelle ich normalerweise fest, dass die Antworten auf solche starken Kontraste tatsächlich irgendwo entlang eines Kontinuums zwischen einem solchen Pol und dem anderen liegen und nicht an beiden Enden.

Ich kämpfe schon seit geraumer Zeit mit dieser Tendenz zur Polarisierung und meine persönliche Lösung ist, dass ich es weitaus nützlicher finde, drei Wörter auf eine solche Bewertung anzuwenden: " bis zu welchem ​​Grad!"

Meine Antwort auf Ihre Frage lautet also, dass Sie sie umformulieren und sich folgende Frage stellen: "Inwieweit bin ich ein schlechter Programmierer?" Oder noch besser, um es in die andere Richtung zu fragen: "Inwiefern bin ich ein guter Programmierer?" Wenn Sie der Wahrheit nachjagen, werden Sie sich wahrscheinlich irgendwo zwischen einem "schlechten" Programmierer und einem "guten" befinden. Wenn Sie dann ungefähr gefunden haben, wo Sie sich auf diesem Weg befinden, können Sie wahrscheinlich einen Punkt identifizieren, der etwas näher am "guten" Ende liegt - ein Punkt, an dem Sie sich in naher Zukunft wiederfinden möchten.

Wenn Sie diesen Punkt nicht zu weit weg setzen, können Sie wahrscheinlich Ihr hinteres Ende einlegen und es in diese Richtung bewegen. Wenn Sie es schaffen, diesen eher einfachen heuristischen Algorithmus mehrmals zu wiederholen, sind Sie möglicherweise bald zu beschäftigt, um diese Frage erneut zu stellen! Oh, und Sie werden wahrscheinlich schneller vorankommen, wenn Sie anfangen, Code auf einer Tastatur so schnell und so oft wie möglich zu tippen. Und wenn Sie ab und zu eine kleine Pause einlegen, lesen Sie den hochwertigen Code, den Ihre Kollegen geschrieben haben! In diesen Tagen der dynamischen Open Source-Entwicklung mangelt es Ihnen nicht an kostenlosem und exquisitem Code, von dem Sie lernen können!

Daher empfehle ich Ihnen nachdrücklich, meine drei kleinen Wörter zu probieren, "bis zu welchem ​​Grad", und zu sehen, wie weit sie Sie in eine gute Richtung bringen können!

Jemand, der sagt "Das geht nicht".

Meiner Meinung nach dreht sich alles um das Lösen von Problemen. Das Tool sollte weitaus weniger relevant sein als die eigentliche Arbeit. Wenn ich es mit MS-Access oder Assembler lösen muss, ist es eine Frage von Zeit und Geld, nicht von "Es kann nicht gemacht werden".

Ein Warnzeichen ist zu sehr auf die akademische und "richtige" Arbeitsweise ausgerichtet und zu wenig auf die Erledigung der Arbeit.

Wenn er nur die Syntax einer Sprache kennt, aber die grundlegenden Konzepte von Algorithmen nicht kennt.

Wenn sie viel pontifizieren, aber sehr wenig produzieren.

! (klug und erledigt Dinge)

Diejenigen, die Prinzipien wie SOLID, DRY, OOP und so weiter nicht kennen. Es ist wichtig, die Prinzipien und Grundlagen der Programmierung zu verstehen, anstatt bestimmte Technologien zu kennen. Diejenigen mit solider Grundlage werden in der Lage sein, neue Themen leicht zu lernen und besseren Code zu produzieren.

Ein eingebetteter Programmierer, der Interrupts oder Multitasking nicht sehr gut versteht. Auch Programmierer, die mit Bitfeldern arbeiten müssen, aber keine logischen Operationen auf sie und Verschiebung begreifen.

Ein sofortiges Erkennungssignal ist jemand, der sagt: "Ich verstehe nicht, warum es nicht funktioniert. Ich habe alles richtig gemacht."

Eine Sache, die einen schlechten Programmierer von einem neuen Programmierer unterscheidet, ist das hartnäckige Bestehen darauf, sein Lieblingssystem in der Sprache und API zu implementieren, in der sie arbeiten.

Ich habe einmal ein System geerbt, auf dem der frühere Entwickler (in Java) einen großen Satz der Ashton Tate DBase III + -API reimplementiert hat, der über der benutzerdefinierten DBF-Zugriffsbibliothek liegt. Keines der Java-Collections-Frameworks wurde verwendet.

Auf diese Weise konnte er eine Java / Swing-App schreiben, die aussah und sich wie eine DBase III + -Anwendung (oder möglicherweise eine Clipper-Anwendung) verhielt.

Die Apps, die er in diesem System geschrieben hat, hatten Lite-Bar-Menüs und öffneten ein vollständiges Fenster mit einer Reihe von Schaltflächen am unteren Rand, wenn Sie mit der Lite-Bar zu der Option navigierten. Es war wie eine kleine Zeitmaschine in den 1980er Jahren.

Der Mann war eindeutig ein erfahrener Entwickler. Er wusste genug, dass er das ganze System im Zeitrahmen dieses Projekts selbst schreiben konnte. Er konnte es auch auf einigen anderen internen Systemen wiederverwenden.

Aber er war insofern ein schrecklicher Programmierer, als sein Code die Funktionen der Systeme missbrauchte, an denen er arbeitete. Er war eher bereit, 3 Monate für eine benutzerdefinierte Bibliothek mit zweifelhaftem Nutzen zu investieren, als Java / Swing / SQL zu lernen.