Eine Liste von Programmierern, die gut darin sind, leistungsabhängige Codes zu schreiben und nicht herumzudoktern - Seite 12

 
prostojparen >> :

Es tut mir leid, ich mache keinen großen Wirbel, ich bin gegen die unbegründete Auflistung. Sie haben eine Person gesucht und auf die Liste gesetzt, und Sie finden das in Ordnung. Ich habe geschrieben, dass man für Inklusion argumentieren muss, aber dies ist ein lauter Showdown. Das ist kein objektives Argument.

Ich denke, ein gutes Argument wäre die Anzahl der veröffentlichten Drehbücher. Ich denke, ein guter Programmierer würde zumindest etwas mitteilen.

 

Und was sind Ihre Erfolge (aus der obigen Liste) bei Weltmeisterschaften im Autohandel?

Ich meine in der Praxis, unter realen Bedingungen. Ich würde gerne wissen, mit wem Sie es zu tun haben?

Ich interessiere mich für Fachautoren und Theoretiker nur für Anfänger.

Ich bin an Anfängern interessiert, die sich von den schönen Bildern, die die Truthähne zeichnen, anlocken lassen können.

 

Nein, die Rentabilität von EAs ist definitiv kein Kriterium. Keine der "Mega-Legenden" in russischsprachigen Foren hat es jemals unter die ersten drei geschafft. Ich hoffe, niemand ist beleidigt, wenn ich versehentlich jemanden unterschätzt habe.

Außerdem waren die Bedingungen alles andere als real.

 
Mathemat писал(а) >>

Nein, die Rentabilität von EAs ist definitiv kein Kriterium.

Rentabilität allein ist definitiv kein Kriterium. Genauigkeit und Gründlichkeit des Codes im Detail - dies ist ein wichtigeres Kriterium, aber leider nur... ein anderer Programmierer :) Die Rentabilität liegt in der Idee, der EA liegt im Code. Es handelt sich um unterschiedliche Dinge.

Außerdem können die Programmierer gute Gründe dafür haben, ihre EAs nicht in Wettbewerbe zu schicken.

zfs schrieb >>

Ich denke, die Anzahl der veröffentlichten Drehbücher ist ein gutes Argument.

Die Quantität ist nicht die Qualität. Ich habe einige EAs mit erschreckenden Fehlern gesehen... mir ist die Kinnlade heruntergefallen.

Ich denke, das beste Kriterium ist immer noch das Feedback der Kunden. Der Kunde kann die folgenden Punkte selbst bewerten:

1. Wurde die Arbeit rechtzeitig erledigt?

War der Code mit Anmerkungen versehen und lesbar?

3. Wurden alle realisierbaren Wünsche des Kunden berücksichtigt?

4. Wenn Wünsche nicht erfüllt werden oder nicht realisierbar sind, konnte der Ausführende dem Kunden den Grund dafür verständlich erklären?

5. Hat der Darsteller dem Kunden geholfen, die Verwendung des bereitgestellten Ratgebers (Indikator, Skript ...) zu verstehen, begleitet von Abschiedsworten, Ratschlägen?

All das ist es, was der Kunde braucht.

 

"1. Wird die Arbeit rechtzeitig erledigt?" - wie viele Fälle, in denen es so aussieht, als ob sie übereinstimmt, und dann trägt der Kunde etwas anderes bei ... und die Frist verschiebt sich.

"2. Ist der Code kommentiert und lesbar? "Wenn der Kunde die Codierung nicht versteht, ist sie ihm egal.

Die Erörterung der ToR allein kann länger sein als die Kodierung. Es braucht Zeit, um zu begreifen, was er wirklich will. Manchmal muss man eine Zange benutzen.

"4. Wenn irgendwelche Wünsche nicht erfüllt oder nicht umgesetzt werden, war der Ausführende in der Lage, dem Kunden den Grund auf einer verständlichen Ebene zu erklären?" - und zu S.5. ist klar, dass jeder normale. proger erklärt (manchmal ist es notwendig zu erklären, so dass das Gehirn kocht)

Geben Sie ihm einfach eine Note von 0 bis 10 und machen Sie sich keine Gedanken darüber.

 

1. Es gibt Fälle, in denen die Frist aufgrund der Bedürfnisse des Kunden im gegenseitigen Einvernehmen verschoben wird. Aber darum geht es hier nicht, sondern um ein eklatantes Dynaema.

2. Vielleicht versteht er nichts von Codierung. Aber "auf die Fresse" - da bin ich nicht einverstanden. Erstens kann es ein vorübergehendes Phänomen sein - jetzt versteht er es nicht, dann wird er es verstehen. Zweitens kann der Code in Zukunft mehrmals aktualisiert werden und muss dafür geeignet sein. Ansonsten gibt es in meiner Abteilung ein paar Programmierer, die, wenn sie sich den Code ansehen, den sie vor einem halben Jahr geschrieben haben, erst einmal eine Woche lang aufschreien: "Heilige Scheiße, WAS habe ich da geschrieben?!

