Programmierer haben unterschiedliche Aussagen über schwierige Probleme. Wahrscheinlich meine Lieblingsoption : "In der Informatik gibt es zwei schwierige Probleme: Cache-Ungültigmachung, Benennung und Fehler pro Einheit."

Ich habe lange genug Software geschrieben, um mich jedem dieser Probleme zu stellen. Gleichzeitig spreche ich von der Seite des Geschäfts und erkläre den Kunden den technischen Teil unseres Produkts, weshalb ich ständig auf Nicht-Programmierer stoße. Das Wichtigste ist, die Idee oder das Konzept so richtig zu vermitteln, dass andere es verstehen.

Und das ist sehr schwierig.

Wie in allen Berufsfeldern haben Programmierer ihre eigene Fachsprache entwickelt, um Konzepte schnell zu übertragen.

Technolepet

Jargon ist sehr wichtig. Wenn mein Kollege und ich einen Algorithmus wählen , ein bestimmtes Problem zu lösen, können wir sagen , dass „die erste Option O(n^2)mit minimalem Aufwand von Anfang an , und die zweiter wird abgeschrieben O(n log n), aber mit teuerer Installation und Konfiguration . “

Dieser einzelne Satz sagt viel darüber aus, für welche Szenarien der Algorithmus verwendet werden sollte und wie sie unter der Haube implementiert werden:

Option A eignet sich hervorragend für ein System mit wenig Eingaben.
Option B eignet sich hervorragend für die Arbeit mit einer wirklich großen Menge von Eingabedaten, wobei die hohen Kosten für die Installation und Konfiguration des Systems durch eine bessere Leistung im Prozess ausgeglichen werden.
Wenn Sie den Algorithmus in einer Schleife verwenden möchten, sollten Sie die erste Option auswählen, um den teuren Installations- und Konfigurationscode zu vermeiden.
Vielleicht können wir die Kosten für die Installation von Option B mithilfe von Caching senken.
Wahrscheinlich wird in Option A jedes Element der Eingabedaten mit allen anderen verglichen (zum Beispiel for x in inputs { for y in inputs { if some_condition(x, y) { ... }}}).
Wahrscheinlich erstellt Option B zuerst einen Baum und führt dann eine lineare Suche durch, gefolgt von einer Suche in diesem Baum.

Wie Sie sehen, konnten wir mehrere Absätze mit Informationen in einem Satz übermitteln, indem wir einfach die richtigen Begriffe verwendeten.

In diesem Fall meinte ich Algorithmen zum Erkennen von Kollisionen, dh Schnittpunkten zwischen zwei oder mehr Objekten. Der erste prüft alle möglichen Kombinationen von Eingabedaten, während der zweite einen Quadrantenbaum oder eine binäre Raumpartition verwendet , um nur geschlossene Elemente zu prüfen.

Wenn Sie jedoch ein Treffen mit Personen außerhalb der Programmierwelt haben (z. B. Maschinenbau- oder Elektrotechniker, Manager, Vermarkter), wird dieser Fachjargon nur Personen beleidigen und verwirren, ohne fast wertvolle Informationen zu übermitteln.

Das nenne ich technoleth, das Murmeln eines Programmierers.

Ehrlich gesagt werden diese Details und Begriffe normalerweise von Menschen aus anderen Bereichen nicht benötigt, und es ist ihnen wirklich egal.

Zum Beispiel erklären Sie eine erstaunliche neue Funktion, die den kürzesten Weg von A nach B findet, ein Navigationsraster generiert und die A * -Suche anwendet .

In keinem Fall müssen Sie die neue Funktion wie im vorherigen Satz beschreiben. Sagen Sie stattdessen so etwas:"Wir berechnen eine Reihe möglicher Pfade und wenden dann die intelligenten Algorithmen an, die in der Spielebranche verwendet werden, um die beste Route zu finden . "

Es spielt keine Rolle, dass wir hier die A * -Suche verwenden (im Gegensatz zum Dijkstra-Algorithmus oder der Breitensuche). Es spielt keine Rolle, dass in Spielen die A * -Suche nicht nur zum Bewegen von Charakteren verwendet wird. Für den Gesprächspartner ist es ausreichend zu wissen, dass Sie einen guten Weg von A nach B finden können und dass wir zuverlässige Werkzeuge verwenden, die bereits in anderen Bereichen getestet wurden.

Es tut nicht weh, die Illustration dessen zu zeigen, was Sie meinen ...

Ich habe zufällig beobachtet, wie erfahrene Programmierer Tech-Jargon verwenden, um Überlegenheit zu demonstrieren, ihre unglaubliche Intelligenz zu zeigen und Dominanz zu etablieren. Das ist wirklich nervig.

