it-swarm-eu.dev

Wann würde jemand als schlechter Programmierer angesehen werden?

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?

57
Tamara Wijsman

Wenn sie nicht aus ihren Fehlern und aus 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.

134
ist_lion

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

125
Graviton

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 so) "Magie"). Toller Beitrag von Eric Lippert hier .

Aus dem Artikel:

programmierer, die verstehen, was der Code tut, aber nicht, wie er es tut.
75
Marcel Lamothe

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

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

45
JohnFx

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

21
EpsilonVector

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


Nachtrag: (Hinzufügen des Strichs unten in den Kommentaren)

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

21
missingfaktor

Wenn ein Teammitglied der negativ produzierende Entwickler ist .

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

Das bedeutet, dass der Rest Ihres Teams wegen des schlechten Entwicklers mehr Arbeit leisten muss. [~ # ~] nnpp [~ # ~]

18
danivovich

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

18
Billy ONeal

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

15
JeffO

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

15
Daenyth

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

15
Reigel

Als ich ein Teamleiter in einem kleinen Geschäft war, gab es einige Leute, die ich neu zuweisen musste (weder ich noch mein direkter Vorgesetzter hatten Kündigungsmöglichkeiten ohne eine Tonne von Bürokratie und einen Stapel Unterlagen.) oder keine Vertragsverlängerung am Ende des aktuellen Auftrags zu haben. Einige der aufgezählten Typen arbeiteten auch für andere Teamleiter, und sie vertraten fast die gleiche Ansicht. Dinge, die Leute in die Kategorie "Bad Programmer" in meinem Buch aufgenommen haben:

  1. In der Vergangenheit nicht trainierbar oder verknöchert
    Wenn der "Programmierer" nicht in der Lage zu sein scheint, das neue System, das neue Tool oder was auch immer eingesetzt wird, zu absorbieren, unabhängig davon, wie die Schulung/Ausbildung durchgeführt wird. Muss das Training häufig 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, warum sollten sie sich also ändern?
  2. Cowboy-Codierer
    Die Person, die zuerst ohne Plan codiert. Der 'Programmierer', der ungetestete Änderungen am Produktionscode und/oder an den Daten vornimmt, "weil wir ihn jetzt reparieren müssen", ist dann überrascht, wenn der "Fix" fehlschlägt.
    Der Cowboy ist definitiv auch kein Teamplayer. Braucht kein stinkendes Team.
  3. Die Wetterfahne
    Dieser 'Programmierer' ist verliebt in die "Technologie du jour " und sieht jedes neue Framework, jede neue Sprache, Methodik oder was auch immer neu und neu ist heiß als
  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 nicht viel Sinn machen. z. B. Umschreiben einer Standardbibliothek "weil sie für unser System ineffizient ist" oder Einführen von Tools und Techniken, die für das jeweilige Problem nicht geeignet sind. z. B. Einführung von LISP oder Forth in eine Mainframe-Umgebung.
  5. LOC ein. Sandbagger
    Dieser 'Programmierer' verwendet Verschleierung und Fehlleitung, um die zu erhöhen ein. LOC: Codezeilen , für die bezahlt wird. Ich habe in dieser Situation Code gesehen, der Seite für Seite, Bildschirm für Bildschirm von doppelter Struktur und Logik war, wobei nur die Namen der Absätze oder Steuervariablen geändert wurden, um die Zeilenanzahl zu erhöhen.
  6. Unverzichtbarer Experte
    Der 'Programmierer', der über das Fachwissen verfügt, um die vorliegenden Probleme zu lösen, aber da er alles darüber "weiß". In der Tat würde die gesamte Organisation zusammenbrechen, wenn sie von einem Bus angefahren würden. { Beobachtung: Diejenigen, die sich für unverzichtbar halten, sind es normalerweise. (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 zu verfolgen sind. z. B. IndexI1O0, Index1I0O usw.
  8. Sommerpraktikant - Speziell Subtyp Walking Disaster
    In meinem alten Laden wurden einige Praktikanten im späten Highschool- oder College-Alter eingestellt. Einmal brauchte 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 Verlängerung um eine Woche, dann eine zweite Woche. Am Ende der zweiten Woche wurde ich ausgesandt, um sein Projekt zu übernehmen und es zur Fertigstellung wieder in die Systementwicklung zu bringen. Er zeigte mir das, was er getan hatte, und dann den unvollendeten Teil. Was funktionierte hatte schöne Augenweide, aber die Anwendung war unvollständig. Als ich die neue Schachtel mit 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.
    Als verdächtiger Typ und als ich feststellte, dass seine Bewerbung fast nichts anderes als eine Augenweide war, ging ich zurück in die Abteilung, holte Norton heraus und löschte die Dateien, die er gelöscht hatte, und versuchte es Finden Sie eine zusätzliche Logik, auch wenn diese unvollständig ist.
    Ich fand keine schlechte Logik, aber schlechtes Benehmen. Der an den von ihm verwendeten PC angeschlossene Drucker war ein Raddrucker. Der normalerweise montierte Zeichensatz war eine Schweizer Variante. Die Ausgabe der gelöschten Programme enthält einen Namen, eine Adresse, ein Geburtsdatum, einige Buchstabencodes und eine Art von ID-Nummer. Das Format und Layout hat mich gestört. Alle Geburtsdaten für mehrere Personen waren kaum legal. Die meisten Adressen waren nicht da, als ich sie in unserem Kreuzverzeichnis nachgeschlagen habe. Als ich seinem Vorgesetzten die Ausdrucke zeigte, sah er mich an und sagte: "Führerscheine, finden Sie nicht?" Ich sagte, ich hätte es getan. Er sagte, deshalb habe er den Transparenzbestand im Müll neben dem Xerox gefunden. Unser böser Junge hatte Überlagerungen gemacht, um sein und das Alter seiner Freunde an ihren Führerscheinen anzupassen. Wir haben es den Behörden gemeldet. Er wurde nicht für seine letzten zwei Wochen bezahlt.

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

/ s/BezantSoft

14
BezantSoft

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

10
Chinmay Kanchi

Kann sich nicht an kommende Technologien anpassen

10
Gopi

Wenn sonst niemand seinen Code lesen kann. Es spielt keine Rolle, wie hell Sie sind; Kein Programmierer ist eine Insel.

10
stevenvh

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

Schlechte Soloprogrammierer sind

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

Schlechte Teamprogrammierer sind diejenigen, die in die Kategorie der schlechten Soloprogrammierer 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 können 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 keine Kommentare abgeben.
7
tia

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

7
talonx

Ein großes Warnsignal in meiner Erfahrung ist, 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, dies zu tun.

Gute Programmierer werden es hassen, dies tun zu müssen, und Inline-Kommentare abgeben, in denen angegeben wird, wie sehr sie es hassen, diese Art von Hack durchzuführen, aber es gibt keine Wahl. Schlechte Programmierer setzen einfach den Hack ein und kommentieren ihn nicht.

4
Bobby Tables

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.

4

Es wird wiederholt gezeigt, wie rechts es gemacht wird, und es wird immer wieder einfach gemacht.

3
DaveDev

Offensichtlich ruhig, wenn ein Programmierer VIEL Code schreibt. Sehr große Funktionen, z. B. Kopieren/Einfügen von Zeilen oder Codeblöcken, Verwendung von viel mehr als erforderlich usw. Dies kann daran liegen, dass der Programmierer keine Standardfunktion kennt, um das zu tun, was er will, aber meistens nicht.

3
user2528

Ich verschiebe meine Antwort von einem geschlossenen doppelten Thema hierher, in dem gefragt wurde Können Sie erkennen, ob Sie ein schlechter Programmierer sind ? Das andere Thema wurde geschlossen, als ich meine Antwort verfasste. Meine Antwort bezieht sich direkter auf die Frage, wie sie vom anderen Fragesteller formuliert wurde, und wird besser gelesen, wenn Sie das verstehen.

Seufzer! Ein Teil von mir wollte dieses bereits beschäftigte Thema nicht ergänzen, aber der andere Teil von mir hat gewonnen! Warum hat es gewonnen? Warum mache ich mir die Mühe, diesem speziellen Multilog noch mehr Wörter hinzuzufügen? Nun, weil ich dies bis zu einem gewissen Grad vielleicht etwas anders sehe 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 Teil von mir ist, immer furchtbar unzufrieden gemacht. Unabhängig davon, für welche Messschemata ich mich entscheide, finde ich normalerweise, dass die Antworten auf solch starke Kontraste tatsächlich irgendwo entlang eines Kontinuums zwischen einem solchen Pol und dem anderen liegen, nicht an beiden Enden.

Ich habe seit einiger Zeit mit dieser Tendenz zur Polarisierung gekämpft, und meine persönliche Lösung besteht darin, 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 Folgendes fragen: "Inwieweit bin ich ein schlechter Programmierer?" Oder noch besser, um es in die andere Richtung zu fragen: "Inwieweit bin ich ein guter Programmierer?" Wenn Sie der Wahrheit nachgehen, werden Sie sich wahrscheinlich irgendwo entlang eines Kontinuums zwischen einem "schlechten" und einem "guten" Programmierer befinden. Sobald Sie es geschafft haben, ungefähr zu finden, wo Sie sich auf diesem Weg befinden, können Sie wahrscheinlich einen Punkt identifizieren, der etwas näher am "guten" Ende liegt - einen Punkt, an dem Sie sich in naher Zukunft befinden möchten.

Wenn Sie diesen Punkt nicht zu weit weg setzen, können Sie wahrscheinlich Ihr hinteres Ende in Gang setzen und es in diese Richtung bewegen. Wenn Sie es schaffen, diesen ziemlich einfachen heuristischen Algorithmus mehrmals zu wiederholen, sind Sie möglicherweise bald zu beschäftigt mit der Programmierung, um diese Frage erneut stellen zu müssen! Oh, und Sie werden wahrscheinlich schneller Fortschritte machen, wenn Sie so schnell und so oft wie möglich Code auf einer Tastatur drücken. und wenn Sie ab und zu eine kleine Pause machen, lesen Sie einen 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!

Ich empfehle Ihnen daher dringend, meine drei kleinen Worte "bis zu welchem ​​Grad" auszuprobieren und zu sehen, wie weit sie Sie in eine gute Richtung bringen können!

3
John Tobler

Diejenigen, die Prinzipien wie SOLID, DRY, OOP usw.) nicht kennen. Es ist wichtig, ein gutes Verständnis der Programmierprinzipien und -grundlagen zu haben, anstatt bestimmte Technologien zu kennen. Diejenigen mit soliden Grundlagen werden es sein in der Lage, neue Themen leicht zu lernen und wird besseren Code produzieren.

2
Giorgi

Eine Sache, die einen schlechten Programmierer von einem unerfahrenen 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 vorherige Entwickler (in Java) einen großen Satz der Ashton Tate DBase III + -API erneut implementiert hat, der über der benutzerdefinierten DBF-Zugriffsbibliothek liegt. Keines der Java Sammlungen Framework wurde verwendet.

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

Die Apps, die er in diesem System geschrieben hat, hatten Lite-Bar-Menüs und öffneten ein vollständiges Fensterformular mit einer Reihe von Schaltflächen unten, wenn Sie mit der Lite-Bar zur Option navigierten. Es war wie eine kleine Zeitmaschine bis in die 1980er Jahre.

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

Aber er war ein schrecklicher Programmierer, da sein Code die Funktionen der Systeme, an denen er arbeitete, missbrauchte. Er war eher bereit, drei Monate mit einer benutzerdefinierten Bibliothek von zweifelhaftem Nutzen zu verbringen, als Java/Swing/SQL zu lernen.

2
sal

Jemand, der sagt "Es geht nicht".

Meiner Meinung nach dreht sich alles um das Lösen von Problemen. Das Tool sollte weit 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 eine Frage von "Es kann nicht gemacht werden".

Ein Warnzeichen ist zu viel Fokus auf die akademische und "richtige" Art, Dinge zu tun, und nicht genug Fokus darauf, Arbeit zu erledigen.

2
Dan Williams

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

2
Chankey Pathak

Wenn sie viel päpstlich machen, aber sehr wenig produzieren.

2
Gratzy

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

2
tcrosley

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

2
Robert Rossney

! (klug und erledigt Dinge)

2
Nick Pierpoint

Heutzutage glauben viele Programmierer, dass diese Komplexität am besten mit nur wenigen gut verstandenen Techniken in ihren Programmen bewältigt werden kann. Sie haben strenge Regeln für die Form festgelegt, die Programme haben sollten, und die eifrigeren unter ihnen werden diejenigen, die diese Regeln brechen, als schlechte Programmierer denunzieren

1
Pir Abdul

Ein Programmierer, der nur Code von anderen Stellen kopiert und einfügt und nicht versteht, wie der Code tatsächlich funktioniert, wird als schlechter Programmierer bezeichnet! Ich sehe das normalerweise mit Javascript.

1
Pir Abdul

Ich denke, ein Programmierer kann nur schlecht programmieren, wenn er nicht mehr auf das hört, was andere zu sagen haben.

Bei der Programmierung geht es um Informationen. Man muss die Ohren und die Augen weit offen halten.

Ein Programmierer kann sich nur verbessern, wenn er die Bücher schlägt und hart arbeitet. Sie sollten sich aber auch darauf konzentrieren, neue Dinge zu lernen und nicht immer wieder dasselbe zu lernen (suchen Sie nach neuen Erfahrungen in Ihrem speziellen Bereich/Ihrer Branche).

Viel Glück.

0
Pablo