4. Ich bin selbst ein sehr erfahrener Programmierer, ich weiß. Ein guter Programmierer unterscheidet sich jedoch von einem schlechten darin, dass er auf dem Reifen erklären kann, was was ist. Ein schlechter hingegen hat nur ein Argument: "Man kann nicht, weil man nicht kann". Mit anderen Worten: Der Kunde sollte zufrieden (nicht verärgert) sein, auch wenn er nicht das bekommen hat, was er wollte. Damit meine ich natürlich nicht Fälle von Psychopathologie auf Seiten des Klienten - auch das kommt vor. Aber im Allgemeinen sind die Kunden vernünftige Menschen, und wenn man es ihnen richtig erklärt, werden sie es verstehen.

Was die Bewertung von 0 bis 10 betrifft - natürlich. Ich habe nur die Kriterien genannt, nach denen der Kunde die Arbeit des Programmierers bewerten kann.

 

Ich empfehle, eine Reihe von Regeln für die Kommunikation mit uns in die Liste der Programmierer aufzunehmen.


Der Programmierer sollte erklären, warum das so ist und nicht so.

Obwohl ich in meiner Praxis der Erstellung von Gutachten die Rentabilität oder Unrentabilität der Idee des Kunden nur durch das Lesen von TOR bewerte, wenn die Idee nicht kompliziert ist, wenn sie kompliziert ist, dann mache ich ein paar Prüfungen und sage auch das ungefähre Ergebnis. Wenn der Kunde über die Informationen nachgedacht hat und bereit ist, die Entwicklung in Auftrag zu geben, beginnen Sie, die Einzelheiten der TOR zu besprechen.


Oft kennen die Kunden nicht nur die Konzepte nicht, sondern können auch nicht zwischen einem Auftrag und einer Position unterscheiden. Und manchmal wird eine solche Terminologie verwendet, dass man die Wörter in Wörterbüchern nachschlagen muss.


Unsere Kunden drücken ihre Gedanken klar und verständlich aus und verwenden so wenig Umgangssprache wie möglich.


Ein Beispiel für Zeichenfolgen von TOR, die der Programmierer nicht versteht.


Dies ist ein Signal kam, so dass wir öffnen, zu stoppen und wo der Gewinn zu schließen ist, muss ich es selbst in Optionen einstellen. Alle haben den Markt betreten und warten ab. Wir müssen warten und warten, und dann muss der Experte das profitable Geschäft selbst abschließen.


Auf diese Weise wird keiner der Programmierer genau verstehen, nach welchen Regeln ein Geschäft zu eröffnen ist, was zu erwarten ist, wie man abschließt....

 
Dort könnte es sich als nützlich erweisen.
Dateien:
fxd.rar  633 kb
 
HIDDEN писал(а) >>

"Wenn ein Signal eintrifft, öffnen wir, stoppen und schließen den Gewinn, was ich selbst in den Einstellungen festlegen muss. Alle haben den Markt betreten und warten ab. Wir warten, wir warten, und dann schließt die Messe das profitable Geschäft von selbst ab.

Das ist genau die Art und Weise, wie keiner der Programmierer verstehen wird, nach welchen Regeln ein Geschäft zu eröffnen ist, worauf man warten muss, wie man abschließt....

Zu dieser Frage in meinem Profil der Link zu dem Buch in Ozone (Structure of Magic).

 
Shaitan писал(а) >>

4. Ich bin selbst Programmierer und habe eine solide Bilanz, ich weiß. Ein guter Programmierer unterscheidet sich jedoch von einem schlechten darin, dass er auf dem Reifen erklären kann, was was ist. Aber ein schlechter Programmierer hat nur ein Argument - "man kann nicht, weil man nicht kann". Mit anderen Worten: 1. Der Kunde sollte zufrieden (nicht verärgert) sein, auch wenn er nicht das bekommen hat, was er wollte. Natürlich beziehe ich mich nicht auf Fälle von Psychopathologie auf Seiten des Kunden, auch das kommt vor. Aber im Allgemeinen sind die Kunden vernünftige Menschen, und wenn man es ihnen richtig erklärt, werden sie es verstehen.

Was die Bewertung von 0 bis 10 betrifft - natürlich. Ich habe nur die Kriterien genannt, nach denen der Kunde die Arbeit des Programmierers bewerten kann.

Bei dieser Herangehensweise auf Seiten des Kunden müssen wir uns Gedanken darüber machen, wie wir sicherstellen können, dass auch der Programmierer zufrieden ist. Gewöhnlich besteht die Psychoanalyse zu 80 % aus Psychoanalyse und nur zu 20 % aus Programmierung und dem ständigen "was ist hier unklar"("ein einfacher Truthahn umsonst"). Anleitungen werden chronisch nicht gelesen.