Verstehen Sie es nicht falsch, manchmal gibt es Situationen, in denen ein ausreichend kompetenter Gesprächspartner fragt: "Das ist sehr schwierig, warum nicht einfach X machen?" - und Sie müssen zeigen, dass Sie hier ein Experte sind, aber er weiß nicht, wovon er spricht ... aber Sie können es trotzdem auf verschiedene Arten tun.

Versuchen Sie nicht, technolepet zu verwenden, um Ihr Ego zu befriedigen, es verbannt Menschen und entehrt unseren Beruf.

Respekt

Also gehen wir allmählich zum nächsten Punkt über ... vergessen Sie nicht den Respekt.

Viele Leute, mit denen ich zusammenarbeite, sind wirklich klug und Experten auf ihrem Gebiet, aber sie haben nicht unbedingt genug Wissen und Erfahrung bei der Erstellung von Informationssystemen.

Bei der Erklärung eines komplexen Problems ist es oft besser, Konzepte zu vereinfachen. Aber versuche nicht herablassend zu sein.

Der Softwareentwickler, über den ich gesprochen habe, antwortete oft: "Es ist ... kompliziert", wenn eine "normale" Person fragte, wie diese oder jene Funktion funktioniert. Es ist, als ob der Code so ausgefeilt ist, dass Sie ihn ohne 20 Jahre Programmiererfahrung nicht verstehen können.

Nicht so.

Die beste Antwort:"Wenn Sie die Dinge ein wenig vereinfachen, dann machen wir zuerst X, dann Y und schließlich Z, aber Sie müssen ein Dutzend Grenzsituationen im Auge behalten (vielleicht eine oder zwei erklären), aber das Wesentliche ist dies . " Ihre Kollegen sind schlau und ohne Techno-Jargon durchaus in der Lage, Sie zu verstehen.

Ein weiterer wirklich nützlicher Trick besteht darin, einen Nicht-Programmierer als Deck zu verwenden, wie eine Gummiente. Wenn Sie an einem komplexen Problem arbeiten, erklären Sie ihm in einfachen Worten Ihre Lösung und fragen Sie, ob Sie eine bessere Option finden können.

Unser Unternehmen arbeitet auf dem Gebiet der CNC, das heißt, es hat etwas mit der realen Welt zu tun (zum Beispiel, wenn Sie versuchen, eine Kompensation für die Breite des Schnitts zu implementieren ). Ingenieure sind wirklich gut darin, Probleme in Bezug auf Physik und Geometrie zu analysieren.

Personifizierung, Übertreibung und Analogie

Menschen sind soziale Wesen. Wir sind darauf programmiert, Beziehungen zu verstehen und Analogien zu lieben, um neue Konzepte mit bestehenden in Beziehung zu setzen. Wenn Sie mit jemandem sprechen, können Sie diese Tricks verwenden, um komplexe Themen zu verstehen.

Angenommen, Ihr Unternehmen verfügt über ein Online-Beschaffungssystem. Der Vermarkter möchte die gesamte Kette von der Online-Bestellung bis zur Zustellung des Pakets verstehen, um Kundenfragen besser beantworten zu können. Ich könnte so etwas sagen:

, . www.example.com, «» ( -, ).

(-). , () . , , , (, ).

( ), , . , , ( — , ), .

( ) . , , .

All dies klingt ein bisschen komisch, und das Beispiel ist mehr als weit hergeholt, aber ich kann garantieren, dass dies eine verständlichere Erklärung ist als ein großes Netzwerkdiagramm mit den Begriffen „Webserver“, „Ereignisarchitektur“ und „Apache Kafka“ (siehe Abschnitt über Technologie) )

Ein anderes Beispiel. Wenn Sie versuchen, einem Außenstehenden zu erklären, wie der Pfad-Suchalgorithmus funktioniert, sagen Sie nicht, dass "besuchte Pfade mehr Gewicht erhalten", sondern dass "der Algorithmus wirklich nicht den Pfaden folgen möchte, auf denen er bereits gelaufen ist".

Dies ist ein subtiler Unterschied, aber wir machen die Personifizierung des Algorithmus. Wir sagen, dass er "wirklich X machen will" oder "sehr bemüht ist, Y zu vermeiden". Oft hilft dies den Menschen nur zu verstehen .

Nützliche Analogien mit Beispielen (falls zutreffend). Sie haben wahrscheinlich bereits bemerkt, dass dieser Artikel voller Beispiele ist. Anstelle einer abstrakten Erklärung erzähle ich bestimmte Geschichten, die zur Erklärung der These beitragen. Dies ist kein Unfall.

Zeichne schöne Bilder

Es klingt kitschig, aber manchmal sagt ein Bild wirklich mehr als tausend Worte.

Vor ein paar Monaten las ich einen Kurs im Radio und das Mädchen in der Nähe konnte sich nicht erinnern, welche Tasten auf der Speisekarte dieses kleinen 16 × 2-LCD gedrückt werden sollten.

Ich fragte, ob sie ein Diagramm zeichnen könne.

Sie hielt mich für einen klugen Kerl und spottete über sie.

Aber ich habe nicht gescherzt.

Stattdessen habe ich ein Stück Papier gefunden und zusammen haben wir so etwas gemacht:

Der Programmierer erkennt das Zustandsdiagramm sofort aus der Theorie der Automaten. Unbekannt für ein Mädchen führte ich die grundlegende Informatik-Technik in ihr Gehirn ein und wie die Schnittstelle dieses Radios unter der Haube programmiert wird.

Aber sie (und alle anderen in dieser Phase) kümmert sich nicht um die Wissenschaft. Sie haben eine Karte, mit der sie in der Benutzeroberfläche navigieren können.

Es ist eine seltsame Freude, ein komplexes Konzept für jemanden aus einem anderen Bereich anzupassen. Besonders wenn sie feststellen können, dass die Karte wirklich ein Fehler ist: Sie müssen die Abbrechen-Taste gedrückt halten, um in den Ruhezustand zurückzukehren, da Sie durch Drücken dieser Taste normalerweise zum "Hauptmenü" zurückkehren.

Ich habe immer ein großes Notizbuch mit leeren Blättern auf meinem Schreibtisch. Normalerweise schreibe ich während der Reflexion eine Aufgabenliste oder einige Zeichnungen auf, aber oft hilft es beim Erklären. Die Möglichkeit, während eines Gesprächs etwas zu zeichnen, hilft dabei, den Kurs zu überprüfen und sicherzustellen, dass Sie sich auf derselben Wellenlänge (Wortspiel beabsichtigt) befinden, auf der Sie dieselbe Idee haben.

Ich habe $ FEATURE verzehnfacht

Angenommen, Sie haben einige Leistungsanpassungen vorgenommen, und jetzt funktioniert ein bestimmter Code viel schneller. Wie kann man dies einem Nicht-Programmierer oder jemandem erklären, der den Quellcode nicht sieht?

Einerseits können Sie der Frage, was Sie letzte Woche getan haben, die Wahrheit sagen: "Ich habe Caching hinzugefügt, lookup_something ()um die allgemeine Suche zu beschleunigen und den Algorithmus von detect_collisions()c O(n^2)nach zu übersetzen O(n log n)" , aber mit hoher Wahrscheinlichkeit verstehen sie nichts (siehe Technolept ). .

Sie können auch sagen, dass Sie die Produktivität optimiert haben , aber das klingt nach einer Ausrede, und der Manager wird darüber nachdenken, warum er Sie eingestellt hat.

Oft sagen Entwickler: "Ich habe $ FEATURE verzehnfacht."(oder eine andere beliebige Anzahl) und dies ist begrenzt. Solch ein Satz erlaubt es Ihnen, eine Reihe von Glückwünschen der Stadtbewohner zu genießen, aber oft ist es ein wenig ... irreführend.

In den meisten Fällen haben Sie die Leistung mehrerer Funktionen tatsächlich verbessert. Wenn diese Funktionen jedoch keinen Leistungsengpass darstellen, wird mit hoher Wahrscheinlichkeit niemand einen Unterschied feststellen.

Hinweis. Wenn Sie mit dem Amdahlschen Gesetz vertraut sind, bedeutet das Erhöhen der Leistung einer Funktion, die kein Engpass ist, das Verwenden von mehr CPU-Kernen für eine Aufgabe, die im Wesentlichen konsistent ist.

Es stellt sich auch die Frage: Was haben Sie getan, um die Produktivität zu verzehnfachen? Ist dies eine überraschend spezifische Zahl, hat Ihr Quellcode eine Arbeit mehrmals wiederholt? Oder hat er Daten (z. B. von Hardware oder einer Website eines Drittanbieters) zehnmal langsamer angefordert, als es sollte? Selbst dies lässt mich an Ihren Fähigkeiten zweifeln, weil Sie entweder die anfängliche Abfragegeschwindigkeit (schlecht) erraten haben oder immer noch die Leistung opfern, indem Sie Abfragen anstelle einer effizienteren Ereignisarchitektur verwenden.

Es scheint mir, dass es besser ist, einen Mittelweg zwischen Genauigkeit und Verständlichkeit zu finden. Wenn Sie eine Änderung vorgenommen haben, die die algorithmische Komplexität eines Codefragments verbessert (z. B. eine Funktion, detect_collisions()von der O(n^2)auf umgeschaltet wurde O(n log n)), können Sie Folgendes sagen:"Funktion X kann jetzt in angemessener Zeit auf eine große Menge an Eingaben skaliert werden, konnte dies aber vorher nicht . "

Es ist normal zu sagen "Ich weiß nicht" ...

... und so weiter: "... aber wenn du mir fünf Minuten gibst, kann ich es dir sagen" .

Ich sehe das oft. Die Menschen haben Angst, ihre Unwissenheit zu zeigen, deshalb schweigen sie, quälen oder erfinden etwas.

Wenn beispielsweise ein Manager zu Ihnen kommt und fragt: „Der Client hat nach Funktion X gefragt, ist dies möglich? Und wie lange wird es dauern? "

In neun von zehn Fällen lautet die ehrliche Antwort "Ich weiß nicht", aber es hilft dem Manager nicht wirklich, das Timing zu bestimmen. Er hat sich an Sie gewandt, weil Sie ein Experte auf dem betreffenden Gebiet sind und am besten bereit sind, eine Antwort zu geben.

Einige versuchen zu raten oder zu betrügen (zum Beispiel "Ja, wir machen das in zwei bis drei Wochen").), aber dieser Ansatz funktioniert normalerweise auf lange Sicht nicht. Im besten Fall verzögern Sie sich um einige Wochen und im schlimmsten Fall arbeiten Sie monatelang, um herauszufinden, dass diese Funktion mit der aktuellen Anwendungsarchitektur nicht funktioniert.

Dies ist eine großartige Möglichkeit, den Respekt von Kollegen und Vorgesetzten zu verlieren.

Auf der anderen Seite zeigen die Worte "Nicht sicher, aber geben Sie 5-10 Minuten, und ich werde eine Antwort haben" mehrere Dinge gleichzeitig:

Sie sind bereit zuzugeben, dass Sie nicht alles wissen (dh kein narzisstischer Egoist).
Sie sind für Ihre Worte verantwortlich und möchten keine ungenaue Antwort geben.
Sie respektieren die Person genug, um einen Teil Ihrer Zeit damit zu verbringen, ihre Frage zu beantworten.
Du bist ein guter Junge :).

(Und Sie haben genug Zeit, um es herauszufinden).

Es ähnelt einem alten Gleichnis :

Andere Leute erwarten (normalerweise) nicht, dass Sie alles auf ihrem Gebiet wissen. Stattdessen erwarten sie, dass Sie über Tools verfügen, mit denen Sie die Frage recherchieren und die Antwort in Begriffe übersetzen können, die sie verstehen können.

Der alte Ingenieur ging in den Ruhestand und nach einigen Wochen brach die Big Machine zusammen, was für das Einkommen des Unternehmens sehr wichtig ist. Der Manager konnte die Maschine nicht wieder zum Laufen bringen, daher lud das Unternehmen den alten Ingenieur als unabhängigen Berater ein.

Er hat zugestimmt. Als er in der Fabrik ankam, schaute er auf die große Maschine, nahm einen Vorschlaghammer und schlug ihn einmal. Danach fing das Auto an zu arbeiten. Der alte Ingenieur ging und die Firma begann wieder Geld zu verdienen.

Am nächsten Tag erhält der Manager vom alten Ingenieur eine Rechnung über 5.000 USD. Der Manager ist wütend und weigert sich zu zahlen. Der alte Ingenieur versichert, dass dies ein fairer Preis ist. Der Manager erwidert, wenn dies ein fairer Preis ist, können Sie Details zum Konto anfordern.

Ein neues, detailliertes Konto sieht folgendermaßen aus ...

Hammer: 5 US-Dollar

Wissen Sie, wo das Auto mit einem Hammer getroffen hat: 4995 US-Dollar

Jeder kann jede Frage googeln. Aber nur ein Softwareentwickler weiß, welche Schlüsselwörter zu verwenden sind und wie die Ergebnisse zu interpretieren sind.

Ergebnisse

Normalerweise veröffentliche ich in meinem Blog rein technische Artikel mit tonnenweise Code, aber manchmal ist es nützlich, sich daran zu erinnern, dass es auf dieser Welt neben Code noch etwas anderes gibt.

Programmierer (nicht ohne Grund) werden als Menschen mit schwachen sozialen und kommunikativen Fähigkeiten wahrgenommen. Ein wesentlicher Teil unserer Arbeit erfordert jedoch eine effektive Kommunikation. Ich hoffe, meine Erfahrung wird Ihnen bei etwas helfen.

Einige mögen dies als „Büropolitik“ und als Manipulation der Meinungen anderer betrachten. Folgendes werde ich beantworten:

Nun ja. Aber gilt dies nicht für die meisten zwischenmenschlichen Interaktionen?

Die Psychologie hilft Programmierern einfach, mit Nicht-Programmierern dieselbe Sprache zu sprechen und zusammenzuarbeiten, um ein gemeinsames Ziel zu erreichen.

Reden ist schwer. Essays zur Kommunikation mit Nicht-Programmierern